[RyoKusnadi]

Summary

Problem: A Jira Cloud connection that uses a long token (for example a scoped service-account token) passes Test Connection, but fails after it is saved. Opening the connection or its data scopes returns HTTP 500 with illegal base64 data at input byte 252.

How it happens: The token is stored encrypted and base64 encoded, which makes it longer than the plain token. The token column of _tool_jira_connections is varchar(255), so the saved value is cut off (or the write is rejected on strict MySQL modes). Reading it back, the encdec serializer cannot decode the cut value. Test Connection works because it uses the token from the request, not the database.

Cause: helper.AccessToken.Token has no explicit column type (backend/helpers/pluginhelper/api/connection_auths.go), so the column was created as varchar(255).

Fix: Add a Jira migration 20261104_change_connection_token_to_text.go that changes _tool_jira_connections.token to text, using ModifyColumnType as other plugins do (for example GitHub 20260819_expand_text_columns.go). Changing the shared AccessToken tag would not touch existing tables, so a per-plugin migration is needed anyway.

Scope: Other plugins that embed helper.AccessToken (gitee, incidentio, testmo, pagerduty, circleci, grafana_irm, linear, clickup, youtrack, bamboo, github, tempo, rootly, opsgenie, slack, sonarqube) could have the same limit. I left them out to keep this PR to the reported Jira case; I can follow up if the maintainers want it. password (basic auth) is also varchar(255) but those values are short. Connections that already saved a cut token must have the token entered again.

Testing: Added TestChangeConnectionTokenToText. It checks that Up calls ModifyColumnType("_tool_jira_connections", "token", "text") and that the script is registered in All(). Before registering, it failed with migration version 20261104120000 is not registered. After, it passes. Ran go vet ./plugins/jira/models/..., go test ./plugins/jira/models/..., gofmt -l. The migration itself was not run against a real MySQL or Postgres database, and the full suite and e2e tests were not run.

Risk: Low. Only the Jira token column type changes (MODIFY COLUMN ... text). Existing values are kept. Rolling back means changing the column back to varchar(255), which would cut long tokens again.

Does this close any open issues?

Closes #9328

Other Information

None.

[RyoKusnadi]

@klesh friendly ping on this one when you have a moment. Happy to change anything.