Firetool

Home / Docs / Environment rules

Docs

Environment rules: reasons and masked copies

Label each project and database Dev, Staging, QA or Production, then give a label rules of its own: a reason for every change, and masked personal data in copies that leave it. New in Firetool 4.5.1, and off until you choose a rule.

Label your environments

  1. Right-click a project in the sidebar and choose Project settings, or right-click a database and choose Settings.
  2. Choose its environment: Dev, Staging, QA or Production. The label shows on every tab, in the sidebar and in the header.

A label alone changes no rule. Choosing Production ticks the production rules (the project ID asked for deletes, scripts and bulk changes), which you can untick. When a label carries an environment rule, Project settings names it beside the label, so choosing one is never a surprise.

Set a label's rules

  1. Open Tools → Policy and roles (Ctrl+Shift+P).
  2. In Environment rules, each label has two choices: Reason for every change and Mask personal data in copies out.
  3. Tick what you want and save the policy. The rules apply to every project and database with that label, on this computer.

Like the rest of the policy, environment rules can be protected with the admin password (see Roles and production safety).

A reason for every change

With Reason for every change ticked for, say, Production, every project and database labelled Production asks for a reason before it changes documents, users, security rules, indexes or Storage files. The reason is kept with the change in the audit log.

  • The question says which label asks for it.
  • The tab's Reason required badge says where the rule comes from.
  • A job asks once for the whole job, not for every batch.
  • In the terminal, --reason "…" gives it; without it, the firetool command stops and says so.

A project's own reason rule, set in its project rules, works as before.

Masked copies out

With Mask personal data in copies out ticked for a label, documents copied from a project or database with that label into one with another label, or none, get their email addresses and phone numbers masked: a***@example.com, +**********10. It covers subcollections too, and document IDs stay as they are.

The rule applies to Copy to…, Copy and Duplicate collection, Data transfer, Duplicate database, copies from Compare collections, Migrate environments, Unfinished copies when they resume, and firetool transfer. A message says so when the copy starts, and the migration preview says so too; a migration compares masked, so a finished one matches when you preview again.

  • Within one label the copy stays exact: Production into Production is not masked.
  • A move is refused, because it would leave only masked data.
  • Users and Storage files can't be masked, so they aren't copied into another environment while the rule is on.

What a rule never does

  • Nothing is on until you tick it: labels alone change nothing.
  • Masking changes only the copy. The documents in the source are never touched.
  • Reading, querying and comparing aren't affected.

Questions

Can I copy real production data into staging when masking is on?

Not through Firetool's copies while Production masks copies out and staging has another label. To copy exactly, untick the rule (if your policy allows it), or copy within one label. Each copy is in the audit log either way.

What counts as personal data?

Email addresses and phone numbers in any text field, at any depth. Other fields, such as names or addresses, are copied as they are, so don't rely on masking alone for data that must never leave production.

Does the rule apply to exports?

No, masking is for copies into another project or database. Exports follow the project's export rules: they can be turned off, and copying to another project can count as an export too.