• Resolved Jer Clarke

    (@jerclarke)


    Tested this with v.1.5.8 (the one my site had before) and the latest 1.7.3 (the one I’m updating to) and it happens on both.

    – I was testing the new version of the plugin on my local site to make sure it works as expected
    – I granted ‘edit_users’ to ‘contributor’ role to make sure that my second logged in user would gain the appropriate abilities (in a second private browser window)
    – Granting the capability worked, though I had to also grant other *_users capabilities to get everything to work as expected
    – After confirming granting worked, I removed all the user caps
    – But edit_users remained
    – I tried several times to remove it, but it just stayed ticked when the page reloaded.
    – I then went to my live server and tested v.1.5.8 and discovered the same behavior. I could add edit_users, but never remove it from anyone.

    Am I missing something? Can you replicate this behavior?

    Maybe there’s some special logic around edit_users because you don’t want ‘administrator’ to remove it from themself or something, but as far as I can tell, this is a bug. Clearly I need to be able to remove ‘edit_users’ from the ‘contributor’ role if I add it by accident.

    Thank you for your time, and for this invaluable plugin

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Kevin Behrens

    (@kevinb)

    There is no special handling for the edit_users capability, but the result you describe would occur if you have one or more custom post types or taxonomies that have edit_users defined as one of its capabilities. For example, maybe you set ‘edit_users’ as the capability requirement to manage a custom taxonomy.

    After assigning ‘edit_users’ in the “WordPress capabilities” section, you would need to remove it from there and also from the corresponding Post or Taxonomy capability checkbox(es).

    Thread Starter Jer Clarke

    (@jerclarke)

    Thanks for replying so quickly!

    Hmmm, that’s an interesting idea, I have a few custom taxonomies and things hardcoded and often use edit_users as a proxy for “pseudo-admin” roles.

    But even if that’s the workaround, I think this constitutes a bug in the plugin, because after I untick edit_users and save, the message back from the plugin is Settings saved., despite the fact that at least one of them was totally rejected.

    If I wasn’t paying careful attention and testing, I’d think this role no longer had edit_users and meanwhile the users in that role would still have the ability. It really violates user expectations to have a success message when the attempt failed.

    It would be great if the plugin identified such failures and showed a big, noticeable warning when the page reloads, so it’s clear that it didn’t work.

    This message would ideally also explain why it didn’t work, and give a sense of how to make it work correctly.

    In my case, I found the taxonomy in question, and managed to turn off edit_users by removing both the taxonomy management and edit_users at the same time (turning off the taxonomy management on its own ALSO failed, I had to do them both at once).

    If it weren’t for your help here, I would have been super unlikely to figure this out. If the plugin had told me “can’t remove because of X taxonomy” (or post type) I would have figured it out quickly (since the taxonomy management cap was an error, and once I was pointed to it, I would want to remove it too).

    Thanks again for your quick reply, and for your work on this plugin. We’ve used it for years and it almost always does just what I want. Hopefully this feedback is helpful 🙂

    Plugin Author publishpress

    (@publishpress)

    Thanks for such detailed feedback, @jerclarke

    We also appreciate you using CME over the years.

    If you could leave a review, that would be a big help as we try to make the plugin even better: https://wordpress.org/support/plugin/capability-manager-enhanced/reviews/

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Can’t untick/remove edit_users’ is closed to new replies.