Tried fresh install, tried dev version, cache/cron/rebuild permissions, etc.
Out of the 5 results that should be hidden in the view, only 1 was hidden. If you click on any of the others you are directed to the access denied page as expected but they still show in views.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | not-hiding-results-in-views-2738979-11266627.patch | 2.46 KB | TravisJohnston |
| #10 | Screen Shot 2016-06-06 at 9.53.00 AM.png | 117.84 KB | TravisJohnston |
| #2 | not-hiding-results-in-views-2738979.patch | 705 bytes | aks22 |
Comments
Comment #2
aks22 commentedPlease check attached patch for this issue.
Comment #3
aks22 commentedComment #4
TravisJohnston commentedThank you for your quick response and attempt but that actually had the opposite effect and instead made the 1 that was hidden show. So now all 5 that should be hidden show.
Comment #5
TravisJohnston commentedFor right now Aks22 I managed to do this in my custom module, so hopefully you can use this to help you patch this one. I used hook_views_pre_render to scan the results from the query and remove any that contained a tid that matched a restricted entity and rebuild. Not the cleanest since it means putting in a physical field versus searching for all fields with tid's.
Comment #6
jepster_Thanks for the bug report. I have fixed this by the latest commit to the dev branch (7.x-1.x):
Please review. If it's ok for you, I will merge the fix to the stable release.
Comment #7
jepster_Details about the code commit can be found here: http://cgit.drupalcode.org/permissions_by_term/commit/?id=a33118c
Comment #8
TravisJohnston commentedIll take a look in more detail tomorrow. Thanks for the work!
Comment #9
aks22 commentedIts working for me, it is now hiding the results..TravisJohnston, please review.
Comment #10
TravisJohnston commentedSeems to work a little but produces a bunch of errors.
I noticed that the terms in field_secure_areas is now limited in my views filter and views results which is great. I still need to modify this though since I need to restrict terms from more than one field but that's in another issue log.
See attached for screenshots of errors.
Comment #11
TravisJohnston commentedHere's a small patch to fix that autocomplete error. Need to only do this when it's available since non-autocomplete filters do not have this set.I need to remake this patch so it's a proper Drupal patch, please disregard (can't delete comment..)
Comment #12
TravisJohnston commentedComment #13
TravisJohnston commentedHere you go.
Comment #14
TravisJohnston commentedNot entirely sure what is causing the trim() error though. I thought it was in the permissions_by_term_autocomplete_multiple function but it doesn't appear to be.
Edit:
I see the issue. It's how _permissions_by_term_remove_restricted_items_in_select_field is called, it's sending in all the exposed filters and only some are being sent as strings, the ones from field_secure_areas, yet any other exposed filters sent are being included as objects which breaks this. Since you are focusing on only 1 field, I suggest just checking to make sure that $option isn't an object before continuing.
Comment #15
TravisJohnston commentedOK please review. This final patch includes both a fix for the autocomplete error and I fixed the trim error which was being cause by objects being loaded into the taxonomy_get_by_name() in _permissions_by_term_remove_restricted_items_in_select_field.
Comment #16
TravisJohnston commentedSmall tweak needed since the last patch wasn't fully solving the problem.
Comment #18
jepster_Thanks for the patch. I was tweaking it a bit, to not only check if an array/variable is set, but also if it contains any value (isset() replaced with !empty()). Additionally there was some more PHP notice on the nodes admin page, since the same form elements are used there. I have fixed this. Please mind the Drupal coding standards. One indent are 2 spaces and such. See https://www.drupal.org/coding-standards.
The changes are part of the new bug fix release: https://www.drupal.org/project/permissions_by_term/releases/7.x-1.31
Comment #19
TravisJohnston commentedThanks, I don't normally code for Drupal.org.