[Due for payment 2025-07-28] [$250] Xero - Report fields locked despite workspace upgrade

[mitarachim]

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: v9.1.67-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/cases/view/3605950
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

1. Create a Collect workspace
2. Enable integrations
3. Navigate to integrations and connect to Xero
4. Navigate to Import > Tracking Categories > Map Xero Cost Centres to > Report Fields
5. Upgrade workspace to Control
6. Go to WS > Reports
7. Try to turn ON toggle Report fields

additional steps

1. Go to ws > Overview
2. Downgrade workspace to Collect again
3. Sync Xero connection

Expected Result:

Toggle is ON. Report field are imported.

additional
User can't downgrade workspace when Map Xero Cost Centres set to Report Fields or if workspace is downgraded, Map Xero Cost Centres must be reset to default.

Actual Result:

Toggle is locked. A modal appears that say go to Xero Import settings.

additional
User can downgrade workspace when Map Xero Cost Centres set to Report Fields, Map Xero Cost Centres stays set to Report fields.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6861938_1750103421657.bandicam_2025-06-16_22-27-58-644.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021934778698659195238
• Upwork Job ID: 1934778698659195238
• Last Price Increase: 2025-06-24
• Automatic offers:
• daledah | Contributor | 107869721

Issue Owner

Current Issue Owner: @maddylewis

[melvin-bot]

Triggered auto assignment to @maddylewis (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]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ahmedGaber93 (External)

[daledah]

Proposal

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

Toggle is locked. A modal appears that say go to Xero Import settings.

What is the root cause of that problem?

When changing tracking categories to Report fields, we don't have any logics to toggle report fields. So policy.areReportFieldsEnabled is always false

App/src/pages/workspace/reportFields/WorkspaceReportFieldsPage.tsx

Line 250 in 7ea0933

isActive={!!policy?.areReportFieldsEnabled}

And report field toggle is always locked if we have accounting connections

App/src/pages/workspace/reportFields/WorkspaceReportFieldsPage.tsx

Line 268 in 7ea0933

disabled={hasAccountingConnection}

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

We should toggle report field if selected tracking categories option is Report field

Add after here

App/src/pages/workspace/accounting/xero/XeroMapTrackingCategoryConfigurationPage.tsx

Line 76 in 7ea0933

);

                if (option.value === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD) {
                    Policy.enablePolicyReportFields(policyID, true);
                    return;
                }
                if (currentTrackingCategoryValue === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD) {
                    Policy.enablePolicyReportFields(policyID, false);
                }

Explanation:

1. If selected option is CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD, we'll enable report field.
2. If current selected option is CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD, which means we select other options, then we'll disable report field.

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

None

What alternative solutions did you explore? (Optional)

1. Alternate 1: Requires both BE and FE changes

We can add optimistic data for updateXeroMappings

App/src/libs/actions/connections/Xero.ts

Line 368 in b9b3462

function updateXeroMappings(policyID: string, mappingValue: Partial<Connections['xero']['config']['mappings']>, oldMappingValue?: Partial<Connections['xero']['config']['mappings']>) {

    const policy = getPolicy(policyID);

    const selectedMapping = Object.entries(mappingValue)
        .find(([key]) => key.startsWith(CONST.XERO_CONFIG.TRACKING_CATEGORY_PREFIX))
        ?.at(1);

    if (selectedMapping) {
        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
            value: {
                areReportFieldsEnabled: selectedMapping === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD,
                areTagsEnabled: selectedMapping === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.TAGS,
                pendingFields: {
                    areReportFieldsEnabled: selectedMapping === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD ? CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE : null,
                    areTagsEnabled: selectedMapping === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.TAGS ? CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE : null,
                },
            },
        });
        successData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
            value: {
                pendingFields: {
                    areReportFieldsEnabled: null,
                    areTagsEnabled: null,
                },
            },
        });
        failureData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
            value: {
                areReportFieldsEnabled: policy?.areReportFieldsEnabled,
                areTagsEnabled: policy?.areTagsEnabled,
                pendingFields: {
                    areReportFieldsEnabled: null,
                    areTagsEnabled: null,
                },
            },
        });
    }

Then have BE send the same result for consistency

2. Alternative 2: (This feels like a workaround for me)

We can add an util function to check if report field is enabled, implement like so

function areReportFieldsEnabled(policy: OnyxEntry<Policy>) {
    const connectedIntegration = getConnectedIntegration(policy);
    const policyReportFieldsEnabled = !!policy?.areReportFieldsEnabled;
    if (!policy?.connections || !connectedIntegration) {
        return policyReportFieldsEnabled;
    }
    switch (connectedIntegration) {
        case CONST.POLICY.CONNECTIONS.NAME.XERO: {
            const config = policy.connections[connectedIntegration]?.config;
            const trackingCategory = Object.entries(config.mappings).find(([key]) => key.startsWith(CONST.XERO_CONFIG.TRACKING_CATEGORY_PREFIX))?.at(1);
            return trackingCategory === CONST.XERO_CONFIG.TRACKING_CATEGORY_OPTIONS.REPORT_FIELD || policyReportFieldsEnabled
        }
        // add other integrations if any
        default:
            return policyReportFieldsEnabled;
    }
}

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.

[DmitryChizhevsky-vs]

Proposal

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

The current implementation of the areReportFieldsEnabled function has a potential issue with how it determines whether report fields should be enabled based on the Xero integration configuration. The function needs to properly check if a policy should have report fields enabled based on either being a Control plan or having specific Xero integration settings.

What is the root cause of that problem?

The root cause is that the function is trying to access a nested property path (xeroConfig?.sync.trackingCategories.mapping.costCenter) without proper optional chaining, which could lead to runtime errors if any intermediate property is undefined. Additionally, the function could benefit from clearer naming and comments to better explain the logic behind enabling report fields.

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

We should update the areReportFieldsEnabled function to:

1. Use proper optional chaining for deeply nested properties
2. Add clear comments explaining the decision logic
3. Use more descriptive variable names
4. Ensure consistency with other policy utility functions
5. Maintain the existing business logic where Control plans always have report fields enabled, and non-Control plans depend on specific Xero integration settings

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

1. Test that a Control policy always returns true for areReportFieldsEnabled regardless of Xero integration settings
2. Test that a non-Control policy with properly configured Xero integration (importTrackingCategories enabled and costCenter mapping set to REPORT_FIELD) returns true
3. Test that a non-Control policy without Xero integration returns false
4. Test that a non-Control policy with Xero integration but without importTrackingCategories enabled returns false
5. Test that a non-Control policy with importTrackingCategories enabled but costCenter mapping not set to REPORT_FIELD returns false
6. Test with undefined or null policy objects to ensure the function handles edge cases gracefully

What alternative solutions did you explore? (Optional)

An alternative approach would be to store the report fields enabled state directly on the policy object rather than deriving it from the integration settings. However, the current approach maintains a single source of truth by deriving the state from the integration configuration, which is preferable for maintaining data consistency.

[melvin-bot]

📣 @DmitryChizhevsky-vs! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[github-actions]

⚠️ @DmitryChizhevsky-vs Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[DmitryChizhevsky-vs]

Contributor details
Your Expensify account email: dmitrii.chizhevskii+test1@vallettasoftware.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01b32582c68b3e3dae