Hello,
Shop Managers are trying to edit Posts: it is no longer possible, even though before the last set of Toolset plugin updates it WAS possible.
Page where the issue can be seen: Posts List of WordPress: there is no Edit link, etc...
I expected to see: Posts to be editable, just like they used to be.
Before these updates, all was fine:
- Updated plugin "Toolset CRED" to 1.9.3.1 from 1.9.3
- Updated plugin "Toolset Views" to 2.5.1 from 2.5
- Updated plugin "Toolset Access" to 2.4.3.2 from 2.4.3.1
- Updated plugin "Toolset Types" to 2.2.21 from 2.2.19
We have not not touched any configuration recently, the only related changes performed are these plugins updates.
As a quick fix I turned OFF Managed by Access for Posts so this way Shop Managers are allowed to edit the Posts but they should also be able to edit them with Shop Managers ON and all access rights granted but it is not the case.
Hi, I haven't been able to reproduce this in my local testing so I wonder if there is a specific edge case on your site. If it's okay with you, I'd like to make a clone of your site so I can run some additional tests. I can install the Duplicator plugin and begin that process if you approve, or you can provide a Duplicator clone download link. I'll activate private reply fields here.
The Slides post type is not managed by Access, and Slides are children of Posts. So if I activate Access Control of Slides and give Shop Mgr all privileges for Slides, the Shop Mgr now has the ability to edit all Posts. Can you confirm this behavior on your site?
"Can you confirm this behavior on your site?"
Yes, I can. However, the strange thing is that afterwards I had set "Use the default WordPress read permissions" to Slides and I expected not to be able to edit Posts by Shop Managers once again but it was not the case. Just by setting Slides to "Managed by Access" and giving all permissions to Shop Managers fixed the issue, even when setting it back to either "Use the default WordPress read permissions" or "Same read permission as posts".
Note that unfortunately there are two post types named Slide in the system. The Slide we are talking about is created by Types (by me). Later on I installed a plugin (Carousel Slider) which created another post type called Slide. I'm not happy with this situation but I do not know if it matters or not, so I left it that way.
BTW, I might be mistaken and we might be dealing with the wrong Slide post type. To tell the truth, I'm not quite sure which one is which 🙁
Note that unfortunately there are two post types named Slide in the system. The Slide we are talking about is created by Types (by me). Later on I installed a plugin (Carousel Slider) which created another post type called Slide.
Luckily these two post types have different post type slugs. The Types Slide slug is "slide" and the Carousel Slide slug is "carousel", even though the tab in wp-admin says "Slides". To differentiate between these in Access settings, I have edited the Types post type to use the name "Types Slides". Now in Access Controls I can see the difference.
afterwards I had set "Use the default WordPress read permissions" to Slides and I expected not to be able to edit Posts by Shop Managers once again but it was not the case.
Okay yes, once you enabled permissions for the Slides post type, you became able to edit posts as Shop Manager. If you then rescind the permissions for the Carousel Slides and Types Slides post types, Shop Managers are still able to edit posts. However, if Shop Mgrs try to add a new Slide using the Post Relationship editor, this will be blocked. If you want to rescind the permission for Shop Mgrs to edit posts, you must do that separately from the Slides permissions.
Have you noticed any other Access quirks like this since updating?
"Luckily these two post types have different post type slugs. The Types Slide slug is "slide" and the Carousel Slide slug is "carousel", even though the tab in wp-admin says "Slides"."
Yes, thanks for reminding me. I can check it - for example - by taking a look at the query string in the URL when navigating in the admin.
To differentiate between these in Access settings, I have edited the Types post type to use the name "Types Slides". Now in Access Controls I can see the difference.
Maybe I should rename it too. I prefer Home Slide(s) though. Is it okay to rename the post type? As long as the slug stays the same (slide) renaming it will probably not have any side effects, right?
"If you want to rescind the permission for Shop Mgrs to edit posts, you must do that separately from the Slides permissions."
It want Shop Manager to be able to fully manage both Posts and "Types" Slides. I mentioned this option switching "issue" because I found it to be strange that things work this ways. I mean, why did changing the children post type's Access setting changed the edit permission of Posts only once? Why did it change the access permissions of its own parent at all?
I do not really want to dig too deep into this issue though. I only want to understand how Access should work.
"Have you noticed any other Access quirks like this since updating?"
No, I have not. I checked all the other Shop Manager access permissions by navigating around the admin and could not spot any other permission related issues.
As long as the slug stays the same (slide) renaming it will probably not have any side effects, right?
I can't think of any problems that would arise from renaming the post type, as long as the slug stays the same.
why did changing the children post type's Access setting changed the edit permission of Posts only once? Why did it change the access permissions of its own parent at all?
Let me ask my 2nd tier support team for some clarification on this, and I will update you when I have some additional information to share.
Hello, I'm going through older tickets and see this one was left pending some feedback from our developers. We have published an erratum post here, where you can follow along for updates: enlace oculto
However, I don't have a good answer for why the permission behavior was working as described. The problem resulted in some unexpected behavior.
