Skip to main content

​
Common Editing Problems at a Glance

​
Read-Only Cells: Diagnosis Checklist

When a cell appears non-editable, work through this checklist to identify the cause:

​
System Fields (Always Read-Only)

The following Polarion system fields are always read-only in Risksheet. They cannot be edited regardless of column configuration:
  • id (work item ID)
  • status (workflow status)
  • type (work item type)
  • project (project identifier)
  • outlineNumber (document structure position)
  • author (item creator)
  • resolution (workflow resolution)
  • created (creation timestamp)
  • updated (last modification timestamp)
The resolution field cannot be edited from RisksheetThe resolution field is typically a mandatory field during status transitions. Because Risksheet does not support editing mandatory transition fields directly, the resolution field remains read-only. If you need to set resolution values during risk rejection, configure the dataTypes.risk.rejectedAction, dataTypes.risk.rejectedStatus, and dataTypes.risk.rejectedResolution properties in your sheet configuration instead.

​
Column-Level Read-Only

A column becomes read-only automatically when any of these conditions are true:

​
Item-Level and Field-Level Permissions

Risksheet respects two levels of per-item permissions:
  • systemReadOnly — When true, the entire row is non-editable. This is set based on work item state and permissions
  • systemReadOnlyFields — A pipe-delimited string of field names (each wrapped as |fieldId|) that are non-editable for that item. Individual fields can be locked while the rest of the row remains editable
For downstream task items, the equivalent properties are systemTaskReadOnly and systemTaskReadOnlyFields.
Polarion Read-only Fields property is not supportedPolarion’s UI-level “Read-only Fields” property has no API, so Risksheet cannot enforce it. Users may be able to edit fields through Risksheet that appear read-only in the standard Polarion work item view. To enforce field-level edit restrictions based on work item status, use Permissions Management with the nextedy.risksheet.checkInstanceFieldPermissions=true project property. There is a known issue where child document items may show fields as editable in the grid but block the save operation — this will be addressed in a future version.

​
Auto-Population of Previous Item Values

Symptom: When you add a new risk item, the description or other fields are automatically filled with values from the previous item, and items may merge unexpectedly with the cell above. Cause: Two different levels in the levels configuration point to the same controlColumn. Each level must use a unique control column. Fix: Open your sheet configuration and verify that each entry in the levels array has a distinct controlColumn value:
This snippet is abbreviated to highlight the unique-controlColumn requirement. A complete level entry also needs name and zoomColumn — see Levels Configuration for the full structure.
Each level must have a unique controlColumnIf two levels both reference controlColumn: title, newly created items will inherit values from the previous row and trigger incorrect cell merging. This is a common configuration error in multi-level FMEA tables. Always ensure each level points to a different column binding.

​
Formula Value Is Correct in the Sheet but Stale in Polarion

Symptom: A formula column shows the expected value in Risksheet, but the bound Polarion field is empty or holds an older value. Work items may show a numeric identifier instead of a computed title. Cause: One of two things.
  • The column is read-only. A formula column is readOnly: true by default, which calculates and displays the value without storing it. Only a column with readOnly: false writes to its Polarion field.
  • The row was last changed outside Risksheet. Opening a document recalculates and displays current values but deliberately does not rewrite stored data; the stored field is refreshed when the row is next edited, or by Check stored formulas.
Fix:
  1. Set readOnly: false on any formula column whose value has to exist in Polarion, and give it a bindings to the field that holds it. The column does not need to be visible.
  2. Run Menu > Rows > Check stored formulas (available since v24.5.1) to reconcile the whole document in one pass, then save.
On versions earlier than v26.7.1A hidden formula column did not execute at all, so rows created in a view that hid it stored empty or incorrect values. Since v26.7.1 formula columns calculate regardless of visibility. After upgrading, run Check stored formulas once per affected document to correct values stored under the old behavior. See Formulas and Column Visibility.

​
Rich Text Formatting Loss

Symptom: Editing a rich text field in Risksheet removes line breaks, HTML formatting, and causes all text to appear as a single block. Cause: Risksheet does not fully support editing rich text (HTML) fields. When a rich text cell is edited, line breaks and HTML formatting may be stripped from the underlying work item XML. Fix: Switch the column type to "text" (multi-line plain text) instead of using rich text:
The text column type supports multi-line plain text editing, preserving line breaks without the complications of HTML formatting. Text wrapping is controlled through CSS classes defined in the styles section of the sheet configuration — not via column-level properties.

​
Unsaved Changes Block Workflow Transitions

Symptom: Attempting to change the document status produces the error message:
“There are unsaved changes. Please save the document first.”
Cause: The grid has pending unsaved edits. Risksheet requires a clean state (no dirty cells) before document-level workflow actions can proceed, to avoid data loss or inconsistent state. Fix:
  1. Save all pending changes by pressing the Save button or keyboard shortcut
  2. Retry the workflow status transition
  3. The page reloads automatically after a successful status change to reflect the new document state
Status changes reload the pageAfter a successful document status change, the entire browser page reloads automatically. This ensures all UI elements (buttons, permissions, validation rules) reflect the new document status. Any unsaved edits would be lost during this reload, which is why the save-first requirement exists.

​
Custom Polarion Script Conflicts

Symptom: Saving works for some rows but throws warnings or fails for others. The behavior is inconsistent and not explained by column configuration. Cause: Custom Polarion workflow scripts that validate work item fields (such as duplicate title checks, mandatory field enforcement, or status-based validation) can interfere with Risksheet save operations. These scripts execute on the server when Risksheet attempts to save work item changes. Diagnosis:
  1. Open the browser developer tools (F12) and check the Console tab for error messages
  2. Check Polarion server logs for workflow script exceptions
  3. Look for patterns: does the failure correlate with specific work item types, statuses, or field values?
Fix: Work with your Polarion administrator to review custom workflow scripts. Ensure scripts that validate fields during save operations handle the case where changes come from Risksheet (which saves individual field changes, not full work item forms).

​
Cell Editor Type Mismatches

When the wrong editor appears for a cell (for example, a plain text input instead of an enum dropdown), the column type property may be misconfigured or auto-detection failed: For sub-columns of linked items, type auto-detection does not work — you must always specify the type explicitly.

​
Verification

After applying fixes, verify the following:
  1. You should now see editable cells responding to clicks with the appropriate editor (text input, enum dropdown, date picker, or autocomplete)
  2. Formula columns should display calculated values automatically, and show a read-only indicator when clicked
  3. New items should not auto-populate values from previous rows
  4. Workflow status transitions should succeed after saving all pending changes
  5. Rich text fields converted to type: "text" should preserve line breaks during editing

​
See Also