[Vladimir]

Hi,

Give me more details. Did you use “Admin menu access” add-on to block those menu items? If yes, what is going wrong?
Does user still can open the linked URL?
Can you provide access to plugin or theme which registered those menu items/URLs?

[Vladimir]

Hi,

Do you use the latest version of URE Pro 4.47.2?
Additional options section view for the current role was not refreshed properly after other current role selection until version 4.47.1. So it would show not real value set for the current role.

Will user see top admin menu bar if you deactivate temporally all plugins? If yes, activate plugins back one by one to isolate a reason.

[Vladimir]

Hi,

Look if “Show Toolbar when viewing site” option is turned ON at this user profile page.

[Vladimir]

This change may produce PHP fatal error in some cases as URE Pro v. 4.47.2 uses some PHP functions available at PHP 5.4 only.

I recommend to revert installed URE Pro to the previous version – 4.47.1. You can get it from the same download page – scroll to “Previous versions” section and select version from the list. Just replace user-role-edito-pro folder with files from 4.47.2. There was no any changes in the used data format.

[Vladimir]

Hi,

If a user has more than 1 this role assigned, then look at the “Hide admin bar” option for other role too.

If you have WooCommerce activated then read this article.

[Vladimir]

Hi Jesse,

Go to “Settings->User Role Editor->Additional Modules” tab and set default values for “Content view restrictions” under “Activate content view restrictions” checkbox, like this:
– Allow;
– Any user role (logged in only).

Any new added post or page will get by default these values and will be available for the logged in users only.

[Vladimir]

Thanks for the link to the related discussion.
They discussed and tested the update routine to replace orders post_author with related customer ID during database update for v. 3.5. So you will not need to update anything manually, I hope.
Let’s wait 3.5 and see.

[Vladimir]

WooCommerce support answered to one of my clients that they plan to change this with one of the future updates and write the customer ID to the order post_author field. I’m not sure when though.
But if they will make that, it does not have sense to extract order customer ID from the post meta and make code more complex (slow) than it is now.
What do you think?

[Vladimir]

It depends from which user your orders are created, who is the author of orders. Are your customers authors of their orders?
I have a report that WooCommerce may register orders from a user with ID=1. URE edit restrictions will not help in this case. You can check this using SQL command, which shows orders list:

SELECT * FROM wp_posts where post_type='shop_order';

Look at the field ‘post_author’ value. Is this field contains different values or it is not?

[Vladimir]

Hi Phil,

You can set view restrictions by category at the role level. Look at the “Role level restrictions” part at the end of this article.

[Vladimir]

It seems that URE does not see new created page ID between of allowed pages ID list just after that page creation. The most probable reason – new page does not have parent page on that moment.
I will look if it’s correct and how to resolve this.

[Vladimir]

Hi Steven,

URE applies edit restrictions to all existing custom post type even if you input to a user profile just ID of event. If Event Calendar Pro (ECP) uses custom post type to store attendees, I may suppose that URE applies edit restrictions to it. And once user can not edit attendees, he does not see them. If my assumption is correct post type exclusion filter may help you.

To give more exact conclusion I need access to ECP plugin copy.

[Vladimir]

Variable $user is not defined inside function ure_show_additional_capabilities_section().
This version will fix the issue:

                function ure_show_additional_capabilities_section($show) {
                    $user = wp_get_current_user();
                    if (in_array('admin', $user->roles) || in_array('administrator', $user->roles)) {
                        $show = false;
                    }

                    return $show;
                }

[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.

[Author]

Posts