Skip to content

Guard role grant emission behind WillSyncResourceType#31

Open
laurenleach wants to merge 1 commit into
mainfrom
lauren.leach/guard-role-grant-emission
Open

Guard role grant emission behind WillSyncResourceType#31
laurenleach wants to merge 1 commit into
mainfrom
lauren.leach/guard-role-grant-emission

Conversation

@laurenleach

Copy link
Copy Markdown

Summary

  • userResourceType.Grants() (pkg/connector/users.go) emits role grants as a sync optimization since the JumpCloud user API response already includes the admin user's role — but it did so unconditionally, even when a customer's sync filter excludes the role resource type.
  • Gate the emission on cli.ConnectorOpts.WillSyncResourceType("role"), threaded from NewLambdaConnectorConnector.syncRolesnewUserBuilder. NewLambdaConnector already received *cli.ConnectorOpts but never used it.
  • When roles aren't synced, also mark the user resource type with SkipEntitlementsAndGrants (the user builder has no entitlements/grants of its own besides the gated role grants).
  • Follows the pattern from Only emit user grants (where we emit the role grants) if role resource type is enabled  baton-linear#55.

Test plan

  • go build ./...
  • go test ./...
  • Added pkg/connector/users_test.go:
    • TestUserGrants_RoleSyncFilter — asserts no grants (and no API call) when roles are filtered out, and a correct role grant when roles are synced (via an httptest.Server mocking the JumpCloud user-get endpoint).
    • TestNewUserBuilder_ResourceTypeAnnotations — asserts SkipEntitlementsAndGrants is set on the user resource type only when roles are filtered out.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

userResourceType.Grants() emits role grants as a sync optimization
(the user API response already includes role membership), but did so
unconditionally. When a customer's sync filter excludes roles, the
connector still emitted grants referencing an unsynced resource type.

Gate the emission on cli.ConnectorOpts.WillSyncResourceType("role"),
threaded from NewLambdaConnector through the Connector struct into the
user builder. Also mark the user resource type with
SkipEntitlementsAndGrants when roles aren't synced, since the user
builder has no entitlements/grants of its own otherwise.

Follows the pattern from ConductorOne/baton-linear#55.

Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
@laurenleach
laurenleach requested a review from a team July 24, 2026 20:10
@github-actions

Copy link
Copy Markdown
Contributor

Connector PR Review: Guard role grant emission behind WillSyncResourceType

Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base de099c1275eb.
Review mode: full
View review run

Review Summary

Scanned the full PR diff for security and correctness. The change gates the user builder's cross-type role grant emission behind cli.ConnectorOpts.WillSyncResourceType(RoleResourceTypeID), threaded cleanly from NewLambdaConnector -> Connector.syncRoles -> newUserBuilder. The gating logic is correct: the default-true fallback matches the SDK's "no explicit filter, sync all" semantics, proto.Clone is used so the shared global resourceTypeUser is not mutated, and SkipEntitlementsAndGrants is only added when roles are filtered out (no pre-existing annotations are lost since the type had none). Tests cover both branches and GetUserByID's nil-safe GetRoleName() getter keeps the untouched grant path safe. No dependency manifests changed. No new issues found.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

None.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

No blocking issues found.

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