[AWAITING PAYMENT] [$250] [OldDot Rules Migration] [Polish] - App freezes after updating Custom report name

[IuliiaHerets]

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

---

Version Number: 9.0.31-12
Reproducible in staging?: Y
Reproducible in production?: N/A
Email or phone of affected tester (no customers): applausetester+kh010901@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Launch New Expensify app.
2. Create a new workspace.
3. Go to Workspace settings > Rules.
4. Enable Custom report names.
5. Tap Custom name.
6. Clear the field, enter anything and save it.
7. Try to scroll through the app.

Expected Result:

App will be responsive after updating Custom report name.

Actual Result:

App is freezing after updating Custom report name.
On web, app is responsive, but "Custom report names" and "Prevent members from changing custom report names toggles" are no longer working after updating Custom report name.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6598298_1725943845774.web.1.mp4

Bug6598298_1725943845758.Android.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021843814682618579436
• Upwork Job ID: 1843814682618579436
• Last Price Increase: 2024-10-09

Issue Owner

Current Issue Owner: @

[melvin-bot]

Triggered auto assignment to @garrettmknight (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.

[melvin-bot]

Triggered auto assignment to @lakchote (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[Nodebrute]

Proposal

Please re-state the problem that we are trying to solve in this issue.

App freezes atter updating Custom report name

What is the root cause of that problem?

This error will only occur when we change the custom report names and areReportFieldsEnabled are false. When we call setPolicyDefaultReportTitle for the first time it's response also returns areReportFieldsEnabled:true which will cause the following condition to be true and in return this useEffect will run in loop causing the app to freeze on different devics

App/src/pages/workspace/WorkspaceInitialPage.tsx

Line 450 in 545f897

highlighted={enabledItem?.routeName === item.routeName}

What changes do you think we should make in order to solve the problem?

We can disable custom report names and tell user to go to more features and enable reportFields. We use this approach widely in our app

 title: translate('workspace.rules.expenseReportRules.customReportNamesTitle'),
            subtitle: policy?.areReportFieldsEnabled ? translate('workspace.rules.expenseReportRules.customReportNamesSubtitle') : renderFallbackSubtitle(translate('common.approvals').toLowerCase()),
            switchAccessibilityLabel: translate('workspace.rules.expenseReportRules.customReportNamesTitle'),
            isActive: policy?.shouldShowCustomReportTitleOption && policy?.areReportFieldsEnabled,
            disabled: !policy?.areReportFieldsEnabled,
            pendingAction: policy?.pendingFields?.shouldShowCustomReportTitleOption,

Note

This is just a pseudo-code example; other minor details can be addressed in the PR. We may also need to update the fallback subtitle content, so a revised version of that will be required.

What alternative solutions did you explore? (Optional)

We can optimistically set areReportFieldsEnabled to true if report fields are not enabled.

App/src/libs/actions/Policy/Policy.ts

Line 3973 in 286b945

value: {

Solution 3
We can check here if !policy?.areReportFieldsEnabled then we can call Policy.enablePolicyReportFields. We can do something like this

  onSubmit={({customName}) => {
                        if( !policy?.areReportFieldsEnabled){
                            Policy.enablePolicyReportFields(policyID, true, true)
                        }
                        PolicyActions.setPolicyDefaultReportTitle(policyID, customName);
                        Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack);
                    }}

[lakchote]

Not a blocker, it's behing beta BETA_WORKSPACE_RULES

cc @BrtqKr @marcaaron since you've worked on [OldDot Rules Migration] Expense report rules

[BrtqKr]

@lakchote I've got a draft for that, but I think we should slightly adjust the logic. If someone disables the report fields, I'd probably assume that the custom names would be switched off and the nested values would be removed. If we end up agreeing on that solution, this will probably require back-end changes, right?

Those fields would be

policy.shouldShowCustomReportTitleOption
policy?.fieldList?.[text_title].defaultValue
policy?.fieldList?.[text_title].deletable

and apart from that front-end changes in the actions to handle optimistic updates properly

[Nodebrute]

@lakchote Since my proposal was used to create the solution and finding the root cause was very challenging, could you let me know if there will be any compensation for this contribution?

[marcaaron]

If someone disables the report fields, I'd probably assume that the custom names would be switched off and the nested values would be removed

Yes I think that was missed in the implementation, but was included in the design:

If the user disables this option (i.e. sends enable: false) from NewDot that will reset the formula back to {report:type} {report:startdate} which we can do by modifying the policy by calling PolicyAPI::mergeReportFields() after setting shouldShowCustomReportTitleOption: false on the policy object.

I can raise a PR to get this fixed. But in the meantime I think it's also fine to not reset anything.

[marcaaron]

Just a heads up that this is going to take several days or more to prepare backend changes due to it triggering a required refactor so we should proceed with a front end solution for now.

[BrtqKr]

@marcaaron, ok then let's just do it separately #48908

[lakchote]

@lakchote Since my proposal was used to create the solution and finding the root cause was very challenging, could you let me know if there will be any compensation for this contribution?

First of all, thank you for suggesting a proposal to solve this.
However we weren't seeking for external help on this one (no External label was present) and your solution isn't the one we're going to pursue as we'll need to do some backend changes. Hope you understand!

[marcaaron]

First part of the BE fix in Auth is done. Second half is in review.

[marcaaron]

Backend changes are done and deployed so we should be good to close this one out.

However, @shubham1206agra is maybe still requiring payment for their review of this PR.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021843814682618579436

[melvin-bot]

Current assignee @shubham1206agra is eligible for the External assigner, not assigning anyone new.

[garrettmknight]

@shubham1206agra you get paid for this anywhere else?

[shubham1206agra]

No

[garrettmknight]

Cool - offer is out to you. https://www.upwork.com/nx/wm/offer/104378678

[garrettmknight]

@shubham1206agra can you accept the offer when you get a chance?

[shubham1206agra]

@garrettmknight Offer accepted

[garrettmknight]

Paid, closing