[Vladimir]

Yes, URE works with edit restrictions by term ID exactly this way, as you described.

Thank you for the suggestion. I will take it into account with one of the future updates.

[Vladimir]

Sure, URE does not restrict access to content for users with ‘administrator’ role, thus, it does not show “Posts/pages edit restrictions” section at such user profile.

If you need apply edit restrictions for such power user, grant him custom role with less permissions.

[Vladimir]

Hi,

Thanks for the good feedback.
You can use the ure_auto_access_child_pages custom filter to exclude automatic adding off child pages to the list of restricted pages.

[Vladimir]

“Page/Post Editor Restrictions” is shown at user profile only for user who really can edit posts and/or pages. Thus,
1st, provide for a user edit access to the pages which you plan to allow him to edit.
2nd, add edit restriction criteria.

[Vladimir]

Did you block any post meta boxes for this role? If Yes, try to remove blocking and make another test. If that will help you can play with meta boxes one by one to isolate which meta box blocking causes this JS error.

[Vladimir]

My test showed that user with custom role, which includes just ‘edit_posts’, ‘publish_posts’, ‘edit_published_posts’ sees and can use “Use the Divi Builder” button at the back-end post editor page.

Divi builder uses JavaScript intensively. I suppose that some JavaScript error may take place in the post editor page. Look at the browser JavaScript console for the critical red colored error messages.

[Vladimir]

It seems that Woffice has updated user interface for bbPress with extended functinality. Can get access to its copy for testing? If Yes, share it via DropBox or similar with support [at-sign] role-editor.com

[Vladimir]

Upload a .zip to DropBox, Google Drive or similar service and send the link to support [at-sign] role-editor.com

[Vladimir]

Re-check if needed option is enabled for a role inside Divi’s internal Role Editor.

If it will not help, can you share the latest version of Divi?

[Vladimir]

Forum deletion is available via back-end only by default. Forums menu is available at wp-admin to user with ‘bbp_forums_admin’ capability.

Thus I’m wonder how it’s possible for your participant to create and delete forums. Does your theme add additional controls at front-end related to forum management?

[Vladimir]

Please read more exact answer here.

[Vladimir]

OK.

In general ‘delete_others_topics’ should allow to delete topic created by other user. User without this capability should be able to delete own topics only.

Do you use a role provided by bbPress, like participant? Or do you grant bbPress capabilities to a custom role?

Check full list of capabilities available to your user. Go to Users and click ‘Capabilities’ link under the user row. Click ‘Granted Only’ checkbox, make screenshot and send a link to it here or screenshot itself to support [at-sign] role-editor.com.

[Vladimir]

‘Newsletter’ plugin was written in special way: it defines admin menu items with virtual capability ‘exist’ which available to any user.

‘Newsletter’ applies/checks permissions before it defines admin menu items. It’s not friendly to the WordPress user capabilities system. It uses directly WordPress built-in roles: administrator or editor (if it’s allowed at the plugin settings page – “Enable access to blog editors”. Parts of menu is available for the ‘administrator’ role only:

function is_allowed() {
        return current_user_can('administrator') || $this->options['editor'] == 1 && current_user_can('editor');
    }

    function admin_menu() {
        if (!$this->is_allowed()) return;
       
        add_menu_page('Newsletter', 'Newsletter', 'exist', 'newsletter_main_index', '', plugins_url('newsletter') . '/images/menu-icon.png', '30.333');

        $this->add_menu_page('index', __('Dashboard', 'newsletter'));
        $this->add_admin_page('info', __('Company info', 'newsletter'));
       
        if (current_user_can('administrator')) {
            $this->add_menu_page('welcome', __('Welcome', 'newsletter'));
            $this->add_menu_page('main', __('Settings and More', 'newsletter'));
            $this->add_admin_page('smtp', 'SMTP');
            $this->add_admin_page('status', __('Status', 'newsletter'));
        }
    }

So User Role Editor will not help you with access to this plugin for a custom role. It would be possible only after direct editing of the code above and other.

[Vladimir]

resume_plugins and `resume_themes’ capabilities are not created by wordpress as all other WP built-in user capabilities. This capabilities are added by WordPress to the user automatically in case user has correspondent WP default capability:

/**
 * Filters the user capabilities to grant the 'resume_plugins' and 'resume_themes' capabilities as necessary.
 *
 * @since 5.2.0
 *
 * @param bool[] $allcaps An array of all the user's capabilities.
 * @return bool[] Filtered array of the user's capabilities.
 */
function wp_maybe_grant_resume_extensions_caps( $allcaps ) {
	// Even in a multisite, regular administrators should be able to resume plugins.
	if ( ! empty( $allcaps['activate_plugins'] ) ) {
		$allcaps['resume_plugins'] = true;
	}

	// Even in a multisite, regular administrators should be able to resume themes.
	if ( ! empty( $allcaps['switch_themes'] ) ) {
		$allcaps['resume_themes'] = true;
	}

	return $allcaps;
}

As you can see from the code above, user with ‘activate_plugins’ automatically can ‘resume_plugins’ and user with ‘switch_themes’ automatically can ‘resume_themes’.

[Vladimir]

Hi James,

Gravity Forms adds menu for add-on if current user has access to this add-on. Permission is checked this way:

if ( $this->current_user_can_any( $this->_capabilities_plugin_page ) ) {
	//creates the subnav left menu
	add_filter( 'gform_addon_navigation', array( $this, 'create_plugin_page_menu' ) );
}

current_user_can_any() function works this way:

public static function current_user_can_any( $caps ) {

	if ( ! is_array( $caps ) ) {
		$has_cap = current_user_can( $caps ) || current_user_can( 'gform_full_access' );

		return $has_cap;
	}

	foreach ( $caps as $cap ) {
		if ( current_user_can( $cap ) ) {
			return true;
		}
	}

	$has_full_access = current_user_can( 'gform_full_access' );

	return $has_full_access;
}

Thus, _capabilities_plugin_page property is a key for access to the plugin. If user does not can _capabilities_plugin_page, code checks if user has older style full access to the GF plugin – ‘gform_full_access’.

_capabilities_plugin_page property of the base class for any add-on GFAddOn is empty by default:

	/**
	 * @var string|array A string or an array of capabilities or roles that have access to the plugin page
	 */
	protected $_capabilities_plugin_page = array();

“Pardot Connector” (PC) plugin does not define this property too. Thus the only way to get access to PC plugin when role editor plugin is active and GF uses detailed capabilities list instead of the single gform_full_access is to grant to a role gform_full_access.

Workaround (fix): add $_capabilities_plugin_page property to PC plugin, like this (look at the last line in the code fragment below):

class PardotGravityFormsConnectorAddOn extends GFFeedAddOn {

	protected $_version = PARDOT_GRAVITYFORMS_CONNECTOR_VERSION;
	protected $_min_gravityforms_version = '1.9';
	protected $_slug = 'pardot-gravityforms-connector';
	protected $_path = 'pardot-gravityforms-connector/pardot-gravityforms-connector.php';
	protected $_full_path = __FILE__;
	protected $_title = 'Pardot Gravity Forms Connector';
	protected $_short_title = 'Pardot Connector';
        protected $_capabilities_plugin_page = 'gravityforms_edit_settings';

This way ‘administrator’ role will get access to PC plugin without ‘gform_full_access’ capability.

[Author]

Posts