Firetool

Home / Docs / Undo an operation

Docs

Undo a whole operation: a bulk change, copy, import or restore

From Firetool 4.5.1, a job that changed many documents or users can be taken back in one step: a bulk field change, a copy or move, an import, a restore, a migration or a script run. This page shows where to find Undo, what it puts back and what it can't. Undo writes, so it needs Pro.

What counts as one operation

Every entry a job writes in the audit log carries the job's operation id, whatever it changed: documents, users, Storage files, rules or indexes. An entry from a job says how many entries its operation has, and Show them all lists exactly those. The audit log's CSV export has the id as its last column.

A job is a bulk field change, Copy, Move, Rename or Duplicate collection, Data transfer, an import, a restore, Migrate environments, Disable or Enable on many users, an applied script dry run, and the firetool transfer and firetool restore commands. Two jobs running at the same time each have their own operation, so undoing one never touches the other. Entries written by versions before 4.5.1 have no operation id.

Undo a finished job

  1. Open Tools → Tasks. A finished job that wrote, deleted or changed users has Undo…. Or open Tools → Audit log, open any entry of the job and choose Undo this operation….
  2. Read the preview (below). Nothing has changed yet: Cancel closes it.
  3. Choose Undo. It runs as a job of its own in Tasks, 500 documents a request, through the usual checks: your role, read-only marks, and on a production project the project ID, asked once.
  4. To stop part way, choose Cancel in the dialog; it stops after the current batch, and choosing Undo again carries on from there.

A single edit made in the user editor offers Undo this change… in its audit log entry instead.

The undo is recorded in the audit log as an operation of its own, so if you undo the wrong thing, you can undo the undo.

What the preview says

The preview is grouped by project and database. For each it says:

  • Documents put back: documents the job changed or deleted, which go back exactly as they were before it.
  • Documents it created are removed: documents that weren't there before the job.
  • Documents that can't be undone: changed by the job, but no copy was kept before the change (see the copies Undo needs).

Each line opens to show the first documents of each kind. Changes made to those documents after the job are replaced too, so look before you choose Undo. If the account that made the changes isn't connected any more, the preview says so: add it again to undo them.

Authentication users

Undo puts Authentication users back too: each user gets back the name, email, phone, verified mark, disabled state and custom claims it had before the operation, and users the operation created (Add user, Import users, Copy to project…, a restored backup, a migration) are removed. An import or a copy records which users were really new, so a user that was already there is never removed.

Some changes to users can't be undone, and the preview lists them with the reason:

  • a deleted user: its password and sign-in methods weren't kept;
  • Sign out everywhere: sessions can't be given back;
  • a new password: the old one isn't kept;
  • a user that had no email before: Firebase can't take one away;
  • imports and copies made before 4.5.1, which didn't record which users were new.

The copies Undo needs

To put a document back, Firetool needs a copy of it from before the change. Those copies are kept in the audit log on your computer, as set in Tools → Policy and roles under Keep restorable copies of:

  • Automatic (the default): a copy of every document before each change on a project or database marked production, including imports, copies, restores, scripts and bulk changes; elsewhere, deleted documents, single edits, bulk field changes and restores. It costs one read for each document changed on production.
  • Deleted documents, single edits and restores: the same as Automatic outside production, everywhere.
  • Everything that changes: copies on every project.
  • Nothing: no copies, so only documents a job created can be removed.

Restoring a backup with Replace, Restore from the audit log and Undo itself keep a copy of each document they write over, on every project, so they can always be undone (unless the policy says Nothing). Documents a job created are always recorded, so they can be removed even without copies.

What Undo doesn't do

  • Changes to Storage files, security rules and composite indexes are listed in the preview but not undone. For rules, the audit log entry of a deploy has Put back these rules…; for a deleted index, Make this index again….
  • It can't undo changes made outside Firetool, or by a copy of Firetool on another computer: the copies are in this computer's audit log.
  • It doesn't merge: a document that was changed again after the job goes back to how it was before the job.

Questions

Can I undo an import or a copy on a project that isn't marked production?

Documents it created, always: they're removed. Documents it replaced go back only if the policy kept copies of them, which on a project that isn't production means Everything that changes. Bulk field changes (Set, Rename, Delete field) and restores keep copies on every project by default. The preview says exactly which documents can't be undone before you start.

Does Undo cost Firestore reads and writes?

One write or delete per document it puts back or removes. Firetool reads nothing from Firestore to work out the plan: it comes from the audit log.

Can I undo from the terminal?

No. Undo runs in the window, where you can see the preview. The firetool command writes to the same audit log, and firetool transfer and firetool restore are each one operation, so you can undo them from the window.