-
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
Skip showing create for new users if user already has a workspace #5244
Skip showing create for new users if user already has a workspace #5244
Conversation
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, thanks!
✋ 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 @robertjchen in version: 1.0.98-2 🚀
|
@Beamanator I was unable to test the |
@Beamanator Friendly bump here. https://github.com/Expensify/Expensify/issues/177739 is blocking a section of QA |
Testing this @kevinksullivan right now |
Hm yeah so it sounds like we can't fully test this until https://github.com/Expensify/Expensify/issues/177739 is resolved unfortunately, you can't create a workspace right now. @Beamanator feel free to post an update if you can think of an alternative way to test |
Sorry for being super slow responding! :O Not sure how I missed this |
Since the new workspace creation happens once we are redirected to New Expensify, I was hoping we should be able to do:
However, |
This is expected. See https://expensify.slack.com/archives/CC7NECV4L/p1631817495283000 |
This PR is blocking deploy and can't be tested until https://github.com/Expensify/Expensify/issues/177739 is fixed. can we please revert this PR so that we can deploy without it? (dm'd robert) |
// For some reason, the menu doesn't open without the timeout | ||
setTimeout(() => { | ||
this.toggleCreateMenu(); | ||
}, 200); |
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 figure out how to do this without a setTimeout
these hacks end up biting us later down the road because anything else that depends on this code then will have to use a timeout/delay to push it's rendering to the end of the stack.
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 setTimeout
is currently our only solution for auto-opening the global create on load, I made this issue for people to look into solutions - read the discussions, it's not a straightforward solutions sadly :D
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 even increased from 200 ms to 1500 ms here: #5369
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 wouldn't say one comment from a contributor is an "exhaustive" discussion on how best to fix this 😅 but I do agree with Rory's comment so did we ever follow up with react-navigation on this?
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.
LOL I meant this issue: #5303 :D (many more comments haha)
reverting this here #5360 to unblock the deploy |
a note on this - We are continuing to experience this issue and investigating why here cc @Beamanator Alex is going to continue looking while online today and we'll need to find someone to keep the work going if not resolved by the time Alex clocks off for the night. Looking for volunteers for the baton pass now |
Let's focus our investigation here #5392 |
cc @kevinksullivan @MitchExpensify @mateomorris
Details
In this comment we discovered that the global create menu still shows up if a user has a workspace, which is not what we want. This PR fixes that.
Fixed Issues
$ #5047 (part 2)
Tests
New test:
To make sure there's no regressions (from the original PR):
Ensure that menu opens for new users & existing users logging in for the first time since update
Ensure that menu doesn't open for existing users who the menu has already opened for
QA Steps
New test:
To make sure there's no regressions (from the original PR):
Using a brand new account:
Using an existing account which hasn't seen the menu open automatically yet
Using the same existing account
Tested On
Desktop(Can't test here since we don't have a desktop old expensify app that could open the desktop new expensify app)iOS(Can't create a workspace from old mobile expensify)Android(Can't create a workspace from old mobile expensify)Screenshots
Web
Screen.Recording.2021-09-14.at.3.37.23.PM.mov
Mobile Web
Really difficult to get this... May only be possible in staging
Desktop
N/A
iOS
N/A
Android
N/A