Provide a "rollback" for update tasks

[mjordan]

It would be very useful to have a way of undoing an update task in the same way that Workbench can roll back nodes and their attached media created during create tasks.

In the current rollback mechanism, create tasks write out a file listing node IDs that can then be used as the input for an ordinary delete task. The only remnants of the created nodes are any taxonomy terms added during the create task. This is pretty straight forward and is not terribly risky.

I'm not sure how we could reliably roll back changed committed during update tasks. A couple of options to consider:

• Before committing the update, Workbench grabs a JSON representation of the updated node, and in the event of a rollback, uses it to put back the node in its pre-update state.
• Before committing the update, Workbench writes out CSV file of the pre-update field data, and in the case of a rollback, this file is the input for a second update task that replaces the updated field data with the pre-commit CSV data.

I think the second option is preferable since there is already a bunch of code that we can reuse. Any other ideas?

[dara2]

I agree that the second option is preferable. It feels more in line with processes that we're used to in Workbench.

[mjordan]

Very good, thanks for the feedback @dara2.

[rosiel]

Do we really need to code this into workbench? It sounds complicated. [edit to say i'm not against it if it's something you really want to do]. If you are doing a round trip update, you probably used Workbench to get the original values out of Drupal anyway. We could get smart and make a backup of that file before altering it, and use that as the input for an "undoing" update.

Another thing that we may want a way to manage (through workbench or otherwise) are taxonomy terms that are orphaned as they're no longer used in our data. It is confusing if you have "bad" names as well as "good" names in your autocomplete.

[mjordan]

If you are doing a round trip update

I think the use case for this feature is more like someone applied a large update task and then realized the updated metadata contained mistakes, and now they just want a way to get their nodes back into the state they were in before the botched update. I also am not assuming that the pre-update metadata was created by a recent Workbench job, it may have been added/edited via the Drupal GUI and therefore unknown to Workbench at the time of update.

I agree that it would be useful to be able to identify, and optionally prune, orphaned terms. Identifying them seems like something a View could easily do. In terms of having Workbench clean up after itself, after a rollback of any kind it could remember which terms it created during the create or update, then after the rollback query each term to see if there are any other nodes attached to it (unlikely if it just created it except for the small possibility that someone attached a newly created term to a node before Workbench finished running). Maybe this should be a new Github issue, or a broader discussion in Slack.

[rosiel]

What if we did this part in Drupal? Reverting to a previous version seems like something that the Drupal community would appreciate.

Edit to say: This is stealing from Fedora, but if we implemented a "revert me the version of thing X at time Y" function, i.e. built a Drupal module that implements a Memento TimeGate then we'd be a third of the way to implementing the Fedora Spec.

[mjordan]

What if we did this part in Drupal? Reverting to a previous version seems like something that the Drupal community would appreciate.

That is an excellent idea. Thanks for suggesting it. Do you mean using a VBO? If we can do that via REST, we could see if Workbench could do it (if that's desired).

[rosiel]

From the video Annie posted the other day, there are a few other ways we could loop into the batch process, not all of which we necessarily need to do but all could be useful:

• as an Action
• as a drush command
• from a custom "update" form
• a module update (probably not😞)
• right on the node form (not needed/already under "revisions" tab)
• as a migration (doesn't apply) We could absolutely add "as a REST endpoint". I'm not sure if we'd want a "batch"-triggering REST endpoint (that sounds prone to async issues, and would the contents of the batch be passed in as a parameter or a file?) but we could have individual node endpoints?

[mjordan]

To follow patterns already existing in workbench the REST approach should be at the individual node level and not at a Drupal batch level.

Drush is fine for those who have access to the Drupal command line but not applicable to Workbench's target audience.