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.
- Update Rust to v1.94.1
- Updated all crates
- Update GHA
- Update global domains and ensure a newline is always present
Signed-off-by: BlackDex <black.dex@gmail.com>
* Change API inputs/outputs and structs to camelCase
* Fix fields and password history
* Use convert_json_key_lcase_first
* Make sends lowercase
* Update admin and templates
* Update org revoke
* Fix sends expecting size to be a string on mobile
* Convert two-factor providers to string
- Update all crates
- Update GHA
- Update Global Domains script to use main instead of master
Also fixed some Python linting warnings
- Updated Admin JS and CSS libraries
The script works by reading the relevant files from the upstream Bitwarden
source repo and generating a matching JSON file. It could potentially be
integrated into the build/release process, but for now it can be run manually
as needed.