feat(backend): tenant support for wallet address (#3114) #3152
Conversation
…nanted-wallet-addresses
github-actions
bot
added
type: tests
koekiebox
changed the title
koekiebox
changed the base branch from
2893/multi-tenancy-v1
to
nl/3123/backend-tenant-service
# Conflicts: # packages/backend/src/app.ts # packages/backend/src/config/app.ts # packages/backend/src/tenants/service.test.ts # packages/backend/src/tests/tableManager.ts
packages/backend/migrations/20241203112902_add_tenant_to_wallet_address.js
Outdated
Show resolved
Hide resolved
# Conflicts: # packages/backend/src/graphql/resolvers/walletAddressKey.test.ts
localenv/mock-account-servicing-entity/app/lib/parse_config.server.ts
Outdated
Show resolved
Hide resolved
| @@ -27,6 +27,5 @@ export const CONFIG: Config = { | |||
| authServerDomain: process.env.AUTH_SERVER_DOMAIN || 'http://localhost:3006', | |||
| graphqlUrl: process.env.GRAPHQL_URL, | |||
| idpSecret: process.env.IDP_SECRET, | |||
| operatorTenantId: | |||
| process.env.OPERATOR_TENANT_ID || '438fa74a-fa7d-4317-9ced-dde32ece1787' | |||
| operatorTenantId: process.env.OPERATOR_TENANT_ID || '' | |||
There was a problem hiding this comment.
we should probably make this required (throw if not provided)
| @@ -634,6 +694,68 @@ describe('Wallet Address Resolvers', (): void => { | |||
| ) | |||
| } | |||
| }) | |||
|
|
|||
| test('bad input data when not allowed to perform cross tenant update', async (): Promise<void> => { | |||
| try { | |||
There was a problem hiding this comment.
ditto with the expect.assertions(...) here as well
| return { | ||
| ...tenantApiSignatureResult, | ||
| container: this.container, | ||
| logger: await this.container.use('logger') | ||
| logger: await this.container.use('logger'), | ||
| forTenantId: this.config.operatorTenantId |
There was a problem hiding this comment.
Including the operator id by default feels less safe, we should either let it be undefined (and just declare this as the TenantedApolloContext, or have ForTenantIdContext let tenantId be undefined)
| .filter( | ||
| (wa: WalletAddress) => | ||
| tenantIdToProceed(ctx.isOperator, ctx.tenant.id, wa.tenantId) != | ||
| undefined | ||
| ) |
There was a problem hiding this comment.
I'm not sure if this works from the client perspective, since we could get into a situation where we set the limit to be e.g. 20 and then because of the filter, end up filtering out a few results. Then we have a situation where we got 15 results, but hasNextPage is still true.
There was a problem hiding this comment.
Maybe we can have the service methods be able to take in a list of tenantIds? That way we can pass in both the operator tenant id and the (on behalf id if necessary)
There was a problem hiding this comment.
@mkurapov, I agree with your first statement. Then the second, I was thinking the opposite. We make the tenantId an optional argument for the WalletAddressesConnection.
This enables us to do the following:
- When the
args.input.tenantIdis set, we do the usualctx.forTenantId- This allows for specific tenant paging when the operator is permitted - When the caller
isOperatorandargs.input.tenantIdis not provided, "default" paging is performed wheretenantIdis undefined and not part of the selection criteria - When the caller
!isOperator, then we always use:ctx.forTenantId- this enforces that the caller is only able to see their own tenant data
Again, we can determine most of this from the resolver. So that we only need to update getPage to have an optional parameter for tenantId.
Changes proposed in this pull request
Context
Checklist
fixes #numberuser-docslabel (if necessary)