-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new query getOrganizationsByEmailPaginated #172
base: master
Are you sure you want to change the base?
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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Quality Gate passedIssues Measures |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
@@ -40,6 +41,22 @@ export default class StorefrontPermissions extends AppGraphQLClient { | |||
}) | |||
} | |||
|
|||
public getOrganizationsByEmailPaginated = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@enzomerca I'm following the same approach of the getOrganizationsByEmail query
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @enzomerca
Is the same approach of the getOrganizationsByEmail query.
@@ -40,6 +41,22 @@ export default class StorefrontPermissions extends AppGraphQLClient { | |||
}) | |||
} | |||
|
|||
public getOrganizationsByEmailPaginated = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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? 🔗