Authors Dropdown Lists Names That Can't Publish Posts

[TheJeffr0]

In Gutenberg 0.9.0, the Authors drop-down box lists names that shouldn't be listed. I expect to see only names who have the ability to publish posts and or pages on the site. The list of names I'm seeing are subscribers. I don't think users with the Subscriber role should be listed in this box.

Issue Overview

Steps to Reproduce (for bugs)

Expected Behavior

Current Behavior

Possible Solution

Related Issues and/or PRs

Todos

• Tests
• Documentation

[youknowriad]

It is possible to add "capabilities" to WP roles and there are custom roles too. So we can't exclude subscribers just because by default, they don't have the "edit posts" capability.

We need a way to fetch users by capability and the REST API is lacking such an endpoint right now.

[aduth]

Related: #2029

[aaronjorbin]

The solution also needs to consider plugins like co-authors-plus which allow the author to be something other a user.

[aduth]

Arguably duplicate of #2157. Will be working on this today.

[aduth]

From what I can discern, Co-Authors Plus disables the default post author selection, replacing it with their own meta box. I will defer this behavior to #952 (adding metaboxes) and #1352 (disabling default controls).

[justintadlock]

Does this merge take into account capabilities instead of user levels?

I have multiple plugins that address the current author drop-down issues in core. It'd be nice for the problem to simply be fixed and not rely on deprecated user levels.

[aduth]

@justintadlock It uses the same capabilities (deprecated user levels) as the current editor does, and is commented to reflect the distinction / decision:

gutenberg/editor/sidebar/post-author/index.js

Lines 34 to 44 in e0f11fb

	getAuthors() {
	// While User Levels are officially deprecated, the behavior of the
	// existing users dropdown on `who=authors` tests `user_level != 0`
	//
	// See: https://github.com/WordPress/WordPress/blob/a193916/wp-includes/class-wp-user-query.php#L322-L327
	// See: https://codex.wordpress.org/Roles_and_Capabilities#User_Levels
	const { users } = this.props;
	return filter( users.data, ( user ) => {
	return user.capabilities.level_1;
	} );
	}

I am personally open to using appropriate capabilities, but am not aware of the context and didn't feel comfortable making such a decision. It also becomes a bit more challenging to implement, as we'd need to check whether the post type assigns a custom capability for edit_posts before checking whether each user has said capability (and, in the case of custom capabilities, I'm not positive whether the REST API includes these in the user responses).

[justintadlock]

I'd suggest we reopen this until some sort of back-compat for the wp_dropdown_users_args hook on the edit post screen is handled or we have a straightforward path on fixing this.

I have 3 public and 4 non-public plugins (by a quick count) that all rely on being able to hook into the current post author drop-down and make sure the correct users are presented. My primary concern is for 1,000s of users and several clients.

Essentially, we have an existing core issue. But, plugin authors have a hook for working around this core issue. Now, there's no hook but the issue remains.

Here's a tutorial I've written for correcting this in the current version of WP: https://themehybrid.com/weblog/correcting-the-author-meta-box-drop-down

I'm not familiar enough with the REST API to even know where to begin with this on that front. You shouldn't need to check each user; just query by role__in. Additionally, I'd want to check the edit_posts, publish_posts, and create_posts caps as a default. See the post above. If that can be translated to the REST API, it shouldn't be tough.

Sorry if I'm taking this ticket too far out of scope. Perhaps I should open a different one to address this. I just jumped on this one after a search and not wanting to open a new ticket if unnecessary.

[aduth]

Some related considerations at #2157 which arguably should not be closed, since its a legitimate request for additional REST API querying. Per your tutorial, if we could determine roles associated with a particular capability, we could query from the endpoint by role, but these associations too are not available from the REST API.

The need to preserve the behaviors of existing hooks in the context of increasingly browser-based (JavaScript) UIs is a much bigger discussion than just the one you mention, and admittedly it's not one with a great answer at the moment.