Open mynoc96 opened 1 month 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?
This issue has been labeled as stale
because it has been open for 30 days with no activity.
Before we consider closing this, did the above example address what you're after?
This works. Thanks!
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