Skip to content

fix(integrations): read every service mark from one registry - #6682

Open
waleedlatif1 wants to merge 4 commits into
stagingfrom
fix/integration-icon-registry
Open

fix(integrations): read every service mark from one registry#6682
waleedlatif1 wants to merge 4 commits into
stagingfrom
fix/integration-icon-registry

Conversation

@waleedlatif1

Copy link
Copy Markdown
Collaborator

Summary

  • OAUTH_PROVIDERS registers 93 service icons and no colour field at all, so every surface built on it drew a flat grey mark for a service whose block config already carries its brand icon and bgColor. That is the reported inconsistency: the same service is branded in suggested actions and grey in the connect dialog.
  • Adds resolveIntegrationBlockTypeForOAuth, mapping any OAuth id (service id, provider id, or an extra authorization server like Salesforce sandbox) to the catalog block behind it, so a credential surface holding only an OAuth identity can reach the registry.
  • The connect dialog now wears the block's tile. ChipModalHeader accepts a rendered mark so a tile can carry its own chrome instead of being tinted with the header's grey.
  • IntegrationTile resolved its fill from the registry but took its icon from whatever the caller passed — one tile, two sources. It now defaults to the registry, keeping an override for family service-account marks that genuinely are not the block's.
  • Its letter fallback read the catalog's bgColor while the tile beside it read the registry's; both go through the tile now.
  • Collapses the duplicates that grew around the gap: two getProviderIcon implementations (one tinted, one not) → one ProviderIcon; a connector tile duplicated verbatim across two KB surfaces → one ConnectorTile; permission rows that hardcoded text-white (white-on-white on a pale brand tile) → BlockTile.

Public pages keep their generated catalog — importing the registry there would ship 282 block configs to a marketing page, and integrations.json is generated from the same bgColor, so the two cannot drift.

Type of Change

  • Bug fix

Testing

bunx turbo run type-check clean across all 23 workspaces; lint clean; check:api-validation passes. 970 tests pass across blocks/, lib/integrations/, lib/oauth/, including new coverage asserting every OAuth integration in the catalog resolves to a block carrying both an icon and a fill — so the bridge can never paint an empty tile.

Not verified in a browser.

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)

A service looked like itself on the canvas and like nothing in particular
everywhere it was connected. `OAUTH_PROVIDERS` registers 93 icons and no colour
at all, so the surfaces built on it — the connect dialog above all — drew a flat
grey mark for a block whose config already carries its brand icon and `bgColor`.

Bridges the two: `resolveIntegrationBlockTypeForOAuth` maps any OAuth id (a
service id, a provider id, an extra authorization server) to the catalog block
behind it, so a credential surface holding only an OAuth identity can still
reach the registry. The connect dialog now wears the block's tile, and
`ChipModalHeader` takes a rendered mark so a tile can carry its own chrome
instead of being tinted with the header's grey.

Folds in the copies that had grown around the gap: `IntegrationTile` resolved
its fill from the registry but took its icon from whatever the caller passed —
one tile, two sources — and now defaults to the registry, with an override kept
for the family service-account marks that genuinely are not the block's. The
letter fallback it grew alongside was reading the catalog's `bgColor` while the
tile beside it read the registry's; both are the tile now. Two `getProviderIcon`
implementations for the same job (one tinted, one not) become one `ProviderIcon`,
the connector tile duplicated verbatim across two knowledge-base surfaces becomes
one `ConnectorTile`, and the permission rows that hardcoded `text-white` — which
renders white-on-white on a pale brand tile — go through `BlockTile`.

Public pages keep their generated catalog: importing the registry there would
ship 282 block configs to a marketing page, and `integrations.json` is generated
from the same `bgColor`, so the two cannot drift.
@vercel

vercel Bot commented Aug 13, 2026

Copy link
Copy Markdown

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

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Aug 14, 2026 12:10am

Request Review

@cursor

cursor Bot commented Aug 13, 2026

Copy link
Copy Markdown

PR Summary

Medium Risk
Wide UI refactor across integrations, OAuth connect flows, and copilot input with large deleted mention-menu code; tests cover OAuth resolution but browser behavior is noted as unverified.

Overview
Unifies integration and OAuth marks so credential surfaces read the block registry (icon + bgColor) instead of grey OAUTH_PROVIDERS icons.

Registry bridge: Adds resolveIntegrationBlockTypeForOAuth to map OAuth service/provider ids to catalog block types (ambiguous shared ids like google-drive / jira intentionally return nothing). The connect OAuth modal header uses BlockTile when a block type resolves; ChipModalHeader now accepts a rendered element so brand tiles are not forced to the header’s grey icon style.

