Switch Jira API calls to GET-based JQL search with project scoping

- getIssue now uses GET /rest/api/2/search with JQL instead of
  GET /rest/api/2/issue/{key} for Charter compliance
- searchIssues switched from POST to GET with URL-encoded query params
- searchIssuesByKeys adds project scoping to JQL clause
- Updated UAT tests and API use-case docs to match
This commit is contained in:
root
2026-04-29 14:12:04 +00:00
parent 4f960d0866
commit 7a179f19a1
3 changed files with 30 additions and 24 deletions

View File

@@ -19,8 +19,9 @@ All API calls are made from a single Node.js backend process. The integration us
| Inter-request delay — writes | 2 seconds minimum between PUT/POST/DELETE requests |
| Explicit field lists | Every GET includes `?fields=` parameter; `/rest/api/2/field` is blocked |
| No bulk updates | Issues are updated one at a time; `/rest/api/2/issue/bulk` is blocked |
| Bulk reads via JQL | Multi-ticket sync uses a single `POST /rest/api/2/search` with JQL, not per-issue GETs |
| JQL scoping | All recurring JQL queries include `updated >= -Xh` clause |
| Bulk reads via JQL | Multi-ticket sync uses a single `GET /rest/api/2/search` with JQL query parameters, not per-issue GETs |
| Single-issue fetch via JQL | `GET /rest/api/2/search?jql=key="KEY" AND project=<KEY>&fields=...&maxResults=1` |
| JQL scoping | All recurring JQL queries include `updated >= -Xh` clause and `project = <KEY>` scoping |
| `maxResults` cap | Search queries capped at 1 000 results per page |
---
@@ -52,11 +53,11 @@ All API calls are made from a single Node.js backend process. The integration us
| | |
|---|---|
| **Endpoint** | `GET /rest/api/2/issue/{issueKey}?fields=summary,status,assignee,created,updated,priority,issuetype,project,resolution` |
| **Endpoint** | `GET /rest/api/2/search?jql=key="ISSUE-KEY" AND project=<KEY>&fields=summary,status,assignee,created,updated,priority,issuetype,project,resolution&maxResults=1` |
| **Trigger** | User clicks "Sync" on a single Jira ticket row |
| **Frequency** | Manual, estimated 1030 per day |
| **Purpose** | Refresh a single ticket's status and summary from Jira |
| **Notes** | Fields are always specified explicitly per Charter requirement |
| **Purpose** | Refresh a single ticket's status and summary from Jira via JQL search |
| **Notes** | Uses JQL-based lookup instead of single-issue GET per Charter compliance. Fields are always specified explicitly. |
### 4. Update Issue
@@ -99,23 +100,23 @@ All API calls are made from a single Node.js backend process. The integration us
| | |
|---|---|
| **Endpoint** | `POST /rest/api/2/search` |
| **Endpoint** | `GET /rest/api/2/search?jql=...&fields=...&maxResults=...&startAt=...` |
| **Trigger** | Admin clicks "Sync All" on the Jira tickets panel |
| **Frequency** | Manual, estimated 13 times per day |
| **Purpose** | Bulk-refresh all tracked tickets in a single request instead of per-issue GETs |
| **JQL pattern** | `key in ("KEY-1", "KEY-2", ...) AND updated >= -24h` |
| **JQL pattern** | `key in ("KEY-1", "KEY-2", ...) AND updated >= -24h AND project = <KEY>` |
| **Fields requested** | `summary, status, assignee, created, updated, priority, issuetype, project, resolution` |
| **Batch size** | 100 keys per JQL query; multiple batches if needed |
| **Notes** | Stops early if rate limit budget is running low (burst remaining <= 5 or daily remaining <= 10) |
| **Notes** | Uses GET with URL-encoded query parameters per Charter compliance. Stops early if rate limit budget is running low (burst remaining <= 5 or daily remaining <= 10) |
### 9. Issue Lookup
| | |
|---|---|
| **Endpoint** | `GET /rest/api/2/issue/{issueKey}?fields=...` |
| **Endpoint** | `GET /rest/api/2/search?jql=key="ISSUE-KEY" AND project=<KEY>&fields=...&maxResults=1` |
| **Trigger** | User looks up a Jira issue by key from the dashboard search |
| **Frequency** | Manual, estimated 515 per day |
| **Purpose** | Quick lookup of any Jira issue to view its current state |
| **Purpose** | Quick lookup of any Jira issue to view its current state via JQL search |
---
@@ -130,7 +131,7 @@ All API calls are made from a single Node.js backend process. The integration us
| Add comment | 515 | POST | 2s |
| Get transitions | 510 | GET | 1s |
| Transition issue | 510 | POST | 2s |
| JQL search (sync) | 15 | POST | 2s |
| JQL search (sync) | 15 | GET | 1s |
| Issue lookup | 515 | GET | 1s |
| **Total estimated** | **43120** | | |