> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cell Editing Issues

> Diagnose and resolve problems with cell editing in the Nextedy RISKSHEET grid, including read-only cells, incorrect data population, formula column behavior, field-level restrictions, and editor type mismatches.

export const LastReviewed = ({date}) => {
  if (!date) return null;
  const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", {
    year: "numeric",
    month: "long",
    day: "numeric",
    timeZone: "UTC"
  });
  return <p className="mt-10 text-sm text-gray-400 dark:text-zinc-500 not-prose">
      Last reviewed on {formatted}
    </p>;
};

## Common Editing Problems at a Glance

| Symptom                                        | Likely Cause                                                    | Resolution                                                                            |
| ---------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Cell is not editable (no editor opens)         | System field, `readOnly` column, formula column, or permissions | Check column config, system fields list, and user permissions                         |
| Previous item's value auto-populates new items | Duplicate `controlColumn` in `levels` configuration             | Fix levels so each level uses a unique `controlColumn`                                |
| Formula column shows wrong or stale value      | Column is hidden; formula not executing                         | Keep formula columns visible or use Check stored formulas                             |
| Workflow status cannot be changed              | Unsaved changes in the grid                                     | Save all changes, then retry the status transition                                    |
| `resolution` field is not editable             | System field restriction (no API for edit)                      | Use `rejectedAction` / `rejectedStatus` / `rejectedResolution` in `dataTypes` instead |
| Rich text formatting lost on edit              | Rich text editing limitation                                    | Switch column to `type: "text"` for multi-line plain text                             |
| Save works for some rows but fails for others  | Custom Polarion script conflict                                 | Check server logs for workflow script errors                                          |
| Fields editable when they should be locked     | Polarion Read-only Fields property not enforced                 | Enable `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)
* `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)

<Warning title="The resolution field cannot be edited from Risksheet">
  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 sheet configuration instead.
</Warning>

### Column-Level Read-Only

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

| Condition              | Property                                   | Notes                                              |
| ---------------------- | ------------------------------------------ | -------------------------------------------------- |
| Formula column         | `formula` is set                           | Cannot override; always read-only                  |
| Server-rendered column | `serverRender` is set                      | Becomes `type: "text"` and read-only automatically |
| Explicit setting       | `readOnly: true`                           | Can be changed in configuration                    |
| Reference column       | Column references another item             | Auto-detected                                      |
| Permission denied      | Permissions Management blocks modification | Server-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`** -- 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`.

<Warning title="Polarion Read-only Fields property is not supported">
  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.
</Warning>

## 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:

```yaml theme={null}
levels:
  - controlColumn: systemItemId
    showInMenu: true
  - controlColumn: failureMode
    showInMenu: true
```

This snippet is abbreviated to highlight the unique-`controlColumn` requirement. A complete level entry also needs `name` and `zoomColumn` — see [Levels Configuration](/risksheet/reference/levels-configuration) for the full structure.

<Warning title="Each level must have a unique controlColumn">
  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.
</Warning>

## 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

```yaml theme={null}
columns:
  - id: title
    header: Title
    formula: computeTitle
    visible: true
```

<Tip title="Check stored formulas for bulk reconciliation">
  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.
</Tip>

## 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:

```yaml theme={null}
columns:
  - id: description
    header: Description
    type: text
    width: 300
```

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

<Note title="Status changes reload the page">
  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.
</Note>

## 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 Editor        | Required `type` Value | Common Misconfiguration             |
| ---------------------- | --------------------- | ----------------------------------- |
| Enum dropdown          | `enum:<enumId>`       | Missing `:enumId` suffix            |
| Multi-select chips     | `multiEnum:<enumId>`  | Using `enum` instead of `multiEnum` |
| Item link autocomplete | `itemLink`            | Set as `text`                       |
| Date picker            | `date` or `datetime`  | Missing 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

* [Permission-Based Field Restrictions](/risksheet/troubleshooting/permission-errors) -- configure field-level permissions
* [Rich Text Formatting Loss](/risksheet/troubleshooting/rich-text-formatting-loss) -- detailed rich text troubleshooting
* [Save Operation Failures](/risksheet/troubleshooting/save-failures) -- diagnose save-related errors
* [Date Column Save Errors](/risksheet/troubleshooting/date-column-save-errors) -- date field formatting issues
* [Rendering and Display Errors](/risksheet/troubleshooting/rendering-errors) -- visual rendering problems
* [Error Messages Reference](/risksheet/troubleshooting/error-messages) -- complete list of Risksheet error messages

<LastReviewed date="2026-06-24" />