Forum Replies Created
-
Posts
-
Did some additional testing with a very basic single role setup with no IDs and also with a single ID.
As long as there are no IDs to restrict what pages a user role has access to, the user can see all pages and there are no issues with pages disappearing and no longer being visible as they sort, filter, or paginate through them.
As soon as even a single ID is added to what pages a user can access, the results are hit and miss. The page and all its children and grandchildren may display and then after a period of time, the available pages are reduced down to just the parent IDs.
My setup has been the same since 2016 and I only started receiving reports of this issue occurring beginning around February 7, 2024. Since then, I’ve been unable to figure out what changed that is now causing my setup to no longer work.
It’s always been very basic setup of department roles (holds all the IDs and is set to allow) + functionality roles (forms, pages, posts, etc… all set to allow) and it’s always worked until recently.
I am having the same experience. I can confirm both the issues noted and the solution of downgrading.
That appears to fix things. Based on user permissions, the CPT taxonomy is now displaying in the CPT taxonomy metabox on the CPT edit screen.
Just checking to see if a beta version is available. Or perhaps a snippet of code that can be added while you’re working on it.
For clarification, using the ‘ure_restrict_edit_post_type‘ code, makes it so the CPT and CPT taxonomy are both available to manage. However, the taxonomy meta box is empty on the CPT edit screen.
So, while one can mange both the CPT and the CPT taxonomy, they can’t assign the taxonomy to anything.
Thanks for working on this functionality.
Upon updating, I see that there is a new section under the “Post View Access” area of the user role edit screen, but nothing under the “Post Edit Access” area. Unfortunately, I’m looking to manage user edit access (not view access) based on page templates. I want to be able to be able to control what pages a user role is able to edit based on the template rather than needing to provide all the individual page IDs.
Perhaps I’m misunderstanding the functionality, but it currently appears that the functionality isn’t quite what I was expecting or needing.
Just touching base to keep this on your radar.
I realize you’re probably busy with all the other functionality you’re creating/managing.
If WordPress auto-selected a category as part of it’s typical behavior, this would have gone unnoticed. The fact that it isn’t normal behavior is what made it present as a bug.
Requiring a category ID that the user has permission to edit makes sense. However, a user can still lose access to the post by deselecting the default category and then saving/publishing. The post then uses the default category set in WordPress settings. If the user doesn’t have access to the default WordPress category, then they are unable to edit the post they just created.
I’m not sure what all you’re able to control in the WordPress admin. At a minimum, requiring the default category be assigned based on the users settings would seem necessary to make this approach work without a user being able to circumvent it. To me, a more user friendly approach would be to disable the publish/draft buttons with a small note indicating that selecting a category is required.
With that info I was able to locate the problem.
All roles are set to ‘Allow’ with the exception of one functional role I created for media access. That role was set to ‘Deny’. Once set to ‘Allow’ the problem was fixed.
