[wp-trac] [WordPress Trac] #65234: Abilities API: Expand `core/get-user-info` with profile fields and filtering

[WordPress Trac]

#65234: Abilities API: Expand `core/get-user-info` with profile fields and
filtering
---------------------------+----------------------
 Reporter:  gziolo         |      Owner:  (none)
     Type:  enhancement    |     Status:  assigned
 Priority:  normal         |  Milestone:  7.1
Component:  Abilities API  |    Version:  6.9
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+----------------------
 Two additive changes to `core/get-user-info` (shipped in 6.9):

  1. Expand the response with five standard profile fields: `first_name`,
 `last_name`, `nickname`, `description`, `user_url`.
  2. Add an optional `fields` input parameter that filters the response to
 a subset of properties, mirroring the pattern already used by `core/get-
 site-info`.

 Field naming follows WP-CLI conventions: `wp_users` columns keep their
 `user_` prefix (`user_url`); user-meta fields are unprefixed
 (`first_name`, `last_name`, `nickname`, `description`).

 == Proposed shape ==

 Default response (no `fields` parameter) after the change:

 {{{#!json
 {
   "id": 1,
   "display_name": "Jane Doe",
   "user_nicename": "jane-doe",
   "user_login": "jane",
   "roles": ["administrator"],
   "locale": "en_US",
   "first_name": "Jane",
   "last_name": "Doe",
   "nickname": "Jane",
   "description": "Site administrator and contributor.",
   "user_url": "https://example.com"
 }
 }}}

 Filtered response with `fields: ["display_name", "first_name",
 "last_name"]`:

 {{{#!json
 {
   "display_name": "Jane Doe",
   "first_name": "Jane",
   "last_name": "Doe"
 }
 }}}

 == Behavioral rules ==

  * '''Included by default, opt-out via `fields`.''' Omitting `fields`
 returns all properties, matching `core/get-site-info`. Passing `fields:
 ["display_name"]` filters down to just that property.
  * '''Schema-validated field names.''' Each entry in `fields` must be one
 of the declared output properties; invalid names are rejected by JSON
 Schema `enum` validation.
  * Capability check unchanged: `is_user_logged_in()`.
  * Annotations unchanged: `readonly: true`, `destructive: false`,
 `idempotent: true`.

 == Acceptance criteria ==

  * `core/get-user-info` returns the five additional fields (`first_name`,
 `last_name`, `nickname`, `description`, `user_url`) alongside the existing
 6.9 fields.
  * `core/get-user-info` accepts an optional `fields` input parameter that
 filters the response to the requested subset.
  * When `fields` is omitted, the response includes all properties.
  * Invalid field names in `fields` are rejected via schema validation
 before execution.
  * JSON Schema documents each new field with `title` and `description` so
 adapters (MCP, WebMCP) can surface them.
  * Unit test coverage in `tests/phpunit/tests/abilities-api/` for:
 expanded read output, `fields` filtering with valid subset, schema
 rejection of invalid field names, and unauthenticated denial.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65234>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform