Add Jira support to tasks, alongside Linear and GitHub Issues

[reicolina]

What problem are you trying to solve?

The tasks section connects to Linear and GitHub Issues, but not Jira. My team runs on Jira, so that whole part of Superset is closed to us. Today I either paste ticket details into a prompt by hand or skip tasks entirely and start a workspace cold, which loses the link back to the ticket everyone else on the team is watching.

This is not a niche gap. Jira is still the default tracker at most companies past a certain size, especially anywhere with compliance, a service desk, or non-engineering teams sharing the same instance. Linear and GitHub Issues cover startups and OSS well, but they leave out a large share of the teams who would otherwise be a good fit for Superset. Someone on Jira opens the tasks section, sees two trackers they don't use, and that is where the evaluation ends.

The teams stuck on Jira are also the ones with the most to gain here. Jira shops tend to have bigger backlogs and more process per ticket, and a lot of those tickets are small, well specified, and boring. That is exactly the work worth handing to a parallel agent, and right now there is no way to feed it in.

Proposed solution

Jira as a third tracker in the same place as Linear and GitHub Issues, behaving the same way so there is nothing new to learn:

• Atlassian OAuth (3LO) connect flow for Jira Cloud, in the same integrations screen as the others.
• Assigned issues pulled into the tasks list with key, summary, status, priority, assignee.
• Start a workspace from an issue, with the issue key in the branch name so PROJ-123 shows up in Jira's development panel automatically.
• Status writes back: transition the issue when the workspace opens a PR, and again on merge.
• Link or comment the PR on the issue so the rest of the team sees the work from inside Jira.

Scope suggestions, take or leave them:

• Jira Cloud only to start. Data Center is a different auth story and can wait for demand.
• A JQL filter for which issues land in the task list. That answers "which issues do I care about" for most people without per project configuration, since Jira setups vary far more than Linear ones do.
• Jira's REST v3 plus webhooks map closely onto what the Linear integration already does (packages/trpc/src/router/integration/linear, apps/api/src/app/api/integrations/linear with its connect, callback, webhook, initial-sync and sync-task jobs), so the existing shape should mostly carry over rather than needing a new pattern.

Workarounds you've tried

• Copying the ticket description into a Superset prompt manually. It works, but it is one way. Nothing goes back to Jira, and it stops being worth it past a couple of tickets.
• Atlassian's MCP server inside an agent session. Fine for reading and updating a ticket mid task, but it puts nothing in the tasks section, so there is no list to pick from, no workspace per ticket, and no status tracking.
• Mirroring Jira into Linear. Not realistic. Jira is the system of record for teams outside engineering, so it is not going anywhere.

Happy to test a beta against a real Jira Cloud instance if that is useful.

[github-actions]

Summary

This is a feature request (no defect to reproduce): add Jira Cloud as a tracker in the tasks section alongside the existing integrations, with OAuth connect, issue sync into the task list, workspace-per-ticket with the issue key in the branch name, and status write-back on PR open/merge. I read through the integration and task-sync code to check how well the proposed shape maps onto what exists. The core suggestion in the report — that the Linear tree is the right thing to copy — is correct, but there's an important wrinkle in the framing: Linear and GitHub Issues are not one pattern with two providers, they're two unrelated architectures, and only one of them is a fit for what's being asked.

What exists today

Linear — org-level cloud sync, bidirectional, writes rows into tasks. OAuth 3LO → integrationConnections → initial-sync/webhook/sync-task jobs:

