Add `core/read-users` ability

[jorgefilipecosta]

Introduce a new Abilities API ability, core/read-users, to retrieve profile data for a specific user or a collection of users.

Core currently has core/get-user-info for the current authenticated user only. Agent/workflows use cases need to be able to look up any user when permissions allow it.

References

• ​https://github.com/WordPress/wordpress-develop/pull/10775
• ​https://github.com/WordPress/ai/issues/40
• ​https://github.com/WordPress/ai/pull/774

Adds a new core/get-user ability to the Abilities API that retrieves profile data for a specific user by id, username, or email. User must be logged in. Users can view their own record. Viewing other users requires list_users.

Trac ticket: https://core.trac.wordpress.org/ticket/64657

## Use of AI Tools

Ticket: 64657
Link: https://core.trac.wordpress.org/ticket/64657

Registered a new Ability of Get User info and Show_in_rest is true.

[desrosj]

Moving tickets related to the Abilities API to a new sub-component.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Removing abilities and abilities-api custom keywords. This is now indicated by the Abilities API component.

[desrosj]

Since this is an enhancement, there's no first version of WordPress this can be reproduced in. Removing trunk version.

[gziolo]

#65234 added several enhancements to core/get-user-info like more supported fields (most of these listed in the description of this ticket), a way to filter which fields get returned. For me, it looks like the best past forward is to extend the existing ability by allowing passing the user identifier as proposed here:

Require one of: id (integer), username (string), or email (string).

Following the user permission validation:

• User must be logged in.
• Users can view their own record.
• Viewing other users requires list_users.

Two firsts conditions are implemented, so it all boils down to the third condition when viewing other user profiles.

Closing in favour on #11525

## What?

• Adds a read-only core/users ability registered from Core ability registration.
• Supports single-user lookup by id, user_email, user_login, or user_nicename.
• Supports collection mode with optional roles, has_published_posts, page, per_page, and fields; omitted REST input defaults to empty collection mode.
• Uses WP_User-shaped field names, including user_login, user_email, user_nicename, user_url, and user_registered, to align with Core’s existing core/get-user-info ability.
• Aligns access checks with the REST users controller: non-list users only see public authors in collection mode, role filtering requires list_users, user email/login lookup for another user requires list_users or edit_user, and inaccessible fields are omitted per user.
• Excludes capabilities, extra capabilities, and meta; avatar_urls is available only when get_option( 'show_avatars' ) is enabled.

Ticket: https://core.trac.wordpress.org/ticket/64657

## Testing

• php -l src/wp-includes/abilities/class-wp-users-abilities.php
• php -l src/wp-includes/abilities.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterCoreUsersAbility.php
• php ./vendor/bin/phpcs --standard=phpcs.xml.dist --warning-severity=0 src/wp-includes/abilities.php src/wp-includes/abilities/class-wp-users-abilities.php tests/phpunit/tests/abilities-api/wpRegisterCoreUsersAbility.php
• php ./vendor/bin/phpunit --filter Tests_Abilities_API_WpRegisterCoreUsersAbility --group abilities-api
• php ./vendor/bin/phpunit --group abilities-api
• git diff --check

[gziolo]

Core currently has core/get-user-info for the current authenticated user only (and not exposed in REST).

I updated that part, as all core abilities are now exposed through the REST API. I didn't find any evidence that an exception should be kept for core/get-user-info.

Thanks @jorgefilipecosta! I checked this port against the merged AI plugin version (​WordPress/ai#774), and it reflects it faithfully. The class body, schemas, permission model, and normalizers are the same, with only the expected Core adaptations (no namespace, no ai text domain, docblocks, and dropping the plugin-only override/init() hook). Test coverage matches too, minus the one plugin-only override test that has no meaning in Core. Nice work keeping the two in sync.

Before this lands, I think we should settle the two points I raised in the comments: the class naming convention (the WP_Abilities_ prefix, shared with the settings PR) and how this ability sits next to the existing core/get-user-info. Since nothing has shipped yet, this is the moment to align the field names and reuse one shared definition source, so we do not freeze two vocabularies for the same user data. That is the last step for me before approval.

The CI failures look unrelated. The run has a single failing test, test_new_admin_email_subject_filter (an admin email subject assertion), while all the abilities tests pass. It looks like test-state pollution, so a rebase or re-run should clear it.

[gziolo]

Moved to WordPress 7.2 based on ​the decision made after evaluating feedback on the merge proposal.