* Add revision_date to org policies
Org policy JSON responses never included a revisionDate field, unlike
every other synced entity. The official Bitwarden server always sets
it, and current official clients (recently migrated to the WASM SDK's
typed PolicyView) now assume it is always a valid date string. Its
absence deserializes to undefined client-side, which then throws
(RangeError: Invalid time value) when the client formats it, breaking
the whole policy sync pipeline and silently emptying the vault view in
the browser and desktop apps.
Adds a revision_date column (mirroring the existing pattern used by
Send), stamped on creation and bumped on every save.
* Fix migration correctness for org policy revision_date
Caught by review: SQLite rejects non-constant defaults in ALTER TABLE
ADD COLUMN, so the sqlite migration would fail outright on every
existing installation (vaultwarden's default backend) rather than the
postgresql setup this was developed against.
- sqlite/mysql: add the column with a constant placeholder default,
then backfill via UPDATE, since neither allows a volatile default
in ALTER TABLE ADD COLUMN (mysql does allow it, but a constant
keeps the three backends' migrations symmetric).
- mysql: use DATETIME instead of TIMESTAMP, matching this repo's
existing revision_date columns, and backfill with UTC_TIMESTAMP()
instead of a session-timezone-dependent CURRENT_TIMESTAMP.
- postgresql: backfill with `now() AT TIME ZONE 'utc'` instead of a
DEFAULT now(), since assigning timestamptz now() into this naive
TIMESTAMP column would otherwise cast through the server's TimeZone
GUC and store local wall-clock instead of UTC on non-UTC servers.
- mysql/postgresql: add a real down.sql (DROP COLUMN) instead of
leaving it empty.
* Move org policy revision_date migration after the latest one
---------
Co-authored-by: Daniel García <dani-garcia@users.noreply.github.com>
will-lottkowitz-prism
d1cbd027cd