[Vladimir]

If a post was written by other author – user should have ‘edit_others_posts’ capability to be capable to edit that post. ‘Edit posts restrictions’ section does not give to the user additional capabilities, it narrows the existing permissions.

[Vladimir]

Hi,

Role based access management for Gravity Forms is unavailable currently.
I agree with you. This feature will be very useful. It’s in my development plan already. I hope it will be available in 1-2 months.

[Vladimir]

Thanks for the suggestion. I will do.

[Vladimir]

Thanks for letting me know. I will realize this feature for roles.

[Vladimir]

Hi Alex,

Thanks for the feedback.

Do you offer to realize this feature for roles? I thought that 1-2 such users do not require of additional layer. What quant of users are allowed to activate/deactivate plugins in your case?

[Vladimir]

Quick fix for version 4.21.1. Open wp-content/user-role-editor-pro/includes/pro/classes/posts-edit-access.php, find save_user_restrictions() function, line #313 and replace this code:

if (isset($_POST['ure_posts_restriction_type'])) {
    $posts_restriction_type = $_POST['ure_posts_restriction_type'];
    if ($posts_restriction_type!=1 && $posts_restriction_type!=2) {  // sanitize user input
        $posts_restriction_type = 1;
    }
    update_user_meta($user_id, $this->umk_posts_restriction_type, $posts_restriction_type);
}

with this version:

if (isset($_POST['ure_posts_restriction_type'])) {
    $posts_restriction_type = $_POST['ure_posts_restriction_type'];
    if ($posts_restriction_type!=1 && $posts_restriction_type!=2) {  // sanitize user input
        $posts_restriction_type = 1;
    }
    update_user_meta($user_id, $this->umk_posts_restriction_type, $posts_restriction_type);
} else {    // 'profile_update' action was fired not from the 'user profile' page, so there is no data to update
    return;
}

[Vladimir]

I repeated a problem at my test environment emulating fake data from AD.
Code after which user loses his URE created meta data is ad-integration.php, line #2784:

if ($display_name != '') {
	wp_update_user(array('ID' => $user_id, 'display_name' => $display_name));
			}

But it is correct. It just shows the bug in my own code, where I delete metadata if there is empty value of a correspondent POST array element, like this:

if (!empty($_POST['ure_posts_list'])) {
...
} else {
  delete_user_meta($user_id, $this->umk_posts_list);
}

This code is definitely fired when user profile is updated not from the web-page but via WordPress API call. So I confirm the bug in User Role Editor Pro and will develop a fix for it.

Thanks a lot for your help in discovering this issue. Update will be available in a week.

[Vladimir]

All ‘Directory Admin’ menu items are protected by ‘administrator’ role.
‘Directory’ custom post type uses the same user capabilities as a standard WordPress post does: ‘edit_posts’, etc. So you may use built-in WordPress roles (editor is enough to publish pending directories from other contributors) as the base for your own custom role to work with ‘Directory’ one.

[Vladimir]

Data input by this add-on at the user profile are stored as the user meta data at the ‘wp_usermeta’ DB table with ‘wp_ure_’ prefix.

Is there any reason it should be cleared when the users role is updated/changed?

I don’t see such reason in general. It could be possible just in case ADI plugin fully clears user meta data during its data update process. I will look into this plugin code and let you know if I find something. I could not test it myself as I don’t have AD server available for testing.

I work currently on the ‘posts edit restrictions’ for roles. It will be available soon.

[Vladimir]

Hi Pierre,

Thanks for letting me know that you found a workaround. I had write a promised code sample if you did not.

Thanks for the suggestion about categories drop-down list at the back-end posts list. I will fix this.

[Vladimir]

All posts are available for view at the front-end by default.

There is a way to restrict posts available at the front-end for view by the logged-in user:

Content view access restriction for selected roles

It does not include ‘by author ID’ feature though. I see that such option will be useful. I will add it to the some of the future versions.

Currently, it’s possible to use some tag or category as a workaround – setup such ‘Posts View’ restriction for role, assigned to this author.

If it’s not acceptable for your client I may provide a piece of code for functions.php in order users of some role will see at the front-end just the posts for which they are authors.

[Vladimir]

Hi Pierre,

Thanks for the good feedback.

If I put author ID’s in there, will this ensure that they can only edit posts by that author ID and not all other posts?

Absolutely correct. Access to the all others posts will be blocked in this case by User Role Editor.

[Vladimir]

Hi Wayne,

I suppose that some other plugin may add its own restriction. You may try to deactivate all plugins and test, if user with ‘list_users’ may open users list.

If you still will need my help on-site, send login credentials to [email protected]

[Vladimir]

Show me the screenshot of such role. Does it have access to the ‘manage_options’ capability.

I tested with standard ‘editor’ role and user does not see ‘Settings’ menu, while ‘Sharing’ under it is protected by ‘published_posts’ only.

[Vladimir]

I don’t see other quick solution. I doubt that similar problem is wide enough to take this specific configuration into account for starting URE’s global code refactoring.
Moreover, it could be resolved by changing WordPress settings.

Removing extra redirection for every page request for the live site is a quite better choice for its health/speed/SEO. It may cost to spend some time to resolve a possible problem with data preparing for the dev/stage copies in order to get such enhancement.

[Author]

Posts