Configure and troubleshoot field-level edit restrictions in Risksheet, including instance field permissions, read-only enforcement for approved work items, downstream item protection, and formula inte
Risksheet applies multiple layers of permission checking when a user attempts to edit a cell. Understanding this flow helps diagnose which layer is blocking (or failing to block) an edit:
By default, Risksheet does not enforce Polarion’s per-instance field restrictions because the native “Read-only Fields” property has no API. To enable field-level permission checking based on Polarion’s Permissions Management, set the following project property in Polarion administration:
This property tells Risksheet to query Polarion’s Permissions Management rules for each field before allowing edits. When enabled, fields that are restricted in the current work item status (e.g., severity locked in “Approved” status) will appear as read-only cells in the grid.How to set the property:
Open Polarion Administration for your project
Navigate to project properties or global administration
Add or modify the property nextedy.risksheet.checkInstanceFieldPermissions
Set the value to true
Reload the Risksheet page
Risksheet cannot read Polarion’s “Read-only Fields” UI property because no API exists for it. You must use Permissions Management with checkInstanceFieldPermissions instead. Without this property enabled, Risksheet allows editing fields that Polarion’s native work item editor would restrict. This is the primary reason users report being able to edit fields on approved work items.
Certain system fields are always read-only in Risksheet regardless of any permissions configuration. Save attempts to these fields are silently ignored:
Field
Binding
Reason
Work Item ID
id
System-generated identifier, immutable
Status
status
Controlled exclusively by workflow transitions
Type
type
Work item type cannot change after creation
Project
project
Project assignment is fixed
Outline Number
outlineNumber
Document structure position, managed by Polarion
Author
author
Auto-set on work item creation
Resolution
resolution
Tied to workflow status transitions
Created Date
created
Auto-set timestamp, immutable
Updated Date
updated
Auto-set timestamp, managed by Polarion
Additionally, columns are automatically set to read-only in the following cases:
Condition
Property
Behavior
Column has a formula
formula property is set
Column becomes read-only automatically
Column uses server rendering
serverRender property is set
Column becomes text type and read-only automatically
Column is a reference
Reference column type
Column becomes read-only automatically
You can also explicitly mark any column as read-only in the configuration:
The readOnly property must use camelCase with an uppercase O. Writing "readonly": false will not work. This is one of the most common configuration mistakes.
When formula-generated fields interact with permission restrictions, unexpected save failures can occur. This is a subtle issue that typically surfaces after data migrations or Polarion upgrades.The conflict sequence:
A formula recalculates a value (for example, auto-generating the title field from hazard + effect)
The recalculated value differs from the stored value (for example, titles were truncated to 80 characters during a Polarion migration, but the formula generates the full-length title)
Risksheet detects a change and marks the item as edited
On save, Risksheet attempts to write the recalculated value
Permissions block the save because the field is read-only in the current status (e.g., “Approved”)
The save fails with a permission error, even though the user only changed a different field (e.g., status)
Diagnosis steps:
Open the browser developer console (F12)
Attempt the save operation
Look for error messages indicating which fields triggered the permission check failure
Compare the formula output with the stored value in Polarion’s work item editor
If the values differ, the formula is regenerating a value that does not match what is stored
Workarounds:
Correct the stored values: Update the stored values in Polarion to match the formula output (e.g., fix truncated titles by editing them in Polarion’s native editor while the item is in a draft status)
Temporarily change status: Move the work item to a status that allows editing, save the formula-recalculated values, then move back to the restricted status
Use Check Stored Formulas: Navigate to Menu > Rows > Check stored formulas to identify all formula values that differ from stored values
If Polarion titles were truncated to 80 characters during a migration, formula-generated titles will differ from stored values. Risksheet tries to save the recalculated title, which is then blocked by permissions on non-draft statuses. Fix the stored data before enabling strict permission enforcement.
Formulas only execute when their column is visible in the current sheet view. If you use saved views for export-specific layouts, formulas in hidden columns will not recalculate. Never set an export view as the default view, since formulas run on sheet load. See Formula Functions for details.
To prevent editing of downstream linked items (tasks from other documents or projects), use the downstreamReadonly configuration setting:
{ "downstreamReadonly": true}
When downstreamReadonly is set to true:
Task cells linked from other documents appear as read-only
Task creation is blocked for read-only items (the canExecute check prevents it)
The context menu hides “Add Task” options for read-only downstream items
The downstreamReadonly property defaults to false.Additionally, task-level read-only state is tracked separately from master item state. The system uses systemTaskReadOnly and systemTaskReadOnlyFields to control which specific task fields are editable, independent of the parent risk item’s permissions.
There is a known issue where items from child documents may appear editable in the grid, but the save operation fails with a permission error. This happens because Risksheet cannot always detect the correct permission state for items inherited from child documents.Symptoms:
Cells for child document items show as editable (clicking activates the editor)
Typing a new value works, but clicking Save produces an error
The error indicates a permission denial for the specific field
The child document editing bug fix status should be verified against the current Risksheet release notes. If you encounter cells that allow editing but block saves for items originating from child documents, this is the known issue. Future versions address the permission detection for child document items.
