/
Jira Snapshots Filtering: Jira JQL extended with page properties and metadata

Jira Snapshots Filtering: Jira JQL extended with page properties and metadata

JQL reading list and references:

  1. https://www.atlassian.com/software/jira/guides/expand-jira/jql

  2. https://www.atlassian.com/blog/jira-software/jql-the-most-flexible-way-to-search-jira-14

  3. https://confluence.atlassian.com/jirasoftwareserver/advanced-searching-939938733.html

Searching for Jira Snapshots Level 1

 

image-20240422-143925.png

 

At the core of each Jira Snapshot operation is a search for Jira issues, driven by a criteria. A “Search JQL”

That “Search JQL” includes any valid JQL, applicable for the Jira from which the snapshot data is retrieved.

Any JQL extensions by apps, as long as they are valid inside that Jira instance, are also supported.

It's a good practice to test the JQL first in Jira. Refer to the Jira manual for more information

 

Search with page Metadata values (supported from version 2.90.2)

If the Confluence page include Comala Metadata values, then Jira Snapshots can use them as placeholder in the search clauses.
When used in the search clause, the syntax is:

$metadata:<MEATADATA KEY>

OR

$metadata:'<MEATADATA KEY>' <- Quotes required if the metadata value may contain blanks


Like this:

image-20240422-151509.png



For example:

  1. The metadata key/value pair is defined: projectkey=SAM

  2. Jira Snapshots search JQL clause may be set to use this metadata:

    project = $metadata:projectkey
  3. The actual search that will be sent to Jira is this:

Its possible to refer to more then a single metadata value in a search clause, for example:

Search with page Page Properties values (upcoming release)

In the near future, Jira Snapshots search will also support Page Properties values. The capabilities will be the same as for Metadata Values.

Watch this space for more information when we are ready to release.

Searching for Jira Snapshots Level 2 or higher

The JQL clause for Level 2 needs to include a reference to Level 1, in order to achieve the dependency/cascading effect.

Therefore, the search clause must reference fields in the previous level.

For example:

  • parent=$key : will retrieve subtasks of issues in the previous level

  • issue in linkedIssues($key) : will retrieve issues linked to the issue in the previous level

  • issuetype = Test AND issue in linkedissues($Key, "is tested by") : will retrieve test issues that are linked with this link type, to the issue in the first level.

Other then this, the JQL clause for level 2 and beyond has all the flexibility existing in the JQL for level 1:

  1. It supports any JQL syntax recognised by your Jira

  2. It can use placeholders referring to page metadata values (supported from version 2.90.2)

  3. It can use placeholders referring to page property values (upcoming release)