Page MenuHomePhabricator

Check for edit conflicts when editing schemas
Closed, ResolvedPublic8 Estimated Story Points


As an editor, I want to be confident that my edits will not overwrite other edits without me realizing it.

We currently don’t handle edit conflicts on, for example, the schema edit page. If you load it, then leave the tab open for days, and then submit an edit, the backend currently has no idea that the user’s input is based on a days-old revision.

The impact of this varies across endpoints; for example, due to the way schema text editing is implemented, any changes to labels will not be overwritten, but changes to the schema text will be discarded (it is unconditionally overwritten with the user-submitted text, which is based on the old revision). We should be able to detect edit potential conflicts, merge concurrent changes that don’t actually conflict, and return an error to the user in case of an actual conflict.

Affected parts:

  • ?action=edit
  • Special:SetSchemaLabelDescriptionAliases
  • undo/restore/rollback(?) via index.php – the diff you see should be the one that is applied, if there’s an edit in between “view” and “confirm” then complain
  • (api.php not affected because “view” and “confirm” are not two separate steps there)

Acceptance criteria:

  • There is a hidden parameter on any page editing a schema that specifies the base revision for the edit.
  • The backend checks for conflicts between any edits since that base revision.

Open questions:

  • Is merging non-conflicting changes a requirement for this or only a nice-to-have? Answer: Nice-to-have
  • (dreaming) can we integrate this with TwoColumnConflict? Answer: dream on

Event Timeline

Change 497810 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseSchema@master] Add browser tests for edit conflict detection

Change 497810 merged by jenkins-bot:
[mediawiki/extensions/WikibaseSchema@master] Add browser tests for edit conflict detection

We tested the subtasks, what is left to test here?

I don’t think there’s anything left to test for now – should we move it back to the backlog until T218300: Merge non-conflicting edits when edit conflicts are detected is done?