Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a jinja split filter #532

Open
mynoc96 opened this issue Sep 30, 2024 · 4 comments
Open

Add a jinja split filter #532

mynoc96 opened this issue Sep 30, 2024 · 4 comments

Comments

@mynoc96
Copy link

mynoc96 commented Sep 30, 2024

Is your feature request related to a problem? Please describe.

Was going to try to repurpose the notes field in the project to allow for report versions. I almost had it working, but there wasn't an intuitive way to parse a field_rt to a list of strings, like if field_rt|strip_html|split|get_item(0)|lower == "revision". It enables kind of hack-ish use cases, but that can be good. :-)

Describe the solution you'd like

I'd like a split filter that breaks a string with line breaks into a list of strings. That would be consistent with having the get_item filter.

Describe alternatives you've considered

None

Additional context

None

@mynoc96 mynoc96 changed the title Add a jinja split function Add a jinja split filter Sep 30, 2024
@chrismaddalena
Copy link
Collaborator

The *_rt suffix denotes a RichText object. These objects are like small Word documents made up of Open XML. If you want to parse the notes, try using the raw note value instead of note_rt. The raw value is HTML, so you'll still want to use strip_html, but then you can split the resulting string.

A better way to accomplish what you're after is a custom field. You can add a field like this to your reports. Assuming your report version is a number, you can use the integer type so the input is limited to a whole number or use the number type to allow decimals.

image

@mynoc96
Copy link
Author

mynoc96 commented Oct 1, 2024

Totally get the _rt extension. I was using it in the example because I was trying to split a multiline string, which would be _rt as there is no multiline plaintext string in ghostwriter tables (I don't think). The use case (which I just updated in the feature request) was to provide a way for users to use extra fields or existing fields like notes as tuples or lists by using a split filter. That way, fields like project notes could be sliced any which way to create lists or lists of lists in user-defined formats without impacting other functionality or providing arbitrary code execution.

A split filter would make it easier to convert text strings into structures that could be tabulated and have fields extracted using for loops.

In the revision case:

revision:1.0:9/22/2024:We did great things!

when parsed as field_name|strip_html|split(":")|get_item(3) would return We did great things!.

I didn't see split anywhere (including the code). The revision case is just one place I could see that functionality being useful.

@mynoc96
Copy link
Author

mynoc96 commented Oct 1, 2024

As I think the issue through, maybe a better way to implement such a feature would be to allow extra fields of type "list of strings", with a UI element that allows addition and deletion of substrings, or even more abstractly, a list of extra_string-ish types where the UI element adds or deletes a (type, data) tuple. I realize this is going pretty far afield, which is why I requested implementing a split filter.

@chrismaddalena
Copy link
Collaborator

You can use Python's split with Jinja2. It's not a filter, so it looks a little different. If you had a revision string field, you might do something like this:

{{ extra_fields.revision.split(“:”)[3] }}

That would return We did great things! from your example. Is that what you're looking for?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants