Users and Roles

Users and roles

Studio uses Drupal's users, roles and permissions, so everything you know about Drupal applies. On top of that, Studio adds one important rule about Developments. Let's untangle it.

Two questions decide what someone sees

flowchart TD
    U[A person opens a record] --> Q1{Does one of their roles<br/>allow this kind of action?}
    Q1 -- no --> X[⛔ Not allowed]
    Q1 -- yes --> Q2{Is the record in a Development<br/>they belong to?}
    Q2 -- no --> X
    Q2 -- yes / not in a Development --> OK[✅ Allowed]

Loading

1. Permissions (from site roles) say what kind of things someone can do: read artifacts, edit diagrams, execute tests…
2. Membership says where: someone sees a Development, and everything inside it, only if they're its owner, its responsible person or one of its members.

So to give Alice access to the Billing platform, you give her a role (say, Content editor) and add her as a member of that Development (its Edit tab).

The roles installed by Studio

Role	For	Highlights
Content editor	Analysts, designers, engineers	Create and edit artifacts, diagrams and traces; move them through their lifecycles; use the Unified Process; work on project tasks and comment; read test plans.
QA User	People who need to read testing	Read test plans and the runs assigned to them.
QA Tester	Testers	Execute assigned runs, record results and evidence, report QA issues. Sees only their own runs.
QA Lead	Test leads	Design plans, create and assign runs, dashboard and reports, link tests to requirements.
QA Manager	Head of QA	Everything a lead can do, plus QA configuration, reopening runs and deleting QA records.
Project Manager	Team leads	Create projects and subprojects, edit any project they see, see everyone's timesheets on them.
Database analyzer	CI service accounts	Only pushes database snapshots over HTTP into the Developments it is a member of.
Studio Manager	Heads of engineering, process owners	Everything in Studio's business logic: all records, the process, QA, projects, timesheets, knowledge, discussions and their configuration. Not a Drupal site administrator: no modules, themes or user administration, and always the Studio theme.
Administrator	Site admins	Everything, including Drupal site administration (admin theme).

The QA roles are cumulative: a Manager is also a Lead, a Lead is also a Tester, and so on. You can give someone Content editor and QA Lead at the same time; roles add up.

Key permissions

Permission	What it unlocks
Access Divengine Studio	The workspace itself.
Use the Unified Process	Developments you belong to, My work.
Administer the Unified Process	Every Development, process configuration. Give it carefully.
View / create / edit artifact (and per type)	Artifacts.
Use lifecycle transition X	Moving artifacts between states (e.g. approve requirements).
View / create / edit trace links	Traceability.
Use projects	See your projects and work on their tasks.
Manage projects	Create projects; edit and delete any project you see.
Administer projects	See every project; edit stages and task types.
Log time	Record your own timesheet entries.
Explore / Manage database schemas	See databases, explorer and evolution / register databases and import snapshots.
Import database snapshots	Push snapshots over HTTP (analyzer accounts).
Read code docs	Read extracted technical documentation in visible Developments.
Manage code docs	Register documentation sets and import snapshots.
Publish code docs	Push documentation from scripts into Developments the account belongs to.
Administer code docs	Delete ready documentation history in visible Developments.
Manage timesheets	See and correct everyone's entries on the projects you see; filter the report by person.
Use test management	Read QA.
Execute tests	Tester actions.
Manage test management	Lead actions.
Administer test management	Manager actions.

Tip: approving requirements is a separate permission (use requirement_lifecycle transition approve). Give it only to the people who should have the final word.

Process roles are not permissions

The Code docs publisher role is for extraction scripts and CI: it grants upload permission only. Add the account to the Developments it feeds. Content editors, Project Managers and the MCP agent receive read access; Studio Managers can manage the documentation. See Code docs.

Inside a Development you also assign process roles (Requirements Analyst, Tester…). Those describe responsibilities and feed the readiness check, but they don't grant access. Keep that in mind when someone says "but I'm the Tester of this Development and I can't execute the run!": they need the QA Tester site role too.

Adding a person, step by step

1. Manage → People → Add user. Fill in the name, email and password.
2. Tick their roles (for example Content editor and QA Tester).
3. Open the Development they work on, click Edit, add them as a member.
4. Optionally, assign them a process role in the Development.

Done. Next time they log in, My work and My test runs will already show their stuff.