[
https://issues.apache.org/jira/browse/SLING-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287319#comment-17287319
]
Paul Bjorkstrand commented on SLING-10150:
------------------------------------------
Just a question for [~Henry Kuijpers], have you tried changing the order of the
hide-children values? If the {{!desired-tab}} is evaluated first then the {{*}}
is next, maybe it is an ordering problem (or maybe I am completely missing part
of the problem).
> Sling Resource Merger completely hides parent when whitelisting in
> combination with asterisk is used for sling:hideChildren
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-10150
> URL: https://issues.apache.org/jira/browse/SLING-10150
> Project: Sling
> Issue Type: Bug
> Affects Versions: Resource Merger 1.3.10
> Reporter: Henry Kuijpers
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provided a failing test case here:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/3/files
> TODO: Fix
> 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:
> /apps/base/test/tabs/undesired-tab
> /apps/base/test/tabs/desired-tab
> /apps/base/test/tabs/desired-tab/items/field@title="title"
> &
> /apps/overlay/test/tabs@sling:hideChildren="[!desired-tab,*]"
> /apps/overlay/test/tabs/desired-tab/items/field@description="test"
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
