Tree: ceeba0bf35

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 'ceeba0bf35'

${ noResults }

Commit Graph

1 Commits (ceeba0bf35548613a43c00822ba9babb27bdd81b)

Author	SHA1	Message	Date
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