Work Item Visibility and Levels

​

Two Configuration Systems

Work item visibility and organization are controlled by two separate but interconnected configuration sections:

​

Data Types: What Work Items Are Shown

The dataTypes section defines:

• Risk items: The primary work item type(s) displayed in the grid (typically “risk” or “requirement”)
• Task items: The downstream/mitigation work item type(s) linked to risks (typically “task” or “issue”)
• Link roles: How tasks connect to risks (e.g., “mitigates” role)

For example, configuring dataTypes.risk.type as "risk" and dataTypes.task.type as "task,issue" with role set to "mitigates" means:

• Only work items of type “risk” will appear as risk rows
• Work items of type “task” or “issue” linked via the “mitigates” role will appear as downstream items
• Any other work item types in the document are invisible to RISKSHEET

​

Levels: How Risk Items Are Grouped

The levels configuration controls visual organization through merging behavior, not parent-child relationships. This is the most misunderstood aspect of RISKSHEET. For example, a two-level configuration with Level 1 using controlColumn: "failureMode" and Level 2 using controlColumn: "systemItemId" works as follows:

• Level 1 columns (associated with “Failure Mode”) merge rows where the failureMode column has the same value
• Level 2 columns (associated with “Cause”) merge rows based on systemItemId (the work item ID), which effectively means no merging since every work item has a unique ID
• All risk items are stored as the same Polarion work item type—levels don’t create separate types

Visually: All three rows represent separate risk work items with different Cause values but the same Failure Mode. The “Brake failure” cell appears merged because Level 1’s controlColumn groups rows by the failureMode field.

​

Common Misconceptions

​

Misconception 1: Levels Create Parent-Child Relationships

Reality: Levels control visual merging only. All risk items at all levels are peers in Polarion’s data model—they’re the same work item type with different field values. In the example above:

• “Brake failure” is not a parent work item containing “Worn pads”, “Low fluid”, and “Air in line” as children
• Instead, three separate risk items happen to share the same “Brake failure” value in their failureMode field
• The merged cell is a UI convenience that reduces visual redundancy

​

Misconception 2: Last Level +1 Represents Child Items

Partially correct: The “Last Level +1” columns (typically Level 3) do represent actual child work items—but they’re linked via Polarion link roles (e.g., “mitigates”), not through hierarchical containment. Structure:

• Levels 1 through N: Different visual groupings of the same risk work items
• Level N+1: Linked task/mitigation work items (different work item type, actual parent-child links)

​

Misconception 3: Changing Level Configurations Changes Work Item Types

Reality: Changing controlColumn or adding/removing levels only affects how existing work items are displayed. It does not:

• Create new work item types in Polarion
• Move work items between types
• Alter link relationships
• Change stored data

Levels are purely presentational.

​

Level Configuration Properties

​

controlColumn

Defines which column’s value determines merging behavior:

• Field-based merging (e.g., "controlColumn": "failureMode"): Rows with identical values in this column are visually grouped, and Level 1 cells merge
• ID-based merging (e.g., "controlColumn": "systemItemId"): Since every work item has a unique ID, this effectively disables merging for that level

​

zoomColumn

Specifies which column receives focus when a new item is created at this level:

• When a user clicks ”+ Failure Mode” in the toolbar, the new row is created with the cursor in the failureMode column (if zoomColumn is set to "failureMode")
• This guides users to immediately fill in the defining characteristic of that level

​

name

Controls the label shown in the toolbar for creating new items at this level. Setting name to "Failure Mode" produces a toolbar button labeled ”+ Failure Mode”.

​

showInMenu

Controls visibility of the creation button. Setting showInMenu to false hides the ”+ [name]” button for this level. Useful when you want visual grouping but don’t want users creating items at that abstraction level.

​

Filtering and Scope

By default, RISKSHEET shows all work items in the associated Polarion document that match the configured types. You can further restrict visibility using:

​

Document Scoping

The document property on dataTypes.risk filters work items to specific LiveDoc folder paths. For example, setting document to "Risks/Safety" limits the view to risk items located under that folder. This is useful for:

• Multi-document FMEA setups where different RISKSHEETs cover different subsystems
• Reuse templates that need to scope work items to specific document hierarchies
• Projects with shared work item types across multiple domains

​

Rejected Status Filtering

Work items with statuses matching rejectedStatus are automatically hidden. Setting rejectedStatus to "rejected,closed-invalid" on dataTypes.risk implements soft-delete behavior — changing a risk’s status to “rejected” removes it from the RISKSHEET without deleting the underlying Polarion work item.

​

Permission-Based Filtering

RISKSHEET respects Polarion’s security model. Work items the current user lacks read permission for are automatically excluded, ensuring users only see data they’re authorized to view. See User Roles and Permissions for details on permission enforcement.

​

Upstream and Indirect Relationships

RISKSHEET can display work items connected through multi-level relationships using custom data rendering: By default, RISKSHEET shows:

• The risk item (primary row)
• Direct downstream links (tasks linked to the risk)

To show upstream items (requirements linked to the risk) or indirect items (tasks linked to upstream requirements), use:

• Item link columns: Configure columns that traverse link roles upward
• Custom renderers: Write JavaScript to query and display items multiple hops away

See Configure Upstream Traceability Columns and Render Custom Data for implementation examples.

​

Practical Decision Matrix

​

Visual Element Reference

​

Related Concepts

• Data Model and Work Items explains how Polarion work items map to RISKSHEET rows
• Traceability and Linking covers link roles and upstream/downstream relationships
• User Roles and Permissions explains permission-based filtering
• Configuration System describes where levels and dataTypes are configured

For practical implementation, see:

• Display Multi-Level Hierarchies
• Configure Multiple Risk Types
• Configure Downstream Tasks

Sources

KB Articles

• What Work Items are visible on the Risksheet and understanding levels
• Multiple Downstream Work Item Types

Support Tickets

• #6242
• #6686
• #6729

Source Code

• RiskSheetContextMenu.ts
• RisksheetDataStorage.java
• StatusComboBox.ts
• ResultFilter.java
• AppConfig.ts