Tree:
8136691ad3
cached-config-operations
main
revert-7033-patch-1
test_dylint
v2-registration
0.10.0
0.11.0
0.12.0
0.13.0
0.9.0
1.0.0
1.1.0
1.10.0
1.11.0
1.12.0
1.13.0
1.13.1
1.14
1.14.1
1.14.2
1.15.0
1.15.1
1.16.0
1.16.1
1.16.2
1.16.3
1.17.0
1.18.0
1.19.0
1.2.0
1.20.0
1.21.0
1.22.0
1.22.1
1.22.2
1.23.0
1.23.1
1.24.0
1.25.0
1.25.1
1.25.2
1.26.0
1.27.0
1.28.0
1.28.1
1.29.0
1.29.1
1.29.2
1.3.0
1.30.0
1.30.1
1.30.2
1.30.3
1.30.4
1.30.5
1.31.0
1.32.0
1.32.1
1.32.2
1.32.3
1.32.4
1.32.5
1.32.6
1.32.7
1.33.0
1.33.1
1.33.2
1.34.0
1.34.1
1.34.2
1.34.3
1.35.0
1.35.1
1.35.2
1.35.3
1.35.4
1.35.5
1.35.6
1.35.7
1.35.8
1.36.0
1.37.0
1.37.1
1.4.0
1.5.0
1.6.0
1.6.1
1.7.0
1.8.0
1.9.0
1.9.1
${ noResults }
1 Commits (8136691ad32623c949287459cb0006c499cc0c59)
| Author | SHA1 | Message | Date |
|---|---|---|---|
tom27052006
|
7542f3d4e9 |
Provide a supported rollback path for the Custom-role change
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. |
6 days ago |