Control who can view, edit, and administer Risksheet documents by configuring project roles, field-level permissions, topic visibility, and template project access.
Risksheet enforces permissions at multiple layers. Understanding how these layers interact prevents common issues where users see broken layouts, cannot save edits, or are redirected away from the Risksheet view entirely.
Permission Level
What It Controls
Where Configured
Project Admin role
Configuration editing, template management, canAdmin flag
Polarion project roles
Sheet-level readonly
Entire Risksheet read-only for all users
readonly property in risksheet.json
Downstream readonly
Prevents edits to linked items from other documents
Risksheet automatically determines admin status from the user’s Polarion project role. The canAdmin property is set at runtime based on the current user’s permissions --- you do not set it manually in risksheet.json.When canAdmin is true, the user can:
Open the Risksheet configuration editor (accessible via the ⚙️ settings button)
Edit risksheet.json directly or through the configuration editor UI
Manage global templates and template paths
Access the configuration editor at the URL: <baseUrl>/risksheet/configuration/?project=<projectId>&document=<documentId>
When canAdmin is false, the configuration editor button is hidden and the user cannot modify the sheet structure.To grant admin access to a user:
Navigate to Administration > Users & Roles in your Polarion project.
Assign the user the Admin role for the project.
The user will see canAdmin = true on their next Risksheet load.
Risksheet can modify Polarion fields that are marked read-only when the user has administrator permissions. This happens because Polarion’s read-only field APIs are not available to third-party applications. Admin users should exercise caution when editing approved or verified risk items.
To make the entire Risksheet read-only for all users (regardless of their project role), set the readonly property in risksheet.json:
{ "readonly": true}
Property
Type
Default
Description
readonly
boolean
false
Makes the entire Risksheet read-only, preventing any user edits to grid cells or structure
downstreamReadonly
boolean
false
Makes downstream linked items (tasks, mitigations) read-only to prevent edits to items from other documents
reviewer
boolean
false
Enables reviewer mode which restricts editing and shows review-specific UI controls
When viewing a historical revision of a document (via the revision URL parameter), Risksheet automatically forces readonly to true, regardless of the configuration setting. This prevents accidental edits to historical snapshots.
Polarion’s built-in “Read-only Fields” UI property has no API, so Risksheet cannot enforce it directly. Instead, use Polarion Permissions Management with the checkInstanceFieldPermissions configuration property to control which fields are editable based on the work item’s current workflow state.
Navigate to Administration > Permissions in your Polarion project.
Define which fields can be edited in each workflow state. For example:
Draft state: all fields editable
In Review state: only review-related fields editable, risk parameters locked
Approved state: all fields read-only
Risksheet reads these permission rules at runtime and marks individual cells as read-only based on each work item’s current status.
Polarion’s “Read-only Fields” property (configured in the work item type’s workflow settings) has no API accessible to third-party apps. Risksheet cannot read or enforce this property. You must use Permissions Management with checkInstanceFieldPermissions=true to achieve field-level read-only behavior. Without this property enabled, Risksheet cannot determine which fields should be locked.
There is a known issue where items from child documents may display fields as editable in the grid but block the save operation when field permissions deny modification. This can cause confusing “save failed” errors. A fix is planned for a future Risksheet version. In the meantime, ensure child document items have consistent permission configurations.
When your Risksheet uses a configuration template from a different Polarion project (via source or templateName in risksheet.json), all users who open the Risksheet must have read access to the template project. Without this access, Risksheet fails to load the template configuration and falls back to a default or broken structure.
Identify the template project by checking the source or templateName property in risksheet.json:
{ "source": "/ProjectTemplates/FMEA-Template/risksheet.json", "templateName": "FMEA Standard Template"}
Navigate to the template project’s Administration > Users & Roles.
Grant read access to all users and groups that need to use the Risksheet in the consuming project.
When a user lacks read access to the template project, Risksheet does not display an error message. Instead, it silently loads a different (likely broken) configuration. If a user reports seeing a different sheet structure than their colleagues, check their access to the template project first.
Risksheet must be registered as a topic in your Polarion project’s navigation for users to access it from the sidebar menu. If the topic is not configured for a user’s role or view, they are redirected to the space home page instead of the Risksheet view.
Navigate to Administration > Topics in your Polarion project.
Ensure the Risksheet topic is listed and enabled.
Verify that the topic is assigned to all relevant views and roles. Each view/role combination must include the Risksheet topic.
If specific users are redirected to the space home page when navigating to Risksheet while other users can access it normally, the issue is almost certainly a missing topic assignment. Check Administration > Topics and verify the Risksheet topic is configured for that user’s view/role combination.
Step 6: Handle Formula and Permission Interactions
Formula-generated fields can conflict with field-level permissions in ways that cause unexpected save failures. Understanding this interaction prevents frustrating errors for end users.
Run Check stored formulas before status transitions: Before moving risk items from Draft to Review or Approved, ensure all formula values are synchronized. Navigate to Menu > Rows > Check stored formulas (requires v24.5.1+).
Keep formula columns visible during status changes: Formula columns must be visible for reconciliation to work.
Avoid title truncation drift: After Polarion migrations, check that stored title lengths match formula output lengths.
Formula-generated fields may trigger save failures when permissions restrict editing. If stored values differ from formula output (for example, after title truncation during a Polarion migration), Risksheet tries to save the recalculated values, which are then blocked by field permissions. Use Check stored formulas in an editable workflow state to resolve the discrepancy before transitioning to a restricted state.