• packages/trpc/src/router/integration/linear/ (router, refresh.ts, utils.ts)
• apps/api/src/app/api/integrations/linear/{connect,callback,webhook,jobs/*}
• Tasks carry externalProvider / externalId / externalKey / externalUrl — packages/db/src/schema/schema.ts:129-134

GitHub Issues — host-local, read-only, live-queried, never persisted as tasks. Issues are fetched on demand through gh/Octokit from host-service and used for browsing and prompt-linking:

• packages/host-service/src/trpc/router/workspace-creation/procedures/search-github-issues.ts
• packages/host-service/src/trpc/router/issues/
• apps/desktop/src/renderer/routes/_authenticated/_dashboard/tasks/issue/$issueNumber/page.tsx

Grepping externalProvider across the repo returns only "linear" string literals, and packages/db/src/schema/github.ts has just githubInstallations / githubRepositories / githubPullRequests — no issues table. So Linear is the only tracker that actually syncs into the task list, and Jira would be the first integration to exercise any multi-provider path. That's worth knowing up front: several places that look generic have only ever run with one provider.

Extension points

The plumbing is mostly registry-shaped, which is in the request's favour:

What	Where
Provider enum (pgEnum → needs a migration)	packages/db/src/schema/enums.ts:26
IntegrationConfig union — add JiraConfig	packages/db/src/schema/types.ts:1-10
Sync dispatch table	packages/trpc/src/lib/integrations/sync/tasks.ts:9-11
Router registration	packages/trpc/src/router/integration/integration.ts:12-15
OAuth callback + signed-state + upsert	apps/api/src/app/api/integrations/linear/callback/route.ts:32, :99-115
Token refresh under a connection lock	packages/trpc/src/router/integration/linear/refresh.ts:25-107
Settings UI cards	.../settings/integrations/components/IntegrationsSettings/IntegrationsSettings.tsx:49-56, :122-141

Two things that fall out for free:

• syncTask already skips providers with no endpoint rather than throwing (sync/tasks.ts:32-35), so adding a Jira row to PROVIDER_ENDPOINTS is the whole dispatch change.
• The branch-name ask needs no new code. deriveBranchName already prefers tasks.branch over the generated slug (apps/desktop/src/renderer/routes/_authenticated/utils/deriveBranchName/deriveBranchName.ts:12-29) — it exists precisely so Linear's autolink format survives. Populating tasks.branch with PROJ-123-summary during sync makes Jira's development panel light up, with no UI change.

Where the Linear shape does not carry over

These are the parts worth designing before writing code:

1. One connection per (org, provider). unique("integration_connections_unique") at schema.ts:216-219. An Atlassian 3LO token grants access to multiple Jira sites (cloudIds), and multi-site instances are common in exactly the large orgs this request targets. Storing the chosen cloudId in JiraConfig and scoping v1 to a single site fits the existing constraint; supporting several sites per org means changing that unique index.

2. Status write-back is structurally different. Linear resolves a target state by name (findLinearState, jobs/sync-task/route.ts:129-131). Jira has no equivalent — transitions are per-issue, id-based, and depend on the issue's current workflow position, so you must call the issue's /transitions endpoint and match at write time. A cached status id will silently fail on issues whose workflow doesn't offer that transition. Also, taskStatuses is unique on (organizationId, externalProvider, externalId) (schema.ts:83-87) while Jira statuses are project/workflow-scoped, so per-project workflows can collide unless the external id is namespaced. Jira's statusCategory (new/indeterminate/done) maps cleanly onto taskStatuses.type.

3. Disconnect cleanup is ~70 lines that would be copy-pasted. linear.ts:50-118 deletes provider tasks, remaps orphaned statuses to defaults, then drops the connection. Adding a second provider is the right moment to extract that as a shared helper rather than fork it.

4. The PR open/merge write-back has no existing implementation for any provider. I looked for a PR→task status automation and found none: tasks.prUrl is only ever set manually via CLI/MCP/tRPC (packages/cli/src/commands/tasks/update/command.ts:52, packages/mcp/src/tools/tasks/update.ts:22, packages/trpc/src/router/task/schema.ts:26). Nothing consumes githubPullRequests events to transition a task. So that bullet isn't Jira work at all — it's a missing linkage that Linear lacks too, and it would probably land better as its own issue that both providers then inherit.

5. Atlassian access tokens last ~1h with rotating refresh tokens, versus Linear's much longer expiry. The existing withConnectionLock + REFRESH_BUFFER_MS design in refresh.ts is reusable as-is and becomes more load-bearing here — concurrent jobs racing a rotating refresh token is the failure mode to watch.

Verifying / testing

There's no bug to reproduce. To confirm the gap as described, a maintainer can check that packages/db/src/schema/enums.ts:26 has no jira member and that PROVIDER_ENDPOINTS in sync/tasks.ts has only a linear key — those two are sufficient.

For implementation, the units that are testable without a live Jira instance and worth covering first: status-category → taskStatuses.type mapping, Jira priority → taskPriority, issue key → branch name, and the transition resolver against a recorded /transitions payload (including the case where the desired transition isn't available). Existing sync/route tests to model against: packages/db/src/task-list-query.test.ts and apps/api/src/app/api/integrations/slack/events/route.test.ts.

Suggested direction

Scoping to Jira Cloud only, one site per org, with a JQL filter in JiraConfig, matches both the request and the current schema constraints, and the Linear directory structure transfers almost directly for connect/callback/refresh/initial-sync/webhook. The two things I'd flag as not-as-simple-as-it-looks are the per-issue transition model in item 2 and the fact that item 4 is a prerequisite that doesn't exist yet — I'd suggest splitting that one out so it isn't blocking the read/sync half, which is the part that unblocks the reported workaround pain.

(Maintainers: I'm an automated triage pass — I read the code but haven't run anything, and the prioritisation call here is yours.)