We use Toolset Access for several custom roles, including a special role that includes the "Edit any" permission for posts.
It's been working fine for awhile, allowing a staff member to edit posts by other staff members.
But when we upgraded to Toolset Access 2.4.3.2 yesterday, this user with a custom role with this "Edit any" permission can no longer edit posts unless he's the author.
I searched your site and I found this workaround: https://toolset.com/errata/yoast-seo-plugin-overrides-access-rules/ and I tried it, since we do run Yoast.
But, the fix did not work. (Plus, we were running Yoast with no problem before this upgrade as well.)
I tried to upload some screenshots, but the "Upload an image" link isn't working (I'm using Chromium on Linux).
Is there a bug in the upgrade?
If so, is safe for me to revert to 2.4.3.1? We really need this functionality to work.
Dear Joel,
There should be some capabilities missing in your custom user role, please check these:
Dashboard-> Toolset-> Access Control-> Custom Roles,
Find the problem user role, click the link "Change permissions", in the following dialog window, click link "Other capabilities", enable below three options:
edit_posts
edit_published_posts
read
Then test again.
More help:
https://toolset.com/documentation/user-guides/managing-wordpress-admin-capabilities-access/
section "Editing Capabilities for Your Custom Roles"
Hi Luo! Thanks for the quick reply.
Unfortunately, the role in question already has these options enabled under "Other capabilities":
- edit_published_posts
- read
And because we are running Yoast, I followed the instructions here: https://toolset.com/errata/yoast-seo-plugin-overrides-access-rules/ to manually add, under Custom capabilities:
- edit_posts
So all these permissions you list seem to be present for this role. Yet, the user with this role can no longer edit any posts unless they themselves are the author.
Again, the user role was working running perfectly until upgrading to Toolset Access 2.4.3.2 yesterday. Is there any possibility that this upgrade could have caused a problem? Perhaps there is some other permission that we now need to add manually under "Custom capabilities"?
Thanks!
There isn't similar problem in my localhost, please try these:
1) deactivate other plugins and switch to wordpress default theme, and test again
2) If the problem still persists, please provide a database dump file (ZIP file) of your website in below private detail box, I need to test and debug it in my localhost, thanks
As I mentioned above, there isn't similar problem in my localhost, so it should be a compatibility problem or server problem in your website, since you can not provide the database dump file, please provide a test site with same problem, and fill below private detail box with login details and FTP access. I need to test and debug it in a live website, thanks
