REST API: no equivalent for `who=authors` to display potential authors

[iseulde]

Currently there is no query argument on the users endpoint to only display users who have the right capabilities to become an author. This would be useful to create a dropdown of users for an edit post page, equivalent to the author dropdown on the wp-admin/post.php page.

These issues for the Gutenberg editor illustrate the problem further:

• ​https://github.com/WordPress/gutenberg/issues/2157
• ​https://github.com/WordPress/gutenberg/issues/3010

Without this query argument we have two options, both with limitations:

• Use /wp/v2/users?context=edit, and filter on the client side by user level, but this can't be done for non-admins.
• Use /wp/v2/users?roles=author,editor,administrator, but this wouldn't catch roles created by plugins, or capability changes by plugins.

[swissspidy]

See #16841. We should query for capabilities, not roles.

[iseulde]

Yeah. ​https://github.com/WordPress/gutenberg/issues/3010#issuecomment-336192011

[joehoyle]

Perhaps a way to do /users?capability=publish_posts or something would be best here? I don't like ?who=authors for one thing :D.

[swissspidy]

@joehoyle Please check out https://core.trac.wordpress.org/ticket/16841#comment:49.

[jbpaul17]

@joehoyle any disagreement with setting this for a milestone=5.0 and keyword=early so we can aim to have it ready early on during the Gutenberg merge?

[dd32]

Bumping this to 5.0 since Gutenberg needs this in some form anyway.

/users?capability=publish_posts seems like it'd be most consistent given there exists /users?roles=author already, however, it seems like it could create an expensive query fast :)

It's worth noting that who=authors currently doesn't base on roles/capabilities (as per #16841), it's based on user_level != 0.
So for Gutenbergs usage it'd probably be a query like /users?capability=level_1,level_2,level_3,..., level_10 currently (and in future, ?capability=$some_custom_field_from_post_type_description). It could also be implemented as /users?capability_not=level_0.

[danielbachhuber]

For the purposes of querying for users who can be assigned to posts, I think we should introduce a who query argument which accepts author. This is the simplest way to emulate the classic editor behavior for wp_dropdown_users(). We can change the underlying implementation at some future date if we need to.

[swissspidy]

Would ​https://github.com/xwp/wordpress-develop/pull/286 be a viable underlying solution? If so, I‘ll try to get it over the finish line asap. It‘s the patch I was working on for #16841.

[danielbachhuber]

I still think the REST API should expose a who query parameter that's passed directly through to WP_User_Query.

While the underlying implementation of user_level != 0 is awful, now isn't the best time to try to refactor it.

It's worth noting capabilities can be modified at runtime, which makes them inherently unpredictable to query against.

[danielbachhuber]

42202.1.diff introduces who=authors as a query parameter for GET wp/v2/users.

Any WordPress user who can edit_posts of a post type with show_in_rest=true can query for authors. This maps to current WordPress behavior where a WordPress user who can view the Manage Posts view for a post type can see any WordPress user assigned to a post (whether published or draft).

This implementation, over restricting who=authors to users with list_users, gives us future flexibility in displaying lists of posts. It still respects more restrictive permissions for context=edit.

[danielbachhuber]

@pento I think this could (and should) go into 4.9.6 if you're amenable to it.

[pento]

Yah, this is a good one to get out there now.

[pento]

@danielbachhuber: Is there any particular reason for the condition in ::get_items_permissions_check() to be ! empty( $request['who'] ), rather than 'authors' === $request['who']?

[danielbachhuber]

@pento Nothing specific, no.

[pento]

Okay, cool. I'll change it to the latter, just so it's clear what it's checking for. We can always modify it in the future if we need.

[pento]

In 43001:

REST API: Add who=authors as a query parameter for GET wp/v2/users.

Any WordPress user who can edit_posts of a post type with show_in_rest=true can query for authors. This maps to current WordPress behavior where a WordPress user who can view the Manage Posts view for a post type can see any WordPress user assigned to a post (whether published or draft).

This implementation, over restricting who=authors to users with list_users, gives us future flexibility in displaying lists of posts. It still respects more restrictive permissions for context=edit.

Props danielbachhuber.
Fixes #42202.

[pento]

Re-open for backport.

[SergeyBiryukov]

In 43067:

REST API: Add who=authors as a query parameter for GET wp/v2/users.

Any WordPress user who can edit_posts of a post type with show_in_rest=true can query for authors. This maps to current WordPress behavior where a WordPress user who can view the Manage Posts view for a post type can see any WordPress user assigned to a post (whether published or draft).

This implementation, over restricting who=authors to users with list_users, gives us future flexibility in displaying lists of posts. It still respects more restrictive permissions for context=edit.

Props danielbachhuber.
Merges [43001] to the 4.9 branch.
Fixes #42202.

[danielbachhuber]

@SergeyBiryukov @pento Sorry for the hassle. I'd like to harden this a bit more by checking edit_posts only for post types that support author (42202.2.diff).

[SergeyBiryukov]

In 43137:

REST API: When handling who=authors query parameter for GET wp/v2/users, only check edit_posts for post types that support author.

Props danielbachhuber.
Fixes #42202.

[SergeyBiryukov]

In 43138:

REST API: When handling who=authors query parameter for GET wp/v2/users, only check edit_posts for post types that support author.

Props danielbachhuber.
Merges [43137] to the 4.9 branch.
Fixes #42202.