Bug

jtk auto enable and jtk auto disable fail when the rule actually needs a state change. The API rejects the request body.

The idempotent cases (enabling an already-enabled rule, disabling an already-disabled rule) work correctly because they check the current state first and skip the API call.

Steps to Reproduce

# Enable a DISABLED rule
jtk auto enable <disabled-rule-uuid>

Expected: Rule "..." DISABLED -> ENABLED
Actual: failed to set automation rule <uuid> state to ENABLED: bad request

Root Cause

The code sends PUT /rest/v1/rule/{uuid}/state with body {"ruleState": "ENABLED"}, but the Jira Automation API rejects this with:

{"errors":[{"title":"The request body could not be parsed, please ensure the values provided are valid."}]}

This undocumented API likely changed its expected payload format. I tested:

• {"ruleState": "ENABLED"} → 400
• {"state": "ENABLED"} → 400
• "ENABLED" (plain string) → 400

The Jira Automation API is not officially public (see AUTO-51), so the endpoint contract may have changed without notice.

Workaround

The idempotent check works, so the get command can still verify rule state. For actual state changes, use the Jira UI.

Notes

The unit tests for this function mock the API response and pass, but the real API rejects the payload format. This is an integration-only failure — unit tests can't catch API contract changes.

Found During

Integration testing of jtk auto enable and jtk auto disable.