Activity Log abilities: register events reads via Registrar#48760
Activity Log abilities: register events reads via Registrar#48760enejb wants to merge 4 commits into
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so: 🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so: Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
|
Summary
Registers the
jetpack-activity-log/list-eventsability via the WordPress Abilities API so AI agents can answer "what happened on my site?" through the standardwp-abilities/v1REST surface. Single consolidated read — passingevent_idreturns a 0- or 1-element array, so the same ability covers both list and detail views (per plan §4.2's "consolidated-read" guidance).Activity_Log_AbilitiesRegistrar subclass underAutomattic\Jetpack\Activity_Log\Abilities, namespaced category slugjetpack-activity-log.REST_Controller::get_activity_log()so the ability rides on the existing permission check, free-tier clamp, and WPCOM proxy path — no duplicate auth surface.actions.phppattern (autoload-files); gated behind the default-offjetpack_wp_abilities_enabledfilter insideRegistrar::init(), so it stays opt-in per-site until the flag is flipped.group,action,date_from/date_to(ISO8601),page,per_page(max 100),event_id.actionandevent_idare applied client-side after the proxy returns (they're not part of the upstream/jetpack/v4/activity-logquery surface).Test plan
composer phpunit -- --filter Activity_Log_Abilities_Test(25 tests / 72 assertions, no notices).src/abilities/,tests/php/, andactions.php.REST_Controller::permissions_callback()).event_idreturns[](notWP_Error); knownevent_idreturns a 1-element projected array.date_from→after,date_to→before,per_page→number(clamped to 100),group→ single-element array. Verified via capturedWP_REST_Request.WP_Errorpropagates unchanged.