Christopher is off at the moment, so let me comment here directly.
I'm not familiar with the history of the site, and what was created using Toolset and what has been created with something else but is working with Toolset.
The roles of your users are stored with slugs like pmpro_role_1 for example, which come from the plugin Paid Membership Pro, but you don't appear to be using that plugin.
In any case, for the user 1hotgal, her role is WOAW Subscriber. I went to Toolset > Access Control > Custom Roles and edited the WOAW Subscriber role. It doesn't include permissions for publishing or editing standard posts, which I expect these roles to fall back to checking, and so when editing the capabilities for this role in the Other Capabilities tab I enabled permissions for publishing and editing standard Posts. (The actual permissions for Posts will be determined by the Access settings for that post type.)
Now when logged-in as 1hotgal and viewing the post hidden link I am able to see the link to edit the post.
Could you please check for yourself? You can make similar adjustments for any other role that has the same problem.
"The actual permissions for Posts will be determined by the Access settings for that post type." So Access checks the generic "edit post" capability when we clicked "edit own" but limits the type of posts that can be edited. Do I understand that correctly?
What is still confusing me is that the "edit post" and "publish post" capabilities you activated are only active on one site of the multi-site. Could you please explain why these capabilities seem to be site-specific instead of network-wide? Also confusing to me is that users were able to submit/publish posts without "publish post" checked. Just trying to better understand how this works to avoid future issues...
Sorry for multiple messages... I checked "edit post" and "publish post" for the other custom roles but that does not work for them (i.e., when I switched from the role that currently works to any of the updated roles for the given user, the user cannot edit the posts).
Do you have a concrete example of something that is not working that I can look into?
(As I have been testing with the user 1hotgal, is it okay for me to temporarily switch her role to test the same content with a different role?)
Regarding the permissions, when post types are registered by 3rd-party code (e.g. other plugins), they made specify the required capabilities when registering the post type (e.g. "edit_events" for an "event" post type).
In scenarios where such capabilities are not specified (which includes when you register a post type with Toolset) then permissions are based on the default post capabilities (e.g. "edit_posts").
That is before Access is involved.
When you bring a post type under Access control and specify which roles can do what, they will override the default capabilities (so you can give a role the "edit_posts" capability, but manage Posts with Access and deny the role permission to edit Posts, which will override the default capability.
Let me know what I can test to see the problems you are now having.
Thanks, Nigel. You can switch roles for that user. That is what we do. It is our test user.
I took a look at capabilities using User Role Editor Pro and saw that the list of capabilities is different for the different sites in the network. The sub-site where events are handle does have specific editing capabilities for the custom post type (see screengrab). However, these capabilities are not available to select in Access and not available in the other sites. I think that is part of the problem because the users sync across the network. That probably explains why checked capabilities unchecked themselves and it stops working.
First, where does the WOAW Events post type come from? What registers it? I thought it was registered with Types, but I wouldn't expect to see specific woaw-events capabilities in that case, post type registered with Types would normally only have generic capabilities like edit_posts.
Second, in a multisite environment capabilities are per-site, not universal across sub-sites, and users (which are registered at the network level) can have different roles and capabilities on different sub-sites. Similarly, Access settings are set individually on each sub-site. I suspect the problems may arise from "the users sync across the network", because that's not part of WordPress and is not something Access is prepared for.
The custom types were registered using Toolset Types. I have 4 different Toolset types including events. My posts access are managed by Toolset Access (not WordPress) in each sub-sites. All 4 four Toolset types have the same set of type-specific capabilities viewable using the User Editor plugin. We did not add any capabilities manually so I assume Toolset did. However, these custom-type specific capabilities do not show up under Toolset Access so they can't be activated manually.
If the capabilities are site-specific then they should be stored in the site-specific section of the database, right? Users in multi-site are native to the network and available to link to any site. Synchronizing does not affect negatively the standard WordPress roles (admin, author, contributor, etc.). I remain confused...
I have taken a copy of the sub-site to do some further testing, and I am sharing it with the developers to get some feedback from them as to why exactly this isn't working as expected.
I can't reproduce anything like this on my own test sites, and I think "syncing" users is very likely the cause of the issue, but let's see what the developers have to say.
A new Toolset Access version has been released addressing the issue.
I'd appreciate it if you follow the steps below:
- IMPORTANT STEP! Create a backup of your website.
- Go to "WordPress Dashboard > Plugins > Add new > Commercial (tab)".
- Click the "Check for Updates" button.
- Update Toolset Access there.
- Check if the issue is fixed.
Thanks. I thought you forgot about me 😉
I did upgrade access (and others), purge cache, reapplied authorizations in Access for the special types and special user roles but I still cannot edit the event posts from the front end unless I hold an standard authorized WordPress role such as admin
after the Access updates I deleted my local copy of the site, and I need a new copy for further testing.
But when logged in as super-admin on the network I don't have permission to upload files, to be able to add the Duplicator Pro plugin manually. Seemingly something to do with SiteGround.
Could you please discuss with the client how I can do this.
Any chance we can have a version of the website so we can double check?
That's odd. I did not change anything for that user so it should have the capacities as it did the first time.
Do you want FTP access to upload the plugin in the plugin folder?
