Skip to content

fix(integrations): show family service accounts on every product they authenticate - #6102

Merged
waleedlatif1 merged 4 commits into
stagingfrom
worktree-jira-sa-naming
Jul 30, 2026
Merged

fix(integrations): show family service accounts on every product they authenticate#6102
waleedlatif1 merged 4 commits into
stagingfrom
worktree-jira-sa-naming

Conversation

@waleedlatif1

Copy link
Copy Markdown
Collaborator

Summary

  • Adding a service account from the Jira page produced a credential that showed up under neither Jira, Jira Service Management, nor Confluence — it was titled "Atlassian Service Account", lost its brand tile, and disappeared from every category filter. The same bug hid a Google service account everywhere except Gmail.
  • Root cause: one Atlassian token authenticates all three products, so it's modeled as an atlassian pseudo-provider. Display resolved through getServiceConfigByProviderId, which walks OAUTH_PROVIDERS in declaration order and therefore landed on that pseudo-service rather than on any product.
  • Credentials now match via credentialProviderMatchesService (a service's OAuth id or its service-account id), so a family credential lists on every product it powers.
  • New lib/integrations/credential-display.ts is the single resolver for catalog join, mark, and copy — replacing three duplicated lookups that keyed the catalog by OAuth service display name, which is exactly why the pseudo-service fell off the map.
  • "Family service account" is derived from the catalog (a service-account id serving >1 integration), not a hardcoded vendor list, so a new integration joining a family needs no edit here.
  • Service-account detail pages now title by credential name and subtitle with their reach; the connect form states that reach up front. Non-family credentials keep the service description they've always shown.
  • Second commit swaps Jira/Confluence to Atlassian's gradient marks alongside a new Atlassian mark. Visual-only, but it renders in ~60 files, so it's split out to stay independently revertable.

Type of Change

  • Bug fix

Testing

  • Coverage for all 22 service-account provider ids is pinned in credential-display.test.ts. 19 are byte-identical to before; only atlassian-service-account (nowhere -> confluence/jira/jira-service-management) and google-service-account (gmail-only -> all 13) move, and both converge on what the block credential picker already shipped via getServiceAccountProviderForProviderId.
  • A dedicated test asserts the index and the predicate the Connected list actually filters on cannot drift apart — verified it goes red when the fix is reverted, while the index-only tests stay green.
  • Full suite: 16497 passed, 1 pre-existing environmental failure (cloud-review-tools.test.ts needs a real rg binary; this change touches no files under executor/).
  • type-check, check:client-boundary, check:utils, check:bare-icons, check:icon-paths, check:api-validation, check:boundaries, check:react-query all pass.
  • No schema, migration, contract, or persisted-value changes — resolution is computed at render time from static config, so pre-existing credentials behave identically to new ones.
  • Not yet verified live — I don't have an Atlassian API token to mint a real service account, so the rendered result is unverified.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

… authenticate

An Atlassian API token authenticates Jira, Jira Service Management, and
Confluence alike, so it is modeled as an `atlassian` pseudo-provider whose
only service is named "Atlassian Service Account". Every credential display
surface resolved through `getServiceConfigByProviderId`, which walks
OAUTH_PROVIDERS in declaration order — so the credential resolved to that
pseudo-service instead of to any product.

The result: adding a service account from the Jira page, through a modal
titled "Add Jira service account", produced a credential that appeared under
neither Jira, JSM, nor Confluence, was titled "Atlassian Service Account" on
its detail page, and lost its brand tile and category on the list. The same
bug hid a Google service account everywhere except Gmail.

- match credentials with `credentialProviderMatchesService`, which accepts a
  service's OAuth id or its service-account id
- add `lib/integrations/credential-display.ts` as the single resolver for
  catalog join, mark, and copy, replacing three duplicated lookups that keyed
  the catalog by OAuth service *display name* — the reason the pseudo-service
  fell off the map
- derive "family service account" from the catalog (a service-account id
  serving >1 integration) rather than hardcoding vendors, so a new integration
  joining a family needs no edit
- title service-account detail pages by credential name, subtitle them with
  their reach, and state that reach up front on the connect form
- keep the service description as the detail subtitle for every non-family
  credential, unchanged

No schema, migration, contract, or persisted value changes; resolution is
computed at render time from static config. Coverage for all 22 service-account
provider ids is pinned in tests, including that the index and the predicate the
Connected list filters on cannot drift apart.
Replaces the flat #1868DB Jira and Confluence marks with Atlassian's gradient
versions, matching the Atlassian mark added alongside them.

- gradient ids go through `useId()` rather than the source SVGs' static ids,
  which would collide wherever two of these icons render on one page — the
  integrations list and the landing loops both do
- pads the Atlassian viewBox so its artwork fills ~78% of the box, matching the
  inset Atlassian ships on the Jira and Confluence marks; without it the mark
  renders ~30% heavier than its siblings in the same tile

Visual-only, but these marks render in ~60 files, so it is split from the
credential fix to stay independently revertable.
@vercel

vercel Bot commented Jul 30, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview Jul 30, 2026 8:41pm

Request Review

@cursor

cursor Bot commented Jul 30, 2026

Copy link
Copy Markdown

PR Summary

Medium Risk
Touches credential listing and matching across many integration UI surfaces; logic is well-tested but wrong matching would hide or mislabel production credentials.

Overview
Fixes family service accounts (one Atlassian token for Jira, Jira Service Management, and Confluence; one Google key for all Google integrations) disappearing from product integration pages after connect, and mislabeled as a single product.

Matching now uses credentialProviderMatchesService so a credential’s providerId can match a product’s OAuth id or its shared serviceAccountProviderId, instead of comparing resolved pseudo-service providerIds.

resolveCredentialDisplay in credential-display.ts centralizes catalog coverage, icons, subtitles, and detail copy so the integrations list, Cmd-K search, credential detail, and connect flows stay aligned. Family accounts show vendor identity (Atlassian / Google), corporate icons, and subtitles that spell out reach.

Connect surfaces use family name/icon via useServiceAccountConnectTarget; the Atlassian modal adds a catalog-derived coverage hint on the site domain field. Docs for Atlassian service accounts are updated for JSM and one-credential-across-three-products setup.

Includes Atlassian corporate icon and refreshed Jira/Confluence gradient marks (visual-only).

Reviewed by Cursor Bugbot for commit 14b5fa7. Configure here.

@greptile-apps

greptile-apps Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR centralizes credential presentation and broadens family service-account visibility across supported integrations.

  • Adds a shared resolver for credential catalog matching, branding, titles, subtitles, and family coverage.
  • Lists Atlassian and Google service accounts on every integration configured to accept their shared provider IDs.
  • Uses family-level names and icons in service-account connection and reconnection surfaces.
  • Updates Atlassian documentation and replaces Jira and Confluence marks with gradient variants.
  • Adds regression coverage for all registered service-account provider IDs.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
apps/sim/lib/integrations/credential-display.ts Introduces the shared, catalog-driven resolver for credential coverage, branding, and display copy.
apps/sim/lib/oauth/utils.ts Adds exact matching against both a service's OAuth provider ID and service-account provider ID.
apps/sim/app/workspace/[workspaceId]/integrations/[block]/integration-block-detail.tsx Uses the shared provider predicate so family credentials appear on each supported product page.
apps/sim/app/workspace/[workspaceId]/integrations/integrations.tsx Migrates connected credential rendering and search metadata to the shared display resolver.
apps/sim/app/workspace/[workspaceId]/integrations/connected/[credentialId]/connected-credential-detail.tsx Uses resolved family branding and credential-specific detail-page copy.
apps/sim/lib/integrations/credential-display.test.ts Pins provider coverage and verifies display behavior for family, single-product, OAuth, and unresolved credentials.
apps/sim/components/icons.tsx Adds the Atlassian corporate mark and updates Jira and Confluence SVG artwork.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Credential[Stored credential provider ID] --> Resolver[Credential display resolver]
  Resolver --> Registry[OAuth provider registry]
  Resolver --> Catalog[Integration catalog]
  Registry --> Match[Match OAuth or service-account provider ID]
  Catalog --> Coverage[Determine covered integrations]
  Match --> Display[Resolve family name and icon]
  Coverage --> Display
  Display --> List[Connected integrations list]
  Display --> Detail[Credential detail]
  Display --> Search[Integration search]
  Display --> Connect[Connect and reconnect modals]
Loading

Reviews (3): Last reviewed commit: "docs(atlassian): correct the service-acc..." | Re-trigger Greptile

…ough the shared target

The workflow editor's credential selector passed the OAuth service's own name
and icon straight to ConnectServiceAccountModal, so opening the setup form from
a Jira block titled it "Add Jira service account" while the integrations page
and the chat — both of which already resolve through
`useServiceAccountConnectTarget` — titled the same form "Add Atlassian service
account".

That is the exact confusion this branch set out to remove, surviving on the one
surface that bypassed the shared resolver.
@waleedlatif1

Copy link
Copy Markdown
Collaborator Author

@greptile

@waleedlatif1

Copy link
Copy Markdown
Collaborator Author

@cursor review

… three products

The setup section could not be followed. It sent readers to a "Settings →
Integrations tab" that does not exist (Integrations is a top-level workspace
module) and told them to search the integrations list for "Atlassian Service
Account", which matches no catalog entry — the catalog lists Jira, Jira Service
Management, and Confluence.

The page also described the credential as covering "Jira and Confluence" while
listing Jira Service Management scopes, and the product now spells the coverage
out in the connect form.

- correct the path: Integrations -> Jira/JSM/Confluence -> Add to Sim -> Add
  service account
- name all three products consistently, and state that one service account
  covers them
- match the real button label ("Add service account")
@waleedlatif1

Copy link
Copy Markdown
Collaborator Author

@greptile

@waleedlatif1

Copy link
Copy Markdown
Collaborator Author

@cursor review

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 14b5fa7. Configure here.

@waleedlatif1
waleedlatif1 merged commit 811a39e into staging Jul 30, 2026
26 of 27 checks passed
@waleedlatif1
waleedlatif1 deleted the worktree-jira-sa-naming branch July 30, 2026 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant