Roles and access
Bloom's user roles, per-project groups of policies, document origins and access requests.
Bloom has three user roles: admin, maintainer, and external, shown in the app as Admin, Maintainer, and Viewer. Admins operate globally. Everyone else works through access per project: each person is given a group of policies in each project. Administrators, Developers, Product Owners, and Testers are available in every project, Customers when you need it. Policies control actions by resource and document origin. The split is built for sharing V&V work with customers without exposing your internal requirement set.
Bud has its own roles (admin, developer, viewer) and its own groups and policies. They are described in the Bud docs.
| Stored value | Shown as | Scope |
|---|---|---|
admin |
Admin | Operates globally |
maintainer |
Maintainer | Works through access per project |
external |
Viewer | Works through access per project |
Groups and policies
Section titled “Groups and policies”A group is a set of policies. Assign people to a policy group separately in each project.
- Default groups. Administrators, Developers, Product Owners and Testers are available in every project. Customers is optional.
- Policies. A policy controls actions by resource and document origin. Write includes Read, while Review remains independent.
- Default policies are protected and can be duplicated. Groups remain editable.
- Application permissions. Application Administration and Access Management are assigned separately from project access.
Origins
Section titled “Origins”Every artefact carries an origin: internal by default, customer when shared. Read Internal covers every origin; Read Customer covers customer content only, so a customer group sees exactly the slice you share. Review Customer also covers customer content.
You can add custom origins. They are stored as tags.
- The Access Management application permissions control the origin catalogue.
- An artefact editor assigns origins from their permitted scope on the artefact’s detail page.
- Policies can restrict access by origin.
- Viewer (
external) accounts choose origins only when creating an artefact. They cannot change them afterwards. - Renaming an origin is available through
PATCH /tags/{id}, rather than a rename control in the web app. A rename preserves the references from artefacts and policies.
What people cannot see
Section titled “What people cannot see”- An export holds only what the user may see. Artefacts hidden from external users and document types outside their allowlist are left out.
- A read by ID of an artefact in a project the user is not in answers
404, the same as for an artefact the user may not see.
Access requests
Section titled “Access requests”A user who opens something they may not see gets an access-denied page with a Request access button. The request and its decision are recorded in the audit log.
- The page covers projects, documents, artefacts, suites and campaigns, and names the resource only by its address (public ID and project).
- The administrators are emailed with the requester, the resource, the time, the request ID and a link to the project’s members.
- A user can send one request per resource every 24 hours. The page says when one is pending.
- Administrators mark a request granted or refused under Access, Requests across projects, or on the project’s members page. Project access itself is managed separately, through groups.
- If the email fails, the user is told and the request is kept. Without SMTP the request is still recorded and shown under Access, Requests and on the project’s members page.
Administrators read the requests and decisions in the audit log. See Security.