[ramonjd]

What

Deleting a reaction through /wp/v2/comments now uses the same permission check as the note it belongs to: edit access to the note's post.

Why

Reactions were added in r64488 to use the note permission checks, and most of the controller already does. check_edit_permission(), which decides who can delete a comment, sends notes through edit_comment since r64875 but doesn't include reactions yet. Deleting a reaction therefore falls back to the permission rules for regular comments. Reactions can't be updated, so deleting is the only action affected.

What changed

• WP_REST_Comments_Controller::check_edit_permission() treats reaction the same as note.
• New test: a user who can moderate comments but can't edit posts can't delete a reaction on a post they can't edit.

Manual testing

1. Give the Author role comment moderation: npm run env:cli -- cap add author moderate_comments.

2. As an Administrator, create a draft post and note its ID (POST). In the block editor console, add a note, then a reaction to it (NOTE is the note's ID):

   wp.apiFetch( { path: '/wp/v2/comments', method: 'POST', data: { post: POST, type: 'note', content: 'Test note' } } ).then( console.log );
   wp.apiFetch( { path: '/wp/v2/comments', method: 'POST', data: { post: POST, parent: NOTE, type: 'reaction', content: '2764' } } ).then( console.log );

3. Log in as an Author, open the editor on a post of your own, and delete the reaction (REACTION is its ID). This should return 403 rest_cannot_delete. On trunk it returns 200.

   wp.apiFetch( { path: '/wp/v2/comments/REACTION?force=true', method: 'DELETE' } ).then( console.log ).catch( console.log );

4. As the Administrator, run the same delete. It should return 200.

5. Undo step 1: npm run env:cli -- cap remove author moderate_comments.

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

Use of AI Tools

Claude to write and test

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props ramonopoly, kirasong, adamsilverstein, sadmansakibnadvi.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[getsource]

This looks good to me.

Tested this PR manually, and verified that it fixes the issue.

[adamsilverstein]

Nice one!

[sadmansakibnadvi]

Tested on 7.2-beta3-64990 with real REST requests (cookie auth + nonce) and a Comment Moderator role that only has read and moderate_comments.

Before the patch the moderator gets a 200 and the reaction is deleted, even though the same user gets a 403 on the note it belongs to. With the patch it's a 403 and the reaction stays. Moderator on a regular comment, editor on their own and the admin's reaction, and contributor all behave the same before and after.

Full results on the ticket: https://core.trac.wordpress.org/ticket/66406

[ramonjd]

Thanks for testing, folks!

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 65038
GitHub commit: 1e34250

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.