Component of #4929
Deferring this to a new issue so we can test rollback on all parts of Batch Edit and not just for simple fields.
From #4929:
Rollbacks
Rollbacks are complicated to perform. In the current design, whenever user creates a batch-edit dataset, via the query builder, it makes two datasets. User can only see one of them. The second is a "backer" of the first, and contains a FK to the first (so we can find backer of a dataset later). When rollback is requested, for every row in the main one, we find the original row in the backer, and perform the regular batch-edit update on it. Essentially, it applies original snapshot.
This is highly experimental, so it is recommended to always take a backup of the db, but this should work in a good amount of cases.
From #5417 (FIXED)
Component of #4929
Deferring this to a new issue so we can test rollback on all parts of Batch Edit and not just for simple fields.
From #4929:
From #5417 (FIXED)
Rollback fails sometimes. In my testing so far, it fails when a dataset has picklists (might just be related to the picklist error mentioned in Batch Edit: Support for editing basic fields #5417) see: Batch Edit: Support for editing basic fields #5417 (review)Rollback failed in Batch Edit: Support for editing basic fields #5417 (review). Cannot reproduce locally, will test it again after we have all batch edit PRs