Resolve Lucene query parsing failures that prevent Risksheet from loading work items, cause errors in filter definitions, or block access to LiveDoc documents after Polarion upgrades.
Query parsing errors in Risksheet can originate from two distinct sources: the Risksheet configuration itself, or from Polarion platform features that interact with the same data layer. Before modifying any Risksheet configuration, determine where the error originates by following this diagnostic flow:
After upgrading Polarion to version 2410 or later, you may see Nextedy components (such as data service hooks) in stack traces for errors that originate entirely within Polarion. These hooks act as data service interceptors and appear in the call stack for any data service exception, even when Risksheet is not the cause. Always examine the actual error message and the originating query text, not the stack trace class names, to determine the true source of the problem.
After Polarion version upgrades, query parsing errors are frequently caused by Polarion features (such as Auto Assignment) with invalid inputs, not by Risksheet. Investigate Polarion’s own configuration settings before modifying risksheet.json or Risksheet project properties.
If query parsing errors appeared immediately after a Polarion upgrade, the root cause is most likely a Polarion configuration issue:
Check Auto Assignment rules — Navigate to Administration > Work Items > Auto Assignment in the affected project. Verify that all rules contain valid field references and user assignments. Invalid entries in Auto Assignment are a known source of unparseable query errors after upgrading to Polarion 2310 and 2410.
Review workflow script queries — Open the workflow configuration for each work item type used in Risksheet. Check that any Lucene queries embedded in workflow conditions or scripts use syntax compatible with the new Polarion version.
Verify custom field expressions — If you use custom field default values or expressions that contain Lucene query fragments, confirm they do not contain unescaped special characters.
Check document ID format changes — Polarion upgrades may change how document IDs with the _default/ prefix are handled. Risksheet automatically strips the _default/ prefix from document IDs when constructing queries, but if the upgrade changed the ID format, verify the documents are still accessible.
Polarion Version
Known Query Issue
Risksheet Fix
2310
UnsupportedOperationException for renderingLayouts document field rendering
No functional impact; update Risksheet to 24.7.0+ to suppress the log error
2410
Unparseable query errors from Auto Assignment feature
Fix Auto Assignment configuration in Polarion; not a Risksheet issue
Risksheet uses Lucene queries to load work items based on the dataTypes configuration in risksheet.json. The types property determines which Polarion work item types appear in the grid. Multiple types are combined with OR logic in the generated query.Verify your data type configuration:
Misspelled type name; at least one type is required or the system throws an error
role
Link role for creating relationships
Invalid or nonexistent role ID in Polarion
query
Custom Lucene query fragment appended to auto-generated filters
Malformed Lucene syntax
showInMenu
Whether creation options appear in context menu (default: true)
N/A
The types property must contain at least one valid Polarion work item type ID. An empty or missing types array causes a query construction error that prevents the grid from loading any items.
The query property under dataTypes.risk or dataTypes.task accepts Lucene query fragments. These fragments are dynamically expanded with project and document context, then combined with the auto-generated type filters using AND logic.Rules for custom queries:
Empty or whitespace-only queries are safely ignored by the system
Document IDs with _default/ prefix have the prefix stripped automatically before query construction
Document IDs are quoted automatically to handle spaces and special characters
Multiple query conditions are merged with AND logic; empty conditions are skipped
Lucene special characters that must be escaped:
Character
Must Escape
Notes
+-
Yes
Escape at start of terms
&&||
Yes
Boolean operators
!
Yes
NOT operator
()
Yes
Grouping operators
{}[]
Yes
Range operators
^"~
Yes
Boost, phrase, fuzzy operators
*?
Context-dependent
Wildcard operators; escape only if literal
:\/
Yes
Field separator, escape character, regex delimiter
Troubleshooting steps for custom queries:
Remove the custom query value temporarily to confirm the base auto-generated query works
Test your Lucene query directly in Polarion’s work item search interface to verify syntax
Add query fragments back incrementally to isolate the failing clause
Check that all field names referenced in the query exist in the target work item type
{ "dataTypes": { "risk": { "types": ["fmea_risk"], "query": "NOT status:rejected AND NOT status:obsolete" } }}
If you cannot resolve a custom query error quickly, set the query property to an empty string "". The system ignores empty queries and uses only the automatic project, document, and type scope filters. This restores grid loading while you debug the query offline.
If you use queryFactory functions to dynamically filter which items are available for linking in item link or multi-item link columns, the function must return a valid Lucene query string. Common mistakes in query factory functions include:
Returning undefined or null instead of an empty string
Missing quotes around string values in the returned query
Referencing a field name that does not exist on the target work item type
Using JavaScript template literals with unescaped Lucene special characters
Verify the function syntax in your risksheet.json:
{ "dataTypes": { "task": { "queryFactory": "function(item) { return 'type:mitigation_action AND NOT status:closed'; }" } }}
The queryFactory function receives the current row’s work item data as its parameter. Use it to construct context-aware queries, such as filtering linked items by the same project or status.
If the autocomplete editor in link columns fails to return results, verify the following:
Minimum search length — The autocomplete editor for multi-item link columns requires a minimum of 3 characters before executing a search query. Typing fewer characters produces no results by design.
Query factory configuration — If the column uses a custom queryFactory, verify the function returns a valid query for the current item context.
Type filtering — The autocomplete search filters results by the configured work item type and optionally by a custom query. Confirm the target work item type exists and has items within the search scope.
Duplicate prevention — The autocomplete editor enforces uniqueness. You cannot select an item that is already linked. If you attempt to add a duplicate, a toast notification informs you and the selection is rejected.
If the autocomplete returns no matches, users can create new work items directly from the link editor when the column’s canCreate property is set to true (the default for itemLink and multiItemLink columns). This reduces context switching when the desired target item does not yet exist.
After applying the appropriate fix, verify the resolution:
Clear your browser cache and reload the Risksheet document
Open the browser developer console (F12) and check the Console tab for any remaining Error parsing filter definition: messages
Check the Network tab to confirm the /api/config endpoint returns a successful response
Verify the Risksheet grid loads completely with all expected risk items displayed
Test autocomplete search in link columns by typing 3 or more characters
If you modified server-side Polarion configuration (Auto Assignment, workflows), restart the Polarion server and verify the server logs are free of query parsing exceptions
You should now see the Risksheet grid fully populated with all expected risk items, filter operations working without console errors, and autocomplete search returning matching results when typing 3 or more characters.