GhostManager / Ghostwriter

The SpecterOps project management and reporting engine
https://ghostwriter.wiki
BSD 3-Clause "New" or "Revised" License
1.33k stars 182 forks source link

Add a jinja split filter #532

Open mynoc96 opened 1 week ago

mynoc96 commented 1 week ago

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

chrismaddalena commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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?