Site Administration

Requires site administration access. The features described in this article are only available to users with the Site Administrator role (or another role granting the relevant site-tier permissions).

The admin area at /admin provides centralized management of users, workareas, groups, roles, and global configuration.

User Management

Navigate to Administration → Site → Users to create and manage user accounts.

Creating a User

1. Click Add User
2. Enter a Username (unique identifier, cannot be changed)
3. Optionally set a Display Name and Email
4. Optionally set a Password — tick Temporary to force a change at first login. Leave it blank to create a passwordless service user that authenticates only through API tokens (see below).
5. Click Create

Editing a User

Click a user to open their detail page. It is organized into tabs:

• General — Change the display name and email.
• Security — Set or reset the user’s password.
• API tokens — Issue, list, and revoke long-lived API tokens on the user’s behalf (see below).
• Roles — Manage both site roles (applying across the whole installation) and per-workarea roles. See Roles & Permissions for how roles work.

API Tokens and Service Users

Under a user’s API tokens tab you can mint tokens that act as that account for tools and automation (for example an MCP client or a CI pipeline). Each token is created with a name, an access scope (Read & write or Read only), and an optional expiry. The token value (prefixed roparc_pat_) is shown only once at creation — copy it immediately, as it cannot be retrieved again. Tokens can be revoked at any time from the same tab.

A service user is simply a user created without a password: because the password is optional in the Add User form, leaving it blank produces a non-interactive account whose only way to authenticate is through the API tokens you issue on its API tokens tab. This is the recommended pattern for integrations and bots.

Deactivating a User

Click the deactivate button next to a user and confirm. Deactivated users cannot log in but their data is preserved. Users can be reactivated later.

Searching Users

Use the search bar to filter users by ID, display name, or email. Summary cards show total, active, and inactive user counts.

Workarea Management

Navigate to Administration → Site → Workareas to manage all workareas in the system.

Creating a Workarea

1. Click Create Workarea
2. Enter a Workarea ID (unique, cannot be changed)
3. Set a Name
4. Select a Group from existing groups
5. Optionally add a Description
6. Click Create

Workarea Actions

From the actions menu on each workarea, you can:

Action	Description
Edit Properties	Change name, group, and description
Manage Members	Add or remove workarea members and change roles
Save as template	Capture the workarea as a reusable project template — see Project Templates below
Activate / Deactivate	Toggle the workarea’s active status
Open Workarea	Navigate to the workarea

Filtering Workareas

Use the status filter to view All, Active, Inactive, or Deleted workareas. The search bar filters by ID, name, or group.

Workarea Group Management

Navigate to Administration → Site → Workarea Groups to organize workareas into groups.

Groups provide a configuration inheritance layer between global defaults and individual workareas. All workareas in a group inherit the group’s item types, link types, enumerations, and workflow definitions. See Configuration Inheritance for how the three tiers merge.

Creating a Group

1. Click Create Group
2. Enter a group name and optional description
3. Click Create

Group Settings

Click the settings icon on a group to configure the settings every workarea in the group inherits. A group’s configuration is organized into tabs — General (name and description), Item Types, Document Types, Iteration Types, Link Types, Enumerations, Suspect Links, Verification, and Icon Library — the same building blocks a workarea configures in its own Settings, applied one tier up.

Deleting a Group

Groups can only be deleted if they have no assigned workareas. Remove or reassign all workareas first.

Project Templates

Navigate to Administration → Site → Templates to manage project templates. A template captures a starting project — its methodology configuration plus a starting structure and content — so you can stamp out new workareas from it instead of configuring each one from scratch.

You create a template from any existing workarea: open the Save as template action from the workarea’s actions menu (on the Workareas page) and give it a name. You can also choose whether to include the workarea’s content or capture structure only. The template is stored in the site repository and versioned in Git like any other configuration.

The Templates page lists every template with its target group and its item and document counts. From each row you can:

Action	Description
Use	Create a new workarea from the template — you supply a Workarea ID (1–10 uppercase letters and numbers), a name, and an optional description
Edit	Change the template’s name and description
Download	Export the template as a .roptmpl archive to move it to another server
Delete	Remove the template (this cannot be undone)

Use Upload template at the top of the page to import a .roptmpl archive exported from another installation.

Access Control

Access in ROPARC is role-based: roles bundle permissions and are assigned to users or user groups at the site, workarea-group, or workarea tier. Four articles cover the system:

• Roles & Permissions — the permission model, built-in roles, the permission matrix, and creating custom roles
• Query-Scoped Permissions — narrowing a grant with a query predicate, e.g. “edit only own drafts”
• User Groups — granting roles to many users at once
• Troubleshooting Permissions — the Effective Permissions inspector and common access questions

Global Configuration

Navigate to Administration → Site → Global Configuration to define system-wide defaults.

Global configuration provides the base settings that all groups and workareas inherit from. It includes:

• Item Types — Default item types available system-wide
• Link Types — Default link types available system-wide
• Enumerations — Default enumerations available system-wide

Individual groups and workareas can inherit these defaults or override them with their own configurations. See Configuration Inheritance for details on the configuration hierarchy and merge rules.

Authentication

The Global Configuration page also has an Authentication tab for installation-wide sign-in and provisioning:

• Single sign-on (OIDC) — Connect an external identity provider so users log in through your IdP. You configure the issuer, client ID, and an optional label, restrict sign-in to specific email domains, choose which claim matches the ROPARC login ID (defaults to preferred_username), and optionally auto-provision new users into a default group.
• SCIM provisioning — Enable SCIM so your identity provider can create, update, and deactivate users automatically. When enabled, you mint a SCIM bearer token (prefixed roparc_scim_) and point your provider at the SCIM endpoint shown on the page. The token is displayed only once at creation.