feature: Editor undo

[steff-o]

Fixes #2223 by introducing two new amazing features:

1. n-level undo and redo for all editor edit operations
2. Menu button to abort all pending edits when not using autosave

Also lays the foundation for implementing #2018 by implementing the UndoStack class which can be used to build undo functionality for Draw tool.

No new configuration is needed to use these new features, they are on by default. The abort edits and undo stack is implemented completely independent of each other, meaning that the abort function does not rely on the undo stack, so disabling undo will still have abort working. The undo stack will default to 100 last operations (why 100? No idea, just pulled a number from the hat). But there are a few new options available:

maxUndoLevels: Number. set on editor to limit the number of undo levels. Defaults to 100. Setting it to 0 will disable undo altogether and hide the undo/redo buttons.

reuseIds: boolean. Defaults to false. Can be set on editor or WFS layers. Layer level will override editor. When set to true, the WFS transaction will use the id of the deleted feature when undoing a delete that has been saved to the server by recreating the feature. Only works for WFS 1.1.0. Also requires that the server implements the "idgen"-attribute in an insert transaction. Geoserver does this, not sure about others. Also for reuseIds to work, the database must allow id insertion. For postgres and identity columns as Private key, the identity must be created with GENERATED BY DEFAULT AS IDENTITY instead of the more common GENERATED ALWAYS AS IDENTITY. If not resudeIds are used the re-created feature will get a new id, which probably only matters if the id is used in a relation.

Only tested for WFS, but it should work for AGS as well as nothing has changed in the actual transmission to the server except the reuseIds code that is not possible to implement in AGS anyway.

[johnnyblasta]

Tested and seems to work fine. Could be good if someone else also tests before approving.

[Grammostola]

Tested too and appears to work more or less as I'd expect, incl. reuseIds and undoing saved things and unfinished steps of a polygon.

Something I noted is that for instance selecting to create a polygon and finishing it, then hitting "undo", only reactivates the "redo" button, the polygon persists until "undo" is hit again. Same with "redo". Why the extra click may not be immediately obvious.

If one creates a polygon and saves it, the save button becomes inactive. Hitting "undo" once will reactivate it and the "redo" button. Hitting it again removes the polygon. Here it is visible that one of the steps is "unsave".

It only takes using it once to learn this so I don't consider it a major issue or necessarily an issue at all.

Edit 2026-02-17: The above behaviour only happens when autoForm is set to true. Setting the attributes is one step on the stack, creating the geometry another, though for the user it seems to happen in one step. Then undo takes two steps, one for undoing the attribute edit, another for getting rid of the geometry*. Whereas without autoForm the first undo after geometry creation is removing the geometry.

• The attribute edit doesn't disappear from the first undo in this sequence. It's "undo" and nothing noticable happens with the geometry or the attributes, then "undo" again and the geometry as well as the attributes vanish. This differs from what happens if an already existing geometry that wasn't just created has its attributes edited. If they are, the first undo undoes the attribute edits. I would expect this to happen for a newly created feature too. Here's a gif of what I mean:
  

[steff-o]

Thanks for the feedback @Grammostola

I have fixed so that attributes are undone even for new features. Problem was that new features without default values don't have the properties in the "before" state, and the undo operation was not capable of removing added properties. Some of those annoying special cases could probably have been eliminated if the editor re-read features from the server when saved. As it is now Origo assumes that the feature looks like in the client, which very well may be wrong if the database uses default values or triggers. It also means that newly created features only have the properties that have defined default values in Origo.

Regarding the autoForm confusion I though about that when implementing but it quickly became complex. In theory it would be possible to defer pushing the create action to the undo stack until we know if the autoForm resulted in any changes and add them to the stack as an atomic operation, but then we probably also has to delay the auto save. It becomes even uglier when considering that the user can remove the created feature in the auto save attributes dialog. That is treated as its own delete operation which in turn can be undone. Probably not that intuitive, but I somehow find it consistent if the user is aware of the meaning of autoForm. Otherwise they will notice when trying to undo.

Another confusing thing is that there is no check if the attribute editor actually changes any attributes, it always creates an undoable action if the dialog is closed with "OK". But that goes for autoSave as well, so I didn't want to mess with that.