feat: add jira service and e2e node

[eryue0220]

This pr is to add Jira e2e node and service

[mbakgun]

Thanks for the very thorough PR again ⭐️ The structure is clean and closely follows the existing GitHub/Linear/Sentry nodes: modular handler plus registry, dedicated properties component, credential type with an additive migration, docs, and tests 🙏

One functional issue should be fixed before merge, and one compatibility claim should be clarified.

Fixes

1. getIssueChangelog appears to read the wrong response key.
get_issue_changelog calls the dedicated GET /issue/{key}/changelog endpoint. Jira Cloud v3 documents this response as PageBeanChangelog, with changelog entries under values: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-changelog-get

The handler reads result.get("histories"), so a normal 200 response can produce an empty changelog with count: 0. The current tests also feed a histories payload, so they pass against the wrong shape. Please switch the handler to values and update the test fixture to match the dedicated endpoint response. Worth confirming against a live Jira instance as well.

2. The advertised v2 / Data Center support does not match body serialization.
create_issue, update_issue, create_comment, and update_comment always wrap text with _adf_text_document(...). That is correct for Jira Cloud v3: Cloud create issue and comment examples use ADF-style type: "doc" objects for description/body:

• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/#api-rest-api-3-issue-issueidorkey-comment-post
• https://developer.atlassian.com/cloud/jira/platform/apis/document/structure/

But Jira Server/Data Center v2 examples use plain strings for issue description and comment body:

• https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/#creating-an-issue-using-a-project-key-and-field-names
• https://developer.atlassian.com/server/jira/platform/jira-rest-api-example-add-comment-8946422/

The default v3 path is fine, but the credential dialog and docs suggest api_version=2 for older Jira Server/Data Center sites. Minimal fix: narrow the UI/docs to say this node targets Jira Cloud v3. Fuller fix: branch serialization by api_version so v2 sends plain strings and v3 sends ADF.

Nits

• workflow_dsl_prompt.py has duplicate section numbering: Jira and GitHub are both ### 35.
• jiraIncludeBinary is the only value-like field without the agent-provided toggle; not critical, but worth checking for consistency.

Nice work overall 🔥 🚀 Thank you once again

[eryue0220]

Thanks for the very thorough PR again ⭐️ The structure is clean and closely follows the existing GitHub/Linear/Sentry nodes: modular handler plus registry, dedicated properties component, credential type with an additive migration, docs, and tests 🙏

One functional issue should be fixed before merge, and one compatibility claim should be clarified.

Fixes

1. getIssueChangelog appears to read the wrong response key. get_issue_changelog calls the dedicated GET /issue/{key}/changelog endpoint. Jira Cloud v3 documents this response as PageBeanChangelog, with changelog entries under values: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-changelog-get

The handler reads result.get("histories"), so a normal 200 response can produce an empty changelog with count: 0. The current tests also feed a histories payload, so they pass against the wrong shape. Please switch the handler to values and update the test fixture to match the dedicated endpoint response. Worth confirming against a live Jira instance as well.

2. The advertised v2 / Data Center support does not match body serialization. create_issue, update_issue, create_comment, and update_comment always wrap text with _adf_text_document(...). That is correct for Jira Cloud v3: Cloud create issue and comment examples use ADF-style type: "doc" objects for description/body:

• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/#api-rest-api-3-issue-issueidorkey-comment-post
• https://developer.atlassian.com/cloud/jira/platform/apis/document/structure/

But Jira Server/Data Center v2 examples use plain strings for issue description and comment body:

• https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/#creating-an-issue-using-a-project-key-and-field-names
• https://developer.atlassian.com/server/jira/platform/jira-rest-api-example-add-comment-8946422/

The default v3 path is fine, but the credential dialog and docs suggest api_version=2 for older Jira Server/Data Center sites. Minimal fix: narrow the UI/docs to say this node targets Jira Cloud v3. Fuller fix: branch serialization by api_version so v2 sends plain strings and v3 sends ADF.

Nits

• workflow_dsl_prompt.py has duplicate section numbering: Jira and GitHub are both ### 35.
• jiraIncludeBinary is the only value-like field without the agent-provided toggle; not critical, but worth checking for consistency.

Nice work overall 🔥 🚀 Thank you once again

Thanks for your review, I've updated.

[ckakgun]

Thanks @eryue0220 🙏 , the previous fixes look good and CI is green. One product requirement is important for us before merge: this node should support self-hosted Jira / Data Center, not only Jira Cloud.

Right now api_version=2 only fixes text body serialization. The rest of the implementation still follows Jira Cloud REST behavior, so the “Jira Server or Data Center” wording is not accurate yet.

Required before merge:

1. Search must branch for Data Center.
   search_issues always calls /search/jql. That exists in Jira Cloud v2/v3, but Jira Data Center documents search as POST /rest/api/2/search with jql, startAt, maxResults, and fields, returning offset pagination (startAt, maxResults, total) rather than nextPageToken.
   References:

   • Data Center search: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/search-searchUsingSearchRequest
   • Cloud v2 search/jql: https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/

2. Changelog must branch for Data Center.
   Cloud uses the dedicated /issue/{key}/changelog endpoint with values. Data Center guidance uses GET /rest/api/2/issue/{key}?expand=changelog and reads changelog.histories.
   Reference: https://support.atlassian.com/jira/kb/how-to-analyze-the-history-or-changelog-of-an-issue-in-jira/

3. User identity and assignee fields must branch for Data Center.
   Cloud uses accountId; Data Center user APIs use username / key, and assignee examples use {"name": "..."}. getUser, deleteUser, create/update issue assignee, and create user payloads need Data Center-compatible handling.
   References:

   • Data Center user API: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/user
   • Data Center assignee: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/issue-assign
   • Cloud user API: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-rest-api-3-user-get

