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

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '8136691ad3'

${ noResults }

Commit Graph

3 Commits (8136691ad32623c949287459cb0006c499cc0c59)

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	f61e4fe727	Address custom-role review findings - 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.	1 week 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