-
Notifications
You must be signed in to change notification settings - Fork 3.5k
fix: bug 2 for Personal details list migration #20661
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
fix: bug 2 for Personal details list migration #20661
Conversation
|
@neil-marcellini @thesahindia 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] |
|
I think this PR does not follow the usual review process, since it's related to a migration issue |
Reviewer Checklist
Screenshots/VideosWebMobile Web - ChromeMobile Web - SafariDesktopiOSAndroid |
src/libs/actions/Report.js
Outdated
| // Add optimistic personal details for new participants | ||
| const optimisticPersonalDetails = {}; | ||
| _.map(participantLoginList, (login, index) => { | ||
| optimisticPersonalDetails[newReportObject.participantAccountIDs[index]] = {login, displayName: login}; |
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.
I wonder if it's possible for participantLoginList to be in a different order than newReportObject.participantAccountIDs?
Wouldn't it be a bit safer to do something like: newReportObject.participantAccountIDs.findBy (match accountIDs)
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.
That's valid, but we can't do by findBy, since here we have two lists, participantLoginList = ['test@email.com', 'test+1@email.com'] and newReportObject.participantAccountIDs = [123123123, 345345345]. I think the best solution would be to pass an object keyed by account ID but for that it would be necessary to change the function params
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.
@Beamanator forgot to tag, but what do you think about changing the function to receive an object instead of an array of logins (comment above)
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.
Sorry I didn't see your response 🙃
Hmm actually looking at where we're calling openReport, I see that we basically create the optimistic participantAccountIDs for the new report in the same order we create the list of logins - so I don't really see how they could be mis-matched? Do you? I could have been over-thinking :D
One more thing: Should we add an avatar & accountID here?
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.
@BeeMargarida pinging you in case this helps 😅
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.
That was my logic, but this is taking into consideration that all openReport usages now and in the future will take that into consideration. For now I think it's fine, from what I see, all calls build userLogins using getLoginsByAccountIDs with participantAccountIDs or vice versa, so they should maintain the order.
Should we add an avatar & accountID here?
Perhaps it's better 😄 I'll add it
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.
Ya now I see it, sorry for getting confused before :D 👍
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.
LGTM (assuming tests pass)
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.
LGTM (I'll fix the lint error in the base branch)
|
🚀 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 🚀
|
Details
bug2: user details are missing on create new chat. Reported in slack here.
When creating a new chat with a random user (new), the personal details of that random user are not saved until they are received by a pusher event after the creation. We only have access to the user accountID and no data for it, so there's a pop-in of user data after creating the chat.
The fix was adding optimistic temporary user details for
PERSONAL_DETAILS_LISTinopenReportthat contains the user account ID and their login and displayName (equal to the login).Screen capture in Web.
Fixed Issues
$ Partially #19007
Tests
Offline tests
Should only show optimistic data
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
Screen.Recording.2023-06-13.at.11.12.15.mov
Mobile Web - Chrome
Mobile Web - Safari
Kapture.2023-06-16.at.15.52.36.mp4
Desktop
iOS
Android