[Vladimir]

Test beta 1 of version 4.56.1. It’s available for from the Download page after login.

[Vladimir]

Hi,

Comment lines with tabs to leave, and uncomment lines with tabs you wish to hide/remove.

add_filter('woocommerce_settings_tabs_array', 'change_wc_settings_tabs', 30);

function change_wc_settings_tabs( $pages ) {
    

    $user = wp_get_current_user();
    if ( in_array( 'orders_manager', $user->roles ) ) {
        //unset( $pages['general']);      // General
        //unset( $pages['products']);     // Products
        //unset( $pages['tax']);          // Tax
        unset( $pages['checkout']);       // Payments
        //unset( $pages['account']);        // Accounts & Privacy
        //unset( $pages['email']);          // Emails
        //unset( $pages['advanced']);       // Advanced
    }
  
  return $pages;
}

[Vladimir]

I found the reason why unfiltered_html works fine from the classic editor, but does not from the Gutenberg. Fortunately, it belongs not to the Gutenberg, but to URE Pro itself. It applied ‘unfiltered_html’ for WordPress admin only using is_admin() function. But Gutenberg saves changes via WP Rest API using AJAX. Admin screen is not defined in this case.
I will include the fix into the next update.
Quick fix: open user-role-editor-pro/pro/includes/classes/user-role-editor-pro.php, go to the line #263 (located inside function allow_unfiltered_html()) and replace this code:

if ( !$multisite || !is_admin() ||          

with

if ( !$multisite ||

to get finally

if ( !$multisite ||
     ( defined( 'DISALLOW_UNFILTERED_HTML' ) && DISALLOW_UNFILTERED_HTML ) ) {
    return;
}

[Vladimir]

I made my own test and confirm – Gutenberg ignores unfiltered_html even with special option activated, while classic editor does not. I will investigate if I it’s possible to fix this via some WordPress hook.

[Vladimir]

Please confirm that you turned ON the ‘Enable “unfiltered_html” capability’ checkbox at the “Network admin->Settings->User Role Editor->Multisite” tab.

[Vladimir]

bbPress checks capability to create topic own way, not as WordPress itself does for any post type:

if ( current_user_can( $post_type_object->cap->create_posts ) ) {

That’s why URE Pro currently does not change bbPress logic to use ‘create_topics’ as expected, even with correspondent option is turned ON at URE’s settings. I will include the fix to the next update.

Thank you for pointing me this. You may use the solution offered above as a temporal workaround until I will publish the version of URE Pro which will support this correctly.

[Vladimir]

bbPress checks if user can create topic ising the function from the bbpress/includes/users/template.php, #2253

function bbp_current_user_can_access_create_topic_form() {

	// Users need to earn access
	$retval = false;

	// Always allow keymasters
	if ( bbp_is_user_keymaster() ) {
		$retval = true;

	// Looking at a single forum & forum is open
	} elseif ( ( bbp_is_single_forum() || is_page() || is_single() ) && bbp_is_forum_open() ) {
		$retval = bbp_current_user_can_publish_topics();

	// User can edit this topic
	} else {
		$retval = current_user_can( 'edit_topic', bbp_get_topic_id() );
	}

	// Filter & return
	return (bool) apply_filters( 'bbp_current_user_can_access_create_topic_form', (bool) $retval );
}

It shows that some time bbPress checks publish_topics, some times ‘edit_topics. But the good news that bbPress offers custom filter bbp_current_user_can_access_create_topic_form where you can check you own capability, like ‘create_topics’ and participant role will can not create topics until you will not grant ‘create_topics’ to it. Like below:

add_filter( 'bbp_current_user_can_access_create_topic_form', 'bbp_current_user_can_create_topic', 10, 1 );
function bbp_current_user_can_create_topic( $ret_val ) {
    $ret_val = current_user_can( 'create_topics' );
    
    return $ret_val;
}

You may add this code to the active theme’s functions.php file of or setup it as a Must Use plugin.

[Vladimir]

Hi,

I confirm the issue. While I added visual changes to the permissions dialog I did not added support for them to the access restriction code. So update was not finished. That’s my fault. Just discovered that yesterday. I will make the fix available in a week.

[Vladimir]

No, you can not manage access to the different tabs inside the page using URE.
It’s just about to allow the URL edit.php with ‘tab’ parameter inside (with any value).

To permit role ‘orders’ to edit gift cards add ‘edit_product’ capability (from ‘Products’) group to this role. I can not explain the logic. Debugger just showed that YGC plugin defines it own custom post type this way.

[Vladimir]

Make the search as admin and look at the URL parameters, try to add them into the list of allowed parameters for this custom post type menu item link:

Admin menu URL parameters white list

[Vladimir]

Hi Erik,

I resolved the issue with this redirection. It’s not obvious though. YITH defines “Gift Cards” menu item as /wp-admin/admin.php?page=yith_woocommerce_gift_cards_panel, but redirects it to the really used /wp-admin/edit.php?post_type=gift_card&yith-plugin-fw-panel-skip-redirect=1
So I had to register the yith-plugin-fw-panel-skip-redirect and tab URL parameters for `edit.php’ as allowed for ‘edit.php’ link:

[Vladimir]

Can I look at your site with admin privileges? If Yes, send URL, user/password to support [at-sign] role-editor.com

[Vladimir]

Hi,

Just to check, will issue go away if you unblock access to the built-in ‘Posts’ menu item?

[Vladimir]

Did you block some menu items for this role using “Admin menu”? If Yes and use ‘not selected’ blocking model, try to switch to ‘selected’ as a workaround or read carefully last part of the documentation article “Technical details” in relation to “Block not selected” variant.

[Vladimir]

Hi,

Is it possible to look at your site with administrator privileges? If ‘Yes’, send user/password and site URL to support [at-sign] role-editor.com

[Author]

Posts