When I enabled the "Node access" alternation for a search index and configure it with a view it do what it's supposed to do, i.e. filter the nodes you don't have access to.
However, if I enable a pager in the view it will always show more pages than the returned results.
And I noticed a strange thing, The total rows return from the view object is 21873. But the output is only showing 5 results, which is correct.
I configured search to to index title and node access, and the view to render entity on the results from the exposed filter on the fulltext and the node status published.
There is only 832 nodes to index so I don't understand the number 21873. The number of rows in the indexed table is only 3231.
Any help appreciated.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | fix_view_pager-1896534-7.patch | 1.87 KB | geekygnr |
| Screen Shot 2013-01-23 at 13.09.04.png | 35.82 KB | johsve339 | |
| Screen Shot 2013-01-23 at 13.08.23.png | 38.32 KB | johsve339 |
Comments
Comment #1
johsve339 commentedSom more information. The total rows for an anonymous user, not in any OG groups gives the expected results of 3. An site administrator (root) gives the expected result of 7. However, a user (sverin) who's a member of an OG group gives the results above with a pager.
Comment #2
dmiric commentedHi!
Have you managed to solove that problem I have the same problem when using node access with search api
Comment #3
dmiric commentedSome more information. I'm using Access by term module. It works ok for everything else only in search api if I enable node access option in workflow it makes a pager mess and as far as I can see shows more than 1 of the same node on those pages.
Comment #4
drunken monkeyEdit: Sorry, wrong issue.
Comment #5
drunken monkeyI guess you are using the Database search backend?
This bug is already known there and should even be fixed – please try whether the latest dev version of that module fixes your problem!
Comment #6
geekygnr commentedI am still seeing this issue.
Comment #7
geekygnr commentedI think I found a solution. It may not be the best way to solve the problem since it reduces the efficiency.
Comment #8
drunken monkeyIt seems no-one has had this problems in years. I guess you're using a mechanism such as the "Additional access checks on result entities" query setting for access control. As that setting's description says, this should be a last resort – you should just try to cover as much of the access rules as possible through normal filters (or with the "Node access" processor, if you're showing nodes).
If you use a mechanism that filters results after the query has run, there's really no way around messing up the pager – except something like your patch, but as you say, that's completely unacceptable performance-wise. (But if it's good enough for you, e.g., because you only have little content, then you can also just keep using it.)