This question was prompted while collating a list of Feature Requests for add-on custom filter Rules in MantisBT. The long-term goal being productive exercises of trying to create the rules in SuperTool … while also clearing some outstanding requests. And to use the experience to improve the wiki on filters and a writing rules workflow. (Particularly, using SuperTool, FilterParams, & the Query Gramplet in concert. With an eye towards a workflow on optimizing & converting a privately created rule into a public add-on.)
I was wondering if the XML formats included chunks to make the file more failsafe?
Specifically:
Since reports in Books.xml tend to reference custom filters, does the format embed a trimmed copy of the custom_filters.xml as a failback?
I don’t have any filter named 2 so I think it’s a kind of index but an index in what list?
When I open another book with filters on Places (image bellow), I can see filters used aren’t those needed for that book dedicated to a specific place. So if it’s an index it doesn’t match filters when filter lists change.
books.xml saves the report options for each report. In the report options filters are stored as enumerated lists (index, filter_name). In books.xml only the value of a filter is saved and not its name. The number 2 means the filter is 2nd or 3rd item in the filter list (depending if the first filter/item starts with 0 or 1) used in the SourcesCitationsReport.
The ability to do Add-on Rules is relatively new. It introduces a new way that stored files can fail and where Gramps needs to handle the failure gracefully.
I can think of 2 specific ways that Custom Rules can decay. Others can probably think of other interactions need to be submitted for enhanced error handling?
a Custom Filter references an add-on query rule that is not installed
a multi-stage (or multi-rule) Custom Filter references another Custom Filter that has been deleted or renamed.
Besides being referenced by name in the custom_filters.xml, bad Rules can be referenced in:
books.xml and report_options.xml (by an option name="filter", a VERY fragile index)
tool_options.xml (by type and name)
This problem is similar to link rot for URLs.
The project probably needs to:
define the methods for gracefully handling the 2 variants of degraded Custom Filters
harmonize the XML reference to filters
Example reference by index: <option name="filter" value="5"/>
I was hoping to find headers for all XML files in the future. If the type of Gramps XML were identifiable, tools like the Text Import might be able to be enhanced to import infrastructure data (like filtersets in custom_filters.xml files) in addition to Tree data from .gramps files.