Skip to main content

​
Two Permission Models

RISKSHEET enforces permissions through two distinct but complementary systems: diagram

​
Polarion Permissions (Base Layer)

Polarion’s native permission system controls:
  • Project Access: Whether a user can see a project at all
  • Document Access: Which documents a user can open (including templates)
  • Field Permissions: Which fields can be edited based on work item status and user role
  • View Configuration: Which topics appear in the portal for specific user roles
These permissions are foundational—if Polarion blocks access, RISKSHEET cannot override it.

​
RISKSHEET Licensing (Application Layer)

RISKSHEET adds a licensing tier on top of Polarion permissions:
  • Active Users: Have edit access within RISKSHEET (limited by license tier)
  • Server Users: Have read-only view access (unlimited count)
All Polarion users with project access can view RISKSHEET data, but only users assigned to the Active User group can create, edit, or delete risk items through the RISKSHEET interface.
Active User count is not automatically calculated by RISKSHEET or determined by Polarion role assignments. It is a business decision made by your organization during license purchase, then manually configured by administrators through Polarion user groups.

​
Access Control Hierarchy

Permissions are evaluated in this order:
  1. Polarion Project Access: Does the user have permission to view this project?
  2. Polarion Document Access: Can the user open this document or template?
  3. RISKSHEET License: Is the user in the Active User group?
  4. Polarion Field Permissions: Does the current work item status allow editing this field?
  5. RISKSHEET Configuration: Is the column marked as readOnly in the configuration?
If any layer denies access, the capability is blocked. For example:
ScenarioPolarion ProjectPolarion FieldRISKSHEET LicenseResult
User A✅ Access✅ Editable✅ Active UserCan edit
User B✅ Access✅ Editable❌ Server UserRead-only (license blocks)
User C✅ Access❌ Read-only✅ Active UserRead-only (Polarion blocks)
User D❌ No AccessN/A✅ Active UserCannot view (Polarion blocks)

​
Field-Level Permission Enforcement

Polarion’s “Read-only Fields” property (which restricts fields based on work item status and user role) does not automatically work with RISKSHEET due to API limitations. Instead, administrators must enable permission checking through configuration: 
nextedy.risksheet.checkInstanceFieldPermissions=true
When enabled:
  • Primary document work items: Fields that violate Polarion permissions are visually disabled (grayed out)
  • Child document work items: Fields appear editable, but save operations fail with an error message
This behavioral difference is architectural—RISKSHEET can only enforce visual restrictions for items in the primary document context.
If you configure read-only fields in Polarion’s workflow but don’t enable checkInstanceFieldPermissions, users will be able to edit those fields in RISKSHEET even when they shouldn’t. Always verify this setting when implementing field-level restrictions.

​
System Fields (Always Read-Only)

Certain fields cannot be edited through RISKSHEET regardless of permissions:
  • Work Item ID (id): Generated by Polarion on creation
  • Type (type): Can be selected during creation but not changed afterward
  • Project (project): Determined by document location
  • Outline Number (outlineNumber): Auto-generated hierarchy position
  • Author (author): Set automatically on creation
  • Created/Updated timestamps: System-managed
Additionally, Resolution is not editable in RISKSHEET because it functions as a mandatory field for specific status transitions, making its validation logic too complex to handle during inline editing. Users must change Resolution through Polarion’s native work item form.

​
Template and Document Permissions

A common access issue occurs when users cannot see or use RISKSHEET templates: Template visibility requires:
  1. Project-level access to the project containing the template document
  2. Read permission for the template document itself
  3. The template path must be configured in project properties (risksheet.templatePath)
Users inheriting projects from predecessors often encounter this issue because templates were configured for specific user groups that no longer include them. Administrators should verify:
  • Topics configuration: Administration → Topics → verify RISKSHEET topic is assigned to relevant user roles
  • View configuration: User’s current view includes the RISKSHEET topic
  • Template location access: User has permission to the project folder where templates reside
See Set Up Global Templates for configuration steps and Access Denied Errors for troubleshooting permission issues.

​
View-Based Access

RISKSHEET visibility in the Polarion portal depends on view configuration, not just permissions. If a user can access a project but RISKSHEET doesn’t appear:
  1. Check Administration → Topics for the project
  2. Verify the current view includes RISKSHEET in its topic list
  3. Ensure the user’s role is assigned to a view that includes RISKSHEET
This is not a permission failure—it’s a view configuration issue. Users can typically resolve this by switching to a different view that includes RISKSHEET, or administrators can add RISKSHEET to the relevant views.
If RISKSHEET redirects to the project home page (especially in Firefox or Edge), this is almost always a view configuration issue, not a browser compatibility problem. Check view topics before investigating other causes.

​
Practical Implications

​
For Administrators

  • Assign Active Users via Polarion user groups (nextedy_risksheet_users or similar)
  • Enable field permission checking with checkInstanceFieldPermissions=true when using Polarion’s workflow-based field restrictions
  • Configure template paths in project properties and ensure users have access to template storage locations
  • Verify view configurations include RISKSHEET topics for all relevant user roles
  • Plan license capacity based on the number of users who need edit access (not total Polarion users)
See Assign Active Users and Configure Permissions for implementation guidance.

​
For Users

  • Read-only mode means either (a) you’re not in the Active User group, or (b) Polarion permissions restrict the field
  • Template access issues usually stem from project-level permissions, not RISKSHEET configuration
  • View-based visibility problems can be resolved by switching views or contacting your administrator
  • Field save failures on child documents may indicate Polarion permission blocks, even if the field appears editable
Support TicketsSource Code
  • AppConfig.ts
  • RisksheetProjectProperties.java
  • PolarionAppConfigManager.java
  • GetSetUtil.java