feat(backend): add Bitbucket Cloud permission syncing#925
Merged
brendan-kellam merged 8 commits intomainfrom Feb 24, 2026
Merged
feat(backend): add Bitbucket Cloud permission syncing#925brendan-kellam merged 8 commits intomainfrom
brendan-kellam merged 8 commits intomainfrom
Conversation
Implements both repo-driven and user-driven permission syncing for Bitbucket Cloud repositories. Repo-driven syncing uses the explicit user permissions API; user-driven syncing fetches all private repos accessible to the authenticated user via their OAuth token. Also refactors RepoMetadata.codeHostMetadata to use a provider-keyed object (e.g. codeHostMetadata.bitbucketCloud) instead of a discriminated union with a redundant type field. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review infoConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
WalkthroughAdds Bitbucket Cloud permission-syncing: new Bitbucket client APIs and helpers, account- and repo-level syncer branches, repo metadata and types for Bitbucket, DB enum/column for permission source, constants and route updates, and documentation marking partial support and prerequisites. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Syncer as Permission Syncer
participant BBAPI as Bitbucket Cloud API
participant DB as Database
participant Accounts as Account Store
User->>Syncer: Trigger permission sync (bitbucket-cloud)
Syncer->>Syncer: Validate OAuth token / create client
Syncer->>BBAPI: Fetch authenticated user's repo UUIDs
BBAPI-->>Syncer: Return repo UUIDs
Syncer->>DB: Query local repos where external_codeHostType='bitbucketCloud' and external_id IN UUIDs
DB-->>Syncer: Return local repo IDs
Syncer->>BBAPI: For each repo, fetch explicit user permissions (paginated)
BBAPI-->>Syncer: Return permission entries
Syncer->>Accounts: Map Bitbucket account UUIDs -> local account IDs
Accounts-->>Syncer: Return account records
Syncer->>DB: Create/Update AccountToRepoPermission rows with source (ACCOUNT_DRIVEN or REPO_DRIVEN)
DB-->>Syncer: Acknowledge updates
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
packages/backend/src/repoCompileUtils.ts (1)
513-520:full_nameis split and the repo is cast twice — consider extracting variables.
full_name!.split('/')is called separately forworkspaceandrepoSlug, andrepo as BitbucketCloudRepositoryis repeated. Extracting these avoids the duplication and makes the intent clearer.♻️ Proposed refactor
-...(codeHostType === 'bitbucketCloud' ? { - codeHostMetadata: { - bitbucketCloud: { - workspace: (repo as BitbucketCloudRepository).full_name!.split('/')[0]!, - repoSlug: (repo as BitbucketCloudRepository).full_name!.split('/')[1]!, - } - } -} : {}), +...(codeHostType === 'bitbucketCloud' ? (() => { + const [workspace, repoSlug] = (repo as BitbucketCloudRepository).full_name!.split('/'); + return { codeHostMetadata: { bitbucketCloud: { workspace: workspace!, repoSlug: repoSlug! } } }; +})() : {}),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/repoCompileUtils.ts` around lines 513 - 520, The bitbucket Cloud branch currently calls (repo as BitbucketCloudRepository).full_name!.split('/') twice and repeats the cast; refactor by extracting the full_name once and splitting it into workspace and repoSlug variables before building codeHostMetadata. Concretely, inside the codeHostType === 'bitbucketCloud' branch get const fullName = (repo as BitbucketCloudRepository).full_name! and const [workspace, repoSlug] = fullName.split('/'), then use workspace and repoSlug when constructing codeHostMetadata to avoid duplicate casts and splits.packages/backend/src/ee/accountPermissionSyncer.ts (1)
271-288: Add upfront OAuth scope validation for Bitbucket Cloud, using thex-oauth-scopesresponse header.The Bitbucket Cloud branch lacks the upfront scope validation present in the GitHub and GitLab branches. Unlike those providers,
getReposForAuthenticatedBitbucketCloudUsercurrently makes an immediate API call without checking whether the token has the requiredrepositoryscope. If the scope is missing, users see a raw API error that is difficult to diagnose.Bitbucket Cloud does expose OAuth scopes via the
x-oauth-scopesresponse header (similar to GitHub'sX-OAuth-Scopes), available on any authenticated API request. Consider adding a lightweightgetBitbucketCloudOAuthScopesutility tobitbucket.tsthat makes an initial call to check the header, validates the presence of therepositoryscope, and throws a clear, actionable error message if it is missing—before attempting the full repository permission lookup.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/ee/accountPermissionSyncer.ts` around lines 271 - 288, Add an upfront Bitbucket Cloud OAuth scope validation before calling getReposForAuthenticatedBitbucketCloudUser: implement a lightweight helper getBitbucketCloudOAuthScopes in bitbucket.ts that issues a minimal authenticated request, reads the x-oauth-scopes header, verifies the presence of the repository scope, and throws a clear actionable Error if missing; then call getBitbucketCloudOAuthScopes(accessToken) in accountPermissionSyncer.ts (inside the bitbucket-cloud branch, before getReposForAuthenticatedBitbucketCloudUser) and only proceed to fetch repos and add repo.id to aggregatedRepoIds when the scope check passes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/backend/src/bitbucket.ts`:
- Around line 640-673: The implementation of
getReposForAuthenticatedBitbucketCloudUser currently returns all accessible
repos but the JSDoc promises "private repositories"; modify the function to
request repository.is_private from the Bitbucket Cloud API (add the fields
parameter to the apiClient.GET call inside the getPaginatedCloud call, e.g.
include "repository.is_private") and then filter the resulting permissions array
to only include entries where p.repository?.is_private === true before mapping
to { uuid: p.repository!.uuid }, keeping the return type the same;
alternatively, if you prefer not to filter, update the JSDoc to state that all
accessible repositories are returned (but do one or the other so implementation
and docs match).
In `@packages/backend/src/ee/accountPermissionSyncer.ts`:
- Line 270: The forEach callbacks that call aggregatedRepoIds.add(repo.id) are
written with concise arrow bodies which implicitly return the Set (causing
Biome's useIterableCallbackReturn error); update each repos.forEach(...)
callback (the occurrences around aggregatedRepoIds.add at the three sites) to
use a block body with an explicit statement (e.g. repos.forEach(repo => {
aggregatedRepoIds.add(repo.id); });) so the callback returns void—apply the same
change for the other two occurrences referenced in the comment.
In `@packages/backend/src/ee/repoPermissionSyncer.ts`:
- Around line 241-245: The current logic around repoMetadataSchema.safeParse in
repoPermissionSyncer.ts masks Zod parsing failures and throws a misleading
"missing required Bitbucket Cloud metadata" error; update the handling in the
block that computes parsedMetadata and bitbucketCloudMetadata so that if
parsedMetadata.success is false you capture and surface the parsing errors
(e.g., include parsedMetadata.error.format() or parsedMetadata.error.errors) in
the thrown Error or processLogger.error before throwing, and only throw the
existing workspace/repoSlug missing message when parsing succeeded but
codeHostMetadata?.bitbucketCloud is actually absent; modify the code around
parsedMetadata, bitbucketCloudMetadata, and the throw to distinguish parse
failures from missing fields.
---
Nitpick comments:
In `@packages/backend/src/ee/accountPermissionSyncer.ts`:
- Around line 271-288: Add an upfront Bitbucket Cloud OAuth scope validation
before calling getReposForAuthenticatedBitbucketCloudUser: implement a
lightweight helper getBitbucketCloudOAuthScopes in bitbucket.ts that issues a
minimal authenticated request, reads the x-oauth-scopes header, verifies the
presence of the repository scope, and throws a clear actionable Error if
missing; then call getBitbucketCloudOAuthScopes(accessToken) in
accountPermissionSyncer.ts (inside the bitbucket-cloud branch, before
getReposForAuthenticatedBitbucketCloudUser) and only proceed to fetch repos and
add repo.id to aggregatedRepoIds when the scope check passes.
In `@packages/backend/src/repoCompileUtils.ts`:
- Around line 513-520: The bitbucket Cloud branch currently calls (repo as
BitbucketCloudRepository).full_name!.split('/') twice and repeats the cast;
refactor by extracting the full_name once and splitting it into workspace and
repoSlug variables before building codeHostMetadata. Concretely, inside the
codeHostType === 'bitbucketCloud' branch get const fullName = (repo as
BitbucketCloudRepository).full_name! and const [workspace, repoSlug] =
fullName.split('/'), then use workspace and repoSlug when constructing
codeHostMetadata to avoid duplicate casts and splits.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
CHANGELOG.mddocs/docs/features/permission-syncing.mdxpackages/backend/src/bitbucket.tspackages/backend/src/constants.tspackages/backend/src/ee/accountPermissionSyncer.tspackages/backend/src/ee/repoPermissionSyncer.tspackages/backend/src/repoCompileUtils.tspackages/shared/src/types.tspackages/web/src/app/api/(server)/ee/permissionSyncStatus/route.ts
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/backend/src/utils.ts (1)
134-233:⚠️ Potential issue | 🟡 MinorRemove unnecessary
connectionConfigfromRepoAuthCredentialsreturn type.
connectionConfigcontains credentials and should not be included in the return object since callers only need authentication tokens/headers. Currently, it's unused byrepoIndexManager.tsand only accessed internally byrepoPermissionSyncer.ts. PassconnectionConfigseparately to the permission syncer or retrieve it on-demand instead of embedding it inRepoAuthCredentials.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/utils.ts` around lines 134 - 233, The function returning RepoAuthCredentials currently includes a sensitive connectionConfig in each branch (github/gitlab/gitea/bitbucket/azuredevops) — remove connectionConfig from all returned objects so RepoAuthCredentials only contains hostUrl, token, cloneUrlWithToken and/or authHeader; keep the logic that computes token (getTokenFromConfig) and clone URL (createGitCloneUrlWithToken) but stop embedding connection.config. Update callers: ensure repoIndexManager.ts does not rely on connectionConfig (it currently doesn't) and change repoPermissionSyncer.ts to accept the connectionConfig separately (pass connection.config from the caller or fetch it on-demand) so permission syncing still has access without leaking credentials in RepoAuthCredentials.
♻️ Duplicate comments (2)
packages/backend/src/ee/accountPermissionSyncer.ts (1)
270-270:⚠️ Potential issue | 🟡 MinorBiome lint: forEach callback should not return a value.
Use a block body to avoid the implicit return fromSet.prototype.add().🐛 Proposed fix
-repos.forEach(repo => aggregatedRepoIds.add(repo.id)); +repos.forEach(repo => { aggregatedRepoIds.add(repo.id); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/ee/accountPermissionSyncer.ts` at line 270, The forEach callback in accountPermissionSyncer.ts currently uses a concise arrow body that implicitly returns the value from Set.prototype.add(); change the callback to a block body so it does not return a value: replace the concise arrow in the repos.forEach(...) call (the one referencing repos and aggregatedRepoIds.add(repo.id)) with a block arrow that calls aggregatedRepoIds.add(repo.id); inside braces and no return.packages/backend/src/bitbucket.ts (1)
631-655:⚠️ Potential issue | 🟡 MinorAlign “private repos only” promise with implementation.
The JSDoc says private repos only, but the function returns all accessible repos. Either filter to private repos (requestrepository.is_private) or update the doc to reflect the actual behavior.✅ Possible fix (filter to private)
- const permissions = await getPaginatedCloud<CloudRepositoryPermission>(path, async (p, query) => { + const permissions = await getPaginatedCloud<CloudRepositoryPermission>(path, async (p, query) => { const response = await client.apiClient.GET(p, { - params: { query }, + params: { query: { ...query, fields: "values.repository.uuid,values.repository.is_private" } }, }); const { data, error } = response; if (error) { throw new Error(`Failed to get user repository permissions: ${JSON.stringify(error)}`); } return data; }); return permissions - .filter(p => p.repository?.uuid != null) + .filter(p => p.repository?.uuid != null && p.repository?.is_private === true) .map(p => ({ uuid: p.repository!.uuid as string }));Please verify the Bitbucket Cloud API supports
fieldsandrepository.is_privatefor this endpoint:Bitbucket Cloud REST API /user/permissions/repositories fields parameter repository.is_private🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/bitbucket.ts` around lines 631 - 655, The JSDoc for getReposForAuthenticatedBitbucketCloudUser claims it returns private repos only but the implementation returns all accessible repos; update the function to filter for private repos by either requesting the is_private field from the API and then filtering (use the CloudRepositoryPermission.repository.is_private property) or change the JSDoc to accurately state it returns all accessible repos—preferably implement the filter: include repository.is_private in the GET (via fields or params if supported) and then replace the final return with permissions.filter(p => p.repository?.is_private).map(p => ({ uuid: p.repository!.uuid as string })).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@packages/backend/src/utils.ts`:
- Around line 134-233: The function returning RepoAuthCredentials currently
includes a sensitive connectionConfig in each branch
(github/gitlab/gitea/bitbucket/azuredevops) — remove connectionConfig from all
returned objects so RepoAuthCredentials only contains hostUrl, token,
cloneUrlWithToken and/or authHeader; keep the logic that computes token
(getTokenFromConfig) and clone URL (createGitCloneUrlWithToken) but stop
embedding connection.config. Update callers: ensure repoIndexManager.ts does not
rely on connectionConfig (it currently doesn't) and change
repoPermissionSyncer.ts to accept the connectionConfig separately (pass
connection.config from the caller or fetch it on-demand) so permission syncing
still has access without leaking credentials in RepoAuthCredentials.
---
Duplicate comments:
In `@packages/backend/src/bitbucket.ts`:
- Around line 631-655: The JSDoc for getReposForAuthenticatedBitbucketCloudUser
claims it returns private repos only but the implementation returns all
accessible repos; update the function to filter for private repos by either
requesting the is_private field from the API and then filtering (use the
CloudRepositoryPermission.repository.is_private property) or change the JSDoc to
accurately state it returns all accessible repos—preferably implement the
filter: include repository.is_private in the GET (via fields or params if
supported) and then replace the final return with permissions.filter(p =>
p.repository?.is_private).map(p => ({ uuid: p.repository!.uuid as string })).
In `@packages/backend/src/ee/accountPermissionSyncer.ts`:
- Line 270: The forEach callback in accountPermissionSyncer.ts currently uses a
concise arrow body that implicitly returns the value from Set.prototype.add();
change the callback to a block body so it does not return a value: replace the
concise arrow in the repos.forEach(...) call (the one referencing repos and
aggregatedRepoIds.add(repo.id)) with a block arrow that calls
aggregatedRepoIds.add(repo.id); inside braces and no return.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/backend/src/bitbucket.tspackages/backend/src/ee/accountPermissionSyncer.tspackages/backend/src/ee/repoPermissionSyncer.tspackages/backend/src/types.tspackages/backend/src/utils.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/backend/src/ee/repoPermissionSyncer.ts
- Adds `PermissionSyncSource` enum (`ACCOUNT_DRIVEN` / `REPO_DRIVEN`) and `source` field to `AccountToRepoPermission` table (non-nullable, defaults to `ACCOUNT_DRIVEN`) - Both syncers now set `source` on all created permission records - Repo-driven syncer uses `isPartialSync` flag (true for Bitbucket Cloud) to only delete `REPO_DRIVEN` records on cleanup, preserving `ACCOUNT_DRIVEN` records from the account syncer - Adds `skipDuplicates: true` to repo-driven `createMany` to handle overlap between the two sync paths Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
packages/backend/src/ee/repoPermissionSyncer.ts (1)
259-263: SilentsafeParsefailure still produces a misleading error (lines 259-263).
parsedMetadata.success === falsecollapses silently —bitbucketCloudMetadatabecomesundefinedand the thrown error incorrectly implies the field was never set rather than that parsing failed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/ee/repoPermissionSyncer.ts` around lines 259 - 263, The current block uses repoMetadataSchema.safeParse and then treats missing bitbucketCloudMetadata the same as a parse failure, producing a misleading error; update the logic in repoPermissionSyncer.ts to first check parsedMetadata.success and if false throw or log a descriptive error using parsedMetadata.error (from repoMetadataSchema.safeParse) before accessing parsedMetadata.data, otherwise extract codeHostMetadata.bitbucketCloud into bitbucketCloudMetadata and only then throw the existing "missing required Bitbucket Cloud metadata" error if that specific field is absent; reference parsedMetadata, repoMetadataSchema.safeParse, bitbucketCloudMetadata, and the existing throw new Error call when making this change.packages/backend/src/ee/accountPermissionSyncer.ts (1)
270-270: Biome lint error:forEachcallback returns a non-void value (line 270).
Set.prototype.add()returns theSet, so the arrow-function body has an implicit non-void return. Biome flags this asuseIterableCallbackReturn. Use a block body to suppress the implicit return.🐛 Proposed fix
-repos.forEach(repo => aggregatedRepoIds.add(repo.id)); +repos.forEach(repo => { aggregatedRepoIds.add(repo.id); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/ee/accountPermissionSyncer.ts` at line 270, The forEach callback in accountPermissionSyncer.ts is implicitly returning the Set because it uses a concise arrow body (repos.forEach(repo => aggregatedRepoIds.add(repo.id))), triggering Biome's useIterableCallbackReturn lint; change the callback to a block body so it returns void (e.g., repos.forEach(repo => { aggregatedRepoIds.add(repo.id); })), or replace the forEach with an explicit loop (for (const repo of repos) aggregatedRepoIds.add(repo.id);) so aggregatedRepoIds.add(repo.id) does not produce an implicit return.
🧹 Nitpick comments (1)
packages/backend/src/ee/repoPermissionSyncer.ts (1)
252-255: Unsafeasassertion onconnectionConfig— prefer a runtime guard.
credentials.connectionConfig as BitbucketConnectionConfig | undefinedskips any runtime check. If the credential object carries a config for a different connection type (or a future refactor changes the shape), this cast silently succeeds and fails late with an opaque error. A discriminant check onconfig.typebefore use would be safer.🛡️ Proposed defensive guard
-const config = credentials.connectionConfig as BitbucketConnectionConfig | undefined; -if (!config) { - throw new Error(`No connection config found for repo ${id}`); -} +const rawConfig = credentials.connectionConfig; +if (!rawConfig || (rawConfig as BitbucketConnectionConfig).type !== 'bitbucket') { + throw new Error(`No valid Bitbucket connection config found for repo ${id}`); +} +const config = rawConfig as BitbucketConnectionConfig;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/backend/src/ee/repoPermissionSyncer.ts` around lines 252 - 255, Replace the unsafe cast of credentials.connectionConfig to BitbucketConnectionConfig with a runtime discriminant guard: check that credentials.connectionConfig exists and that its type/discriminant equals the Bitbucket connection type (e.g. config.type === 'bitbucket') before treating it as BitbucketConnectionConfig; if the check fails throw the existing error for repo id. Update the const named config (from credentials.connectionConfig) to be assigned only after this guard so downstream usage in repoPermissionSyncer (the variable config and the surrounding block that throws for missing config using id) operates on a properly validated BitbucketConnectionConfig.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/backend/src/ee/accountPermissionSyncer.ts`:
- Around line 271-292: The new concise-arrow forEach in the Bitbucket Cloud
branch causes the same Biome lint error; replace the repos.forEach(repo =>
aggregatedRepoIds.add(repo.id)) use with an explicit loop (e.g., for (const repo
of repos) { aggregatedRepoIds.add(repo.id); }) inside the
accountPermissionSyncer logic so the callback does not return a value; update
the block that calls createBitbucketCloudClient and
getReposForAuthenticatedBitbucketCloudUser and references bitbucketRepoUuids,
repos, and aggregatedRepoIds accordingly.
In `@packages/backend/src/ee/repoPermissionSyncer.ts`:
- Around line 286-291: Fix the typo in the comment inside
repoPermissionSyncer.ts where the returned object (accountIds and isPartialSync)
is documented; change "explicitly granted accesss to the repo" to "explicitly
granted access to the repo" (locate the comment near the return that constructs
accountIds from accounts and sets isPartialSync: true).
---
Duplicate comments:
In `@packages/backend/src/ee/accountPermissionSyncer.ts`:
- Line 270: The forEach callback in accountPermissionSyncer.ts is implicitly
returning the Set because it uses a concise arrow body (repos.forEach(repo =>
aggregatedRepoIds.add(repo.id))), triggering Biome's useIterableCallbackReturn
lint; change the callback to a block body so it returns void (e.g.,
repos.forEach(repo => { aggregatedRepoIds.add(repo.id); })), or replace the
forEach with an explicit loop (for (const repo of repos)
aggregatedRepoIds.add(repo.id);) so aggregatedRepoIds.add(repo.id) does not
produce an implicit return.
In `@packages/backend/src/ee/repoPermissionSyncer.ts`:
- Around line 259-263: The current block uses repoMetadataSchema.safeParse and
then treats missing bitbucketCloudMetadata the same as a parse failure,
producing a misleading error; update the logic in repoPermissionSyncer.ts to
first check parsedMetadata.success and if false throw or log a descriptive error
using parsedMetadata.error (from repoMetadataSchema.safeParse) before accessing
parsedMetadata.data, otherwise extract codeHostMetadata.bitbucketCloud into
bitbucketCloudMetadata and only then throw the existing "missing required
Bitbucket Cloud metadata" error if that specific field is absent; reference
parsedMetadata, repoMetadataSchema.safeParse, bitbucketCloudMetadata, and the
existing throw new Error call when making this change.
---
Nitpick comments:
In `@packages/backend/src/ee/repoPermissionSyncer.ts`:
- Around line 252-255: Replace the unsafe cast of credentials.connectionConfig
to BitbucketConnectionConfig with a runtime discriminant guard: check that
credentials.connectionConfig exists and that its type/discriminant equals the
Bitbucket connection type (e.g. config.type === 'bitbucket') before treating it
as BitbucketConnectionConfig; if the check fails throw the existing error for
repo id. Update the const named config (from credentials.connectionConfig) to be
assigned only after this guard so downstream usage in repoPermissionSyncer (the
variable config and the surrounding block that throws for missing config using
id) operates on a properly validated BitbucketConnectionConfig.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/backend/src/ee/accountPermissionSyncer.tspackages/backend/src/ee/repoPermissionSyncer.tspackages/db/prisma/migrations/20260224202008_add_source_field_to_account_to_repo_permission_table/migration.sqlpackages/db/prisma/schema.prisma
brendan-kellam
deleted the
brendan/bitbucket-cloud-permission-syncing
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GET /user/permissions/repositories)bitbucketCloudtoPERMISSION_SYNC_SUPPORTED_CODE_HOST_TYPESandbitbucket-cloudtoPERMISSION_SYNC_SUPPORTED_IDENTITY_PROVIDERSbitbucket-cloudto thepermissionSyncStatusroute so the UI correctly reflects pending sync stateRepoMetadata.codeHostMetadatafrom a discriminated union (with a redundanttypefield) to a provider-keyed object (e.g.codeHostMetadata.bitbucketCloud), making it cleaner to extend for future providerscodeHostMetadataduring repo compilation (fromfull_name) to avoid fragiledisplayNamestring parsingPermissionSyncSourceenum (ACCOUNT_DRIVEN/REPO_DRIVEN) and a non-nullablesourcefield toAccountToRepoPermission, so each permission record tracks which sync path created itisPartialSyncflag (true for Bitbucket Cloud) to only wipeREPO_DRIVENrecords on cleanup, preservingACCOUNT_DRIVENrecords set by the account syncer — necessary because the Bitbucket Cloud repo permissions API only returns directly-granted users, not those with access via groups or project membershipKnown limitation
Bitbucket Cloud's permissions API only returns explicitly granted user permissions. Access granted via:
...is not captured by repo-driven syncing. These users will still gain access via user-driven syncing, but with a delay up to
experiment_userDrivenPermissionSyncIntervalMs(default: 24h).Test plan
EXPERIMENT_EE_PERMISSION_SYNC_ENABLED=true🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores