fix: set resolution and priority through --field - #79
Conversation
…ty as references
atl jira issue transition/edit/create --field sent a system field under the
user's casing ("Resolution") and its value as a bare string or number. Jira
matches field keys case-sensitively and requires resolution and priority as an
{id} or {name} object, so a transition that requires a resolution could not be
completed through atl.
There was a problem hiding this comment.
Code Review
This pull request introduces support for resolving Jira system fields in their canonical casing and wrapping reference fields (such as resolution and priority) in reference objects (using id or name) without requiring an API call. Unit tests were also added to verify this behavior. The review feedback suggests handling empty or whitespace-only values in reference fields by returning nil instead of an empty name object, which allows Jira to clear the field rather than rejecting the request, along with adding corresponding test cases.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces mapping and handling for Jira system fields to ensure they are sent with the correct case-sensitive keys and that reference fields (like resolution and priority) are wrapped in reference objects without making API calls. The feedback suggests defining a local map of schemas for well-known system fields like labels, description, and environment to allow proper coercion, integrating this schema lookup in ParseCustomField, and adding corresponding test cases to verify the coercion.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces support for canonicalizing Jira system field keys and wrapping reference fields (like resolution and priority) in reference objects (id or name) during parsing. It also adds corresponding unit tests and documentation. However, a critical issue was identified where non-reference system fields (such as labels) bypass type-based coercion because the field definition is not fetched, which leads to API errors. It is recommended to fetch the field definition using jira.GetFieldByID for system fields to ensure proper coercion.
|
🔏 Readiness attested — the Readiness summaryPR Readiness Check (#79, 3714b98) Live evidence: on the sandbox site, released atl fails "transition ... --field Resolution=Won't Do" with a 400; this branch transitions the issue and it reads back Erledigt / Won't Do. An empty resolution or priority value is refused locally before any API call. |
Merging this branch will increase overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. Changed unit test files
|
Summary
--fieldonjira issue transition,editandcreatecould not set a resolution, so transitions that require one (for example WARD's "Erledigt") failed.Resolutionbecomesresolution,fixversionsbecomesfixVersions). Jira matches field keys case-sensitively.resolutionandpriorityvalues are sent as a reference object: an all-digit value becomes{"id": ...}, anything else{"name": ...}. Jira rejects a bare string or number for these fields.resolutionorpriorityvalue is refused locally withfield <key> requires a value (id or name). Jira rejects both{"name": ""}andnullfor them (checked on the sandbox site).Testing
go test ./...passes;make lintreports 0 issues.TestParseCustomField_SystemFields,TestParseCustomField_SystemFieldKeyCasingandTestParseCustomField_EmptyReferenceValue. Each fails when its guard is reverted (checked by mutation, one guard at a time).transition WARD-14 Erledigt --field "Resolution=Won't Do"returns400 ... Field 'Resolution' cannot be set. It is not on the appropriate screen, or unknown.Transitioned WARD-14: Neu -> Erledigt, and the issue reads back as statusErledigt, resolutionWon't Do.