#6753·keep

[➕ Feature]: Query Jira issues by JQL from both Jira providers

Author: purisevCreated Sep 3, 2026Updated Sep 3, 2026

Is your feature request related to a problem? Please describe.

_query in both Jira providers takes a ticket_id and a board_id (keep/providers/jira_provider/jira_provider.py:652, keep/providers/jiraonprem_provider/jiraonprem_provider.py:593). With a ticket id it returns that one issue. Without one it fetches a board's issues and returns the count alone:

python
issues = response.json()
return {"number_of_issues": issues["total"]}

The issues it just fetched are thrown away, so a workflow has nothing to iterate, and the only question it can ask is how many issues a board holds. "Open in project SA for more than three days" or "assigned to nobody" is a JQL query, and there is no parameter to send one through.

Describe the solution you'd like

Three parameters on _query: jql, max_results, fields. The result carries the total, the query it ran, and the issues, so a workflow can foreach over them:

yaml
with:
  jql: "project = SA AND status = Open AND created <= -3d"
  max_results: 50
  fields: summary,status,created,assignee

max_results: 0, the default, answers with the count and an empty list, which covers a threshold check without moving issue data around. fields keeps custom fields out of the payload.

The endpoints differ between deployments. Server and Data Center answer both halves in one /rest/api/2/search request. On Cloud that endpoint is going away, so the search goes to search/jql, which returns a page and no total, and the count comes from search/approximate-count beside it.

Describe alternatives you've considered

Fetching a board and filtering afterwards. The board path returns no issues at all, only their number, so there is nothing to filter.

Additional context

A PR implementing this follows.