Roles and access
Bud roles, policies and groups, who can see and change what, and how Test Stations are kept apart from users.
Bud has admin, developer, and viewer user roles. A user’s permissions are those of their role plus those of their groups: a group is a set of policies, and a policy is a set of permissions such as evidence.view, custom_runs.create, bloom_publish.execute, and access.manage. Administrators and users with access.manage manage groups on the Access page. Test Stations use separately enrolled runner identities and are the only identities that submit results and upload artifacts.
Base roles
Section titled “Base roles”Every user has a base role, chosen when they are invited.
- Viewer reads everything and changes nothing. The Viewer role is meant for internal viewers.
- Developer is Viewer plus queuing custom runs on the Test Stations and publishing a run’s report to Bloom.
- Admin holds every permission. Admin is chosen when a user is created or invited. An existing user is never promoted to it, and an Admin’s role is never changed.
Managing users and their accounts, deleting runs and artifacts, and confirming an Admin’s own email change stay with the Admin base role. They are never given through a group.
Policies and groups
Section titled “Policies and groups”A policy is the set of rights for one area of Bud: Results, Custom runs, Publish to Bloom, Stations, Products, Settings and integrations, Audit log, and Access management. A group is a named bundle of policies. A user can have several groups. Their access is the base role’s allowance plus every policy of every group. A group only adds.
Permissions are resource.action pairs:
evidence.view, reports.export, products.view, products.manage, stations.view, stations.manage, custom_runs.create, bloom_publish.execute, settings.view, settings.edit, audit.view, access.manage.
Bud ships five groups:
- Results Viewers
- Test Operators: Results, Custom runs, Publish to Bloom
- Station Managers: Results, Stations
- Access Managers: Station Managers plus Access management
- Application Administrators: every policy
These rules apply:
- Shipped groups and policies cannot be changed. Duplicate one to make an editable copy.
- A group that manages stations is given only to users with the Admin or Developer base role.
- Only an Admin gives Application Administrators and edits policies.
- Someone with Access management gives, creates, and edits only groups whose policies they hold themselves.
- Access is not scoped by products or stations: every user sees every product.
The Access page
Section titled “The Access page”Access in the sidebar is open to Admins and users with access.manage. It has four parts:
| Part | What it holds |
|---|---|
| Assignments | Group rosters |
| Groups | Policy bundles |
| Policies | Read and Write controls |
| Requests | Access requests |
Users is a separate account-management page.
Access requests
Section titled “Access requests”A user who opens a run they may not see gets a page with a Request access button. A user without Publish to Bloom finds Request access in place of Publish on a run. Admins and Access managers are emailed, and grant Publish to Bloom by giving the user a group that holds it.
Requests are decided under Access, Requests. A user can make one request per resource per 24 hours. Requests and their decisions are written to the audit log. If the email fails, the request is kept and the user is told. See Email and invites.
Test Stations
Section titled “Test Stations”Test Stations create execution records, report their status and counters, and submit raw results using their station credentials. These submissions are limited to the station’s own runs. Human sessions, including Administrator, cannot submit those execution records. Users request queued work through Custom Run. See Backend-queued runs.
Roles in Bloom
Section titled “Roles in Bloom”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.
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. 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.