Change Details

As an editor, I want to be confident that my edits will not overwrite other edits without me realizing it.
**Problem:**
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.
**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

As an editor, I want to be confident that my edits will not overwrite other edits without me realizing it.
**Problem:**
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

As an editor, I want to be confident that my edits will not overwrite other edits without me realizing it.
**Problem:**
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