WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 6 weeks ago

#16808 reopened defect (bug)

Insufficient permissions for custom post type management and custom role/caps

Reported by: Genesis2001 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Role/Capability Keywords: needs-patch
Focuses: Cc:

Description (last modified by nacin)

I asked a question over at StackExchange about this. Went into their chat room to talk to a few people and came to the conclusion I need to post this ticket.

---

When accessing an admin page located at post-new.php with a custom post type on a user that's in a custom role that has the available permission to "Add New", you get "You do not have sufficient permissions to access this page."

		$post_caps = array( 'delete_post' => 'argus_admin', );
		$visitor_caps = $post_caps;
		$visitor_caps = array_merge( $visitor_caps, array(
				'edit_post' => 'argus_visitors',
				'read_post' => 'argus_visitors',
				'edit_posts' => 'argus_visitors',
				'edit_others_posts' => 'argus_visitors',
				'publish_posts' => 'argus_visitors',
				'read_private_posts' => 'argus_visitors',
			));

		$v_args = array(
			'labels' => array (
					'name' => 'Visitors',
					'singular_name' => 'Visitor',
					'add_new_item' => 'Register New Visitor',
				),
			'public' => true,
			'publicly_queryable' => false,
			'exclude_from_search' => true,
			'show_ui' => true,
			'show_in_menu' => 'argus',
			//'show_in_menu' => false,
			'hiearchical' => false,
			'supports' => array( '' ),
			'capabilities' => $visitor_caps,
			'register_meta_box_cb' => array ( &$this, '_wp_visitor_meta_box_cb' ),
		);
		
		register_post_type( 'visitor', $v_args );

I've tested it with 3.0.4 and it worked flawlessly. However, when in 3.1, it doesn't want to work.

Attachments (4)

argus.php (1.3 KB) - added by dd32 6 years ago.
trac-16808.php (3.9 KB) - added by alexkoti 5 years ago.
16808.patch (1.5 KB) - added by alexkoti 5 years ago.
16808-tests.php (9.0 KB) - added by alexkoti 5 years ago.
Test plugin, with multiple CPTs and different caps and show_in_menu configurations

Download all attachments as: .zip

Change History (17)

#1 @scribu
8 years ago

Related: #16714

#2 @nacin
8 years ago

  • Description modified (diff)

#3 follow-up: @nacin
8 years ago

What capabilities does a visitor have? Simply argus_visitors and no other capabilities?

#4 in reply to: ↑ 3 @Genesis2001
8 years ago

  • Cc zack@… added

Replying to nacin:

What capabilities does a visitor have? Simply argus_visitors and no other capabilities?

Hmm? The Visitor CPT has all caps set to a single permission (K.I.S.S.) "argus_visitors". If that's what you mean, yes.

#5 @nacin
8 years ago

Seems like it might have to do with show_in_menu. What is 'argus'? Keep in mind show_in_menu is new in 3.1 so that might be your change.

#6 @Genesis2001
8 years ago

'argus' is a custom menu I have which I use to group my CPT's together instead of all-over my Admin CP.

		add_menu_page( 'Argus', 'Argus Admin', 'argus', 'argus', array( &$this, '_wp_argus_main_panel' ), '', -1 );
		add_submenu_page( 'argus', 'Argus Administration', 'Control Panel', 'argus', 'argus', array( &$this, '_wp_argus_main_panel' ) );

I use the same slug for both menus there because of the duplicate menu item that gets generated. I did however test it by changing the submenu to 'arguscp' and that created a second sub-menu (undesired if add_menu_page also creates an identical sub-menu underneath itself). Same behaviour occurred when I did so ("Insufficient Permissions" error)

@dd32
6 years ago

#7 @dd32
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Could not duplicate. Potentially some code was being run too early, which would cause some of the suggested issues.
Attached mu-plugin that I used to test with.

#8 @alexkoti
5 years ago

Hi, I managed to create a test plugin that can reproduce the problem. Tested in WordPress 4.1 running Twenty Fifteen theme, without other plugins.

