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

[Genesis2001]

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.

[scribu]

Related: #16714

[nacin]

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

[Genesis2001]

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.

[nacin]

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.

[Genesis2001]

'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]

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.

[alexkoti]

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]

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

[bynicolas]

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" );
  }
}

[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

[Goback2]

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

[manfcarlo]

#57062 was marked as a duplicate.