FAQ
This section is for users signed up for this EAP. Sign up for this round is closed, but if you are interested in signing up for future EAPs, please contact support.
Q: Will the new JQL Enhanced Search experience work with our restricted fields?
A: We need to test this since permissions would be applied from Atlassian. If our app does not have permissions to see certain fields/issues, then we are unlikely to be able to retrieve those results.
Q: Will filter IDs stay the same after migration/sync?
A: Filter IDs will stay the same.
Q: Will migrated filters become fully native Jira filters, or remain ScriptRunner-managed objects exposed in native search?
A: Migrated filters will be fully managed via Jira filters and Jira UI. We will store info about the individual precomputations that make up the filter, but all editing will be through native Jira UI.
Q: What exact permissions are required for a full initial sync? How are restricted comments, issues, etc. handled in the new native search experience?
A: There is no initial sync with Forge.
Q: Are there any deprecated keywords, changed operators, or validation differences we should know about?
A: There are syntax changes from Connect to Forge. Visit Syntax Changes for more information.
Q: This is implemented as a Forge app. How will this Forge/native implementation impact performance, especially for large instances?
A: There is a chance large instances will hit timeouts more frequently and some filters will not work if they return too many issues. More testing is required.
ScriptRunner is not in control of timeout and search limits because they are set by Atlassian. For more information, see Timeouts and Performance.
Q: Are there new limits on query complexity, nested functions, result size, or refresh frequency?
A: Yes, filters are being split into individual Enhanced Search function use. Therefore, if you can make each instance of a function as efficient as possible, you can have infinite instances in one query and it should not affect the overall filter results.
We will support nested functions to a nesting level of 3. For example, the following level of nesting works: issue in linkedIssuesOf("issue in childrenOf("issue in parentsOf("project = test")")")
Result size is dictated per precomputation. As long as the individual precomputation only returns up to 1000 values, there is no limit on the overall filter results. For more information, see Timeouts and Performance.
Q: What are the expected timeout limits in the Forge-based native search implementation?
A: Currently Atlassian has set this to 25 seconds per precomputation. For more information, see Timeouts and Performance.