Affects Version/s: Resource Merger 1.3.10
Fix Version/s: Resource Merger 1.4.0
Provided a failing test case here: https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/3/files
When trying to configure a whitelisting approach to inheriting nodes from a parent (i.e. through resource super type, or through overlaying), the following way:
One would expect that requesting the children of /merged/test/tabs would yield the "desired-tab" only, i.e. "undesired-tab" (and other nodes not whitelisted) being hidden. This is working as expected.
One would also expect the "desired-tab" to have the properties of the base-structure as well as the properties of the overlay-structure. This is also working as expected.
One would expect that the underlying nodes of "desired-tab" from the base would remain intact and would be merged with the underlying nodes of "desired-tab" in the overlay. So, while listing the items of desired-tab, one would expect:
MergedResource containing properties [title=test, description=test] consisting of original resources [/apps/base/test/tabs/desired-tab/items/field, /apps/overlay/test/tabs/desired-tab/items/field]
However, instead, the following is returned:
MergedResource containing properties [description=test] consisting of original resources [/apps/overlay/test/tabs/desired-tab/items/field]
So, the original "base" resource is not considered anymore!
I believe the issue is in MergingResourceProvider.ParentHidingHandler, in the constructor, actually. At some point, it decides that the parent resource (which indeed has the sling:hideChildren property defined) defines an exclude entry which is "*" and adds that entry to the list.
Then, when the class starts checking the parent of the parent (marked with "// also check on the parent's parent whether that was hiding the parent") - There it will find that asterisk exclude that was defined on the parent, not taking into account that it was preceded by a whitelisting "!desired-tab" - Removing the parent of the parent's children entirely.
I believe this should be changed into a more robust way of handling this use-case. Probably the asterisk exclude can be global, even though it should still be desired that any child of the parent still is able to remove that exclude. But whenever those excludes are considered, also the includes that were preceding it should be considered to figure out if it's a real include in the case of that specific path.