Only emit user grants (where we emit the license grants) if license resource type is enabled#32
Only emit user grants (where we emit the license grants) if license resource type is enabled#32laurenleach wants to merge 2 commits into
Conversation
…license resource type is enabled Zoom has no /licenses endpoint, so License is a derived resource type whose grants are emitted principal-side from userBuilder.Grants. When a customer's sync filter excludes the license resource type, those grants would target resources that were never listed, so the user syncer skips its grants pass entirely via SkipEntitlementsAndGrants. Users have no entitlements of their own, so the user resource type keeps skipping the entitlements pass in both cases. The skip annotation now lives on a per-builder clone of resourceTypeUser rather than the shared static var. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
||
| {/* AUTO-GENERATED:END - capabilities */} | ||
|
|
||
| Licenses are a derived resource type — Zoom exposes no `/licenses` endpoint, so license grants are emitted from the account sync using each user's Zoom license tier. If licenses are excluded from the connector's sync, accounts skip their grants pass entirely, since license grants are the only grants accounts emit. |
There was a problem hiding this comment.
🟡 Suggestion: This paragraph says license grants come "from the account sync" and that "accounts skip their grants pass," but the grants are actually emitted principal-side from userBuilder.Grants (see pkg/connector/user.go), and there is no account resource syncer. To match the code (and this PR's own description), it should read "user sync" / "users" instead of "account sync" / "accounts."
Connector PR Review: Only emit user grants (where we emit the license grants) if license resource type is enabledBlocking Issues: 0 | Suggestions: 2 | Threads Resolved: 0 Review SummaryScanned the full PR diff for security and correctness. The core change is sound: Security IssuesNone found. Correctness IssuesNone found. Suggestions
Prompt for AI agents |
Recent baton-sdk versions moved profile, status, icon, and created_at from the individual traits to attributes on Resource, deprecating the trait-level options. CI's staticcheck flags the old ones as SA1019. Following the same migration as ConductorOne/baton-procore#43: WithUserProfile / WithGroupProfile / WithRoleProfile -> WithResourceProfile WithStatus(v2.UserTrait_Status_STATUS_*) -> WithResourceStatus(v2.Status_RESOURCE_STATUS_*, "") userTrait.GetProfile() -> resource.GetProfile(res) The trait options move out of the trait slice and into the variadic ResourceOption list. Traits themselves are unchanged: users keep their email trait, groups keep GroupTrait, roles keep RoleTrait. resource.GetProfile falls back to the deprecated trait-level profile, so reads still work against data written by earlier connector versions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Connector PR Review: Only emit user grants (where we emit the license grants) if license resource type is enabledBlocking Issues: 0 | Suggestions: 2 | Threads Resolved: 0 Review SummaryScanned the full PR diff for security and correctness. The license-grant gating is sound: userBuilder clones resourceTypeUser via proto.Clone and adds SkipEntitlements (licenses synced) or SkipEntitlementsAndGrants (licenses excluded) without mutating the shared static var, and syncLicenses is correctly derived from WillSyncResourceType (true when no explicit filter is set). The trait-to-resource profile/status migration (WithResourceProfile / WithResourceStatus / GetProfile) uses APIs present in the vendored SDK, and a nil GetProfile result is safe because a nil struct AsMap call yields an empty map. No new issues found; the two suggestions below were flagged in a prior review and remain unaddressed in the current diff. Security IssuesNone found. Correctness IssuesNone found. Suggestions
Prompt for AI agents |
Only emit user grants (where we emit the license resource grants) if the license resource type is enabled.
Same shape as ConductorOne/baton-linear#55, applied to Zoom's derived License resource type.
Why
Zoom exposes no
/licensesendpoint, soLicenseis a derived resource type: its grants are emitted principal-side fromuserBuilder.Grantsusing theUser.typetier stashed in the user profile duringList. When a customer's sync filter excludes the license resource type, those grants would target resources that were never listed.What
main.goderivessyncLicensesfromcli.ConnectorOpts.WillSyncResourceType(connector.LicenseResourceTypeID)— true when licenses are explicitly selected or when no filter is set at all (e.g. local CLI runs) — and passes it toconnector.New.userBuildernow clonesresourceTypeUserand sets the skip annotation per-run instead of mutating the shared static var:SkipEntitlements(unchanged behavior; users have no entitlements of their own)SkipEntitlementsAndGrants(license grants are the only grants users emit)LicenseResourceTypeIDis exported somain.gocan reference it.baton_capabilities.jsonandconfig_schema.jsonare byte-identical to main, since the capabilities stub (NewForCapabilities, zero-valueskipLicenseGrants) still advertisesSkipEntitlementson the user resource type.docs/connector.mdx: wrapped the capabilities table in theAUTO-GENERATEDmarkers (the table contents already matchedbaton_capabilities.json) and documented the derived-license grant behavior.Testing
go build ./cmd/baton-zoom,go vet ./...,go test -mod=vendor ./...all pass.CapabilityPermissionsplus exactly one skip annotation (SkipEntitlementswhenskipLicenseGrants=false,SkipEntitlementsAndGrantswhen true), and the sharedresourceTypeUservar is left unmutated.docs/connector.mdxcompiles with@mdx-js/mdx.🤖 Generated with Claude Code