When a user have only the cap required for CPT (and do not have permission to create default posts), and at the same time, this CPT is configured with 'show_in_menu' to be displayed in another admin page, the user will not be allowed to add a new CPT.

The error is show at line 319 in wp-admin/includes/menu.php:

wp_die( __('You do not have sufficient permissions to access this page.') );

Which is triggered by user_can_access_admin_page() in wp-admin/includes/plugin.php at line 1703

if ( isset( $_wp_submenu_nopriv[$key][$pagenow] ) )
        return false;

If the user have permission to add regular posts, the above condition returns true.
Removing 'show_in_menu' and the subscriber can add new CPT.

Possible solutions:
1) Add aditional submenu page in wp-includes/post.php function _add_post_type_submenus(), with post-new.php?post_type=$ptype:

add_submenu_page( $ptype_obj->show_in_menu, $ptype_obj->labels->add_new_item, $ptype_obj->labels->add_new, $ptype_obj->cap->edit_posts, "post-new.php?post_type=$ptype" );

2) Modify user_can_access_admin_page() to allow user, or get_admin_page_parent() to define the admin page as parent.

At the moment, is possible to workaround adding the post-new menus in 'admin_menu' hook:

add_action( 'admin_menu', 'trac16808_add_post_type_submenus', 99 );
function trac16808_add_post_type_submenus() {
        foreach ( get_post_types( array( 'show_ui' => true ) ) as $ptype ) {
                $ptype_obj = get_post_type_object( $ptype );
                // Sub-menus only.
                if ( ! $ptype_obj->show_in_menu || $ptype_obj->show_in_menu === true )
                        continue;
                add_submenu_page( $ptype_obj->show_in_menu, $ptype_obj->labels->add_new, $ptype_obj->labels->add_new_item, $ptype_obj->cap->edit_posts, "post-new.php?post_type=$ptype" );
        }
}

This will pass the verifications in user_can_access_admin_page();

@alexkoti
5 years ago

@alexkoti
5 years ago

@alexkoti
5 years ago

Test plugin, with multiple CPTs and different caps and show_in_menu configurations

#9 @alexkoti
4 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

#10 @SergeyBiryukov
4 years ago

  • Milestone set to Awaiting Review

#11 @bynicolas
3 years ago

This also happens on the edit.php page when a CPT is set not to use the Add New UI when registered using

'capabilities' => array(
  'create_posts' => false
  ),

and no other menu item is created (no custom tax, settings, etc.)
This happens for custom roles that don't have WP core capabilities (at least edit_posts and publish_posts) enabled.

The issue is similar but the workaround needed to be updated since in this case it did not fail at line 1703 (now line 1725 in WP 4.5.3) but rather at line 1716

This worked for me

add_action( 'admin_menu', 'trac16808_add_post_type_submenus_edit', 99 );
function trac16808_add_post_type_submenus_edit() {
  foreach ( get_post_types( array( 'show_ui' => true ) ) as $ptype ) {

          $ptype_obj = get_post_type_object( $ptype );

          if ( $ptype_obj->cap->create_posts )
            continue;

          add_submenu_page( $ptype_obj->show_in_menu, $ptype_obj->labels->all_items, $ptype_obj->labels->all_items, $ptype_obj->cap->edit_posts, "edit.php?post_type=$ptype" );
  }
}

#12 follow-up: @tripflex
3 years ago

I can confirm this is still (as of 4.6), and has been an issues for years now, can we not get a patch pulled in on this? Very frustrating having to allow capabilities on users they should not have (on regular posts) just to not have this problem

#13 in reply to: ↑ 12 @Goback2
3 years ago

  • Keywords needs-patch added

Replying to tripflex:

I can confirm this is still (as of 4.6), and has been an issues for years now, can we not get a patch pulled in on this? Very frustrating having to allow capabilities on users they should not have (on regular posts) just to not have this problem

Same here

Note: See TracTickets for help on using tickets.