When using Access to create a custom user level that is below admin, but still able to use Toolset, you have to grant the permission "manage_options".
When this is granted, the newly created user can navigate to Toolset > Access and simply grant themself complete access across the whole site, including removing existing and creating new admin users etc.
This seems like something I think users of Toolset should be aware of, I'm not sure how many users of Access will realise this is possible!
I am having to use an external plugin whilst there is this vulnerability within Access.
So if a user has access to Toolset (manage_options) and either Access activated already or the ability to upload the Access plugin and activate it themselves, then they can seize complete control of that site.
Instead of granting "manage_options" to this role, couldn't you grant other individual options like "wpcf_custom_post_type_view", "wpcf_custom_post_type_edit", "wpcf_custom_post_type_edit_others", and so on? The Toolset menu will appear with limited options available, preventing access to Toolset > Access Control. It may be enough depending on what all you want the User to be able to do with Toolset.
Hello Christian,
Yes this could be a solution.
Is there a list, or documentation, for the capabilities used within Toolset?
Can I give full access to Toolset for a user but exclude the Access plugin this way?
I don't really understand the goal here. If you grant full Toolset permission except for Access Control, then the User can delete all your custom post types and custom taxonomies and custom fields and Views and Content Templates and Relationships...effectively destroying the site even without Toolset Access Control.
I understand that, but the goal (in an ideal world) would be to have the Toolset functions accessed separately to the rest of the site.
I would want a user to be able to manage the data in the site, but not the site itself. It's best practise to keep access to users information/passwords/security etc to as small a group as possible.
Let me check with the team and get some feedback, because the public capabilities available aren't comprehensive and I don't know of any documentation on the site for other individual capabilities.
Thank you Christian. I appreciate your help with this.
Sorry to be a pain!
As per Shane's request on this ticket (https://toolset.com/forums/topic/capabilities-required-to-edit-custom-code-snippets/) can I also ask about the permissions needed to edit custom code snippets as this seems to be "delete_users".
I can enable every permission possible other than "delete_users" but I cannot edit or modify custom code snippets until "delete_users" is enabled.
Okay I have some feedback but it's not good news. There is no comprehensive list of capabilities other than the public caps available in the Access Control editor. Furthermore there is no single capability you can grant or take away to manage access to Access Control. We have submitted that specific request (ability to grant or rescind access to Toolset > Access Control with a single capability) to the developers as a feature request in the past, but it hasn't received much traction yet. If you'd like to add your vote for this feature, please fill out the form here: https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
As far as code snippets, there is no public capability available to handle access to that settings screen. If you'd like to see that added as a manageable capability, please fill out the form again to request this specific capability.
Thank you for your help with this Christian.
