-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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: Cannot remove RBR when invite an invalid member to workspace #23157
Fix: Cannot remove RBR when invite an invalid member to workspace #23157
Conversation
@eVoloshchak Please 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] |
Bump @eVoloshchak |
Reviewer Checklist
Screenshots/VideosWebScreen.Recording.2023-07-25.at.16.15.36.movMobile Web - Chromescreen-20230725-161816.mp4Mobile Web - SafariScreen.Recording.2023-07-25.at.16.22.57.movDesktopScreen.Recording.2023-07-25.at.16.24.51.moviOSScreen.Recording.2023-07-25.at.16.21.38.movAndroidscreen-20230725-162044.mp4 |
src/libs/actions/Policy.js
Outdated
@@ -743,6 +773,13 @@ function clearAddMemberError(policyID, accountID) { | |||
Onyx.merge(`${ONYXKEYS.COLLECTION.POLICY_MEMBERS}${policyID}`, { | |||
[accountID]: null, | |||
}); | |||
|
|||
// Remove draft accountID | |||
if (accountID.toString().length >= 15) { |
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.
@tienifr, why do we delete it only if accountID.length >= 15?
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.
It's a "dummy" accountID
, generated locally by
Line 214 in d3a13d6
function generateAccountID(searchValue) { |
In other words, they're invalid account that we've just invited. Otherwise, even after dismissing the error, the invalid accounts still appear in the suggested invite list.
I don't know if there's already a function for checking "dummy" accountID
so I manually check based on length
.
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 would happen if we deleted accountID here no matter if it's the dummy one or not?
We will remove a valid accountID from PERSONAL_DETAILS_LIST, but will it be there after a refresh?
I'm basically wondering what would happen if in the future we had accountID's longer than 15
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.
How about adding isDummyAccount
(or sth else) into these account personal details when we create the optimisticPersonalDetails
?
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.
Yeah, that would be better, let's do that instead
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've updated that. Please check again.
dummy-account-compressed.mov
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.
Now that I think about it more, we shouldn't delete the account info when we dismiss an error. The error doesn't necessarily mean "This account is invalid", just that there was some kind of a problem when inviting the user.
We might want to add the ability to "clear" recent users if this is considered a problem, but I don't think this should be a part of this PR
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 that we're good with showing the invalid accounts in the invite suggestion list; and will implement another feature to clear that later?
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.
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.
Well that didn't get a lot of traction 😄
But still, it's 2 vs 1 in favor of removing the user, so let's leave it as it is, no changes needed, I'll finish the checklist shortly
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.
Looks good + tests well - one small question
src/libs/actions/Policy.js
Outdated
avatar: UserUtils.getDefaultAvatarURL(accountID), | ||
displayName: LocalePhoneNumber.formatPhoneNumber(memberLogin), | ||
login: OptionsListUtils.addSMSDomainIfPhoneNumber(memberLogin), | ||
isDummy: 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.
Do we actually need isDummy
? We are able to get the personalDetails to be removed in clearDeleteMemberError
clearAddMemberError
by accountID
. Tested locally and seemed to work fine without including this
(edited function name)
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.
Ah, I guess for the cases where we have an error we want to dismiss but where we don't want to remove that user from the policy details 🤔 Though... do we have a case like that? I don't think so?
If we do (and it's entirely possible I'm missing/unaware of some flow like that) I guess I would call this something a little more descriptive like isOptimisticDetails
/ isOptimisicData
or something like that.
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 error is cleared in clearAddMemberError
, not delete. The point is to remove the invalid personal details on clearing the error. Otherwise, those invalid details would still be shown in the invite suggestion page. And isDummy
is to check for those invalid ones. I've tried removing isDummy
but it didn't work.
Also, isOptimisticData
sounds great to me, thanks for the suggestion.
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.
Oops, sorry, you're right about that, I mistyped the function name. But the comment still holds, why do we need isDummy
/isOptimisticData
if we can remove the optimistically added member by accountID
?
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.
Hmm, sorry I might not understand your point. Inside clearAddMemberError
we only remove the accountID
from the policy's members list ONYXKEYS.COLLECTION.POLICY_MEMBERS
but we haven't remove it from personal details list, which we should do as explained above:
Otherwise, those invalid details would still be shown in the invite suggestion page
Also as you've mentioned here:
Tested locally and seemed to work fine without including this
Can you elaborate on the test you've made?
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.
No worries, I'm not explaining things very clearly 😅 Effectively, I'm not sure I understand why we need to include the isOptimisticData
value at all.
The logic you have here conditionally retrieves the personal details that match the accountID
and where isOptimisticData = true
, and then removes those details from ONYXKEYS.PERSONAL_DETAILS_LIST
, right?
But whenever we call clearAddMemberError
, we're going to want to update ONYXKEYS.PERSONAL_DETAILS_LIST
to remove the details for the provided accountID
, because that user won't have been added to the workspace successfully. We can do this based on accountID
alone, so why do we need isOptimisticData = true
as a condition to be met?
Hopefully, that's a bit clearer? Let me know if I'm misunderstanding something or if it's still unclear.
Can you elaborate on the test you've made?
Yeah, for sure. I just removed this line and adjusted this line to be as follows:
- if (lodashGet(allPersonalDetails, [accountID, 'isOptimisticData'])) {
+ if (lodashGet(allPersonalDetails, [accountID])) {
Then retested using the testing steps for this PR.
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.
Cool! Thanks for your patience and detailed explanation. At first we tried to only remove the "dummy" account personal details but there's no way to do it. But as mentioned above, we should remove all errored account from personal details list.
Please check again!
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.
One minor adjustment otherwise looks great
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 PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by https://github.com/NikkiWines in version: 1.3.47-0 🚀
|
Not passing staging QA :( |
🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.47-6 🚀
|
Details
Inviting an invalid member to the workspace returns an error (RBR) but we cannot remove that. This PR fixes that.
Fixed Issues
$ #22359
PROPOSAL: #22359 (comment)
Tests
+916541237890
for example)Offline tests
NA
QA Steps
+916541237890
for example)PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
this
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Web
Screen.Recording.2023-07-19.at.17.22.21.mov
Mobile Web - Chrome
video_2023-07-19_20-11-31.mp4
Mobile Web - Safari
Screen.Recording.2023-07-21.at.13.30.27.mov
Desktop
Screen.Recording.2023-07-19.at.20.14.18.mov
iOS
Screen.Recording.2023-07-19.at.20.16.48.mov
Android
Screen.Recording.2023-07-19.at.20.33.28.mov