Query documents by attributes of a compound field fail

Question

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?

Is the year property of type date or long? – Jeroen Jan 18 '17 at 10:46 — Jeroen, Jan 18 '17 at 10:46

Jeroen · Answer 1 · 2017-01-18T21:27:09.517

1

The addGreaterOrEqualThan operator works with name based elements. In your case you want to select a property of a node, which in XPATH are always prefixed by an @ sign.

Try using the following expression:

try {
        filter.addGreaterOrEqualThan("web:exclusive/@web:year", 1900L);
        filters.add(filter);
    } catch (FilterException e) {
        LOGGER.error("", e);
    }

You can always experiment with XPath queries in the repository servlet interface (http://localhost:8080/cms/repository/).

edited Jan 18 '17 at 21:27

answered Jan 18 '17 at 12:22

Jeroen

3,076
1
17
16

I tried with '@', but the result is the same. Thanks a lot for the url, the query I pasted in the question works correctly from the repository servlet interface both with and without '@'. My next assumption is that something is wrong with Lucene indexes. BTW, default url to the repository servlet interface is http://:/cms/repository – Sergey Zhabinskii Jan 18 '17 at 14:48
If you do not get results through the HST it might be caused by incorrect authorization levels. In the repository interface you usually login with the admin user (all permissions on all nodes) where the HST has a preview or live 'user', which can access documents that are either in preview or live state. – Jeroen Jan 18 '17 at 21:43
In case of authorization level issue I guess I wouldn't get results without adding the filter, but without the filter all the documents are returned. – Sergey Zhabinskii Jan 19 '17 at 05:36
Actually, when I login into the /cms/repository interface as the `liveuser` I get results only if I query for all documents or filter by web:saleexclusive own attributes. But if I add `and (web:exclusive/@web:year >= 1900)` the result set is empty (with `admin` I get correct results). Is it possible that `liveuser` has access to the document, but not to it's compound child? – Sergey Zhabinskii Jan 19 '17 at 19:56

score 0 · Accepted Answer · answered Jan 19 '17 at 20:34

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.

Useful documentation about security domains

Query documents by attributes of a compound field fail

2 Answers2