Shared tiles: IntegrationTile defaults icon from getBlockTileIcon; ProviderIcon and ConnectorTile replace duplicated inline styling. Integration lists, suggested actions, KB connectors, permission groups, and credential selectors route through these components. Shared accent constants (DEFAULT_BLOCK_TILE_COLOR, VARIABLE_TILE_COLOR) replace ad hoc greys in logs, terminal, toolbar, tag dropdown, and preview.

Cleanup: Removes unused copilot @ mention stack (useMentionData, folder keyboard handlers, caret overlay resize, and related constants). Table workflow-output column headers keep icon-only metadata (no duplicate bgColor on plain column icons).

Reviewed by Cursor Bugbot for commit b724b08. Configure here.

@greptile-apps

greptile-apps Bot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR centralizes integration marks and tile colors around the block registry while safely declining ambiguous OAuth-to-block mappings.

  • Adds an OAuth identity-to-block resolver covering service IDs, provider IDs, and additional authorization servers.
  • Updates OAuth dialogs, integration surfaces, credential selectors, and knowledge connectors to use shared tile and icon components.
  • Adds catalog-wide tests for resolver coverage, collision handling, and renderable icon/color metadata.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
apps/sim/lib/integrations/oauth-service.ts Builds a collision-aware OAuth-key index that omits shared Google Drive and Jira identities rather than selecting the wrong sibling block.
apps/sim/lib/integrations/oauth-service.test.ts Covers unique IDs, shared-ID rejection, additional authorization servers, catalog completeness, and tile metadata.
apps/sim/app/workspace/[workspaceId]/components/connect-oauth-modal/connect-oauth-modal.tsx Resolves registry-backed header tiles while retaining the existing provider mark when an OAuth identity is ambiguous.
apps/sim/blocks/accent.ts Consolidates registry-backed block tile icon and color resolution for consuming UI surfaces.
packages/emcn/src/components/chip-modal/chip-modal.tsx Extends the modal header to accept a rendered mark so registry-styled tiles can preserve their own presentation.

Reviews (2): Last reviewed commit: "fix(integrations): never answer with a s..." | Re-trigger Greptile

Comment thread apps/sim/lib/integrations/oauth-service.ts
Sweeping the surfaces above turned up colour data nothing reads and colour data
two surfaces disagreed on.

Dead: `BLOCK_COLORS.DEFAULT/LOOP/PARALLEL` in the tag dropdown (only `VARIABLE`
was ever referenced), `BlockIconInfo.color` on table columns — whose consumer
documents that it deliberately ignores the colour, so the `#2F55FF` behind it
could never render — and the `bgColor` threaded into the add-resource dropdown,
whose row renders a bare tinted icon.

Disagreeing: the Variables tile is `#2F8BFF` in the tag dropdown and `#8B5CF6`
in the preview panel, for the same "V" on the same concept. Both now read
`VARIABLE_TILE_COLOR`, and the preview panel's two hand-rolled squares become
`BlockTile` like every other tile.

Four spellings of the neutral fallback (`#6B7280`, `#6b7280`, `#666666`, and a
`cancelled` status that happened to equal it) now point at
`DEFAULT_BLOCK_TILE_COLOR`.

The terminal and logs resolvers stay. They look like duplicates of `accent.ts`
but carry behaviour it does not have — status fills for synthesized
error/validation/cancelled rows, near-black contrast correction, MCP tool-id
parsing, and a model-provider branch — so folding them in is a behavioural
change, not a deletion.
The workflow panel's copilot tab renders `MothershipChat`, and that component
brings its own input — so `panel/components/copilot` no longer holds a
component at all, only the hook library the old input used. Five of those hooks
have no caller anywhere: `useMentionData`, `useMentionKeyboard`,
`useCaretViewport`, `useMentionInsertHandlers`, `useTextareaAutoResize`.

They are not all of it. `home/components/user-input` still imports
`useFileAttachments`, `useMentionMenu`, `useMentionTokens`,
`useContextManagement`, and `useIntegrationAutoMention` from this directory,
so it survives as a shared hook library rather than dead weight — which is why
this removes the uncalled five rather than the folder.

What they alone reached goes with them: `getFolderData` / `getFolderLoading` /
`getFolderEnsureLoaded` and the `FOLDER_CONFIGS` table describing every mention
folder, `buildMentionHighlightNodes`, the `MentionFolderNav` type, and the
slash-command tables. Of the 266-line constants file only `SCROLL_TOLERANCE`
had a live reader left.
Two integrations can share one OAuth id: Google Slides is authenticated by
Drive's `google-drive` service and Jira Service Management by Jira's `jira`.
Indexing first-write-wins made those ids resolve to whichever sorted first, so
the dialog connecting Slides could wear Drive's brand.

An id claimed by more than one block type now resolves to neither, and the
caller keeps the service-specific mark it already had. A wrong brand is worse
than no tile.
@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 b724b08. Configure here.

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