Skip to main content

​
Permission Architecture Overview

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.
diagram
1

Configure Admin Access

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 sheet configuration.When canAdmin is true, the user can:
  • Open the Risksheet configuration editor (accessible via Menu > Configuration > Edit Risksheet Configuration)
  • Edit sheet configuration 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 Edit Risksheet Configuration entry under Menu > Configuration is hidden and the user cannot modify the sheet structure.To grant admin access to a user:
  1. Navigate to Administration > Users & Roles in your Polarion project.
  2. Assign the user the Admin role for the project.
  3. 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.
2

Set Sheet-Level Read-Only Mode

To make the entire Risksheet read-only for all users (regardless of their project role), set the readonly property in sheet configuration:
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.
3

Enable Field-Level Permissions

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.

​
Enable the Property

  1. Navigate to Administration > Configuration Properties in Polarion.
  2. Add the following property:
  1. Save the configuration.

​
Configure Field Permissions in Polarion

  1. Navigate to Administration > Permissions in your Polarion project.
  2. 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
  3. 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.

​
How Field Permissions Appear in the Grid

When checkInstanceFieldPermissions is enabled:
  • Read-only cells receive a readonly CSS class, which provides a visual indicator (typically a subtle background change)
  • Attempting to edit a read-only cell has no effect --- the cell editor does not activate
  • The readOnly column property is automatically set to true for restricted fields, overriding the column-level configuration
  • System fields (author, resolution, created, updated, type) are always read-only regardless of permission settings
4

Configure Template Project Access

When your Risksheet uses a configuration template from a different Polarion project (via source or templateName in sheet configuration), 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.

​
Symptoms of Missing Template Access

  • Users see a completely different Risksheet structure than other users in the same project
  • The column layout does not match the expected FMEA/HARA configuration
  • No explicit error message is displayed --- the sheet simply loads with wrong columns

​
Resolution

  1. Identify the template project by checking the source or templateName property in sheet configuration:
  1. Navigate to the template project’s Administration > Users & Roles.
  2. 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.
5

Configure Topic Visibility

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.

​
Add Risksheet to Navigation

  1. Navigate to Administration > Topics in your Polarion project.
  2. Ensure the Risksheet topic is listed and enabled.
  3. 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.
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.

​
The Problem

  1. A formula column computes a value (e.g., a title or RPN) and stores it in the work item.
  2. The work item’s status changes to one where the field is read-only (e.g., “Approved”).
  3. On the next Risksheet load, the formula recalculates the value.
  4. If the stored value differs from the formula output (due to data migration, truncation, or external edits), Risksheet marks the item as “edited.”
  5. When the user saves, Polarion rejects the write because the field is read-only in the current workflow state.

​
Prevention Strategies

  • 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.

​
Verification

After configuring permissions, you should now see:
  1. ✅ Admin users can open the configuration editor via Menu > Configuration > Edit Risksheet Configuration and can modify sheet configuration
  2. ✅ Non-admin users cannot access the configuration editor
  3. ✅ When checkInstanceFieldPermissions=true is set, cells in approved work items display as read-only with visual indication
  4. ✅ All users see the same Risksheet structure (confirming template project access is correct)
  5. ✅ Risksheet appears in the project navigation sidebar for all intended roles
  6. ✅ Connect/viewer users see the sheet in read-only mode without editing capability

​
See Also

Last modified on July 10, 2026