fi: support uuid -> username mapping

[vnugent]

Issue #202

Incrementally move user profile data to our own db. The goal of this PR is to support syncing username from Auth0 to our db to enable mapping from user uuid to username.

• support user profile create/update
• support uuid -> username mapping
• restrict setting email field on profile creation
• introduce "builder service account" with elevated permissions to read user profile
• retire get username hack
• fix unit tests
• run job to create users collection in prod

[vnugent]

@zichongkao any idea why end-to-end tests are failing?

[zichongkao]

@zichongkao any idea why end-to-end tests are failing?

Basically in

openbeta-graphql/src/utils/testUtils.ts

Line 26 in 2589e6b

const jwtSpy = jest.spyOn(jwt, 'verify')

we mock jwt.verify's return value and the return value has no scope field. I made the middleware robust to not having scope. But in future, I'm sure we'll have to mock scope in the mocked response so that we can give isBuilder status for testing out user profile stuff.

[zichongkao]

I'll review the PR later this evening!

[vnugent]

I pulled your fix down. API tests are still failing inside queryAPI()

  ● areas API › queries › retrieves an area and lists associated organizations

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 500

      80 |         userUuid
      81 |       })
    > 82 |       expect(response.statusCode).toBe(200)
         |                                   ^

The response object:

{
        status: 500,
        text: '{"errors":[{"message":"Context creation failed: connect ECONNREFUSED 127.0.0.1:80","extensions":{"code":"INTERNAL_SERVER_ERROR"}}]}\n',
        method: 'POST',
        path: '/'
      }

      at Object.<anonymous> (src/__tests__/areas.ts:83:15)

  ● are

[zichongkao]

That's a bit surprising. They pass locally and on the automated checks. Is your .env in a good state? On my end, I don't see anything that is trying to connect to port 80.

[vnugent]

That's a bit surprising. They pass locally and on the automated checks. Is your .env in a good state? On my end, I don't see anything that is trying to connect to port 80.

You're right. I have a .env.local that overrides some of the DB values. All green now.

[zichongkao]

Looks good in general! I can see how adding username resolvers will help reduce frontend API calls in many places.

Many of the questions I raised are for my own learning.

The one product decision that might be worth discussing is whether to make usernames mandatory during sign-up. I'm leaning toward yes, especially since they are mutable so users can revisit them later if they don't like them. Otherwise the power of defaults is strong and users may just leave the auto-generated ones.

[zichongkao]

Thanks for fixing this!

[zichongkao]

Slightly confused too, since below we type this as a "NotUpdatableField", so how come we allow an updatedAt time?

[zichongkao]

Ok I understand now why we allow updatedAt. But still wondering why we list as a "NotUpdatableField".

[vnugent]

updatedAt: true: Mongo will set the value for you whenever there's an update
*Edit: in this case I simply want Mongo to create the updatedAt field for me. We want to set username update timestamp ourselves, but don't want API users to do it.