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

Proposal

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

Category RHP loads indefinitely in 1:1 flow

What is the root cause of that problem?

We do not show not found page in category RHP when report does not have a policy. Same issue could occur if the categories are disabled for the workspace.

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

Add condition to show not found page if report.policyId is not present. Additionally, we can also show not found page if workspace does not have categories enabled.

Current code:

Updated code

if we only check that report is in workspace:

const shouldShowNotFoundPage = !report?.policyId || (isEditing && (isSplitBill ? !canEditSplitBill : !ReportActionsUtils.isMoneyRequestAction(reportAction) || !ReportUtils.canEditMoneyRequest(reportAction)));

if we also want to check that categories are enabled:

const shouldShowNotFoundPage = !policy?.areCategoriesEnabled || (isEditing && (isSplitBill ? !canEditSplitBill : !ReportActionsUtils.isMoneyRequestAction(reportAction) || !ReportUtils.canEditMoneyRequest(reportAction)));

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

No extra tests are needed for this

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Edited by proposal-police: This proposal was edited at 2024-12-26 19:16:34 UTC.

Proposal

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

Category RHP opens and loads infinitely.

What is the root cause of that problem?

The shouldShowNotFoundPage is false if the policy is personal policy or it's undefined

Then because policyCategories is undefined, the loading page appear

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

We should add a condition to update shouldShowNotFoundPage to true if the policy is not group policy. Because we can enable the category feature with the empty state then we should only display not found page if the policy doesn't have policy feature (policy isn't group policy)

const isGroupPolicy = ReportUtils.isReportInGroupPolicy(report) || ReportUtils.isGroupPolicy(policy?.type ?? '');
const shouldShowNotFoundPage = !isGroupPolicy || (isEditing && (isSplitBill ? !canEditSplitBill : !ReportActionsUtils.isMoneyRequestAction(reportAction) || !ReportUtils.canEditMoneyRequest(reportAction)));

That is how we do here

We should do the same fix for other steps in money request flow that require group policy if these steps has the same problem

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Proposal

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

IOU category page opens but shows infinite loading on a DM IOU flow.

What is the root cause of that problem?

When we open the category page from a DM IOU, the policy categories will be undefined and if we are online, then the loading will show.

The not found page doesn't show because we don't have any check whether the user can access the category field page or not.

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

We can wrap the page with AccessOrNotFoundWrapper which handles the check whether the user can access it or not. For category page, it will look like this:

return (
    <AccessOrNotFoundWrapper 
        policyID={policy?.id}
        iouType={iouType}
        featureName={CONST.POLICY.MORE_FEATURES.ARE_CATEGORIES_ENABLED}
    >
        ...
    </AccessOrNotFoundWrapper>

This will prevent the user to access the page if:

1. The IOU flow is a DM IOU
2. The IOU is a workspace request, but the categories feature is disabled

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Or even better, we can copy the condition whether to show the field or not from the confirmation list field to each step page.

etc.

We can create a util function for the condition that is more complex.