-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Optimistically create policy expense chats for new members of workspaces #16764
Optimistically create policy expense chats for new members of workspaces #16764
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
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.
Just one small thing from me that you can change or leave as is, I don't have a strong opinion.
Tested on desktop and 👍 :chef-kiss:
const membersListKey = `${ONYXKEYS.COLLECTION.POLICY_MEMBER_LIST}${policyID}`; | ||
const logins = _.map(memberLogins, memberLogin => OptionsListUtils.addSMSDomainIfPhoneNumber(memberLogin)); | ||
|
||
// create onyx data for policy expense chats for each new member | ||
const membersChats = createPolicyExpenseChats(policyID, logins, 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.
NAB maybe a better variable name would be like membersChatData
oh sorry forgot this PR. reviewing now |
all you @0xmiroslav let me know if you need help with the checklist. |
@robertKozik can you please merge from |
e6d32a5
to
f3eb8ac
Compare
@0xmiroslav rebased, so should be up to date |
BUG: multiple workspace chats are created for the same user bug.mov |
@bondydaa should we also cross-out workspace chat when remove user from workspace offline? |
src/libs/actions/Policy.js
Outdated
onyxSuccessData: [], | ||
onyxOptimisticData: [], | ||
optimisticReportIDs: {}, |
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 need failureData here?
src/libs/actions/Policy.js
Outdated
onyxMethod: CONST.ONYX.METHOD.MERGE, | ||
key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticReport.reportID}`, | ||
value: { | ||
isLoadingReportActions: false, |
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.
Is this necessary?
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 was modelling that on creating report inside Report.js
file in function openReport
(393:400 lines). If you think it can be ommited I'll remove 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.
If not needed, let's remove
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 like false
is the default here
App/src/pages/home/ReportScreen.js
Line 96 in 64f4a78
isLoadingReportActions: false, |
and it's used here
App/src/pages/home/ReportScreen.js
Line 228 in 64f4a78
const isLoadingInitialReportActions = _.isEmpty(this.props.reportActions) && this.props.report.isLoadingReportActions; |
as well as here
src/pages/home/report/ReportActionsList.js
180: if (this.props.report.isLoadingReportActions && lastReportAction.actionName !== CONST.REPORT.ACTIONS.TYPE.CREATED) {
src/pages/home/report/ReportActionsView.js
134: if (nextProps.report.isLoadingReportActions !== this.props.report.isLoadingReportActions) {
Seems like it can probably be removed.
Hmm I didn't considered that scenario initially. I think let's try to keep the scope of this PR small and only focused on the |
@bondydaa are you able to reproduce this one? |
I didn't see more than 1 when I tested yesterday on desktop but let me try again. Did you only add 1 member while offline? Or multiple? I think I tested adding 2 users but not just a single user so I'll try both. |
I tried only one. Please try to repeat adding/removing the same user. |
Hmm yeah I am seeing some weird things when you remove the user while offline. Steps are like:
Though I think this is related more to removing a user vs adding a user so I think we handle that in the follow up GH for |
@0xmiroslav @bondydaa I came up with quicker fix, as after removing the user chat remains as edit: @bondydaa I was testing it with following steps:
I came across one more problem though @bondydaa . Now we are passing only the reportID and It's merging into one as it should. But as we are not passing the created report action ID, when user clicks the created chat after coming back online we have double welcome notice. I think we should also pass the reportActionID as it is done when creating normal chat
|
I created this #17137 for the follow up issue. Let's keep adding reproduce steps for things we see related to removing a user from the workspace / |
hmm nope still nodda locally for me, let me switch my new dot to staging as well and see if that does it since the workspace name change offline still reverted back. |
@bondydaa please add |
yeah even against staging I'm still seeing the optimistic Expense Policy Chats being created. 2023-04-26_17-01-00.mp4 |
okay kicked off a build for this, workflow is here https://github.com/Expensify/App/actions/runs/4814233404. I guess a QR code should show up in like an hour or so? |
QR code should show up in a few hrs. I will test this tomorrow. |
🧪🧪 Use the links below to test this build in android and iOS. Happy testing! 🧪🧪 |
All tests well but one issue: members.mov |
Great catch, fixed 🔧 scree-bug.mov |
} | ||
|
||
_.each(members, (login) => { | ||
const oldChat = ReportUtils.getChatByParticipantsAndPolicy([sessionEmail, login], policyID); |
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 for now since I think workspaces can only allow 1 admin anyways but as we expand to allow multiple admins this will break and only add the admin of the current user.
I think the members
variable we pass to this method should have all users on the workspace right? I wonder if we could run something to check if they are a workspace admin and then add them to this array?
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.
members
variable stores only users which are going to be add to the workspace. But we can get the policy members from Onyx store and filter out members to get all admins. The downside is that while being offline there is possibility of not having this info stored, so we would still fallback to the [newMember, ourMail]
situation like 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.
It shouldn't be difficult to implement, so If you think it should support multiple admins already, I'm happy to help
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 I think this is probably better as is for now, if/when we start allowing more than 1 admin on a workspace we can update this code as needed.
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 on all possible cases except the known workspace name issue on production backend. This is fixed in staging backend.
Anyway, not a blocker for this PR.
workspace.name.mov
🚀 Deployed to staging by https://github.com/bondydaa in version: 1.3.8-4 🚀
|
🚀 Deployed to production by https://github.com/marcaaron in version: 1.3.8-8 🚀
|
hmm testing this on staging and production right now isn't working anymore 😢 |
oh think i might have figured it out, testing more, hold on to your butts |
yep confirmed, this #15672 broke it. |
Following up on @bondydaa's comment here, I am seeing that the workspace chats appear to be created optimistically: Then successfully created when coming back online: Testing on dev. Let me make sure my Web-E & Auth are up-to-date... |
Oh, maybe I lied and there was an error set on those chats... |
Would love it if we could follow-up with some automated tests for this btw... might have prevented it from breaking |
This PR caused this bug. A user can be part of a workspace's room (if invited), but not part of the workspace. Inviting those users to the workspace would cause an error, as we'd wrongly identify the room as the Workspace chat. |
Details
Add creating optimistic policy expense chats while adding new members to the workspace, so created chats would pop up while user is offline.
Fixed Issues
$ #14594
PROPOSAL: #14594 (comment)
Tests
Same as QA steps
Offline tests
Same as the QA steps. Workspace chats for each member should appear optimistically
QA Steps
policy-expense-chat
betaForce offline
Force online
. Verify that workspace chats created for each members are updated accordinglyPR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)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-03-30.at.12.58.35.mov
Mobile Web - Chrome
RPReplay_Final1680175838.MP4
Mobile Web - Safari
Screen.Recording.2023-03-30.at.13.23.18.mov
Desktop
Screen.Recording.2023-03-30.at.13.34.57.mov
iOS
Screen.Recording.2023-03-30.at.13.13.12.mov
Android
Screen.Recording.2023-03-30.at.15.50.22.mov