[Résolu] Child Custom Post Type not editable by other
This support ticket is created Il y a 6 années et 10 mois. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
Hello there, Perhaps I already asked this question but it was part of a non related thread.
I have an issue on this peculiar problem (perhaps more linked to wp-types than wp-access) :
As an editor, I cannot edit custom some post type created by another. All the CPT I've created behave corrrectly, except for this one.
The only difference I can think of is this CPT being a child type of two other CPT.
You may find down here a screenshot of the current config params for this cpt.
Thank you for contacting Toolset Support. This is also due to the same problem that was reported in the other ticket. Basically it is happening when the native WP Posts are not controlled by Toolset Access.
Our developer suggest this as a Solution for this problem:
- Set Posts (WP Posts) managed by Access with default permissions (no need to set edit permissions for contributor role, just default edit_own, delete own permissions).
After this the other permissions you have setup will be effective as normal.
Thank you
Hello Noman, and thanks a lot for your fast answer
i'm afraid it is not related : I basically tried to manage this CPT while being a native "editor", and this peculiar CPT does not let me edit others posts...
I also tried your solution of course (it was already on), but this does not work for this CPT (but for others, non-child CPT, its OK).
For a complete report, here's what I tried :
- Giving full rights for this CPT parent => No change
- Trying as a native editor => No change
It seems like it's this CPT that won't let me do it.
Thanks,
Charles
Thank you for providing more details, now I can understand your problem.
To further debug this issue, I need to request temporary access (WP-Admin and FTP Login info) to your staging site.
Your next answer will be private which means only you and I have access to it.
=== Please backup your database and website ===
✙ I would additionally need your permission to de-activate and re-activate Plugins and the Theme, and to change configurations on the site. This is also a reason the backup is really important.
✙ Please add the Links to the [CRED] Edit Screen and [Page] Screen where you have inserted this form.
✙ Please provide:
- parent cpt name
- child cpt name
- custom role name and user login for testing.
- native Editor user login for testing.
I have debugged the issue and enabled WP native Posts so they are Managed by access, then disabled all checkboxes (permissions) for WP Posts so that Editor can only edit the 3 post types we have want him to edit.
And the Edit / Delete permissions are now same for Partenaires post type too just like others, please see attached screenshot.
On the other side !
OK Noman, I see you have taken the problem from the other side (giving a bigger role, then removing permissions vs starting from subscriber and adding permissions) , that's good, I will try to make it work today, and I'll be happy if it will. That's certainly a good workaround but if not a bug, it should be written on the plugin page so that we can understand how it's working.
Have a nice day
KO Noman, now let's go further 🙂 :
- It works perfectly on the test site you have access to .
- Now I created a new role "Golf Manager", having the same rights as editor, except that I deactivated a few permissions for "Pages" and "Posts". This new Role works perfectly as I's expect . that is, reduced rights for posts and pages, and full rights for Trous, Competitions and Partenaires.
It still works allright for the test site.
So I tried to reproduce these settings on the live site. And now, Boom, it does not work.
- I activated the "advanced" mode on the roles tab of the access plugins ISO the test site.
- I event tried to give "Golf Manager" full rights on native pages and posts, but still no write rights for CPT "Partenaires".
- I double checked the Types settings for this CPT, saw a few differences that I equalized.
All the Post types behave correctly, except for the "Partenaires" Post type, which is still on read only.
My questions are :
1/ Is there another setting that you have made when enabling this Role rights for the CPT "Partenaires" ?
2/ Would you mind giving me a brief but complete explanation of the behavior / issues of this plugin ? Because I must admit I don't understand everything... Seems to work more with "hacks" or "workarounds" than with simple intuition...
I saw some updates for Toolset plugins and I updated those, so if you see same on live site please go ahead (please take backup first): https://toolset.com/account/downloads/
1. I don’t think there was something else that I tired or left unchanged. You may try to delete current roles in live site and recreate them using Editor role or higher, and the restrict his permissions.
- Also check “Activities” Taxonomy permissions under Access and ensure that its same as Test site.
2. Toolset access allows you to create custom roles, modify permissions for each users / posts / content. It also allows to restrict specific things like CRED Forms. There were some changes in latest versions of Access that allows inheriting “Same read permission as posts” which has made things to work somewhat different than we expect it to. Our development team is aware of this but for now they have suggested this workaround only, based on other priorities and the solution to overcome this will require major changes in the plugin.
I think I've achieved to manage it on the production site. It's been very hard, the hardest part being that I don't even know why at a time it did not work, and then, without even understanding why, it did.
I'll be glad to be updated if you have any news regarding a more intuitive UX.
Good that it's at least working. Not quite sure why it is behaving strange on live site, on the test site I found things working with the workaround we have, other than the workaround I could not find any strange things over there. The original problem was already reported and in the knowledge to development.
More improvements to Toolset Access will ofcourse be coming soon in upcoming versions but its on development team that which features they will prioritize based on all users feedback. I will keep an eye on this and if I see anything strange or reproducible issue I will be happy to report it.
Thank you
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
