Batch rollback restores many resources at once to their last version saved before a cutoff moment. Use it to undo a bulk edit that went wrong, or every edit made by one user in a time window. It requires the site admin role or higher and runs as an Omeka S background job.
Starting the wizard
Open /admin/resource-versioning/rollback in one of these ways:
- Click Batch rollback at the top of the Resource Versions page.
- Click Roll back next to an entry under Recent bulk operations, which pre-fills the batch key.
- Click Roll back this batch on a batch page.
Step 1: choose what to roll back
| Field | Meaning |
|---|---|
| Batch key | Roll back one specific bulk operation. When set, the other fields only narrow the match. |
| User | Limit to versions written by this user. Defaults to Any user. |
| Resource type | Limit to items, media, or item sets. Defaults to All. |
| Window start | Required unless a batch key is given. Resources are restored to their state just before this moment. |
| Window end (optional) | Ignore versions written after this moment when finding affected resources. |
You must supply either a batch key or a window start. The date fields accept a date and time; a date without a time counts from the start of that day (window start) or the end of that day (window end).
Click Preview rollback. Nothing is changed at this step.
Step 2: preview
The cutoff is the earliest version time in the batch when a batch key is given, otherwise the window start. The preview lists every resource that has at least one version matching the criteria, with:
- Restores to: the latest version of that resource written before the cutoff, with its date, and
- Status: will restore, or a reason for skipping:
- No version exists before the rollback window: the resource was created inside the window or has no earlier snapshot, so there is nothing to return to.
- Resource no longer exists: the resource has been deleted; deleted resources cannot be restored.
A summary line reports how many resources are affected and how many will be restored. If none match, the page says so.
Executing
Click Roll back N resource(s) and confirm the browser prompt. The criteria are dispatched to the BatchRollback job and you are returned to the browse page with the job number. Each resource is then restored exactly as a single restore would be, in the background, with the same key stripping, owner handling, and dangling-reference warnings.
Each restored resource gets a new restore version, and all of those versions share one batch key, so the rollback itself appears under Recent bulk operations and can be rolled back in turn if needed.
Checking the result
Open Admin > Jobs and select the job. Its log records the criteria, then a final line with counts of resources restored, skipped, and failed, followed by one line per failure (up to 100). A resource fails, rather than being skipped, when its restore is rejected by Omeka, for example by resource template validation. Stopping the job from the Jobs page halts it after the current resource.
Notes
- A resource that was edited several times in the window is restored once, to its last version before the cutoff.
- The rollback target is chosen by time, not by batch. If a resource was edited in the batch and then edited again afterwards, the later edit is also undone, because the resource returns to its pre-batch state. Check the preview.
- The job reads the version table at run time, so versions pruned between preview and execution are not available as targets.