WordPress.org

Make WordPress Core

Opened 7 months ago

Closed 3 weeks ago

Last modified 6 days ago

#42202 closed enhancement (fixed)

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

Reported by: iseulde Owned by: pento
Milestone: 4.9.6 Priority: normal
Severity: normal Version:
Component: Users Keywords: has-patch has-unit-tests commit fixed-major
Focuses: rest-api Cc:

Description

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:

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.

Attachments (2)

42202.1.diff (5.0 KB) - added by danielbachhuber 6 weeks ago.
42202.2.diff (759 bytes) - added by danielbachhuber 3 weeks ago.

Download all attachments as: .zip

Change History (29)

#1 @swissspidy
7 months ago

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

#3 @joehoyle
6 months ago

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.

#4 @joehoyle
6 months ago

  • Owner set to joehoyle
  • Status changed from new to assigned

#6 @jbpaul17
2 months ago

@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?

#7 @dd32
2 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.0

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.

#8 @danielbachhuber
6 weeks ago

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.

#9 @swissspidy
6 weeks ago

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.

#10 @danielbachhuber
6 weeks ago

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.

#11 @danielbachhuber
6 weeks ago

  • Keywords has-patch has-unit-tests added; needs-patch removed
  • Owner changed from joehoyle to pento

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.

#12 @danielbachhuber
6 weeks ago

  • Component changed from REST API to Users
  • Focuses rest-api added

This ticket was mentioned in Slack in #core-editor by danielbachhuber. View the logs.


4 weeks ago

#14 @danielbachhuber
4 weeks ago

  • Keywords commit added

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

#15 @pento
4 weeks ago

  • Milestone changed from 5.0 to 4.9.6

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

#16 @pento
4 weeks ago

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

#17 @danielbachhuber
4 weeks ago

@pento Nothing specific, no.

#18 @pento
4 weeks ago

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.

#19 @pento
4 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#20 @pento
4 weeks ago

  • Keywords fixed-major added

Re-open for backport.

#21 @pento
4 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

This ticket was mentioned in Slack in #core by desrosj. View the logs.


3 weeks ago

#23 @SergeyBiryukov
3 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#24 @danielbachhuber
3 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@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).

#25 @SergeyBiryukov
3 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#26 @SergeyBiryukov
3 weeks ago

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.

This ticket was mentioned in Slack in #core-restapi by desrosj. View the logs.


6 days ago

Note: See TracTickets for help on using tickets.