Search Engine and Live Table display wrong amount of results and page


I was hesitating to directly open a Jira issue for that, but maybe there is something we did wrong so I prefer to talk about it first.

We have two issues very similar, one using default solr search engine, the other in live table.

In the search engine, the results are ok, but the amount of page and the amount of results doesn’t match the number of item in the list ! It looks like the number of page and results doesn’t care about de XWIkiRIght of the user on theses documents.

For exemple here I look for “test” in all XWikiDocument and content, I see just 1 item in the result list which is correct. But it say that there is 920 results and 92 which is wrong ! Maybe theses results exists ( not even sure ) but if they do I don’t have any right to see theses documents so it should not be counted.

Screenshot 2021-03-03 at 16.33.53

Same kind for Live Table. If I’m listing all the Document of a given class, I see all the empty line even for document where I don’t have any access. Here the amount of line is correct, but it’s not a good UX experience to see theses empty line for a user.

Screenshot 2021-03-04 at 15.39.38

Do you have any idea/configuration to fix that or if it sound weird to you do you have an idea from where it could come ? If it’s an issue I can open it on Jira.

Yes, because currently access rights cannot be checked at query time, neither for Solr nor for database search. We can only check access rights after we get the search results, before displaying them. Access rights are hierarchical in XWiki, meaning that page access rights inherit from parent page access rights and so on, up to the wiki access rights and then main wiki access rights. Computing the access rights for a specific page is complex and cannot be done at query time. This leaves us with two options when paginating search results:

  1. ignore access rights when paginating, but hide or obfuscate the protected search results
  2. take into account access rights when paginating

Each has its cons and pros. If you have 1000 search results, with 10 per page, and the current user can only view the last one, then:

  1. first option: the search results load fast as we only load and check the access rights for 10 documents, but the display is ugly
  2. second option: the search results load slow as we have to load and check the access rights for 1000 documents just to display the first page of results, but the display is nice

We chose the option that makes the UI faster and puts less stress on the server.

For live table there is .

Thanks for the answer.

It’s a bit desapointing for the user experience. Maybe there is a 3rd tricky solution. Since the amount of page is irelevant, maybe you should juste keep the way it works currently but hide the amount of results and hide the amount of page and add a button “next page” on frontend side.

Then if there is 10 results by page and you just have between 0 and 9 entries you don’t display “next page”. If there is 10 results you display “next page”. The Only bad UX experience here is there is exactly 10 results so next page will display nothing. A proper way would be to do it on back end side, if you know that the users is asking 10 results by page, check the access right up to 10 results and also check until you found 1 more so you can return theses 10 results and the information that there is a next page.

Thanks for the ticket about livetable, it’s open since 2013, maybe it’s very complex to solve ? I guess it’s the same kind of problematic, checking right and have to deal with amount of page/result. We are using severals live table and this is not so minor to us I hope you will considerate this issue :slight_smile:

Hiding the number of pages and showing just “Next page” doesn’t make the UX better unless we retrieve the next 10 results the user has access to:

  • showing just one result (that the user has access to) and the “Next Page” link is not better than the current state. The user will surely ask “why is there a next page if I see only one result. This must be the last page, so seeing the Next Page link is most probably a bug”. Then clicking on the Next Page link will show some other results (that the user has access to) which will convince the user that the pagination is wrong.
  • and retrieving the next 10 results that the user has access to can be very very costly as I mentioned previously.

There aren’t really other options besides:

  • what we have right now: fetch the next 10 results and show only those that the user can access to; this is fast but bad UX
  • what you want: fetch the next 10 results that the user has access to; this can be very slow (potentially loading and checking access rights for all wiki pages matched by the search query) but it’s better for UX.

The only way out of this for me is to add a configuration option and let the administrator choose what they want.

See also [XWIKI-8583] Correctly handle pagination for results that are not viewable by the user - JIRA .

Yes I agreed with your analysis. The complexity of the “worst case scenario” could be checking every pages of the Wiki which is really bad performance, my screenshot is a good exemple 920 results and probably just 1 accessible :confused:

I’m beginner with solr so I don’t know how companies deal with using it as search engine and check access right to the document. It’s probably not possible with the current design of XWiki Right :frowning:

Just a though : We have an other homemade search page (but not as powerfull of the global search) and we are checking directly access using rights given to groups that we use as a second level of right String.format("property.XWiki.XWikiRights.groups_string:(%s)", String.join(" OR ", userGroups)); users are synchronized with access groups on login and theses groups have or not access to some XWiki spaces. It’s probably not helpfull :sweat_smile: