Open mynoc96 opened 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.
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.
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.
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?
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