Open/close operations are too easy to do and lead to dupplicate

[nh2]

When you accidentally press o for open/close in termui, it seems that there's no way to undo that without resetting the entire changes to an issue (e.g. new comments). (If there is, maybe it could be made a bit clearer in the UI?)

That can lead to repeated open/closes, like here: https://github.com/nh2/hatrace/issues/61#issuecomment-612296129

It would be nice to be able to undo those, or collapse operations that undo each other.

[MichaelMure]

Yeah, that could be done better indeed. Not sure what's the best solution though, it might be just an UX issue. Here is what I see as possible fix:

• Finish the transaction concept (https://github.com/MichaelMure/git-bug/issues/337) and give more control to UIs over what is pending and allow to revert
• Have the status change be "less easy":
  • have a "confirm" step ?
  • as the status will eventually have more values than open/closed, have a secondary UI to select the value
• have a way to "undo", but that implies knowing what can be undo as you must not remove operation that were already propagated. This could be limited to the pending ops. There is also a more general notion here of editing the pending operation (especially comments).

[nh2]

Have the status change be "less easy":

I don't think that would help much, eventually people will get into the situation where they want to undo.

Another alternative:

One can already select messages and status changes by pressing ↓↑. Could the Del key simply remove the selected status change from the history?

E.g. pressing Del here could delete it:

If it is illegal to have multiple subsequent status changes to the same status, they could simply be collapsed into the first one.

[MichaelMure]

From a UX perspective:

• when existing on other bug-trackers, editing the history appears in the form of editing/deleting/masking elements. Currently, git-bug only support editing a comment with a special Operation. It's possible to extend that system ("delete comment" seems to be the more probable) but it doesn't seems to be important to me, even to support importing from external bug tracker.
• having a way to edit the pending history is a different thing and would be helpful to give more control to the user. I'm noting this this sort of staging area for bug edition doesn't exist anywhere else. Not sure if that's a plus or a minus.
• there is two different concepts here: "undo" and "delete". It seems to me that it should be one or the other, not both to not overwhelm the UI/UX.
• "undo" is easy to understand and implement but can't alter something deep in the stack without being destructive
• "delete" doesn't have that limitation but also imply a trickier implementation because you can't delete everything: what happen if you delete the creation of a comment when there is a comment edition later ? In the future we will likely have more dependency like this.

From a technical perspective:

• unless it's "making the status change slightly more difficult", all of those solutions imply deeper control over those pending operation, possibly the notion of transaction as well. That would probably be a good thing to have but it's also quite a big piece of work and won't happen quickly.

[arcanemachine]

Just ran into this when I pressed the 'o' key out of curiosity.

As a short-term workaround (to avoid issues with committed transactions and such), I think a simple "Are you sure?" confirmation dialog would be a good way to prevent fat-finger issues like I just encountered.