Permission-Based Field Restrictions

​

Understanding Permission Enforcement

​

Enable Permission Checking

1. Navigate to project settings - Go to Project Administration > Permissions Management in Polarion
2. Enable field permission validation - Add this property:

nextedy.risksheet.checkInstanceFieldPermissions=true

3. Save and refresh - Save the configuration and reload your RISKSHEET
4. Verify enforcement - Test editing restricted fields to confirm visual locking appears

​

Diagnose Permission Denial

​

Visual Indicators

​

Check User Role Permissions

1. Review project permissions - In Polarion, navigate to Administration > [Project] > Permissions > Work Items
2. Identify your role - Find your assigned role(s) in the project (e.g., Developer, Reviewer, Project Manager)
3. Check field permissions - For each field you’re trying to edit, verify your role has “Write” permission, not just “Read”
4. Review workflow-based restrictions - Some fields may be editable only in certain workflow states (e.g., editable in “draft”, locked in “approved”)

​

Resolve Common Permission Scenarios

​

Scenario 1: Status Transition Blocked by Formula Mismatch

1. Identify formula columns:

{
  "columns": [
    {
      "id": "title",
      "formula": "item.severity + ' - ' + item.occurrence + ' - ' + item.description"
    }
  ]
}

2. Compare stored vs. generated values - In Polarion, check if the work item’s title matches what the formula would generate
3. Correct mismatches - Either:
   • Update the stored value in Polarion to match formula output
   • Adjust the formula to match existing data
   • Temporarily remove the formula, save the status change, then restore it

​

Scenario 2: Primary vs. Child Document Behavior Differences

1. Understand the design - This behavioral difference is intentional:
   • Primary documents: Visual prevention (cell won’t open editor)
   • Child documents: Save-time prevention (editor opens, but save fails with error)
2. Check document structure - Identify whether the work item is in the primary document or a child document
3. Train users - Communicate this behavioral difference to prevent confusion when the same field behaves differently in different contexts

​

Scenario 3: System Fields Ignore Configuration

1. Accept the limitation - System fields cannot be edited through RISKSHEET
2. Use Polarion directly - To change work item type or project, use Polarion’s native interface
3. Remove conflicting configuration:

{
  "columns": [
    {
      "id": "id",
      "readOnly": false  // This will be ignored—ID is always read-only
    }
  ]
}

​

Configure Read-Only Columns Explicitly

{
  "columns": [
    {
      "id": "calculatedRisk",
      "header": "Risk Level",
      "formula": "item.severity * item.occurrence",
      "readOnly": true  // Explicitly mark as read-only
    },
    {
      "id": "author",
      "header": "Created By",
      "readOnly": true  // System field, but explicit is clearer
    }
  ]
}

​

Handle Task vs. Risk Permission Differences

1. Check task-specific read-only settings - Configuration supports separate read-only states:
   • systemReadOnly: Controls risk item fields
   • systemTaskReadOnly: Controls task item fields
2. Configure task field restrictions:

{
  "dataTypes": {
    "task": {
      "type": "mitigationTask",
      "role": "mitigates"
    }
  },
  "columns": [
    {
      "id": "taskStatus",
      "binding": "status",
      "level": 2,  // Task level
      "readOnly": false  // Editable for tasks even if locked for risks
    }
  ]
}

3. Verify task permissions separately - Users may have different permissions for task-type work items vs. risk-type work items

​

Verify Resolution

1. Test with restricted role - Log in as a user with limited permissions
2. Attempt to edit restricted field - Click the cell that should be read-only
3. Confirm visual lock - For primary documents, the cell should have a gray background and not open an editor
4. Test child document behavior - For child documents, the editor may open, but save should fail with a clear error message
5. Verify allowed fields - Fields your role has permission to edit should open editors and save successfully

​

See Also

• Cell Editing Issues - General cell editing troubleshooting
• Access Denied Errors - Document-level access issues
• User Roles and Permissions - Understanding RISKSHEET permission model
• Configure Permissions - Setting up project permissions
• Configuration Properties Index - All configuration options
• Column Type Reference - Read-only column types