You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Global create opening in workspace configuration screen #5392
Global Create is open in the workspace configuration screen
Workaround:
Ignore it and click "Get Started". This is the mainline flow so we can't expect users to follow this workaround. They could easily select a global create option and get diverted from the mainline flow.
Hmm so this is actually really tricky to solve now because of the latest changes.
Basically when the Sidebar loads we need to know if we have a free policy, but we might not have created one yet.
Before the most recent changes we were only redirecting after the policy was created. But now the sidebar loads (inside the MainDrawerNavigator) at the same time as the LoginWithShortLivedTokenPage. So we can no longer guarantee that allPolicies will contain the policy we just created.
I'm struggling to think of a clean way to get around this but we can hack it for now by looking at what route we're on. Unless someone has a better idea... I'm a little stumped since the sidebar doesn't know that we are trying to create a policy via WorkspaceNew and the two things don't really have any relationship to eachother.
Probably a better way to fix this would be to stop triggering the modal to open via the SidebarScreen in componentDidMount() entirely and instead do it programmatically (unsure if there's a clear reason why it should be there vs. somewhere like Expensify.js), but that's going to be more complicated than referring to the navigation state.
Ah wait are you seeing it workspace/new as well? I only saw it with workspace/12312/card when I was transitioning from the existing policy. Is the invalid workspace closing bug also happening for if you hit localhost:8080/workspace/new?
Yeah global create thing pops open for workspace/new because we are creating it via New Expensify and the sidebar may load before that happens e.g. if it takes longer than 1.5 seconds to create the policy.
Ahh wait sorry I'm getting this discussion and the inconsistent InvalidWorkspace thing mixed up. Ignore what I said there.
This is kind of hacky behavior on top of hacky behavior, but one thing we could do is set this NVP which is called from Onyx here for the user while we're doing the transition in LogInWithShortToken or anywhere in its flow.
Anyone who's coming in from OldDot is going to be routed to a Workspace so we don't need to automatically open the global create menu.
It makes sense to me to move the isFirstTimeNewExpensifyUser out of the SidebarScreen and pass a prop to trigger the create menu to open when it has to, or save a ref somewhere so that it can be triggered like SidebarScreen.toggleCreateMenu()
It just that the logic should be synchronised to have the firstTimeUser check and the policy check as well as trigger the create menu no sooner than 1500ms (to avoid the modal bug)
e.g. something like
Promise.all([firstUserCheck,policyCheck,delay(1500),]).then(results=>/* open the create menu if any of the checks passed `true` */)
@TomatoToaster Oh hmm so basically set them as "not a first time user"? That could work, but creates a weird condition where we must block navigating until after the NVP has been set + also block on the two API calls @kidroca is calling out.
Either way I think we'll have to reorganize the code after, but looking at the route works for now.
Activity
MelvinBot commentedon Sep 21, 2021
Triggered auto assignment to @Christinadobrzyn (
AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.parasharrajat commentedon Sep 21, 2021
@MitchExpensify #5244 was reverted here
Beamanator commentedon Sep 21, 2021
Latest Slack thread here.
Basically it's pretty easy to reproduce in dev, and was determined that currently there shouldn't be any race condition weirdness with one possible solution (@marcaaron 's PR: https://github.com/Expensify/App/pull/5394/files).
However, @TomatoToaster is working on changing some of the flow so we're planning to hold on this until that change is done.
marcaaron commentedon Sep 22, 2021
Hmm so this is actually really tricky to solve now because of the latest changes.
Basically when the Sidebar loads we need to know if we have a free policy, but we might not have created one yet.
Before the most recent changes we were only redirecting after the policy was created. But now the sidebar loads (inside the
MainDrawerNavigator) at the same time as theLoginWithShortLivedTokenPage. So we can no longer guarantee thatallPolicieswill contain the policy we just created.I'm struggling to think of a clean way to get around this but we can hack it for now by looking at what route we're on. Unless someone has a better idea... I'm a little stumped since the sidebar doesn't know that we are trying to create a policy via
WorkspaceNewand the two things don't really have any relationship to eachother.marcaaron commentedon Sep 22, 2021
Probably a better way to fix this would be to stop triggering the modal to open via the
SidebarScreenincomponentDidMount()entirely and instead do it programmatically (unsure if there's a clear reason why it should be there vs. somewhere likeExpensify.js), but that's going to be more complicated than referring to the navigation state.TomatoToaster commentedon Sep 22, 2021
Ah wait are you seeing it
workspace/newas well? I only saw it withworkspace/12312/cardwhen I was transitioning from the existing policy. Is the invalid workspace closing bug also happening for if you hitlocalhost:8080/workspace/new?marcaaron commentedon Sep 22, 2021
Yeah global create thing pops open for
workspace/newbecause we are creating it via New Expensify and the sidebar may load before that happens e.g. if it takes longer than 1.5 seconds to create the policy.TomatoToaster commentedon Sep 22, 2021
Ahh wait sorry I'm getting this discussion and the inconsistent InvalidWorkspace thing mixed up. Ignore what I said there.
This is kind of hacky behavior on top of hacky behavior, but one thing we could do is set this NVP which is called from Onyx here for the user while we're doing the transition in LogInWithShortToken or anywhere in its flow.
Anyone who's coming in from OldDot is going to be routed to a Workspace so we don't need to automatically open the global create menu.
kidroca commentedon Sep 22, 2021
It makes sense to me to move the
isFirstTimeNewExpensifyUserout of the SidebarScreen and pass a prop to trigger the create menu to open when it has to, or save a ref somewhere so that it can be triggered likeSidebarScreen.toggleCreateMenu()kidroca commentedon Sep 22, 2021
It just that the logic should be synchronised to have the
firstTimeUsercheck and thepolicycheck as well as trigger the create menu no sooner than1500ms(to avoid the modal bug)e.g. something like
marcaaron commentedon Sep 22, 2021
@TomatoToaster Oh hmm so basically set them as "not a first time user"? That could work, but creates a weird condition where we must block navigating until after the NVP has been set + also block on the two API calls @kidroca is calling out.
Either way I think we'll have to reorganize the code after, but looking at the route works for now.