> ## 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. # Configure Permissions > Control who can view, edit, and administer Nextedy RISKSHEET documents by configuring project roles, field-level permissions, topic visibility, and template project access. 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

Last reviewed on {formatted}

; }; ## Permission Architecture Overview Risksheet enforces permissions at multiple layers. Understanding how these layers interact prevents common issues where users see broken layouts, cannot save edits, or are redirected away from the Risksheet view entirely. diagram | Permission Level | What It Controls | Where Configured | | --------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------- | | **Project Admin role** | Configuration editing, template management, `canAdmin` flag | Polarion project roles | | **Sheet-level `readonly`** | Entire Risksheet read-only for all users | `readonly` property in sheet configuration | | **Downstream `readonly`** | Prevents edits to linked items from other documents | `downstreamReadonly` property in sheet configuration | | **Field-level permissions** | Per-field read-only based on workflow state | Polarion Permissions Management + `checkInstanceFieldPermissions` | | **Reviewer mode** | Restricts to review-specific UI controls | `reviewer` property in sheet configuration | | **Topic visibility** | Whether Risksheet appears in project navigation | Polarion Administration > Topics | | **Template project access** | Whether the sheet loads the correct configuration | Polarion project read permissions | Risksheet automatically determines admin status from the user's Polarion project role. The `canAdmin` property is set at runtime based on the current user's permissions --- you do not set it manually in sheet configuration. When `canAdmin` is `true`, the user can: * Open the Risksheet configuration editor (accessible via **Menu > Configuration > Edit Risksheet Configuration**) * Edit sheet configuration directly or through the configuration editor UI * Manage global templates and template paths * Access the configuration editor at the URL: `/risksheet/configuration/?project=&document=` When `canAdmin` is `false`, the **Edit Risksheet Configuration** entry under **Menu > Configuration** is hidden and the user cannot modify the sheet structure. To grant admin access to a user: 1. Navigate to **Administration** > **Users & Roles** in your Polarion project. 2. Assign the user the **Admin** role for the project. 3. The user will see `canAdmin = true` on their next Risksheet load. Risksheet can modify Polarion fields that are marked read-only when the user has administrator permissions. This happens because Polarion's read-only field APIs are not available to third-party applications. Admin users should exercise caution when editing approved or verified risk items. To make the entire Risksheet read-only for all users (regardless of their project role), set the `readonly` property in sheet configuration: ```yaml theme={null} readonly: true ``` | Property | Type | Default | Description | | -------------------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------- | | `readonly` | boolean | `false` | Makes the entire Risksheet read-only, preventing any user edits to grid cells or structure | | `downstreamReadonly` | boolean | `false` | Makes downstream linked items (tasks, mitigations) read-only to prevent edits to items from other documents | | `reviewer` | boolean | `false` | Enables reviewer mode which restricts editing and shows review-specific UI controls | When viewing a historical revision of a document (via the `revision` URL parameter), Risksheet automatically forces `readonly` to `true`, regardless of the configuration setting. This prevents accidental edits to historical snapshots. Polarion's built-in "Read-only Fields" UI property has no API, so Risksheet cannot enforce it directly. Instead, use Polarion Permissions Management with the `checkInstanceFieldPermissions` configuration property to control which fields are editable based on the work item's current workflow state. ### Enable the Property 1. Navigate to **Administration** > **Configuration Properties** in Polarion. 2. Add the following property: ``` nextedy.risksheet.checkInstanceFieldPermissions=true ``` 3. Save the configuration. ### Configure Field Permissions in Polarion 1. Navigate to **Administration** > **Permissions** in your Polarion project. 2. Define which fields can be edited in each workflow state. For example: * **Draft** state: all fields editable * **In Review** state: only review-related fields editable, risk parameters locked * **Approved** state: all fields read-only 3. Risksheet reads these permission rules at runtime and marks individual cells as read-only based on each work item's current status. Polarion's "Read-only Fields" property (configured in the work item type's workflow settings) has no API accessible to third-party apps. Risksheet cannot read or enforce this property. You **must** use Permissions Management with `checkInstanceFieldPermissions=true` to achieve field-level read-only behavior. Without this property enabled, Risksheet cannot determine which fields should be locked. There is a known issue where items from child documents may display fields as editable in the grid but block the save operation when field permissions deny modification. This can cause confusing "save failed" errors. A fix is planned for a future Risksheet version. In the meantime, ensure child document items have consistent permission configurations. ### How Field Permissions Appear in the Grid When `checkInstanceFieldPermissions` is enabled: * Read-only cells receive a `readonly` CSS class, which provides a visual indicator (typically a subtle background change) * Attempting to edit a read-only cell has no effect --- the cell editor does not activate * The `readOnly` column property is automatically set to `true` for restricted fields, overriding the column-level configuration * System fields (`author`, `resolution`, `created`, `updated`, `type`) are always read-only regardless of permission settings When your Risksheet uses a configuration template from a different Polarion project (via `source` or `templateName` in sheet configuration), all users who open the Risksheet must have **read access** to the template project. Without this access, Risksheet fails to load the template configuration and falls back to a default or broken structure. ### Symptoms of Missing Template Access * Users see a completely different Risksheet structure than other users in the same project * The column layout does not match the expected FMEA/HARA configuration * No explicit error message is displayed --- the sheet simply loads with wrong columns ### Resolution 1. Identify the template project by checking the `source` or `templateName` property in sheet configuration: ```yaml theme={null} source: /ProjectTemplates/FMEA-Template/risksheet.json templateName: FMEA Standard Template ``` 2. Navigate to the template project's **Administration** > **Users & Roles**. 3. Grant **read access** to all users and groups that need to use the Risksheet in the consuming project. When a user lacks read access to the template project, Risksheet does **not** display an error message. Instead, it silently loads a different (likely broken) configuration. If a user reports seeing a different sheet structure than their colleagues, check their access to the template project first. Risksheet must be registered as a topic in your Polarion project's navigation for users to access it from the sidebar menu. If the topic is not configured for a user's role or view, they are redirected to the space home page instead of the Risksheet view. ### Add Risksheet to Navigation 1. Navigate to **Administration** > **Topics** in your Polarion project. 2. Ensure the Risksheet topic is listed and enabled. 3. Verify that the topic is assigned to all relevant **views** and **roles**. Each view/role combination must include the Risksheet topic. If specific users are redirected to the space home page when navigating to Risksheet while other users can access it normally, the issue is almost certainly a missing topic assignment. Check **Administration** > **Topics** and verify the Risksheet topic is configured for that user's view/role combination. Formula-generated fields can conflict with field-level permissions in ways that cause unexpected save failures. Understanding this interaction prevents frustrating errors for end users. ### The Problem 1. A formula column computes a value (e.g., a title or RPN) and stores it in the work item. 2. The work item's status changes to one where the field is read-only (e.g., "Approved"). 3. On the next Risksheet load, the formula recalculates the value. 4. If the stored value differs from the formula output (due to data migration, truncation, or external edits), Risksheet marks the item as "edited." 5. When the user saves, Polarion rejects the write because the field is read-only in the current workflow state. ### Prevention Strategies * **Run Check stored formulas before status transitions**: Before moving risk items from Draft to Review or Approved, ensure all formula values are synchronized. Navigate to **Menu** > **Rows** > **Check stored formulas** (requires v24.5.1+). * **Keep formula columns visible during status changes**: Formula columns must be visible for reconciliation to work. * **Avoid title truncation drift**: After Polarion migrations, check that stored title lengths match formula output lengths. Formula-generated fields may trigger save failures when permissions restrict editing. If stored values differ from formula output (for example, after title truncation during a Polarion migration), Risksheet tries to save the recalculated values, which are then blocked by field permissions. Use Check stored formulas in an editable workflow state to resolve the discrepancy before transitioning to a restricted state. ## Verification After configuring permissions, you should now see: 1. ✅ Admin users can open the configuration editor via **Menu > Configuration > Edit Risksheet Configuration** and can modify sheet configuration 2. ✅ Non-admin users cannot access the configuration editor 3. ✅ When `checkInstanceFieldPermissions=true` is set, cells in approved work items display as read-only with visual indication 4. ✅ All users see the same Risksheet structure (confirming template project access is correct) 5. ✅ Risksheet appears in the project navigation sidebar for all intended roles 6. ✅ Connect/viewer users see the sheet in read-only mode without editing capability ## See Also * [Assign Active Users](/risksheet/guides/licensing/assigning-active-users) --- control who gets named edit access versus viewer access * [Understand License Types](/risksheet/guides/licensing/understanding-licenses) --- how licensing tiers affect edit permissions * [Manage User Groups](/risksheet/guides/licensing/user-groups) --- organize users into permission groups * [Work with Formulas and Hidden Columns](/risksheet/guides/advanced/formulas-hidden-columns) --- formula behavior and reconciliation * [Set Up Global Templates](/risksheet/guides/configuration/global-templates) --- configure template inheritance across projects * [Troubleshoot Administration Issues](/risksheet/guides/administration/troubleshooting) --- resolve common permission-related errors