| Anomie added a comment. |
The logic for determining the Content object for the undo based on the supplied 'undo' or 'undoafter' URL parameters looks like it's already in ContentHandler::getUndoContent(). EditPage calls through the stub in WikiPage, while ApiEditPage calls ContentHandler directly.
But note that the logic for undoing edits via the web UI ends with displaying the edit form with the undo content loaded (or not, if there's a "merge" conflict), so this probably depends on T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR].
Perhaps free form editing can be dropped from the undo function completely.
That sounds like a "torches and pitchforks" type of change.
EditPage will already have to deal with not-editing slots that aren't directly editable, all this would mean is the not-editing carrying forward the Content object from ContentHandler::getUndoContent() instead of inheriting the slot. We'll probably need to do something similar anyway for when someone edits an old revision rather than the current one.
When the undo operation spans multiple slots, free form editing should be disabled.
Same.
As a baseline, undo operations could just be denied of they would affect any slots other than the main slot.
That's probably the most straightforward approach until T174033 is done. Although the Commons editor community might consider that a blocker to SDC deployment.
Cc: Anomie, Aklapper, -jem-, Lokal_Profil, Smalyshev, TomT0m, Liuxinyu970226, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
