I agree; we implemented the current system in 2018.2, as before summary
pages where using the fields marked for summary/search in the latest form
definition, but applying this to all form data, which could potentially be
incorrect. The current system is correct (and more sane!), but isn't ideal
for cases where the fields you're showing on the summary page don't change
much between versions. Would you have some ideas how to improve this?
I agree the current system is much better just mentioning a border case with
One way to solve it it will be:
1) Add checkbox next to each search fields: "Search in all Versions"
2) Enable this checkbox in properties-local.xml
3) Add a header in the call to the Persistence Layer.
If the header is "true" then the search should be performed in all versions.
The problem here is how to display the result.
If two different versions match the search and summary fields are different
in both versions then ???
* To have a ../summary?global=true
In this Global Summary instances of all versions are displayed and the
search is performed on al versions. And the fields to display is the
intersection of all versions definitions (here is responsibility of the form
designer to avoid an empty intersection between all versions).
Also the search fields is the intersection of all search fields in all
versions (designer responsibility here again).
These are general ideas, not sure how difficult it will be the
I like the idea of having a "Search in all Versions" checkbox, thank you for
the suggestion. One implementation wrinkle is that it means we would need to
index every document for all the fields marked as search or summary in *all*
the versions of the form definition. I'm not sure that what we would gain
from this feature is worth the implementation and runtime cost.