Although most user uploads are probably harmless, it's possible someone
has (either maliciously or not) uploaded sensitive information. Prevent
robots from indexing the uploads route.
* This looks like we're doing the same thing but
we're debugging a race condition where a user
can be created without an email record. Therefore,
we prefer the more obvious method of assigning an
association.
* Since we can no longer restore into a different schema,
we will move tables in the public schema into the backup schema
first before restoring the dump file which goes into the public
schema. The downside to this approach is that we will increase
the downtime experienced during the restore process. Downtime
would equal the duration of restoring the dump file.
* In `pg_dump` 10.3+ and 9.5.12+, in
it does a `SELECT pg_catalog.set_config('search_path', '', false)`
which changes the state of the current connection. This is known
to be problematic with Pgbouncer which reuses connections. As such,
we'll always try to connect directly to PG directly during
the backup/restore process.
We trust staff + tl2 and up to perform edits in grace period.
Allow them significantly more edit room in grace period prior to storing
a revision.
editing_grace_period_max_diff_high_trust applies to users with tl2 and up.
So
tl0 / 1 : we store an extra revision if more than 100 chars change
tl2 and up : we store an extra revision if more than 400 chars change
We may tweak these numbers as we go.
If a user performs a substantive edit of 20 chars or more during grace period
we will store a revision to track the change
This allows for better auditing of changes that happen during the grace period
