Timeline for Building a search View that respects access control
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2016 at 4:00 | history | bounty ended | UltraBob | ||
| Jun 1, 2016 at 2:12 | comment | added | UltraBob | Rebuilding permissions is making a difference, now I can see different values showing up there. Unfortunately it still doesn't help with the facets. Great idea though to reach out to the editor of the documentation page. I'll look at that, though I may not need the answer for my project anymore. | |
| Jun 1, 2016 at 2:08 | comment | added | Shawn Conn | Lastly, you might want to reach to the user that put the "Needs details on how to build a View that respects access control." in the docs under the presumption he might know but didn't have the time to put it into the docs. | |
| Jun 1, 2016 at 2:07 | comment | added | Shawn Conn | You might be able to do it through a Indexed Node: Node access information that's pulling the information through PHP code, but that feels hackish. | |
| Jun 1, 2016 at 2:07 | comment | added | Shawn Conn |
I see. You might want to try re-indexing. With Node Access filter it looks like it indexes anything utilizing hook_node_access_records() and hook_node_grants() (which TAC does ). Search Views allows you to filter on this information through the Indexed Node: Node access information filter but you need to know the indexed key (e.g. set = "node_access__all" for everything viewable by the anonymous user), which can't be dynamically pulled from a current user contextual filter.
|
|
| Jun 1, 2016 at 2:05 | comment | added | UltraBob | I was wrong about taxonomy access control, and apparently something had gone wrong with the access rebuild. I think I'm going to probably simplify the access model to make this unnecessary, but I think the question is still important. | |
| Jun 1, 2016 at 0:27 | comment | added | UltraBob | automatically, that would be inefficient , but it would work, but I don't immediately see a way to limit the index to only items that meet the criteria for unauthenticated access. I have the index set up to index node access information, but apparently with Taxonomy Access Control the node_access table doesn't get written to, so looking at the sm_search_api_access_node field in the solr index shows all terms with node_access__all. Where are these non last-resorts that the interface and help hint at? | |
| Jun 1, 2016 at 0:12 | comment | added | UltraBob | I thought I had mentioned, but rereading, I guess not specifically. I have the Additional access checks on result entities checkbox checked for now, but as you mention, this means that the facets will show options for things that don't exist. and counts are incorrect. All over the place, the interface and the help hint that there is a better way to handle access checking, but I can't find anywhere where it is actually done. If there was a way to generate a different index for logged in users and non-logged in users (the only access check I need) and search the right one in the search view… | |
| May 31, 2016 at 22:41 | history | answered | Shawn Conn | CC BY-SA 3.0 |