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.

Comments

TravisJohnston created an issue. See original summary.

aks22’s picture

StatusFileSize
new705 bytes

Please check attached patch for this issue.

aks22’s picture

Assigned: Unassigned » aks22
Status: Active » Needs review
TravisJohnston’s picture

Status: Needs review » Needs work

Thank 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.

TravisJohnston’s picture

For 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.

function MY_MODULE_views_pre_render(&$view) {
    global $user;
	$userRoles = $user->roles;
	if (!in_array('administrator',$userRoles)){ // Only for non-admins
		if($view->name == "calendar"){
			$results = $view->result;
			foreach($results as $r => &$result) {
				$locationTid = $result->_field_data['nid']['entity']->field_location_program['und'][0]['tid'];
				$location_taxonomy_term = taxonomy_term_load($locationTid);		
				if (!in_array($location_taxonomy_term->name,$userRoles)) {
					unset($results[$r]);
				}
			}
			$view->result = $results;
		}
	}
}
jepster_’s picture

Status: Needs work » Needs review

Thanks for the bug report. I have fixed this by the latest commit to the dev branch (7.x-1.x):

Date: Fri Jun 3 00:07:56 2016 +0200

Issue #2738979 by aks22: Not hiding results in Views

Please review. If it's ok for you, I will merge the fix to the stable release.

jepster_’s picture

Details about the code commit can be found here: http://cgit.drupalcode.org/permissions_by_term/commit/?id=a33118c

TravisJohnston’s picture

Ill take a look in more detail tomorrow. Thanks for the work!

aks22’s picture

Its working for me, it is now hiding the results..TravisJohnston, please review.

TravisJohnston’s picture

StatusFileSize
new117.84 KB

Seems 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.

TravisJohnston’s picture

StatusFileSize
new847 bytes

Here'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..)

TravisJohnston’s picture

TravisJohnston’s picture

StatusFileSize
new953 bytes

Here you go.

TravisJohnston’s picture

Not 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.

TravisJohnston’s picture

StatusFileSize
new2.52 KB

OK 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.

TravisJohnston’s picture

StatusFileSize
new2.46 KB

Small tweak needed since the last patch wasn't fully solving the problem.

  • jepSter committed 194c893 on 7.x-1.x
    Issue #2738979 by TravisJohnston, aks22, jepSter: Fixed issue about "Not...
jepster_’s picture

Status: Needs review » Closed (fixed)

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

TravisJohnston’s picture

Thanks, I don't normally code for Drupal.org.