Vaultwarden only ever applies pending migrations, so putting an older image
back leaves it facing a schema whose `access_all` column is gone -- and it
refuses to start. The downgrade guard did not help there either: it only ever
blocked `diesel migration revert`, which a self-hosted install cannot run.
- tools/custom_role_rollback/ holds a self-contained script per backend that
restores the pre-PR schema, folds Custom back onto Manager, and drops the
seven ledger rows, so the older version starts again. SQLite rebuilds the
table instead of using DROP COLUMN, for the same 3.35 reason as the forward
migration.
- The guard now states its terms instead of being a dead end: create
__vw_allow_custom_role_downgrade and the revert goes through, so the data
loss is acknowledged rather than merely prevented.
- README documents what the old schema cannot represent, including the two
values that cannot be reconstructed: Owner/Admin return with access_all set,
and a plain User's former access_all stays materialized as the per-collection
assignments the upgrade wrote.
- Migrate legacy `access_all` Users losslessly into per-collection
assignments instead of refusing to start the server.
- Keep provisioning of Admin/Owner memberships Owner-only (invite,
confirm, delete); state changes stay as they were.
- Drop the new organization-import gate; the import stays authorized per
target collection, and now requires a confirmed membership.
- Scope `accessReports` to the caller's own collections instead of
handing out every cipher in the organization.
- Let `createNewCollections` read the collection list it needs.
- Reject group changes a caller may not make instead of silently
dropping them.
- Detect partially applied permission-column migrations on MySQL.
- Drop the migration bookkeeping table and remove dead code.
tom27052006