Feature Parity and Script Alternatives

addedAfterSprintStart is available in ScriptRunner Enhanced Search.

This JQL function will identify issues that were added to an open sprint after the feature was released (21st December 2020). Historical searches for issues added to open sprints prior to that date are not supported.

The DC implementation calculates aggregates (sum, count, etc.) across issue data and displays results in a separate panel. Native Jira doesn't support displaying aggregate summaries in a UI panel in search results.

Also, there are performance considerations because aggregate expressions require complex calculations across large datasets.

There is no like-for-like function in Jira Cloud, but depending on what you want to achieve, you could implement a new function in Cloud.

Cloud's version API (/rest/api/3/project/{projectIdOrKey}/version) should return version data, including archived status, and would need to fetch all versions and filter by archived: true.

There is no like-for-like function in Jira Cloud, but depending on what you want to achieve, you could use some ScriptRunner JQL Keywords to achieve the same:

• firstCommentedDate
• lastCommentedDate
• commentedOn
• commentedBy
• lastCommentBy

epicsOf is available in ScriptRunner Enhanced Search.

This function is available for Jira company-managed projects but not for team-managed projects.

The Server/DC implementation allows arbitrary Groovy expressions to be evaluated against issue data and can compare duration, date, number, picker, and user fields, and perform mathematical operations on them.

In Cloud, Jira expressions are used and cannot be embedded in JQL functions the same way. The expression function can compare duration, date, number, pickers, and user fields (and perform mathematical operations on them), making it too complex to parse automatically and determine the type of field without querying Jira. For date field types only, there is a potential partial conversion to the dateCompare function:

• issue in dateCompare(<JQL>, <expression>) for expressions where date field types are encountered. However, the syntax is different, and the migration would require extra manual changes.

There is no like-for-like function in Jira Cloud, but depending on what you want to achieve, you could use some ScriptRunner JQL Keywords to achieve the same result:

• numberOfAttachments
• attachmentType
• firstAttachmentDate
• lastAttachmentDate
• fileAttachedBy

The Server/DC implementation searches for issues with remote links (links to external systems like Confluence and Bitbucket).

Cloud has a remote link: /rest/api/3/issue/{issueIdOrKey}/remotelink

Implementing for Cloud would require fetching issues and checking each issue for remote links, although it could be slow/expensive.

The Server/DC implementation returns all users who have been marked inactive in the system.

For Cloud:

• Cloud has /rest/api/3/user/search/query endpoint (Jira Cloud API docs) that we could use to return users with active: false status in response objects.
• There is a constraint mentioned in the documentation: "Note that the operations in this resource only return users found within the first 1000 users". The function would work correctly for small instances (<1000 inactive users), but could potentially create inconsistent behaviour for larger instances.
• Atlassian recommends using the paginated endpoint /rest/api/3/users/search, which includes the status of each user ("active": true/false) that we could filter on the client side.

Cloud Status: not possible to migrate

• Unlike Server/DC's Lucene indexing, Cloud's API doesn't expose indexed custom field relationships in a way that supports efficient reverse queries.
• Cloud's /rest/api/3/search API can query custom fields directly (e.g., cf[12345] = "PROJ-123"), but fetching all issues that reference a specific issue in a custom field would require expensive operations and perform reverse relationship queries, which wouldn't perform well and would likely result in timeouts.
• In terms of performance, this would require fetching all issues with the custom field populated and checking if each issue matches the query, which could be quite expensive, especially for large instances.

issuesInEpics is available in ScriptRunner Enhanced Search.

This function is available for Jira company-managed projects but not for team-managed projects.

The Server/DC implementation returns users with matching Jira user property values (custom key-value pairs stored on user accounts).

Cloud Status: not possible to migrate without limitations

• Cloud has /rest/api/3/user/search/query endpoint which supports querying by entity properties using syntax: [propertyKey].entity.property.path is "<property value>"
• The API documentation states: "Note that the operations in this resource only return users found within the first 1000 users." (Same limitation as inactiveUsers, and would return incomplete results for larger instances)
• Cloud's entity properties would also match Server/DC's user properties format. In Server/DC, user properties use the jira.meta. prefix (e.g., "jira.meta.region"). We would need to verify that all Cloud's entity properties follow this format.

There is no like-for-like function in Cloud, but depending on what you want to achieve, you could use the lastCommentBy or lastCommentedDate ScriptRunner JQL keyword to achieve the same result.

linkedIssuesOf is available in ScriptRunner Enhanced Search.

