Skip Navigation

[Resolved] Toolset Access causing 403 errors for custom role

This support ticket is created 5 years, 1 month ago. 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.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 1 reply, has 2 voices.

Last updated by Beda 5 years, 1 month ago.

Assisted by: Beda.

Author
Posts
#1384349

I created a new post type called "Jobs" with two custom field sets containing some fields each.
I created a new role, called HR manager which is supposed to be only able to see and manage job postings or "Jobs"

In the custom roles tab of the Access Control page, I changed the permissions for the "HR Manager Role" as follows:

Other Capabilities
[x] level_0
[x] level_1
[x] level_2
[x] level_3
[x] level_4
[x] level_5
[x] level_6
[x] level_7
[x] level_8
[x] level_9
[x] read

Under Post types Pages, Posts and Jobs are managed by access

The HR manager has Read access to both posts and pages, but no editing capability. (I don't want them editing pages or posts)
The HR Manager has Publish, Delete any, Edit any, Delete own, Edit own, Preview any, Read permissions for the Jobs custom post type.

Under Types Fields,

The HR Manager has access to modify fields in Edit Page and View Fields in Edit page.

__

Despite this, when logged in as an HR Manager I am seeing the following errros in the console when editing a custom post (using the block editor)
- Failed to load resource: the server responded with a status of 403 () /wp-json/wp/v2/taxonomies?per_page=100&context=edit&_locale=user:1 Failed to load resource: the server responded with a status of 403 ()
- data.min.js?ver=4.4.0:1 Uncaught (in promise) Response
- Failed to load resource: the server responded with a status of 403 () /wp-json/wp/v2/users/?who=authors&per_page=100&_locale=user:1 Failed to load resource: the server responded with a status of 403 ()
- Uncaught (in promise) Response data.min.js?ver=4.4.0:1 Uncaught (in promise) Response
- Uncaught TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at Object.success (seopress-counters.min.js?ver=3.7.4:1)
at i (jquery.js?ver=1.12.4-wp:2)
at Object.fireWith [as resolveWith] (jquery.js?ver=1.12.4-wp:2)
at x (jquery.js?ver=1.12.4-wp:4)
at XMLHttpRequest.c (jquery.js?ver=1.12.4-wp:4)
seopress-counters.min.js?ver=3.7.4:1 Uncaught TypeError: Cannot convert undefined or null to object
- Failed to load resource: the server responded with a status of 403 () /wp-json/wp/v2/themes?status=active&_locale=user:1
- Uncaught (in promise) data.min.js?ver=4.4.0:1 Uncaught (in promise) Object
___
These errors only show up for user roles created by Access
I have no conflicting permissions management plugins enabled
I realize there is an SEOPress related error, but that is caused by a 403 error, most likely caused by access restricting access to a needed resource or not including a permission by default.

#1384789

Can you elaborate why you had to alter the Custom Capabilities (which are protected from edits until you unlock them) for the control of Post Types?
This is not required usually, and I suggest resetting them unless you need this for very particular reasons.

In any case, they would not directly affect errors in the console or error log, neither "basic" Access Rules would change this
Errors are caused because of mistakes, or conflicts in the code.
I understand the status of 403 suggests a capability issue, but it would then relate to Taxonomies, REST and what seems to be some SEO Field or plugin function, as the error says.
However - when you remove access by user from Post Types or such, Access doesn't handle this by throwing status of 403, instead, it will remove/hide/stop access from those elements altogether.

What can be is that due to the custom role created, and other plugins and codes used, they may expect more rights for users generally accessing content with it.
I cannot answer this directly as first, I would need to know if the issue happen with just Access as well - but no other software or plugin, and if so, how precisely to replicate it.

I tried locally with a new custom user role with only the caps you mention, and I can't see such errors on Custom Post or native Posts, with or without custom fields. However it might be I miss crucial steps to this issue, can you provide them?

Thanks!