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	bf56c9b169	Add accessEventLogs, accessImportExport and accessReports Custom permissions Implements the three remaining Bitwarden Custom-role permissions on top of the existing set. Each is an independent, persisted flag on the membership, gated on the Custom role in code (stale flags on other roles grant nothing); Owners/Admins hold every permission implicitly. They are parsed from and emitted in the `permissions` object (replacing the previously hard-coded `false`) so the unmodified web-vault shows and round-trips them. Server-side enforcement: - accessEventLogs: the organization event-log endpoints (`GET .../events` and `GET .../users/<id>/events`) now use a new `AccessEventLogsHeaders` guard (Admin/Owner or the permission) instead of `AdminHeaders`. - accessImportExport: `GET .../export` uses a new `AccessImportExportHeaders` guard, and `post_org_import` gains an explicit permission check. NOTE: this tightens org import, which previously accepted any confirmed member (with per-collection gating). It now requires Admin/Owner or the permission, matching Bitwarden and the web-vault, which only offers org import to permitted members. Flagged here for maintainer review. - accessReports has no server endpoint in Vaultwarden (reports are computed client-side from vault data the member already has), so it is stored and reported in the permissions object and enforced by the client UI, matching Bitwarden's own model. No server route gates it. New migration adds the three columns (down drops them). Unit tests cover independence, type-gating, parsing and change-detection; a black-box probe over HTTP confirms the event-log/export/import gating and the permission round-trip (16/16), and the existing custom-role suite still passes (30/30).	3 weeks ago