Fix resolution comment actions becoming enabled after reopening

[karthick-murugan]

What?

Closes #73236

Fixes an issue where menu actions (Edit, Delete) were incorrectly enabled for system-generated resolution comments after using "Reopen & Reply".

Why?

When a note is resolved, a system-generated "Marked as resolved" comment is created. These resolution messages should always remain non-interactive and immutable. However, after using "Reopen & Reply", the menu actions became incorrectly enabled for the previously resolved entry, allowing users to interact with system-generated resolution messages in ways that should not be permitted.

How?

Disable menu actions for resolution comments: Ensures that resolution comments always have an empty moreActions array, preventing any menu interactions.

Testing Instructions

1. Test system-generated resolution messages remain immutable:

   • Create a new Note on any block
   • Click "Resolve" — a system-generated "Marked as resolved" comment appears
   • Verify menu actions are disabled (menu button should be disabled)
   • Add a reply to the note
   • Click "Reopen & Reply"
   • Verify the original "Marked as resolved" note still has disabled menu actions

2. Test user replies via "Reopen & Reply" remain editable:

   • Create a new Note on any block
   • Click "Resolve"
   • Click "Reopen & Reply" and add some text in the reply box
   • Submit the reply
   • Verify the newly created reply (with your text) has enabled menu actions (Edit, Delete should be available)

3. Test system-generated "Reopened" messages:

   • Create a new Note on any block
   • Click "Resolve"
   • Reopen the note without adding a reply (if this action exists)
   • Verify any system-generated "Reopened" message has disabled menu actions

Video

REC-20251113201442.mp4

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthick-murugan <karthickmurugan@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

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

[t-hamano]

I tested this PR, and I found that the issue occurs when reopening a note with a comment. As you can see, the text "Reopened:" is missing from the reopen action:

Before	After

Additionally, if it is reopened with a comment, the comment should only allow edit actions.

[karthick-murugan]

I tested this PR, and I found that the issue occurs when reopening a note with a comment. As you can see, the text "Reopened:" is missing from the reopen action:
Additionally, if it is reopened with a comment, the comment should only allow edit actions.

Updated both the issues @t-hamano

REC-20251114144544.mp4

[t-hamano]

Additionally, if it is reopened with a comment, the comment should only allow edit actions.

Sorry, on reflection, this may not be ideal. For consistency, we should probably allow editing even when there is no comment. Later, some users may want to add a comment to the reopen action.

Additionally, the current implementation makes it a bit difficult for me to predict what actions will be available - the actions can only be determined by the isEligible property.

What do you think about the following implementation? cc @Mamaduka

	const isParentComment = thread.parent === 0;
	const hasResolved =
		thread.status === 'approved' || parent?.status === 'approved';
	const isReopenComment = thread.meta?._wp_note_status === 'reopen';
	const isResolvedComment = thread.meta?._wp_note_status === 'resolved';
	const isResolutionComment = isReopenComment || isResolvedComment;

	const actions = [
		{
			id: 'edit',
			title: __( 'Edit' ),
			isEligible: () => ! isResolvedComment && ! hasResolved,
			onClick: () => {
				setActionState( 'edit' );
			},
		},
		{
			id: 'reopen',
			title: _x( 'Reopen', 'Reopen note' ),
			isEligible: () => isParentComment && hasResolved,
			onClick: () => {
				onEdit( { id: thread.id, status: 'hold' } );
			},
		},
		{
			id: 'delete',
			title: __( 'Delete' ),
			isEligible: () =>
				isParentComment || ( ! isResolutionComment && ! hasResolved ),
			onClick: () => {
				setActionState( 'delete' );
				setShowConfirmDialog( true );
			},
		},
	];

	const moreActions = actions.filter( ( item ) => item.isEligible() );

[karthick-murugan]

Thanks for the suggestion, @t-hamano! I've updated the implementation to follow your suggested approach and it works good. Can you take a look.

[t-hamano]

LGTM! To my understanding, this is the correct behavior.

@Mamaduka @adamsilverstein, I'd be happy to receive second feedback to see if my understanding is correct.

Note Status	Note Type	Available Actions
Opened	Parent note	Edit, Delete
Opened	Reply	Edit, Delete
Opened	Reply (Marked as resolved)	None
Opened	Reply (Reopened)	Edit
Resolved	Parent note	Reopen, Delete
Resolved	Reply	None
Resolved	Reply (Marked as resolved)	None
Resolved	Reply (Reopened)	None

[Mamaduka]

The whole point of the isEligible callback is to derive value at run time. I know there will be some duplication, but that's okay.

Deriving everything outside kind of defeats the whole purpose of this method.

[karthick-murugan]

@Mamaduka Updated the changes