[Vladimir]

I can not repeat this. ‘Other roles access’ add-on should not apply restrictions to administrator role at all. And it does at my test WordPress single site istallation.
1) created ‘webmaster’ role as a full copy of ‘administrator’ role.
2) marked ‘webmaster’ role as blocked for ‘administator’ role.
3) revoked all URE capabilities from the ‘administrator’ role.
4) created new user with ‘administrator’ role and new user with ‘webmaster’ role.
5) logged in under a new user with ‘administrator’ role.
6) this user sees user with ‘webmaster’ role as expected, – restrictions does not applied for ‘administrator’ role by design.

Give me an exact scenario to repeat the issue or send credentials for your stage copy to support email address.

[Vladimir]

I read your initial message in this topic again and paid attention that roles ID matches ‘admin’ is an exact part of ‘administrator’. It’s not a good idea to name roles this way.
WordPress stores roles list granted to a user in the text field as a serialized PHP array – string.
`WHERE meta_value like ‘%admin%’ SQL expression will return records as for the user with ‘admin’ role, as for the user with ‘administrator’ role. It may lead to the different issues.

[Vladimir]

Working on the update I changed my decision – it will be more correct to apply additional options for any role, including administrator. It will give ability for customization for any users, including admins.

This update will be available at the 1st decade of July, 2018.
Thanks again.

[Vladimir]

I confirm this information.
Additional options for role does not applied to the user with ‘ure_edit_roles’ capability, as such user can change any option for any role.
I will hide additional options for ‘administrator’ role in order theme not confuse users.

Thank you for notification about this user interface inconsistency in URE.

[Vladimir]

OK.

[Vladimir]

Is it possible to look at your site online with ‘administrator’ privileges? If yes, send user login credentials to support [at-sign] role-editor.com
If ‘no’, I will ask you to share site backup copy created with UpdraftPlus plugin via DropBox or similar service.
I will can take more deep view on a possible problem and provide you better support.

[Vladimir]

Such strict association does not exist. Any user with ‘list_users’, ‘edit_users’ can edit any other user except users with ‘administrator’ role.

Check if you applied to this role some additional restrictions – via “Other roles access” add-on, for example. Deactivate ALL URE’s add-ons for testing or even
deactivate URE and re-test. ‘ure_manage_options’ will not work at last case.

[Vladimir]

OK.

wp-admin/includes/plugin.php may be not loaded at the point you tried to call is_plugin_active(), if you called it beyond function, hooked to the action.

[Vladimir]

Error messages from the server logs will be useful in this case.
I made another test – code works without error. You can send your own functions.php to support [at-sign] role-editor.com. I will look what may be wrong with your version.

[Vladimir]

Plugins on the activation (sometimes for the 1st time only) usually add custom capabilities exactly to the ‘administrator’ role to provide for admin a full access to a plugin.

If user can install new plugin, he can get a superadmin privileges in a minute adding to the site a plugin with a special PHP code. There is no sense to set any restrictions for such user, as he can overcome them in any moment.

New plugins should be installed by the person fully responsible for the site – superadmin. Even if user will not try to become a superadmin, adding new plugin may break the site – so it is a potential large problem for the future maintenance.

“as such user is a superadmin there.” – superadmin is a “God” for this site. He can anything. There are no restrictions for him inside existing functionality. There is no sense to limit him in any manner.

[Vladimir]

Thank you for a valuable suggestion. I can not tell about date when it will be realized, but I will really consider it for the plugin functionality enhancement.

[Vladimir]

Right. I explained that URE hides ‘administrator’ role and users with ‘administrator’ role by default from any user without ‘administrator’ role at your previous topic. More – URE hides all users with administrator role from any other user with ‘administrator’ role. This protection measure does not take effect for the WordPress built-in superadmin with ID=1.

User with ‘ure_manage_options’ capability is a superadmin for User Role Editor. So admin protection does not applied for such user too.

If you wish to switch this logic off use URE’s custom filter ‘ure_supress_administrators_protection’.

add_filter('ure_supress_administrators_protection', 'switch_off_ure_administrators_protection', 10, 1);
function switch_off_ure_administrators_protection($supress_protection) {

    $supress_protection = true;
    
    return $supress_protection;
}

Similar topic was discussed at this thread.

[Vladimir]

1) URE hides ‘administrator’ role from ‘Role’ and ‘Other Roles’ drop-down lists by default.
2) URE exclude users with ‘administrator’ role from the users list by default.

It makes this for users with ‘edit_users’ capability, which do not have ‘administrator’ role.
Thus there is no sense to hide/block ‘administrator’ role via ‘Other roles access’ add-on. ‘administrator’ checkbox is disabled for this reason.

[Vladimir]

I confirm such behavior. It’s by design. URE does not apply any restrictions to a user with ‘administrator’ role for the single site WordPress installation as such user is a superadmin there.

I agree that checkboxes available for the selection at the “Other Roles” dialog window for the ‘administrator’ role may confuse a user. I will fix this with the next update.
You can change this logic under WordPress multisite, as it’s not enough to have ‘administrator’ role in order to be superadmin there. It’s possible via custom filter ure_not_block_other_roles_for_local_admin.

[Vladimir]

Pay attention, that 1st, user should have edit access to the event, in order to see it. If event was created by other user, this user should be able ‘edit_others_events’ or similar capability. In other case such event will be hidden from user, even if you allow valid category ID for him.

[Author]

Posts