Add new query getOrganizationsByEmailPaginated - #172
Conversation
|
Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖 Please select which version do you want to release:
And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.
|
|
Beep boop 🤖 I noticed you didn't make any changes at the
In order to keep track, I'll create an issue if you decide now is not a good time
|
wender
left a comment
There was a problem hiding this comment.
Please run the Lint in the files changed to auto-fix the line-break issues?
If vtex setup don't install all dependencies, you need to run yarn in the root and node folder
|
enzomerca
left a comment
There was a problem hiding this comment.
A general comment: I would try to avoid using session data as much as possible in these new APIs as this would make it harder to use it in a headless scenario and in integrations where the system has no session token to provide on the call. (we can discuss offline if you have any concerns by removing the session token usage/verification)
| }) | ||
| } | ||
|
|
||
| public getOrganizationsByEmailPaginated = async ( |
There was a problem hiding this comment.
Do we need this function here and on the storefront-permissions app? (PR)
Can't we query Master Data directly from this app and avoid additional call to another app?
There was a problem hiding this comment.
@enzomerca I'm following the same approach of the getOrganizationsByEmail query
There was a problem hiding this comment.
Yes, but we are removing the cyclic dependencies, and this is one of them, and thinking about the domain and context, the storefront shouldn't know about the organization.
|
|
||
| if ( | ||
| (!adminUserAuthToken && | ||
| !checkUserPermission?.permissions.includes('add-sales-users-all')) || |
There was a problem hiding this comment.
why are we checking if the user has add-sales-users-all permission if this is just a getOrganizationsByEmail query?
There was a problem hiding this comment.
Hi @enzomerca
Is the same approach of the getOrganizationsByEmail query. If I'm not mistaken this is for the case of a query run through the webstore where there's no admin auth cookie.
| return null | ||
| }) | ||
|
|
||
| if (checkUserPermission?.permissions.includes('add-users-organization')) { |
There was a problem hiding this comment.
why are we checking if the user has add-users-organization permission if this is just a getOrganizationsByEmail query?
There was a problem hiding this comment.
Hi @enzomerca
Is the same approach of the getOrganizationsByEmail query. If I'm not mistaken this is for the case of a query run through the webstore where there's no admin auth cookie.
There was a problem hiding this comment.
Why don't you remove it to test? It appears to be a bug or old mistake.
| const orgId = | ||
| sessionData?.namespaces?.['storefront-permissions']?.organization | ||
| ?.value | ||
|
|
||
| if (!orgId) { | ||
| throw new Error('No permission for getting the organizations') | ||
| } | ||
|
|
||
| organizationFilters.push(orgId) |
There was a problem hiding this comment.
session will have just one org id, the current logged org, right? and below we are filtering the result to return only the orgs added to organizationsFilters, so the getOrganizationsByEmail would not return all the organizations for the given email in this case, right? (which would not make much sense as this is called getOrganizationsByEmail)
There was a problem hiding this comment.
Hi @enzomerca
Is the same approach of the getOrganizationsByEmail query. This is the case for the request from the storefront where there's no admin auth cookie.
There was a problem hiding this comment.
@vhaalmeida We would like to avoid old mistakes, and we have a lot of tasks to improve the source code and the B2B suite app implementations. So our advice is to adjust the rules to test.
| if (!(email?.length > 0)) { | ||
| email = sessionData?.namespaces?.profile?.email?.value | ||
| fromSession = true | ||
| } | ||
| } |
There was a problem hiding this comment.
the function is named getOrganizationsByEmail but we are allowing the user to not provide an email and get the email from the session. Who ever is going to call this API can do that on their side, right?
I prefer to remove this, make the email a required field and simplify the code.
There was a problem hiding this comment.
Hi @enzomerca
Is the same approach of the getOrganizationsByEmail query.
| }) | ||
| } | ||
|
|
||
| public getOrganizationsByEmailPaginated = async ( |
There was a problem hiding this comment.
Yes, but we are removing the cyclic dependencies, and this is one of them, and thinking about the domain and context, the storefront shouldn't know about the organization.
| return null | ||
| }) | ||
|
|
||
| if (checkUserPermission?.permissions.includes('add-users-organization')) { |
There was a problem hiding this comment.
Why don't you remove it to test? It appears to be a bug or old mistake.
| const orgId = | ||
| sessionData?.namespaces?.['storefront-permissions']?.organization | ||
| ?.value | ||
|
|
||
| if (!orgId) { | ||
| throw new Error('No permission for getting the organizations') | ||
| } | ||
|
|
||
| organizationFilters.push(orgId) |
There was a problem hiding this comment.
@vhaalmeida We would like to avoid old mistakes, and we have a lot of tasks to improve the source code and the B2B suite app implementations. So our advice is to adjust the rules to test.



What problem is this solving?
This new query will allow to retrieve the users' organizations paginated.
Currently when an user is associated to a big number of organizations is generating a timeout.
This PR should be merged only when this other one is merged: vtex-apps/storefront-permissions#157
How to test it?
Access https://timeoutsfp--jamalstore.myvtex.com/admin/graphql-ide
Run the query below in the b2b-organizations-graphql app
Workspace
Screenshots or example usage:
Describe alternatives you've considered, if any.
Related to / Depends on
vtex-apps/storefront-permissions#157
How does this PR make you feel? 🔗