This function can be used in Jira Server/Data Center to search for issues linked with the parent-child hierarchy provided by Advanced Roadmaps/Portfolio but not in Jira Cloud Enhanced Search.

The Cloud API doesn't provide indexed access to remote link properties for efficient searching, and the /rest/api/3/issue/{issueIdOrKey}/remotelink endpoint:

• doesn't support searching or filtering remote links by properties
• requires fetching all issues, then checking each issue's remote links individually, which would impact performance.

Cloud status: possible with significant limitations

• Server/DC behaviour:
  • Takes field name and one or more role names as arguments, e.g. issueFunction in memberOfRole("Reporter", "Administrators"), and can be used with all User fields (reporter, creator, assignee, user custom fields, script fields).

• Cloud has project role endpoints, which can retrieve users/groups directly assigned to roles, or role membership per project:

  • /rest/api/3/project/{projectIdOrKey}/role - Get all roles for a project.
  • /rest/api/3/project/{projectIdOrKey}/role/{roleId} - Get role details, including users and groups assigned to that role.

• It might not be practical in the Cloud due to the following reasons:

  • Project scope complexity: the function would need to determine which projects to query (from the query context or all projects). For queries without project restrictions, we would need to query all projects, and each project requires an API call to get each role membership.
    • Refer to the documentation where we mention this limitation 'If you have a large number of projects each having a large number of role memberships, the function will fail', which could likely occur in the Cloud.
  • There might be a need to resolve group members in some cases, which could require additional API calls to /rest/api/3/group/member for each group.
• Cloud has the native membersOf() JQL function for group-based searches, but this doesn't work for project-specific project roles.

Cloud Status: possible to implement, with significant limitations.

• Server/DC behaviour:
  • project in myProjects() returns projects where the user is in any role, except projects where the user only has access via global permission groups (e.g., jira-users, jira-admins).
    • Refer to the documentation where we mention: 'being a member means being in any role, except where that is by virtue of being in a group with a global permission'.
• Cloud has project-related endpoints to retrieve projects and check role membership per project:
  • /rest/api/3/project/search - Returns projects visible to the authenticated user (i.e. has Browse Projects permission).
  • /rest/api/3/project/{projectIdOrKey}/role - Get all roles for a project.
  • /rest/api/3/project/{projectIdOrKey}/role/{roleId} - Get role details including users and groups assigned to that role.
• This wouldn't be as practical in Cloud, since /rest/api/3/project/search returns projects where user has specific permissions, which is not the same as "projects where user is in a role". To replicate the exact behavior, we'd need to check role membership (not just browse permission), adding overhead to the query:
  • Get all projects (or use /rest/api/3/project/search to get visible projects)
  • For each project, get all roles: /rest/api/3/project/{projectIdOrKey}/role
  • For each role, check if current user is in that role

Cloud Status: could be implemented as a new function

• Server/DC behaviour:
  • Returns versions that are: a) unreleased, and b) have a release date in the past.
    • Example: fixVersion in overdue() - finds issues with fix versions that are overdue
  • Can optionally filter by release date: fixVersion in overdue("before -14d") (at least 14 days overdue).
    • Example: fixVersion in overdue("before -14d") - finds issues with fix versions at least 2 weeks overdue.
• Similar to archivedVersions, overdue could be implemented in the Cloud as a separate function:
  1. Use Cloud's version API (/rest/api/3/project/{projectIdOrKey}/version) to get all versions.
  2. Filter versions where:

     • released: false (unreleased)

     • releaseDate exists and is in the past (before the current date)
  3. (Optional) Apply date filtering if an argument is provided.
  4. Return version IDs.

childrenOf can be used to find all descendant issues of a given subquery, including children, grandchildren, and beyond.

Second parameter (optional): You can use a second JQL query for childrenOf(Subquery) that acts as a filter on descendant issues. We strongly recommend using this option to avoid filters that require significantly longer processing times because of their recursive nature.

For example, you could use:

issueFunction in childrenOf("issue = EXAMPLE-1")

And then narrow the search results:

issueFunction in childrenOf("project = DEMO", "issueType != Subtask")

parentsOf can be used to find all ancestor issues of a given subquery, including parents, grandparents, and beyond.

projectMatch is available in ScriptRunner Enhanced Search.

In Jira Cloud this function uses the projectKey, whereas in server/data centre it uses project name.

Cloud Status: possible to implement (could be implemented as a separate function, similar to archivedVersions and overdue)

