Powersheet Architecture

This page explains the architectural layers, how data flows between them, and how security is enforced — giving you the mental model needed to reason about configuration changes, troubleshoot loading behavior, and plan domain model design.

​

High-Level Architecture

The diagram above captures the key insight: there is no external database, no middleware cache, no separate service to operate. Powersheet is an in-process Polarion extension. YAML configuration and work item data both reside in the same Polarion SVN repository. When you edit a cell in the sheet, the write goes directly to Polarion’s work item API — not to an intermediary.

​

No Separate Data Store

This is the single most important architectural concept to internalize. Unlike tools that synchronize data to an external database, Powersheet works entirely within Polarion:

• Work items are the rows in the sheet. They are standard Polarion work items, queryable and editable through any Polarion interface.
• Link roles connect work items across entity types. Powersheet reads and writes these native Polarion links — it does not maintain its own relationship tables.
• Custom fields on work items store property values. Powersheet columns bind to these fields through the domain model.
• YAML files stored in the project SVN repository define what data to show and how to present it. They are version-controlled alongside the rest of the project.

This design means that anything you do in a Powersheet is immediately visible in Polarion’s native views and vice versa. There is no synchronization lag, no import/export step, and no risk of data divergence between the sheet and the underlying platform.

​

Three-Tier Architecture

​

Server Extension

The server extension runs as a Java plugin inside the Polarion application server process. It handles four responsibilities: The server extension registers four administration pages within Polarion at Administration > Nextedy POWERSHEET:

• Domain Models — file manager for domain model YAML files
• Sheet Configurations — file manager for sheet configuration YAML files
• Setup — initial setup and configuration
• License — license status and management

These pages are available at project, project group, and repository (global) scope, following Polarion’s standard administration hierarchy.

​

Client Application

The client application runs in the user’s browser and renders the interactive sheet. It receives the parsed configuration and typed metadata from the server, then builds the sheet UI with:

• Hierarchical row expansion based on the domain model’s expansion paths
• Inline cell editing with type-aware editors (text, dropdowns, reference pickers)
• Column filtering and sorting including multi-column sort
• Row grouping by column values with collapsible headers
• Copy and paste with level-aware restrictions that prevent cross-hierarchy paste errors
• Keyboard shortcuts for common operations (add row, export, freeze columns, grouping)

The client uses a data guard mechanism that blocks rendering until the metadata system has fully initialized. This prevents displaying an empty sheet while data is still loading — a common source of confusion when network latency is high.

​

Configuration Layer

All behavior in Powersheet is driven by two types of YAML files: The domain model acts as a semantic abstraction layer over Polarion’s native work item types and link roles. You can reuse the same sheet configuration across projects that have different Polarion type setups — only the domain model mapping needs to change. The sheet configuration is assigned to a document through a custom field on the Polarion LiveDoc. When a user opens that document, Powersheet reads the assigned configuration and renders the sheet accordingly. For a deeper comparison, see Data Model vs Sheet Configuration.

​

Data Flow: Loading a Sheet

The following diagram traces the sequence from the moment a user opens a Powersheet document to the fully rendered sheet. The load sequence in detail:

1. Document opens — The document’s custom field identifies which sheet configuration to use
2. Server loads YAML — The server reads the sheet configuration and the referenced domain model from the SVN repository
3. Metadata generation — The server generates a typed metadata schema from the domain model and sends it along with the configuration to the client
4. Client initializes — The client builds columns from the configuration, sets up type-aware editors, and prepares the sheet structure
5. Data query execution — The client issues queries that the server translates to Polarion Lucene queries, expanding along configured expansion paths to load related entities at each level
6. Sheet renders — All rows, columns, formatting, and grouping are applied

After initial load, the configuration and metadata remain cached in the client. Subsequent user actions (editing cells, adding rows, creating links) interact directly with the server API, which writes through to the Polarion data layer. No YAML reload occurs during normal editing — you only need to refresh the page when you change the configuration itself.

​

Security Architecture

Powersheet inherits and enforces Polarion’s security model at every layer. It does not implement its own authentication or maintain separate access control lists. Authentication — Powersheet requires an active Polarion session. It does not have its own login screen. Users authenticate through Polarion’s standard mechanisms (SSO, LDAP, or local accounts) before the Powersheet widget loads. Server-side enforcement — Every data operation goes through the Polarion API, which applies the user’s project permissions, work item permissions, and field-level security. If a user lacks write permission on a work item, the server rejects the save operation regardless of what the client allows. Client-side controls — The sheet configuration can mark columns as read-only (isReadOnly: true) or apply formatters that prevent editing. Workflow-protected fields and calculated properties are automatically non-editable. These client-side controls provide immediate UI feedback but are not the sole enforcement mechanism — the server independently validates every write. Configuration access — YAML configuration files are stored in the SVN repository and follow Polarion’s repository permission model. The administration pages at Administration > Nextedy POWERSHEET are restricted to users with project administrator roles.

​

Configuration Scoping

Powersheet configuration operates at three levels, following Polarion’s standard administration hierarchy: Project-level configurations supplement global ones. A project can reference a global domain model while defining its own sheet configurations, or vice versa. This enables organizations to maintain a standard entity model centrally while allowing individual projects to customize their column layouts. For details on how global and project-level configurations interact, see Global vs Project-Specific Configuration.

​

Where Each Component Lives

Understanding the physical location of each component clarifies what is deployed, what is configured, and what is stored:

​

Related Pages

• Core Components — Detailed look at each building block
• Data Model vs Sheet Configuration — Why two YAML files exist and how they divide responsibilities
• Model-Driven Design — How the domain model shapes the entire sheet experience
• Polarion Integration — How Powersheet extends the Polarion platform
• Global vs Project-Specific Configuration — Configuration inheritance and scoping
• YAML Configuration System — How configuration files are discovered and loaded

Sources

Support Tickets

• #6844
• #6821
• #6792

Source Code

• Powersheet.tsx
• PowersheetDocumentConfigurationService.java
• PowersheetService.java
• hivemodule.xml
• powersheet.yaml