Update docs for non member unresolving resolved thread

Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/62122

What does this MR do?

This will update the documentation to cover bevhiour when non-member project unresolves their own comment which will update the discussion thread from resolved to unresolved.

TLDR;

Current

They can then be individually resolved by anyone with at least Developer access to the project or by the author of the change being reviewed.

Suggestion

They can then be individually resolved by anyone with at least Developer access to the project or by the author of the change being reviewed.

If the thread has been resolved and a non-member un-resolves their own response. This will unresolve the discussion thread. And should the non-member resolves their own response, this will resolve the discussion thread.

If the thread has been resolved and a non-member unresolves their own response, this will also unresolve the discussion thread. If the non-member then resolves this same response, this will resolve the discussion thread.

Background Information (optional read)

Here is some background information on some scenarios I look into as part of the concern raised my the Issue. Not a necessary read, so okay to skip over.

This is the scenario that was raised from the report that was thought to be incorrect.

Guest can resolve and unresolved read for "Resolved thread"

• Administrator has resolved discussion
• When guest click on the resolve checkmark, now they can resolve the thread or unresolved thread.

By unresolving their own comment, the guest have successfully Unresolved Thread.

→ This is the part that contradicts with our current statement in the docs

They can then be individually resolved by anyone with at least Developer access to the project or by the author of the change being reviewed.

I don’t think this is a problem. This behaviour makes sense to me. Because if a guest unresolved their own comment, it should update the thread to be unresolved. This will allow the guest to communicate to the author that this thread is not resolved and give the author an opportunity to address it. And if the author disagrees or whatever they decide, they can simply resolve the thread again.

→ So my proposal is this:

They can then be individually resolved by anyone with at least Developer access to the project or by the author of the change being reviewed.

If the thread has been resolved and a non-member un-resolves their own response. This will unresolve the discussion thread. And should the non-member resolves their own response, this will resolve the discussion thread.

More Research Information

These are some sample scenarios that I tested that is behaving as expected 👍

Guest can only resolve their own comment

• This is correct
• I’m currently "Yu Nicolas" and I can only resolve my own response
• The checkmark is not available on the "Administrator"

Admin can resolve their own and guest’s comment

• This is correct
• I’m currently "Administrator" and I can resolve my own and guest’s comment
• The checkmark is accessible on "Administrator" and guest

Admin can resolve thread

• This is correct
• I’m currently "Administrator" and I can resolve the entire thread

Guest can not resolve thread for Unresolved Thread

• This is correct
• Nothing happens when I click the "Resolve thread" button

Get a 404 when trying to click the "Resolve thread" button

→ Suggestion: If that’s the case, a better experience would to hide the "Resolve thread" button on the frontend. Since it doesn’t do anything. We shouldn’t give the user the option and hide it from them instead.

→ This should be addressed in a separate ticket so some discussion can happen and get input from other stakeholders. I will create a separate ticket.

Related issues

Author's checklist

• Follow the Documentation Guidelines and Style Guide.
• Link docs to and from the higher-level index page, plus other related docs where helpful.
• Apply the ~Documentation label.

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

• Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

• Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
2. Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
3. If there has not been a technical writer review, create an issue for one using the Doc Review template.