Tree: 0ee17660d0

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

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '0ee17660d0'

${ noResults }

Commit Graph

2 Commits (0ee17660d065dea198ec214654d2db1c302e4b8a)

Author	SHA1	Message	Date
tom27052006	634d9b2bd3	Fix migration portability and preserve legacy group collection authority - SQLite: the access_all drop used ALTER TABLE ... DROP COLUMN, which needs SQLite 3.35 while a sqlite_system build links whatever the host provides and libsqlite3-sys accepts 3.34.1. Use the portable table rebuild instead. - Preflight: it returned Proceed for every database carrying the repair migration. Both the access_all drop and the access-permission columns run after that repair, so their interrupted MySQL/MariaDB states went undetected and every restart failed with 1091/1060. Check schema and ledger after the repair too, complete a recorded-drop-without-ledger in place, and refuse the remaining states with a recovery path. - Keep deriving a legacy Manager's collection edit/delete from the organization-local access_all group it came from, rather than dropping the authority when the repair removes its 0/1/1 copy. Stays revocable with the group; collection creation remains the independent permission. - post_org_import: Bitwarden does not require accessImportExport either, it authorizes on that permission *or* per-collection create/import authority.	6 days ago
tom27052006	5558b41801	Remove membership access_all flag and fold Manager role into Custom The per-membership `access_all` flag was Vaultwarden's pre-permissions patch for "this member reaches every collection". It is now fully represented by the role model: Owners/Admins hold it implicitly, and a Custom member holds it via `edit_any_collection`. Every authorization query that read `users_organizations.access_all` now reads `edit_any_collection = true OR atype <= Admin` instead, which is exactly the set the flag ever identified, so admin/owner and edit-any access is preserved. The column is dropped via a new migration (down-migration restores it from the role/permission model). `groups.access_all` is a separate, still-supported group feature and is untouched. The legacy Manager role (wire value 3) is folded into Custom: the `MembershipType::Manager` variant is removed, all `>= Manager` rank checks become `>= Custom` (identical authorization rank), the `LegacyManager` collection-access path collapses into the Custom rules, and an incoming wire `type=3` is mapped onto Custom for backward compatibility. Custom stays `type=4` because that is the only role modern Bitwarden clients render with custom permissions. Existing type-3 members were already converted to Custom by the earlier migration. Server-only change; verified against the unmodified web-vault. Unit tests, clippy and rustfmt pass; migration up/down verified against SQLite.	3 weeks ago