Skip to main content

​
Common Editing Problems at a Glance

SymptomLikely CauseResolution
Cell is not editable (no editor opens)System field, readOnly column, formula column, or permissionsCheck column config, system fields list, and user permissions
Previous item’s value auto-populates new itemsDuplicate controlColumn in levels configurationFix levels so each level uses a unique controlColumn
Formula column shows wrong or stale valueColumn is hidden; formula not executingKeep formula columns visible or use Check stored formulas
Workflow status cannot be changedUnsaved changes in the gridSave all changes, then retry the status transition
resolution field is not editableSystem field restriction (no API for edit)Use rejectedAction / rejectedStatus / rejectedResolution in dataTypes instead
Rich text formatting lost on editRich text editing limitationSwitch column to type: "text" for multi-line plain text
Save works for some rows but fails for othersCustom Polarion script conflictCheck server logs for workflow script errors
Fields editable when they should be lockedPolarion Read-only Fields property not enforcedEnable checkInstanceFieldPermissions via Permissions Management

​
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)
  • author (item creator)
  • resolution (workflow resolution)
  • created (creation timestamp)
  • updated (last modification timestamp)
  • type (work item type)
The 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 risksheet.json instead.

​
Column-Level Read-Only

A column becomes read-only automatically when any of these conditions are true:
ConditionPropertyNotes
Formula columnformula is setCannot override; always read-only
Server-rendered columnserverRender is setBecomes type: "text" and read-only automatically
Explicit settingreadOnly: trueCan be changed in configuration
Reference columnColumn references another itemAuto-detected
Permission deniedPermissions Management blocks modificationServer-side enforcement

​
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 — An array of specific field names 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’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 risksheet.json and verify that each entry in the levels array has a distinct controlColumn value: 
{
  "levels": [
    {
      "controlColumn": "systemItemId",
      "showInMenu": true
    },
    {
      "controlColumn": "failureMode",
      "showInMenu": true
    }
  ]
}
If 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.

​
Hidden Formula Columns Do Not Execute

Symptom: A formula column shows incorrect, stale, or missing values. Newly created work items have incorrect titles (just numbers instead of computed names). Cause: Formula columns do not execute when they are hidden from the Risksheet view via column visibility settings or saved views. If a title column uses a formula and is hidden during item creation, the Polarion work item stores whatever raw value exists (often just a numeric ID). Fix:
  1. Keep formula columns visible in all views where items are created or edited
  2. Use the Check stored formulas feature (available since v24.5.1) to reconcile stored values with current formula results after changes
  3. If the title column must use a formula, ensure it is visible during item creation workflows
{
  "columns": [
    {
      "id": "title",
      "header": "Title",
      "formula": "computeTitle",
      "visible": true
    }
  ]
}
After discovering that formula columns were hidden during data entry, use Check stored formulas to scan all rows. The feature detects differences between formula results and stored values, and marks affected items for update. This is especially important for the title field, which affects how items appear throughout Polarion.

​
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: 
{
  "columns": [
    {
      "id": "description",
      "header": "Description",
      "type": "text",
      "multiLine": true,
      "wordWrap": true,
      "width": 300
    }
  ]
}
The multiLine: true property (default for text columns) enables multi-line editing, and wordWrap: true ensures text wraps within cells. This preserves line breaks without the complications of HTML formatting.

​
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
After 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:
Expected EditorRequired type ValueCommon Misconfiguration
Enum dropdownenum:<enumId>Missing :enumId suffix
Multi-select chipsmultiEnum:<enumId>Using enum instead of multiEnum
Workflow status dropdownworkflowSet as enum instead of workflow
Item link autocompleteitemLinkSet as text
Date pickerdate or datetimeMissing type; falls back to text
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 when visible 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

Support TicketsSource Code
  • CellEditorFormatter.ts
  • AppConfigHelper.ts
  • AddTaskCommand.ts
  • SheetConstants.ts
  • StatusChangeCommand.ts