Page MenuHomePhabricator

'Mark as resolved' requires 'Update summary'
Closed, ResolvedPublic


  1. Add summary to a topic and log out.
  2. Log in as a different user and click 'Mark as resolved' on the topic from #1
  3. The user who does 'Mark as resolved' is forced to click on 'Update summary' option. Thus, the user will be displayed as the one who edited the summary the last - and the user's name will be displayed in 'Summary last edited by..'.

It should be possible to 'Mark as resolved' without updating the summary.

Event Timeline

Etonkovidova raised the priority of this task from to Needs Triage.
Etonkovidova updated the task description. (Show Details)
Etonkovidova added a subscriber: Etonkovidova.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 20 2015, 5:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Etonkovidova renamed this task from 'Mark as resolved' on a topic with a summary will attribute the summary to a user to 'Mark as resolved' requires 'Update summary' .Aug 20 2015, 5:24 PM
Etonkovidova set Security to None.

The user who does 'Mark as resolved' is forced to click on 'Update summary' option.

You don't actually have to. It's already resolved by that point. Testing this, I can definitely see there is a perception that you either have to or are supposed to. Otherwise, you're stuck with this editor open.

@DannyH, @Pginer-WMF, do you think we should add a cancel button to this Flow?

In order to avoid this confusion, the behaviour proposed in the original designs (try resolving and reopening the 2nd topic) was to:

  • Present the action button as "Keep summary" unless the user modifies the text. Clicking on it leaves the original summary and author.
  • If the text is modified, the action button becomes "Update summary", which updates the summary.

I'd prefer the above solution to adding a cancel button because of the following reasons:

  • Simplicity. At each point there is only one logical next step. In both cases the behaviour is to confirm the summary text above (modified or not) so it should not be confusing to be provided by the same button (we tested a very similar behaviour with the draft UI prototypes).
  • Avoid confusions. This is a multi-step process (resolve the topic summarise), providing a "cancel"-like option may create confusion about which part of the process is cancelled (i.e., some users expecting it to reopen the topic).
DannyH closed this task as Resolved.Aug 24 2015, 7:10 PM
DannyH claimed this task.

The current solution is fine. We tried using the distinction between Keep summary / Update summary buttons, and it was confusing even for the devs working on it. :)

The real problem is T60975: Null edits should not be saved in posts, topic titles, descriptions, summaries, because that interprets the null edit of hitting "update summary" as a new edit, and assigns the summary to the person resolving the thread. When that's fixed, this will be less of an issue.