feat: People API user provider + unified user model#120
Merged
Conversation
…erRef Move the mozcloudPeople provider block before the mozcloud root guard so it registers even when catalog.providers.mozcloud is absent. Update the module JSDoc to mention the people provider. Delete the unused userRef export from refs.ts.
…r future enrichment
…berships for non-members The previous edit based the query on the person directory but still grouped by m.value and ARRAY_AGG'd a STRUCT that is all-NULL for staff with no workgroup membership. That (a) is invalid SQL (p.email/p.name not grouped) and (b) would drop every non-member via schema validation. Group by p.email/p.name, move member_type='user' into the join, and IGNORE NULLS so non-members get an empty memberships array.
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
Adds a People entity provider that emits
Userentities in a newpeoplenamespace, sourced from BigQuery, and rewires the workgroup provider to reference those users in Groupspec.members. This is the precursor to Auth0 SSO — every user who can sign in needs aUserentity for the sign-in resolver to match.Design (sourcing)
We explored the CIS Person API but pivoted to BigQuery as the base source, because the provisioned CIS credential is scope-limited (
classification:workgroup:staff_only): its staff-filter endpoint 500s,staff_informationisn't readable, and itsprimary_emailis often a personal address — which can't match Auth0's@mozilla.comlogin claim. BigQuery'susersdata has clean@mozilla.comemails + names + GitHub identity, so it yields complete, SSO-resolvable entities with no fragile join.MozcloudPeopleEntityProvider— full-mutation provider over the BigQueryuserssource (workgroup_subgroup_members). Each row →user:people/<emailToUserName(email)>with displayName (name), email, GitHub annotations/link, and a gravatar picture. Nospec.memberOf(membership is derived from Groupspec.members).Userentities; sets each subgroup Group'sspec.membersto the sameuser:people/<emailToUserName(email)>refs, so membership resolves exactly.userToEntitiesremoved; dev guest resolver points atuser:people/….PersonApiSource(+ schema) — committed but unwired, reserved for a future best-effort avatar-enrichment pass.catalog.providers.mozcloudPeople.bigqueryUsers; theauth/apiBaseUrlblock is reserved (not read).Auth0
Resolves by
@mozilla.comemail (mozilla.org/email+spec.profile.email).Testing
Unit tests for the BigQuery
personToEntitytransform, the provider (full mutation, dedupe), the workgroup refactor (buildGroupMembers, no users emitted), and the reservedPersonApiSource. Full package suite 111 passing,package lintclean,tsc -p tsconfig.jsonexit 0.Follow-ups