Custom units are broken

[jasperhuangg]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open or create any workspace.
2. Attempt to update the custom unit rates.
3. Notice how it just doesn't work.

Screen.Recording.2022-09-13.at.2.01.02.PM.mov

Expected Result:

Updates to the custom unit rate should be persisted.

Actual Result:

Updates to the custom unit rate aren't persisted. The policy.customUnits is null.

Workaround:

Reverting changes from #10873 fixes things locally

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: v1.2.0-0
Reproducible in staging?: yes
Reproducible in production?: no
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @mallenexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[melvin-bot]

Current assignee @mallenexpensify is eligible for the AutoAssignerTriage assigner, not assigning anyone new.

[jasperhuangg]

@francoisl

The biggest thing I'm noticing from #10873 is that we're not calling Policy.loadFullPolicy anymore. This means that we'll only have loaded the policy from AppInit, which sets customUnits to be null. The only way we can grab a policy's custom units is if we load the full policy.

This is definitely what's causing the custom unit rate to be 0.000 when we first load the page, and any subsequent updates to it to fail. If you log this.props.policy.customUnits it's actually null when it shouldn't be.

I'm not entirely sure what the decision behind getting rid of the call to Policy.loadFullPolicy was, maybe we can wait for @arosiclair to clarify?

[jasperhuangg]

@francoisl After reading the design doc it looks like not calling Policy.loadFullPolicy was an intentional design choice to prevent additional chaining, it seems this was an unintended consequence that wasn't considered previously.

I say we revert #10873 for now to avoid blocking the deploy.