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
[HOLD #44582] Workspace - Distance rate enabled offline when creating the workspace online not grayed #44163
Please re-state the problem that we are trying to solve in this issue.
The distance rates aren't grayed out when enabling the distance rate while offline.
What is the root cause of that problem?
When we create a new workspace, the distance rates are already added to the workspace. When the workspace creating is still pending, we also add it as the distance rate pending action.
After the request is complete, there is no pending action anymore. When we enable the distance rate, the list won't be grayed out because the pending action is already done.
What changes do you think we should make in order to solve the problem?
If we still want to grayed it out when enabling it while offline, then we can add a policy?.pendingFields?.areDistanceRatesEnabled,
condition so it's grayed out when the distance rate is enabled while offline.
changed the title [-]Workspace - Distance rate enabled offline when creating the workspace online not grayed[/-][+][HOLD #44582] Workspace - Distance rate enabled offline when creating the workspace online not grayed[/+]on Jun 28, 2024
Could we please get this issue cleared out a little?
Specifically, why should the rate be greyed out the second time we enable the distance rates offline?
The first time it's greyed out because the rates are enabled offline for the first time, and the default rate must be created, so it's in the pending status until coming back online.
The second time we disable-enable the rates, the default rate is not getting either re-created or modified – meaning it has no pending action, so why should it be greyed out?
@paultsimura I think the vid is supposed to show that there's discrepancy when creating new workspaces and then going offline and adjusting the mileage rate. I'm assuming that when a new workspace is created, we're not carrying over any distance rate info from other workspaces, is that correct?
there's discrepancy when creating new workspaces and then going offline and adjusting the mileage rate
There is one, and it's visible in the recording. But in my understanding, it's a normal expected behavior. That's why I would like to understand better why the issue reporter expects the rates to be greyed out in the second scenario.
we're not carrying over any distance rate info from other workspaces
Yes, the workspaces are not connected in that matter. When a new workspace is created, the default rate is created when we enable the distance rates.
Stepping back, to make sure I'm understanding things. From the vid it appears the user creates a new workspace, goes offline, does distance and the mileage rate is greyed out. They then do the same (or very similar) steps again and that time, the mileage rate isn't greyed out. Is that correct? And, if so, do you know what that's happening?
From the vid it appears the user creates a new workspace, goes offline, does distance and the mileage rate is greyed out.
One step is missing here: goes offline – enables the distance rates for the first time – checks the mileage rates.
When a new workspace is created, it has no distance rate. When the user enables the distance rates for the first time, the default rate is created.
Since this is done offline, the rates get enabled for the first time, and the default rate is in the pending "create" state – that's why it's greyed out. IMO that's expected.
They then do the same (or very similar) steps again and that time, the mileage rate isn't greyed out. Is that correct?
Yes, and IMO this is expected as well, because the second time we enable-disable the rates, the default rate has no pending action, so it shouldn't be greyed out.
Activity
melvin-bot commentedon Jun 21, 2024
Triggered auto assignment to @mallenexpensify (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.bernhardoj commentedon Jun 21, 2024
Proposal
Please re-state the problem that we are trying to solve in this issue.
The distance rates aren't grayed out when enabling the distance rate while offline.
What is the root cause of that problem?
When we create a new workspace, the distance rates are already added to the workspace. When the workspace creating is still pending, we also add it as the distance rate pending action.
App/src/pages/workspace/distanceRates/PolicyDistanceRatesPage.tsx
Line 118 in 7512346
After the request is complete, there is no pending action anymore. When we enable the distance rate, the list won't be grayed out because the pending action is already done.
What changes do you think we should make in order to solve the problem?
If we still want to grayed it out when enabling it while offline, then we can add a
policy?.pendingFields?.areDistanceRatesEnabled,condition so it's grayed out when the distance rate is enabled while offline.
App/src/pages/workspace/distanceRates/PolicyDistanceRatesPage.tsx
Lines 113 to 118 in 7512346
mallenexpensify commentedon Jun 21, 2024
Checking on in #wave-collect
OfstadC commentedon Jun 21, 2024
This seems pretty similar
mallenexpensify commentedon Jun 24, 2024
Yeah, please hold here, trying to figure out a holistic plan, since there are a lot of these
OfstadC commentedon Jun 25, 2024
Sounds good Matt!
[-]Workspace - Distance rate enabled offline when creating the workspace online not grayed[/-][+][HOLD #44582] Workspace - Distance rate enabled offline when creating the workspace online not grayed[/+]mallenexpensify commentedon Jun 28, 2024
@paultsimura , please comment so I can assign to you
2 remaining items
melvin-bot commentedon Jul 1, 2024
@mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!
paultsimura commentedon Jul 4, 2024
Could we please get this issue cleared out a little?
Specifically, why should the rate be greyed out the second time we enable the distance rates offline?
The first time it's greyed out because the rates are enabled offline for the first time, and the default rate must be created, so it's in the pending status until coming back online.
The second time we disable-enable the rates, the default rate is not getting either re-created or modified – meaning it has no pending action, so why should it be greyed out?
cc: @mallenexpensify
mallenexpensify commentedon Jul 8, 2024
@paultsimura I think the vid is supposed to show that there's discrepancy when creating new workspaces and then going offline and adjusting the mileage rate. I'm assuming that when a new workspace is created, we're not carrying over any distance rate info from other workspaces, is that correct?
paultsimura commentedon Jul 9, 2024
@mallenexpensify
There is one, and it's visible in the recording. But in my understanding, it's a normal expected behavior. That's why I would like to understand better why the issue reporter expects the rates to be greyed out in the second scenario.
Yes, the workspaces are not connected in that matter. When a new workspace is created, the default rate is created when we enable the distance rates.
mallenexpensify commentedon Jul 9, 2024
Stepping back, to make sure I'm understanding things. From the vid it appears the user creates a new workspace, goes offline, does distance and the mileage rate is greyed out. They then do the same (or very similar) steps again and that time, the mileage rate isn't greyed out. Is that correct? And, if so, do you know what that's happening?
paultsimura commentedon Jul 10, 2024
One step is missing here: goes offline – enables the distance rates for the first time – checks the mileage rates.
When a new workspace is created, it has no distance rate. When the user enables the distance rates for the first time, the default rate is created.
Since this is done offline, the rates get enabled for the first time, and the default rate is in the pending "create" state – that's why it's greyed out. IMO that's expected.
Yes, and IMO this is expected as well, because the second time we enable-disable the rates, the default rate has no pending action, so it shouldn't be greyed out.
WDYT @mallenexpensify?
mallenexpensify commentedon Jul 12, 2024
Thx for the details @paultsimura , sounds like we should close this then, it's working as expected. Right?
paultsimura commentedon Jul 12, 2024
Yes, IMO this is an expected behavior.