-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Policy members keyed by accountID #20397
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
Policy members keyed by accountID #20397
Conversation
Beamanator
left a comment
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.
So it looks like some things we'll need to do next are:
- Stop needing to map emails to accountIDs in onyx (in
${ONYXKEYS.COLLECTION.WORKSPACE_INVITE_MEMBERS_DRAFT}${policyID}& elsewhere) - Make sure linting & tests work
- Work out the kinks & bugs
|
|
||
| /** The employee list of all policies (coming from Onyx) */ | ||
| policiesMemberList: PropTypes.objectOf(policyMemberPropType), | ||
| allPolicyMembers: PropTypes.objectOf(PropTypes.objectOf(policyMemberPropType)), |
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.
NAB - I feel like policyMembers could be a slightly more appropriate new variable since that exactly matches the new onyx key.
- Now I realize it's cuz we're getting ALL of them. like your variable explains. I'll shut up 😬
Also, why PropTypes.objectOf(PropTypes.objectOf(? I think we can keep just PropTypes.objectOf( right?
- Also now I think it makes sense since this is an object of collections 😬
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.
Maybe update the comment like you did somewhere below: /** A collection of objects for all policies which key policy member objects by accountIDs */
| /** | ||
| * Checks if we have any errors stored within the POLICY_MEMBER_LIST. Determines whether we should show a red brick road error or not. | ||
| * Data structure: {email: {role:'user', errors: []}, email2: {role:'admin', errors: [{1231312313: 'Unable to do X'}]}, ...} | ||
| * Checks if we have any errors stored within the POLICY_MEMBERS. Determines whether we should show a red brick road error or not. |
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.
NAB
| * Checks if we have any errors stored within the POLICY_MEMBERS. Determines whether we should show a red brick road error or not. | |
| * Checks if we have any errors stored within the POLICY_MEMBERS list. Determines whether we should show a red brick road error or not. |
| function getPolicyBrickRoadIndicatorStatus(policy, policyMembersCollection) { | ||
| const policyMembers = lodashGet(policyMembersCollection, `${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${policy.id}`, {}); |
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.
This seems like a good place to use allPolicyMembers since it's literally all policy members collections, right?
| function getPolicyBrickRoadIndicatorStatus(policy, policyMembersCollection) { | |
| const policyMembers = lodashGet(policyMembersCollection, `${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${policy.id}`, {}); | |
| function getPolicyBrickRoadIndicatorStatus(policy, allPolicyMembers) { | |
| const policyMembers = lodashGet(allPolicyMembers, `${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${policy.id}`, {}); |
| * | ||
| * We only return members without errors. Otherwise, the members with errors would immediately be removed before the user has a chance to read the error. | ||
| */ | ||
| function getClientPolicyMemberEmailsToAccountIDs(policyMembers, personalDetails) { |
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.
What will it take for us to be able to get rid of this?
| value: _.object(accountIDs, Array(members.length).fill({errors: ErrorUtils.getMicroSecondOnyxError('workspace.people.error.genericRemove')})), | ||
| }, | ||
| ]; | ||
| API.write( |
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.
We should eventually change emailList to accountIDList in the API command param, right? Is there an issue for this already?
| * @returns {Object} - object with onyxSuccessData, onyxOptimisticData, and optimisticReportIDs (map login to reportID) | ||
| */ | ||
| function createPolicyExpenseChats(policyID, members, betas) { | ||
| function createPolicyExpenseChats(policyID, invitedEmailsToAccountIDs, betas) { |
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.
aah looks like lint caught here - we still use members in this function
|
Merging b/c I want to get everything on the |
|
@sobitneupane @arosiclair One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
Oh lol ok I wasn't expecting you to merge this quite yet. Anyways no problem, I'll be planning to finish up the rest of this migration with another PR. |
|
🚀 Deployed to staging by https://github.com/Beamanator in version: 1.3.29-0 🚀
|
|
🚀 Deployed to production by https://github.com/luacmartins in version: 1.3.29-11 🚀
|
| const details = lodashGet(this.props.personalDetails, email, {displayName: email, login: email}); | ||
| const details = this.props.personalDetails[accountID]; | ||
| if (!details) { | ||
| Log.hmmm(`[WorkspaceMembersPage] no personal details found for policy member with accountID: ${accountID}`); | ||
| return; | ||
| } |
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.
This caused a regression #22442. When we add a new user offline we didn't set their optimistic data in personalDetails but we used the fallback object (the one in lodashGet). Now neither is available which made the offline behaviour broken (user not added to the members list).
Details
Fixed Issues
$ #20211
PROPOSAL: GH_LINK_ISSUE(COMMENT)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
Mobile Web - Chrome
Mobile Web - Safari
Desktop
iOS
Android