Work Item editing conflict resolution
Problem
Primary: Issues descriptions are edited asynchronously, which can result in conflicted updates when the description is updated by one user while another user is still drafting an edit. The current outcome requires the user to refresh the edit form to proceed.
Secondary: When conflicts occur, the user must open the Issue in another window/tab to review the updates.
Tertiary: Conflicts can generate two error banners simultaneously, which is unnecessary.
Proposal
Use a single alert to show that the "Save" action was captured, why it didn't proceed, and present actions to continue. Show the new description on-demand from this context to allow users to review without reopening.
All states attached as designs; default would NOT be expanded
Notably for Work Items, shifting from a single "edit" to individually editable fields means that this would be better suited within the context of the description element as opposed to a more general header position.
Future Enhancement
Real-time updates would in most cases remove the need for a conflict state altogether, providing an overall better experience.
Other considerations
Other concepts explored
Side-by-Side Modal
This was considered to alleviate some of the location concerns for future extensibility — in a direct editing model, would you see a banner? - but generally felt too disruptive and added more complexity than in-page options.
History Viewer
I've explored an idea of a more comprehensive history navigation pattern for descriptions — originally an idea for more easily understanding the history of the description, as today you'd have to track down and expand each system note for a change, but it seemed possible to reuse for conflicts. Significantly bigger change, so would need to vet the value proposition.
Availability and Testing
Job e2e:package-and-test
will need to be run in the MR(s) that introduces the change.
Ensure test coverage in unit/integration tests.