WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 17 months ago

Last modified 16 months 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 17 months ago.
42202.2.diff (759 bytes) - added by danielbachhuber 17 months ago.

Download all attachments as: .zip

Change History (29)

#1 @swissspidy
2 years ago

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

#3 @joehoyle
22 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
22 months ago

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

#6 @jbpaul17
18 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
18 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
18 months 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
18 months 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
17 months 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
17 months 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
17 months 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.


17 months ago

#14 @danielbachhuber
17 months ago

  • Keywords commit added

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

#15 @pento
17 months ago

  • Milestone changed from 5.0 to 4.9.6

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

#16 @pento
17 months 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
17 months ago

@pento Nothing specific, no.

#18 @pento
17 months 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
17 months 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
17 months ago

  • Keywords fixed-major added

Re-open for backport.

#21 @pento
17 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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


17 months ago

#23 @SergeyBiryukov
17 months 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
17 months 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
17 months 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
17 months 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.


16 months ago

Note: See TracTickets for help on using tickets.