Configuration Hierarchy

​

Why Inheritance Matters

Consider an organization with 50 FMEA documents across multiple projects. Without configuration inheritance, each document would need its own copy of risksheet.json — and every change to column layout, formula definitions, or rating scales would require updating all 50 files individually. The configuration hierarchy solves this by allowing a single template to define shared settings that all documents inherit automatically. Think of it like CSS in web design: a global stylesheet sets defaults, while individual pages can override specific rules. Risksheet applies the same principle to risk analysis configuration.

​

The Inheritance Chain

Configuration resolution follows a top-down chain with three distinct levels: At each level, the configuration file is a risksheet.json attachment. When a document opens, Risksheet resolves the effective configuration by reading the chain and merging settings from the most general to the most specific level.

​

Template Path Configuration

Administrators configure one or more template paths through the project-level settings. These paths define where Risksheet looks for template documents when creating new risk documents or resolving inherited configuration. The default template path is Risks/Risk Specification. Multiple paths can be specified using comma separation, enabling organizations to maintain different templates for different risk analysis types — for example, one for FMEA and another for HARA.

​

Configuration Properties at Each Level

​

Project-Level Settings

Project-level settings are managed through the Polarion administration interface and control behaviors that apply across all Risksheet documents in a project:

​

Document-Level Configuration

The risksheet.json file attached to a specific document can override any property from the template. The system tracks the configuration source through two properties:

• source — The path to the configuration file that was used to load this document’s settings (a document or template path).
• templateName — The name of the template when configuration is loaded from a global template rather than a document-specific file.

These properties create a traceable link back to the configuration origin, which is valuable for auditing and troubleshooting.

​

How Overrides Work

When a document defines its own risksheet.json, the configuration manager merges it with the inherited template configuration. The merge follows these principles:

1. Section-level replacement — Top-level sections like columns, formulas, or styles replace the template’s corresponding section entirely when defined in the document configuration.
2. Automatic enrichment — After merging, the configuration manager applies defaults and type inference. Column types are auto-detected from Polarion field bindings if not specified (columns[].type). Column IDs are auto-generated from headers or bindings if omitted (columns[].id).
3. Read-only enforcement — Regardless of what the configuration specifies, certain columns are forced read-only: formula columns, server-rendered columns, reference columns, and system fields (author, resolution, created, updated, type).

​

Configuration Update Flow

Configuration changes can be applied through the configuration editor, which supports a scope parameter indicating whether the update copies from a template or modifies the document directly. The update executes within a write transaction to prevent partial changes from corrupting the configuration.

​

Common Misconceptions

One frequent source of confusion is the relationship between project-level settings and document-level risksheet.json. Project-level settings (tool name, suggester behavior, template paths) are independent of the JSON configuration file — they apply globally and cannot be overridden per document. The risksheet.json hierarchy only governs grid-level settings: columns, formulas, styles, data types, and views. Another misconception is that editing a template automatically updates all documents that inherit from it. In practice, documents that have already loaded their configuration retain it until the next reload. Documents with their own risksheet.json override the template regardless of template changes.

​

Related Topics

For details on all configuration sections and their properties, see Configuration System. To understand how configuration controls which work items appear in the grid, see Work Item Visibility and Levels. For practical guidance on setting up templates, visit the How-To Guides.

---

Sources

KB Articles

• Adjusting Risksheet configuration
• Risksheet Configuration Properties
• Setup risk review process
• Configure Multiple Risk Item types

Source Code

• RisksheetViewServlet.java
• RisksheetProjectProperties.java
• AppConfigParser.ts
• AppConfig.ts
• PolarionAppConfigManager.java