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 |
| // 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.
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.
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.
@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.
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.
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.
Ya now I see it, sorry for getting confused before :D 👍
Beamanator
left a comment
There was a problem hiding this comment.
LGTM (assuming tests pass)
Beamanator
left a comment
There was a problem hiding this comment.
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