[Vladimir]

Do you place this menu item to the front-end to just to show the page content to the linked user? Will it be allowed to user A see the content of the page from user B or access to the page view should be isolated for every page: one page – one user?

Or this is about the back-end and user will be capable to edit this single page?

[Vladimir]

Could you give me more details what do you wish to achieve? Roles by definition are the groups of users with the same permissions set. So 200 users with unique roles, finally 200 roles is little beyond the usual permissions model. WordPress is not designed for the very large quant of roles:
– all roles are loaded to the memory at once;
– Roles a listed as the views at the top of users list. Imagine how the “Users” page will be looked with 200 views links at the top. With 1 user at every view such views will have no sense
– Role selection user interface is realized as a drop-down list at the most of places including User Role Editor itself. So such controls will become unusable with 200 roles inside.

May be you need to re-design your idea and use some other WordPress feature, e.g. user metadata, etc. to differentiate users from each other?

One of potential variants: it’s possible to assign some unique capability to every user directly, not via role. It depends where do you plan to use this flag/value. Will it be really used as the part of permissions system or for some other purpose, like reporting, classification, etc.?

[Vladimir]

Hi Michal,

Does users exist at the site and you need to assign them some role?
Will it be the only (primary) role or you wish to add this role to one which user has already?

[Vladimir]

Thanks for this note. I introduced some changes to the hosting environment yesterday. It involved a switching to another SSL certificate. I missed a problem with CA certificates somehow.

I re-uploaded SSL certificate data to the server with CA certificates data together. A problem should be resolved. Try to open “Settings->User Role Editor” and check the license key stated.

[Vladimir]

Hi,

1st of all, nothing was changed at the user interface / background processing of user requests at “Admin menu access” add-on with 4.29 update. As earlier plugin sends standard jQuery AJAX request to the web server and gets back the HTML data to fill the form shown at the modal dialog window.

Is there any chance to get more detailed information what thing in the AJAX request is not liked by your antivirus. May be some information from the antivirus logs?

Does antivirus block other add-on buttons like “Posts Edit”, “Posts View”, “Meta Boxes” too?

[Vladimir]

Can that user edit the same post at the back-end?
What plugin do you use for front-end post form?

[Vladimir]

Let me know if you still need a custom decision for the ‘wp-lister’ plugin product search problem when you restrict access to admin menu using “block not selected” model.
It’s possible to provide by adding wp-lister parameters to the list of allowed parameters for this URL admin.php?page=wplister.

Compare, you allowed the at admin menu access to menu item with this URL
admin.php?page=wplister
but when we try to search a product, plugin try to use this URL
admin.php?page=wplister&listing_status&s=some_word&action=-1&profile_id&paged=1&action2=-1

[Vladimir]

Hi,

It does not have sense to set any restriction to the user or role if you allow him full access to the plugins: deactivating plugins, installing new plugins use can get full access to the site. The same is right if you give to a user a full access to the User Role Editor.

If you need to provide a restricted access to the WordPress admin back-end, first of all restrict it revoking unneeded user capabilities from the role. Leave capability at the role just in case user can not access some menu item without it.

I created another test role () at your site for demonstration and excluded from it almost all user capabilities you blocks with “Admin Menu”. Just after that I blocked the rest unneeded menu items with “Admin Menu”.

There are much less menu items to block. So, in order to provide you a quick decision for the product search problem with ‘wp-lister’ plugin, I blocked admin menu items for new role with “Block selected” model. When you block menu items using ‘block selected’ URE blocks just them and does not try to block others.
When you use “block not selected” URE compares full URLs, taking in account all parameters and, even if the main menu link is allowed, but you try to open it with the additional parameters, URE may block it, if parameters are not found in the list of allowed parameters. This is a reason why “product search with module” via wp-lister does not work currently with “block not selected” model.

Please test if user with new restricted role has the access, which you try to configure.

[Vladimir]

>> I want to give them all the access but im restricting the functions via the ADMIN MENU if that make sense.

Good point. I see that the latest update in this part excluded users with “delete_users” capability from the scope of “Admin access menu” and other add-ons because of WordPress’s built-in is_super_admin() function counts them as superadmin users under single site WordPress.
I will rollback this change with a next update. For the time being you may replace is_super_admin() method in the includes/classes/ure-lib.php file with this version:

/**
     * Returns true if user has a real super administrator permissions
     * It takes into account $this->raised_permissions value, in order do not count a user with temporally raised permissions 
     * of a real superadmin under WP Multisite
     * For WP Singlesite superadmin is a user with 'administrator' role only in opposite the WordPress's is_super_admin(),
     * which counts any user with 'delete_users' capability as a superadmin.
     * 
     * @param int $user_id
     * @global WP_User $current_user
     * @return boolean
     */
    public function is_super_admin($user_id = false) {
                
        if (empty($user_id)) {
            $user = wp_get_current_user();
            $user_id = $user->ID;
        } else {
            $user = get_userdata($user_id);
        }
        if (!$user || !$user->exists()) {
            return false;
        }
        
        if ($this->multisite && !$this->raised_permissions && is_super_admin($user_id)) {
            return true;
        }
        
        if (!$this->multisite && $this->user_has_capability($user, 'administrator')) {
            return true;
        }                
        
        return false;
    }
    // end of is_super_admin()

[Vladimir]

1. Does, a new role contain ‘delete_users’ capability? User Role Editor Pro does not apply restrictions to the superadmin users. It uses WordPress built-in is_super_admin() function to check this. WP checks ‘delete_users’ capability to define if not multisite WP user is super admin or not.

2. You may send a copy of wp-lister plugin to support [at-sign] role-editor.com
I will test and make suggestion on the issue.

[Vladimir]

Hi,

Yes, 4.29 contains the fix for the search issue.

I confirm, the admin menu access data should not be changed with this update. Please re-check “Admin menu” settings for the role. Are they in place?

[Vladimir]

Right, you need to activate the “Posts edit access restrictions” add-on.

I thought you activated it after reading this “…only be able to edit their Inventory posts…”.

[Vladimir]

If user should edit just his own data remove ‘edit_others_inventorys’, ‘delete_others_inventorys’.
To hide from the listings the items created by other authors open ‘Posts Edit’ for the role and turn ON the “Own data only” checkbox.

[Vladimir]

‘Yes’ on both questions.

[Vladimir]

Thanks.

Temporal workaround: You may give ‘manage_options’ to the role for this user and use “Admin menu access” add-on to block extra menu items which will become available to the user after that.

Investigate a problem at the dev. copy. Try to deactivate all plugins (may be except one which creates a CPT inventory if you use some). Will it change situation?

[Author]

Posts