I think api_version alone may be too ambiguous because Jira Cloud REST v2 and Jira Data Center REST v2 are different surfaces. A credential-level deployment mode such as cloud / data_center may be clearer, with Data Center using REST API v2 paths and username/name-based user identity.

Please add v2/Data Center path tests for search, changelog, assignee/user identity, and create user. The text body handling added in the last commit is good and should stay.

[mbakgun]

We’ll need to update 94 for our Alembic credential for the team file sharing feature , which will be merged into main with 0.0.61. Just wanted to give you a quick heads-up. Great work, thank you so much. 🙏

[eryue0220]

We’ll need to update 94 for our Alembic credential for the team file sharing feature , which will be merged into main with 0.0.61. Just wanted to give you a quick heads-up. Great work, thank you so much. 🙏

Got it, thanks for your sharing.

[eryue0220]

Thanks @eryue0220 🙏 , the previous fixes look good and CI is green. One product requirement is important for us before merge: this node should support self-hosted Jira / Data Center, not only Jira Cloud.

Right now api_version=2 only fixes text body serialization. The rest of the implementation still follows Jira Cloud REST behavior, so the “Jira Server or Data Center” wording is not accurate yet.

Required before merge:

1. Search must branch for Data Center.
   search_issues always calls /search/jql. That exists in Jira Cloud v2/v3, but Jira Data Center documents search as POST /rest/api/2/search with jql, startAt, maxResults, and fields, returning offset pagination (startAt, maxResults, total) rather than nextPageToken.
   References:

   • Data Center search: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/search-searchUsingSearchRequest
   • Cloud v2 search/jql: https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/

2. Changelog must branch for Data Center.
   Cloud uses the dedicated /issue/{key}/changelog endpoint with values. Data Center guidance uses GET /rest/api/2/issue/{key}?expand=changelog and reads changelog.histories.
   Reference: https://support.atlassian.com/jira/kb/how-to-analyze-the-history-or-changelog-of-an-issue-in-jira/

3. User identity and assignee fields must branch for Data Center.
   Cloud uses accountId; Data Center user APIs use username / key, and assignee examples use {"name": "..."}. getUser, deleteUser, create/update issue assignee, and create user payloads need Data Center-compatible handling.
   References:

   • Data Center user API: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/user
   • Data Center assignee: https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/issue-assign
   • Cloud user API: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-rest-api-3-user-get

I think api_version alone may be too ambiguous because Jira Cloud REST v2 and Jira Data Center REST v2 are different surfaces. A credential-level deployment mode such as cloud / data_center may be clearer, with Data Center using REST API v2 paths and username/name-based user identity.

Please add v2/Data Center path tests for search, changelog, assignee/user identity, and create user. The text body handling added in the last commit is good and should stay.

I’ve update for this.

[ckakgun]

Thanks for the Data Center work @eryue0220 🙏 , this is a big step up. Search, changelog, text bodies, and the accountId vs username handling all look right now, and the deployment flag is a clean way to model it.

There is still one thing that breaks on real self-hosted before we can call Data Center supported.

listProjects calls /project/search for every deployment. That is the Cloud project search shape, but Jira Server / Data Center documents project listing as GET /rest/api/2/project, which returns a plain array instead of the { values, ... } page shape the handler reads. I also do not see /project/search in the Data Center REST docs. So on a Data Center instance listProjects can 404 or come back empty.
https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/project-getAllProjects

Could you branch list_projects on deployment so Data Center hits /rest/api/2/project, normalize the array into the same output the node returns for Cloud, and add a Data Center test for it?

One smaller thing, not strictly blocking: auth is still Cloud shaped. The service always sends Basic auth with email and api_token. Username/password Basic auth can work on Data Center, so this will not always fail, but the Email and API Token labels are confusing for a self-hosted setup, and Data Center personal access tokens use Bearer auth, which we do not support yet. A follow-up auth mode for Data Center, such as basic vs PAT, would make this cleaner. At minimum, the Data Center credential labels/docs should make the supported auth path clear.

Everything else looks good and CI is green. Once listProjects works on Data Center this is good to merge. 🚀

[eryue0220]

Thanks for the Data Center work @eryue0220 🙏 , this is a big step up. Search, changelog, text bodies, and the accountId vs username handling all look right now, and the deployment flag is a clean way to model it.

There is still one thing that breaks on real self-hosted before we can call Data Center supported.

listProjects calls /project/search for every deployment. That is the Cloud project search shape, but Jira Server / Data Center documents project listing as GET /rest/api/2/project, which returns a plain array instead of the { values, ... } page shape the handler reads. I also do not see /project/search in the Data Center REST docs. So on a Data Center instance listProjects can 404 or come back empty. https://docs.atlassian.com/software/jira/docs/api/REST/9.14.0/#api/2/project-getAllProjects

Could you branch list_projects on deployment so Data Center hits /rest/api/2/project, normalize the array into the same output the node returns for Cloud, and add a Data Center test for it?

One smaller thing, not strictly blocking: auth is still Cloud shaped. The service always sends Basic auth with email and api_token. Username/password Basic auth can work on Data Center, so this will not always fail, but the Email and API Token labels are confusing for a self-hosted setup, and Data Center personal access tokens use Bearer auth, which we do not support yet. A follow-up auth mode for Data Center, such as basic vs PAT, would make this cleaner. At minimum, the Data Center credential labels/docs should make the supported auth path clear.

Everything else looks good and CI is green. Once listProjects works on Data Center this is good to merge. 🚀

Sorry for the missing, I've updated.

[mbakgun]

Thanks 👑 , we’re happy to have such a fabulous contribution. 🚀