How Data Flows Between Grid and Server
The grid communicates with Polarion through an OData service layer that translates grid operations into work item CRUD (Create, Read, Update, Delete) operations. Every interaction — adding a risk item, editing a severity rating, linking a mitigation task — passes through this layer.
Transaction Management
All data operations are wrapped in transactions with begin, commit, and rollback support. This ensures data consistency — if any part of a save operation fails, the entire batch is rolled back to prevent partial updates from corrupting your risk data. This transactional approach is particularly important when creating multiple linked items in a single save. For example, when you add a new risk item and simultaneously create a mitigation task linked to it, both operations must succeed or neither is committed.Temporary ID Mapping
When you create a new work item in the grid, Risksheet assigns it a temporary client-side ID (prefixed with*). This temporary ID is visible in the grid until the item is saved. Upon saving, the server generates a permanent Polarion work item ID and the system maps the temporary ID to the permanent one.
This mapping is critical for bulk operations where items reference each other. The system tracks three types of mappings:
| Mapping Type | Purpose |
|---|---|
| Task ID map | Maps temporary task link IDs to permanent Polarion IDs |
| Item ID map | Maps temporary single item link IDs to permanent IDs |
| Item link ID map | Maps temporary multi-item link IDs by column |
Items with IDs starting with
* are unsaved. Workflow status transitions and certain operations are unavailable until the item is saved and receives a permanent Polarion ID.Formula Synchronization
Calculated columns use client-side JavaScript formulas to derive values from other cells. These formula results exist in the browser and are saved back to Polarion for persistence. However, if work item fields are modified outside Risksheet (for example, through Polarion’s standard work item editor), the stored formula values may become stale. The Check stored formulas feature (accessible via Menu > Rows) reconciles formula values between Polarion and Risksheet. When formula columns are marked withreadOnly:false, this feature recalculates all formulas based on current field values and updates any that have drifted out of sync.
Save Operations
Risksheet supports two types of update operations:- PATCH (partial update) — Sends only the changed fields for an existing work item. This is the default for cell edits.
- PUT (full update) — Sends all field values for an item. Used in specific scenarios where the complete item state needs to be persisted.
Cross-Project Data Operations
When working with items from different Polarion projects, the system uses anIdProject format (project/itemId) to qualify work item IDs. This ensures that operations target the correct project context, even when the grid displays items from multiple sources.
Cross-project operations support:
- Creating and linking items in other projects
- Deleting or unlinking cross-project items
- Task unlinking using composite IDs in the format
project;riskItemId;taskItemId;*
Revision Comparison
Risksheet supports comparing the current document state against a historical revision. The comparison command ensures data is fully loaded before initiating the comparison, preventing incomplete or incorrect results. During comparison, the grid displays changes between versions with visual indicators for modified, added, and removed items.The exact visual indicators and comparison behavior may vary depending on your Risksheet version and configuration.