Add `access_admin` capability

[krogsgard]

Many, many plugins do various types of checking of capabilities the determine if a user should really have the ability to view the WordPress admin. It's very common to prevent that from happening.

Within WordPress's roles and capabilities, there are many checks that have something to do with the admin, like edit_posts and myriad others, but there isn't one that's an explicit admin_access check.

Even a Subscriber role sees the toolbar by default, only to be able to edit their profile and see WordPress news, the activity widget (and Akismet stats btw) once they log in. I can't imagine many scenarious where this is truly wanted by site administrators -- for lower level users to even know what CMS the site uses, much less view the admin.

I'd love to see admin_access or a similar capability enabled in core. I think for backward compatibility reasons, it may have to be set to true for all roles by default, but at least plugins would have a standard capability to flag for disabling it.

It'd also be nice as a "Reading" option for the site owner to choose roles that should have access to the admin and would trigger this capability -- but that's probably wishing too much from a core standpoint.

@drewapicture has a plugin called ​Remove Dashboard Access that has a ​pretty thorough UI, if folks were interested in taking this the next step, but I'd rather focus on the capability itself as the primary mission of this ticket.

To me this is a new user experience issue and would make for a very helpful flag for plugin authors, at a minimum.

[ocean90]

That's actually the read capability which is the only capability which subscribers have by default.

If a user has a role with no capabilities then they will only have access to /wp-admin/about.php. Should they? Dunno.

[krogsgard]

@ocean90 Good point I didn't address. So... both read and edit_posts could otherwise seem like logical capability checks.

I understand that read is technically for administrative access, but its other inconvenience is that it's the only capability for subscribers, therefore making it scary territory for actually checking for such a thing -- because who knows how folks are using it. I can imagine all sorts of stuff that has nothing to do with admin access that developers could be using the only cap made available to all users for.

This came about because I was having an issue where WooCommerce customers who were also authors/editors lost admin access, and it turns out to be from some multi-role issues and various capability checking. Sidenote: customer and subscribers look a lot alike, capability wise. (Double sidenote, here's the ​goofiness they use to lock down the admin... I assume they have reasoning for not just altering read access? Pretty smart folks there.)

When plugins may be using some of those same capability checks for other things (I dunno? front end account editing, maybe?) it makes it a bit scary to start turning off read access from WP itself because that's the only capability available.

A second, more explicit capability would be nice in this case... hence admin_access -- not to mention the less confusing name than "read" :)

[rmccue]

Following the general pattern of verb_noun, this should be access_admin, as in current_user_can( 'access_admin' ).

I'm not sure I'm a fan of this, since I can't really see a reason why users shouldn't be able to access their own profile, for example. I think if you want that behaviour, you should be handling it via other actions/filters rather than via capabilities.

Replying to krogsgard:

This came about because I was having an issue where WooCommerce customers who were also authors/editors lost admin access, and it turns out to be from some multi-role issues and various capability checking.

For reference, this is #36376.

[greenshady]

As the author of one of the most popular role management plugins, I can say that this is probably one of the top 5 requests I get from users. I just found this ticket when searching to see if core had plans for a related capability.

[johnbillion]

When was the last time a new primitive capability was introduced? The last few that were introduced (customize, delete_site, upload_plugins, upload_themes) are all meta capabilities with corresponding mapping in map_meta_cap().

The reason I ask is because backwards compatibility with custom roles is tough. If an access_admin cap is introduced, should core add that cap to all roles or just the default roles? What about existing plugins that add a new role with a limited set of caps - if the plugin was activated after this new cap is introduced then a user with that role would not have the access_admin cap.

It looks like we're kind of stuck with our existing primitive caps and can only ever introduce new meta caps if the cap relates to existing functionality. This is what I'm doing in #35614.