@surajmarkupResponse to Cursor Bugbot review
Issue 1: add_users_to_project_role.py — manage:jira-configuration vs manage:jira-project
Bugbot is incorrect on this one. The asymmetry between add (POST) and remove (DELETE) on /rest/api/3/project/{projectIdOrKey}/role/{id} is by Atlassian's design, not a spreadsheet error.
Verified directly against https://dac-static.atlassian.com/cloud/jira/platform/swagger.v3.json:
// POST /rest/api/3/project/{projectIdOrKey}/role/{id}
"x-atlassian-oauth2-scopes": [
{"scheme": "OAuth2", "scopes": ["manage:jira-configuration"], "state": "Current"},
{"scheme": "OAuth2", "scopes": ["read:user:jira", "read:group:jira", "read:project-role:jira",
"read:project:jira", "write:project-role:jira",
"read:avatar:jira", "read:project-category:jira"],
"state": "Beta"}
]
// DELETE /rest/api/3/project/{projectIdOrKey}/role/{id}
"x-atlassian-oauth2-scopes": [
{"scheme": "OAuth2", "scopes": ["manage:jira-project"], "state": "Current"},
{"scheme": "OAuth2", "scopes": ["delete:project-role:jira"], "state": "Beta"}
]
Atlassian deliberately requires the global manage:jira-configuration for adding actors but only project-level manage:jira-project for removing them. Mercury's current scopes match the spec exactly. Leaving as-is.
Issue 2: get_fields.py — wrong granular scopes
Bugbot is correct. The QA spreadsheet had a row mix-up; get_fields.py was given the issuetype endpoint's granular scopes instead of /field's.
Per swagger.v3.json:
// GET /rest/api/3/field
"x-atlassian-oauth2-scopes": [
{"scheme": "OAuth2", "scopes": ["read:jira-work"], "state": "Current"},
{"scheme": "OAuth2", "scopes": ["read:field:jira", "read:avatar:jira",
"read:project-category:jira", "read:project:jira",
"read:field-configuration:jira"],
"state": "Beta"}
]
Fixed in 9a780fb — replaced read:issue-type:jira with read:field:jira and added read:field-configuration:jira so Mercury now requires the documented granular set when granular scopes are granted. Tests pass; ruff clean.