Skip to main content

​
All or Nothing

Powersheet applies the whole where clause together with the entity type, the project and the data model constraints. It never skips part of a filter: if a predicate cannot be applied, the query stops with an error that names the reason, so the sheet never shows rows the query meant to exclude.
diagram

​
Supported Predicates

​
What Stops a Query

A query stops with an error when it uses:
  • startsWith, endsWith or contains on a field that is not a string, including enum fields
  • any predicate on a built-in date and time field; these fields can only be sorted. Custom date fields can be compared
  • any predicate on a multi-valued built-in work item field
  • a custom field of rich text, currency or duration type
  • eq, ne or a null check on the rich-text description; it takes contains, startsWith and endsWith
  • null with lt, le, gt, ge or in, or in with an empty list
  • a calculated or server-rendered custom field
  • a dotted path through a to-many relationship, or to anything other than the document or project
  • an orderBy on a field that cannot be sorted, such as a multi-valued field
These are the common cases. The error names the reason for any other. Rewrite the predicate so it fits the field — for example eq or in on an enum instead of contains.

​
Query Execution Pipeline

The query processor follows this execution order:
  1. Security enforcement — Verify read permission for the queried entity type
  2. Scoping — Combine the where predicates with the entity’s polarionType, the current project and the data model constraints
  3. Execution — Run the combined query, sorted by orderBy, together with the related entities of its expansion paths, which stay within the same project and follow their own constraints
  4. Row permissions — Drop work items the current user cannot read
  5. Paging — Apply take and skip to the readable rows

​
Document Predicates

Predicates on document properties — a dotted path such as document.moduleName — are applied in the same query as the rest of the where clause, restricting the work items to those in matching documents.

​
Query Parameters

The query processor extracts parameters that control query behavior. See Query Context and Baseline and Revision Queries for parameter details.

​
Security Enforcement

Before any query executes, the processor verifies that the current user has read permission for the queried entity type. A query against an entity type the user cannot read returns no rows, without running.
Permission CheckEntity-level security is checked before any query execution. If the current user does not have READABLE permission for the entity type, the query returns no rows. Individual work items the user cannot read are left out of the result.

​
Constraint Annotations

The query processor applies constraint annotations from the data model to queries:
  • Project constraints from entity type annotations are added to the query
  • Document constraints from entity type and expansion path annotations are merged into document filters
  • Navigation property constraints combine both the expansion path and target entity type constraints
See Constraints for data model constraint configuration.

​
Complete YAML Example

In this configuration:
  • The where clause is a supported equality predicate
  • The applyCurrentDocumentTo constraint restricts results to the current document context
  • Expansion paths load related entities after the primary query executes