I try to create a page with a list of documents and add filtering to the list. Documents structure looks like this:
/content/documents/web/sale-exclusives/
<node name> [web:saleexclusive]
web:exclusive [web:exclusive] (@web:year)
So, there are root documents of type web:saleexclusive
that have compound children of type web:exclusive
with attribute web:year
.
I want to filter documents of type web:saleexclusive
by web:year
attribute of it's child compound node.
To achive this I extend EssentialsListComponent
and override contributeAndFilters
method like this (just for test):
@Override
protected void contributeAndFilters(List<BaseFilter> filters, HstRequest request, HstQuery query) {
Filter filter = query.createFilter();
try {
filter.addGreaterOrEqualThan("web:exclusive/web:year", 1900L);
filters.add(filter);
} catch (FilterException e) {
LOGGER.error("", e);
}
}
The problem is that I'm getting an empty result, although there are documents with web:year > 1900. Without the filter I'm getting all documents under sale-exclusives
.
The filter above produces following XPath query:
//*[(@hippo:paths='79a713cf-294d-4e99-9d63-fc50db10e43f') and (@hippo:availability='live') and not(@jcr:primaryType='nt:frozenNode') and (web:exclusive/web:year >= 1900)] order by @jcr:score descending
Filtering by own attributes of web:saleexclusive
works fine.
How can I fix that?
With @Jeroen help I've found the solution.
The same issue is descussed here:
1) According domain configuration, the 'liveuser' has no read access to nodes of type poll:poll. Since the domains are used to create the authorization query, this authorization query does not contain the nodes of type poll:poll, hence, they won't show up in search results
2) The AccessManager treats nodes below documents a bit different: If a node is below a Document that you are user are allowed to read, you are also allowed to read child nodes of that Document according the AccessManager, even if you do not have this configured in the domain rules
The two above rules are contradicting. You can 'fix' it yourself by adding domains for a liveuser that he is allowed to read nodes of type hippo:compound and hippostd:html.
The solution is in the last paragraph. After adding the security domain and granting the read permission to the liveuser
the issue was solved.