[Vladimir]

Hi,

Thanks for the feedback.
URE Pro supports auto-update from the very begin:
https://storage.googleapis.com/role-editor/downloads/support/ure-autoupdate-plugins.png
https://storage.googleapis.com/role-editor/downloads/support/ure-autoupdate.png

[Vladimir]

Please re-test. It’s seems my service provides right answer for the older curl versions now.
At least an error was gone when I try to test from my 1and1 server.

[Vladimir]

Please ignore a suggestion you may receive by mail – it’s testing is not finished yet.

[Vladimir]

In general problem may be resolved by updating server side curl version to one which support automatic selection of TLS v. 3. I agree that it’s a problem with a shared hosting. Fortunately, I can reproduce a problem at my 1and1 hosted server and search a solution currently.

[Vladimir]

Hi,

Earlier versions did not check license key after you updated it.

This issue could be related to the older version of system software (PHP, curl) installed at your hosting server:
http://unix.stackexchange.com/questions/192944/how-to-fix-curl-sslv3-alert-handshake-failure

Try input into browser this URL:
https://www.role-editor.com/update?action=get_metadata&slug=user-role-editor-pro&license_key=your-license-key-here

Does it work without error?

URE just calls wp_remote_get() with this URL. A problem with SSL connection occurs at PHP or even deeper system level.

[Vladimir]

User Role Editor Pro will provide it.

If you give to a user role ‘edit_others_posts’ capability, you have these variants how to restrict his access to the posts list:

1) input to a user profile the only ID of the post from other author – user will can edit just the only post with that ID (or the list of posts in you input multiple IDs).

2) input this user ID to the ‘with author user ID (comma separated)’ field. User will can see and edit its own posts only at WordPress the admin backend.

[Vladimir]

Thanks. I reproduced a problem and will develop a fix for it.

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

[Author]

Posts