Risksheet operates within the Polarion ALM permission framework, layering its own access control model on top of Polarion’s native roles and project settings.
This page explains the conceptual model behind user roles in Risksheet, how permissions flow from Polarion through to the grid interface, and how licensing intersects with editing capabilities.
Risksheet does not define its own standalone user database. Instead, it inherits and extends the permission model already established in Polarion. Think of it as a series of gates that a user must pass through before they can perform an action in the risk grid:Each gate narrows or grants access. A user who passes all gates with full permissions can create, edit, and delete risk items. A user who is blocked at the license gate can only view the data in read-only mode.
Before Risksheet even loads, Polarion’s own project roles determine what a user can do within a project. These roles are configured in Administration > User Management and include built-in roles such as:
Polarion Role
Typical Risksheet Impact
Project Administrator
Full configuration access, can edit risksheet.json, manage templates
Project User
Can create, edit, and delete risk items (subject to license gate)
Project Reader
Read-only access to the project and all documents
Custom Roles
Mapped to specific permissions via Polarion’s permission model
Risksheet respects these project-level permissions. If a user has only read access at the Polarion level, Risksheet will not allow editing regardless of the license or configuration settings.
Modifying Risksheet configuration settings such as risksheet.json requires a Polarion Admin role for the project. Non-admin users who need configuration changes must contact their project administrator to request modifications.
Risksheet uses a license model that distinguishes between users who actively work with risk data and those who only need to view it. This distinction is controlled through a Polarion user group mechanism.
Any Polarion server user who is not a member of the nextedy_risksheet_users group automatically receives Connect (read-only) access. These users can:
View all risk data in the grid
Navigate between levels and documents
Use saved views to switch column visibility
View review status and comments
They cannot modify any data. The grid visually indicates read-only status, and save operations are blocked.
A common source of confusion is the difference between server users and Polarion license holders. Risksheet counts all registered users on the Polarion server as server users, regardless of their Polarion license type. This means users with ALM, QA, or even deactivated Polarion licenses still count toward the Risksheet server user total. If your organization has 200 registered Polarion users but only 50 hold active Polarion licenses, Risksheet still sees 200 server users.
The nextedy_risksheet_users group is a standard Polarion user group. Administrators create this group and add the email addresses of users who should have edit access. The license page in Administration > Risksheet displays:
Server Users: Total count of all registered users on the Polarion server
Configured Named Users: Count of users in the nextedy_risksheet_users group
License Capacity: Maximum named users allowed by your license tier
The canAdmin property in the Risksheet configuration indicates whether the current user has administrative privileges for the configuration editor. When canAdmin is false (the default), the user cannot open or modify the risksheet.json configuration through the Risksheet interface.This property is typically evaluated dynamically based on the user’s Polarion project role. Project administrators automatically receive canAdmin = true, which grants access to:
The configuration editor within Risksheet
Template management operations
Document-level configuration overrides
In development or testing environments, setting nextedy.risksheet.disable_admin_check=true as a Polarion system property bypasses the admin permission requirement. Do not use this setting in production.
Setting readonly to true in the configuration makes the entire sheet non-editable for all users, regardless of their role or license status. This is useful for archived documents, baseline views, or compliance snapshots that should not be modified.
The downstreamReadonly property, when set to true, prevents editing of downstream linked items. This protects mitigation tasks and verification activities that originate from other documents, ensuring that edits to shared items occur only in their source location.
Risksheet supports fine-grained field-level permissions through the nextedy.risksheet.checkInstanceFieldPermissions project property. When this property is enabled (set to true), Risksheet evaluates Polarion’s field-level permissions for each work item instance.
Polarion’s built-in “Read-only Fields” UI property has no API that Risksheet can access. If you rely on this Polarion feature to restrict field editing based on work item status (for example, making fields read-only on approved items), those restrictions will not be enforced in the Risksheet grid. Instead, use the Permissions Management approach with nextedy.risksheet.checkInstanceFieldPermissions=true to control field editability based on work item state.
When checkInstanceFieldPermissions is enabled, the system evaluates each field for each work item individually. Fields that the current user does not have permission to modify appear as read-only in the grid. This integrates with Polarion’s workflow-based permission model where field editability can change based on the work item’s current status.
There is a known behavior where items from child documents may show fields as editable in the grid but block the save operation. This occurs because the permission check evaluates at display time differently than at save time for child document contexts. A fix is planned for a future version.
Risksheet visibility in the Polarion navigation sidebar depends on the Risksheet topic being configured for the user’s active Polarion view (also called a “hat”). If the topic is missing from a view, users assigned to that view will be redirected to the space home page instead of seeing Risksheet.This is a common source of confusion that is frequently misidentified as an installation problem, a certificate issue, or a browser compatibility bug. The actual cause is always the topic configuration:
Symptom
Likely Cause
Redirected to space home page
Risksheet topic not configured for user’s view
Risksheet works for some users but not others
Different users assigned to different views/hats
Risksheet disappears after update
Topic removed from custom view during update
XML parsing error on style.css
Missing topic in current view (not a browser issue)
To verify and fix topic configuration, navigate to Administration > Topics and ensure the <topic id='risksheet'/> entry is present for every view/role combination that needs access.
When Risksheet appears broken after an update or for specific users, always verify the Risksheet topic is enabled in the user’s current Polarion view before investigating browser issues, certificates, or server configuration. Ask the affected user which Polarion view (hat) they are using, then check Administration > Topics for that view.
Regardless of the user’s role or permissions, certain system fields are always protected from modification through Risksheet:
Protected Field
Reason
id
Work item identity, managed by Polarion
status
Controlled by workflow transitions, not direct editing
type
Work item type is immutable after creation
project
Project assignment is structural
outlineNumber
Document outline position, managed by Polarion
author
Set at creation time, not editable
resolution
Controlled by workflow transitions
created
Timestamp, set automatically
updated
Timestamp, set automatically
Attempts to save changes to these fields are silently ignored by Risksheet. The grid may display these fields for informational purposes, but they are always rendered as read-only.
When POWERSHEET is installed alongside Risksheet with a valid production license, additional features are automatically unlocked. This integration is transparent — no manual configuration is required. The system detects the POWERSHEET license and adjusts available capabilities accordingly.Key points about the integration:
Evaluation or trial POWERSHEET licenses do not enable the enhanced feature set
License changes are detected automatically without requiring a server restart
Both products can be licensed independently
When upgrading to version 25.11.0 or later with POWERSHEET installed, users must also be added to the nextedy_powersheet_users group for license alignment
After upgrading Risksheet to version 25.11.0 or later, if POWERSHEET is also installed, you may see 0 named users on the license page even if the nextedy_risksheet_users group is correctly configured. Create a nextedy_powersheet_users group and add the same users to resolve this. A Polarion service restart may be required for changes to take effect.