• Server/DC behaviour:
  • Takes a date query argument with predicates: after, before, on
  • Example: fixVersion in releaseDate("after now() before 10d") - finds issues with fix versions due in the next 10 days.
  • Example: fixVersion in releaseDate("on 2016/09/07") - finds issues with fix versions released on a specific day.
  • Can be used with fix versions, affects versions, and version custom fields.
  • Supports date expressions like -5d, -8w, or date functions like startOfMonth().
• Cloud's API (/rest/api/3/project/{projectIdOrKey}/version) returns version objects, including releaseDate, so it would be feasible in the Cloud by following a similar approach to archivedVersions:
  • Use Cloud's version API (/rest/api/3/project/{projectIdOrKey}/version) to get all versions.
  • Parse the date query argument and its expressions (relative dates like -5d, 10d, absolute dates, date functions, etc).
  • Filter versions where releaseDate matches the date predicates:
    • after date: releaseDate > date
    • before date: releaseDate < date
    • on date: releaseDate == date (at day level)
  • Handle multiple predicates (e.g., "after now() before 10d" means releaseDate > now() AND releaseDate < now() + 10 days).
  • Return version IDs.
• For large instances with many projects, project restrictions may be required, although the same limitation would apply to other functions, such as archivedVersions and overdue.

Cloud Status: possible to implement, but with additional complexity, similar to Cloud's addedAfterSprintStart.

• Server/DC behaviour:
  • Example: removedAfterSprintStart("Development Scrum", "Sprint 25") - finds issues removed after Sprint 25 started.
  • Example: removedAfterSprintStart("Product Overview") - finds issues removed after all active sprints started.
  • Used to track sprint scope changes (issues removed after sprint planning).
• Cloud's addedAfterSprintStart uses the issue changelog to detect when issues were added to sprints. For removedAfterSprintStart:
  • Find issues that were removed from the sprint (not currently in it).
  • Use a similar changelog-based approach but in reverse:
    1. Get all issues that were in the sprint.
    2. Check the changelog for Sprint field changes for each issue.
    3. Look for changelog entries where:
       • field === "Sprint"
       • Sprint ID is in from field but not in to field (removed from sprint)
       • Change date is after the sprint start date
    4. Return matching issue IDs.
• Similar performance profile to addedAfterSprintStart (but with potentially more issues to check, since we need to find issues that might have been removed).
• Could be optimised by using project/board scope and date ranges to limit candidate issues, or caching changelog data where possible.

Cloud Status: possible to implement as a separate function, identical to releaseDate but using startDate field.

• Server/DC behavior:
  • Takes a date query argument with predicates: after, before, on.
  • Example: fixVersion in startDate("after 14d") - finds issues with fix versions starting in more than 14 days.
• Feasible in Cloud, since this is the exact same approach that works for archivedVersions, releaseDate, and overdue. The only difference would be using startDate instead. Aside from that the implementation would be identical.
  • Cloud's API (/rest/api/3/project/{projectIdOrKey}/version) returns version objects which include startDate.
  • Parse the date query argument (e.g., "after 14d").
  • Filter versions where startDate matches the date predicates:
    • after date: startDate > date
    • before date: startDate < date
    • on date: startDate == date

Cloud Status: partial native support for date queries only; author/role/group queries not supported natively.

• Server/DC behavior:
  • Supports date queries: on, after, before dates; e.g. issueFunction in workLogged("on 2025/03/28 by admin")
  • Supports user queries: by username or user function (e.g., by admin, by currentUser())
  • Supports role queries: inRole role (e.g., inRole Administrators)
  • Supports group queries: inGroup group (e.g., inGroup jira-administrators)
• In Cloud:
  • Date queries are already supported natively via worklogDate
  • Author/role/group queries aren't natively supported in Cloud. It is possible to implement but potentially expensive (similar to inactiveUsers and jiraUserPropertyEquals).
    • To carry this out, you need to:
      1. Get candidate issues (from JQL query scope).
      2. Fetch worklogs via /rest/api/3/issue/{issueIdOrKey}/workload for each issue.
      3. Filter worklogs by: Author (for by queries), role (for inRole queries) or group (for inGroup queries).
      4. Return issue IDs that have matching worklogs.

ALT

ALT

This is not possible in Jira Cloud.

"Local" databases are on-premises behind your firewall. Cloud runs in Atlassian's AWS infrastructure and cannot access your internal network due to security isolation. ScriptRunner Cloud runs as a separate service with no direct network access to customer infrastructure.

ALT