Permissions field on user edit form leads to unexpected results

A couple good examples of unexpected results:

1) If you have some very large taxonomies, for example (as is my case) a list of thousands of organizations associated with your site, then performing any action on a user edit page causes the site to slow to a crawl or even crash. This can potentially be remediated by first going to the PbT settings page and selecting a vocabulary that isn't populated with so many terms. It would be better if PbT can automatically determine which vocabularies I've put permissions on and have those selected by default.

2) The first time a user edits their page after this update, they are taken to a rebuild permissions page. This could be a surprise for people who perform administrative functions on a site but aren't directly involved in module updates.

I would prefer the ability to toggle this section on the user page off, as I don't plan to use it (I don't want to override the default behavior I set on the term pages where I was setting at the Role level).

I am having the same problem. When I remove roles, the term permissions are still set on the user because of this issue.

This only happens on my Admin role since that is the role that has permissions to view the term permissions information on the user edit page.

This is a pain since I only want to manage the permission by term using roles. I do not want/need to assign individual users using term permissions. This makes managing users a bit of a pain since the module is automatically assigning users to terms. The issue is that this is automatically extending permissions to users on terms that I do not want to allow them to have access to and also it does not remove permissions when I remove a role from the user.

This is indeed a very annoying "feature". I tried to find a way to completely remove the permissions by term entry on users' edit page, but administrator will always see it, no matter what.

The only way to handle this at the moment is to NOT use the administrator role and instead add another role that has all the admin privileges except for this one. I *presume* that this is a good practice anyway, but well...

Agree to 101%! Can we please make this form on the user page optional by a setting or move it into a submodule or whatever?

The idea behind permissions_by_term is great, but some concepts (like this and the entity submodule) are a bit confusing to me...

Exactly the same scenario for me as #4. Only need the permissions based on Role, not per individual user. The fact that removing a role from a user doesn't remove the permissions from that user seems like a major issue.

Throwing out a patch for anyone who needs a quick fix to user-specific permissions. As @Anybody mentioned, ideally there will be an option for disabling. But for now, this patch does what #3 mentions... removes permissions_by_term_form_user_form_alter() and permissions_by_term_user_form_submit(). Applies cleanly on 3.1.16

@ChuckSimply, we finally created a simpler module: https://www.drupal.org/project/entity_access_by_role_field
Feel free to try and help us to test and in coding. :)
Be careful, it's quite new.

For the given reasons above and the maintainers choice to keep things (which is absolutely ok) like they are in some conceptual points we don't agree with, we made the switch. Anyway Permissions by term is a great module, for more complex cases than ours.

Thanks @Anybody. Looks great... unfortunately I need that access control to be passed off to specific taxonomy terms (which are related to specific roles). Doesn't look that the new module has that capability correct?

Thanks @Anybody. Looks great... unfortunately I need that access control to be passed off to specific taxonomy terms (which are related to specific roles). Doesn't look that the new module has that capability correct?

Well I'm not sure if I got you right, but using the module you'd add a role access field to the taxonomy and in the single terms, select which role should (not) have access. But we shouldn't spam this thread, so try it and otherwise feel free to create a support request in the module... but first try :D

Will do. Thanks again!

Patch #8 doesn't apply to last updates of "Permissions By Term".
The content of permissions_by_term.module has changed in the meantime.
So, first I built my own patch and ultimately I prefered building a tiny custom module with 2 hooks, and it works!
I expect this way to be safer against future updates of "Permission By Term"

<?php
/**
 * Implements hook_module_implements_alter() for 'user_form'.
 */
function mytinymodule_module_implements_alter(&$implementations, $hook) {
  if($hook == 'form_alter' && isset($implementations['mytinymodule']) {
    // Move our mytinymodule_form_user_form_alter() implementation to the end of the list.
      $group = $implementations['mytinymodule'];
      unset($implementations['mytinymodule']);
      $implementations['mytinymodule'] = $group;
  }
}

/**
 * Implements hook_form_FORM_ID_alter() for 'user_form'.
 */
function mytinymodule_form_user_form_alter(&$form, &$form_state, $form_id) {
  // remove $form['access'] from "user_form"
   $form['access']['#access']=FALSE;
}

Here's a new patch for 3.1.29. Does the same thing, removes permissions_by_term_form_user_form_alter() and permissions_by_term_user_form_submit().

Would be great to get disabling this as an option.

Tested the patch in 14 and it cleanly removes the permissions by taxo area from the user edit page.

I'll set this to RTBC just so people know there's a working patch here that solves the problem, even if building out a UI in the app isn't there. I can't see why we'd really want to tie terms to a specific user vs roles given the scope and functionality of the app.

If someone disagrees with that feel free to set it back to active!

Hey everybody! Thanks for the input on this issue! I went ahead and created an issue fork that does two things:

• In the settings there now is a new option to toggle the display of the terms on the user page on and off. (Defaults to TRUE)
• If the terms are displayed, they are split up by vocabulary to reduce the potential insanity of having tens of thousands of terms in the same select field

Could someone with a bit more mileage on this issue take a look at that fork and let me know if these changes make sense?

Hi everyone, I went ahead and merged the fork with the new setting. It will be released in 3.1.31.

Marking this as fixed. Is this issue persists for anyone on 3.1.31, feel free to reopen it or open a new one.

Looks good. Thanks!

Hi, we were setting defaults in the permissions by term field when creating new users and this broke our code.

In the user form, splitting up `$form['access']['terms']` by vocabulary was probably an unnecessary change that didn't need really need to happen.

Just making a comment here so that others might find something when looking. It's a hard problem to find if you don't know what's going on.

Anyway this was a breaking change.