[ForeignKeyCN]

Summary

Jira 1.0.0 adds OAuth and Each user signs in (Atlassian OAuth 2.0 3LO) next to the existing API token, and adds the common Jira operations that were missing. It follows the same per-user design as the reworked Microsoft plugins (#4163–#4168).

Existing API-token credentials keep working unchanged. The 10 original tools keep their names and parameters.

Auth

• API token (unchanged): Jira URL + Basic (Cloud) or Bearer (Server / Data Center PAT).
• OAuth: Atlassian 3LO from the Dify console.
  • Optional Site URL, for accounts that can reach several sites.
  • The cloud ID is resolved through accessible-resources.
  • Refresh handles Atlassian's rotating refresh tokens.
• Each user signs in: the first time a chat user needs Jira, the tool returns an Atlassian sign-in link.
  • A plugin endpoint (GET /jira/callback) only stores the one-time code; the tool redeems it with the client secret, which the endpoint never sees.
  • Per-user tokens are Fernet-encrypted in plugin storage, keyed by a hash of client_id | Dify user ID. They never appear in tool output.
  • The callback page warns people who did not start the sign-in themselves and lets them cancel it.
  • jira_sign_out forgets the user's sign-in.
  • The mode is also inferred when the OAuth app fields are filled in and no token is given, because the Mode select is easy to miss.
• Where OAuth tokens go: only to api.atlassian.com/ex/jira/<cloud id>.
  • Attachments are downloaded through the API route; the content link in the metadata is on the site host, which does not accept OAuth tokens.
  • On Server, a metadata link is followed only when it is on the configured Jira host.
• Scopes:
  • Default: read:jira-work write:jira-work read:jira-user offline_access plus read:board-scope:jira-software read:project:jira read:issue-details:jira for the board tools.
  • Can be overridden in a Scopes field.
  • No User identity API scope: the account name comes from Jira's /myself.

New tools (prefixed jira_: the new Agent rejects duplicate tool names across plugins)

Operation	Tool
Issue: Get Many (JQL)	jira_search_issues: Cloud /search/jql with nextPageToken, Server /search; an empty JQL means "updated in the last 30 days" (Cloud refuses unbounded queries)
Issue: Update	jira_update_issue: summary, description (Markdown → ADF on Cloud), assignee, priority, labels, due date, parent, custom fields JSON, optional no-notify
Issue: Changelog	jira_get_changelog
Issue: Transitions / Update status	jira_list_transitions, jira_transition_issue (by target status, transition name or ID, with an optional comment)
Issue: Notify	jira_notify_issue
Issue Comment: Add / Get / Get Many / Update / Remove	jira_add_comment, jira_get_comment, jira_list_comments, jira_update_comment, jira_delete_comment
Issue Attachment: Add / Get / Get Many / Remove	jira_add_attachment (a file, or text + file name), jira_get_attachment (returns the file, up to 50 MB), jira_list_attachments, jira_delete_attachment
User: Get	jira_get_user (empty = the signed-in account), jira_search_users (to find account IDs)

• create_issue now accepts a project key as well as an ID (it sent {"id": "PROJ"} before). It also takes optional assignee, priority, labels, due date, parent and custom fields.
• Creating and deleting users is left out: it needs site-admin rights.
• Every new tool returns typed output variables (success / error plus its fields).
• The original tools work in all three modes through the same client.

Safety: issue keys, comment and attachment IDs are encoded as one path segment each, so a value chosen by the model cannot change which API is called.

Release Notes

• Jira can now be authorized with OAuth, or with Each user signs in for chat agents, where each person works in Jira as themselves.
• 17 new tools:
  • JQL search, update issues, change status, changelog, notifications.
  • Comments: add, list, get, update, delete.
  • Attachments: add, list, download, delete.
  • Users: search, get.
• create_issue accepts a project key and optional fields.
• New tools return typed output variables.

Change Type

• Documentation / non-plugin change
• Non-LLM plugin (tools, extensions, datasource, etc.)
• LLM plugin

Screenshots / Videos

The README walks through the setup with screenshots:

• Atlassian developer console: permissions, scopes, callback URLs, client ID/secret.
• The Dify credential form.
• The agent configuration.
• A chat where the agent asks the user to sign in and then answers as that user.

Testing

• Unit tests: 95 passed (pytest tests); the existing test_sdk_compatibility.py also passes. They cover:
  • Per-user sign-in: link, callback, redeem, cache, refresh with rotation, revoked refresh, encryption and per-user isolation, cancel/error pages, sign-out.
  • Site selection among several sites.
  • The OAuth provider methods and credential validation.
  • Every new tool on Cloud and Server, with path encoding and no OAuth token sent off api.atlassian.com.
  • Every tool's output variables.
  • The original tools under OAuth and per-user.
• Real Jira Cloud site, API token (jira_e2e.py): all 28 tools in 32 steps.
  • Create an issue, update it, move it to In Progress with a comment.
  • Search three ways; comment CRUD; attachment upload, download (content matches) and delete.
  • Changelog, users, projects, boards and board issues; then delete the issue.
  • 31 passed. jira_notify_issue got Jira's "No recipients" because the site has a single user and Jira never emails the sender. The tool now explains this.
• Self-hosted Dify (Community), Each user signs in: in an agent chat, the agent returned the Atlassian sign-in link. After consent, it redeemed the code, found the site, named the account (/myself) and ran a JQL search as that user.
• Not run end to end: write operations through an OAuth / per-user token. They use the same requests as the token-mode run, against api.atlassian.com.

Checklist

• I have read the contribution guidelines
• Version bumped: 0.0.11 → 1.0.0

[crazywoola]

Reviewed the plugin scope, manifest, documentation, and relevant source changes. Approving this revision to run the repository pre-merge plugin validation; merge is contingent on successful validation.