Community
Participate
Working Groups
Consider this sequence of operations - Create a task - Modify the task's attributes (via properties dialog or cell editor in tasks view) - Delete the task You may now "Undo Delete Task" This correctly recreates the marker with all the attributes it had prior to deletion. Problem/Feature In theory, you should then be able to undo the prior modification of the marker's resources. The current implementation does not support this, since the marker was deleted and recreated. The new marker has a different id. The original update operation knows the original marker and doesn't attempt to establish any relationship based on equality (ie, same location, resource, and attributes). Doing so would be somewhat dangerous since we don't know that all "equal-looking" markers really refer to the original marker. There are other similar scenarios, but the basic issue is that if a marker is deleted (by a delete, or an undo of a create, etc.) then any other operations that refer to that marker will now be invalid.
This may not be a priority for 3.3, but marking 3.3 for now so that all limitations of the new workspace undo support can be examined and documented. I think we can look at this bug again after we implement undo for resource create/update/delete, because we will have similar issues for resources, not just markers.
I doubt this is a big deal for 3.3. It didn't turn out to be an issue with resources, since you can always get and keep a handle for a non-existent resource, and it will "work" once the resource does exist. So the handles kept by undoable resource operations tend to work across resource delete/recreates. But marker id's don't work this way, so the marker ops tend to get stale faster.
I don't see this as a 3.3 issue. Marking REMIND for now.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
