Skip to content

[Due for payment 2026-10-14] [$175] Workspace - Rules are not enabled when copying Merchant rule to the Collect workspace #102210

Closed
Closed
[Due for payment 2026-10-14] [$175] Workspace - Rules are not enabled when copying Merchant rule to the Collect workspace#102210
Assignees
JmillsExpensifymarcochavezfmallenexpensifydaledah
Labels
Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Description

@applause-bot
applause-bot
bot
opened on Sep 24, 2026

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: v9.4.93-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #101710
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5.1 Safari, iPhone 13 iOS 26.6
App Component: Workspace Settings

Action Performed:

Preconditions: User has a Control workspace (Workspace A) with Rules enabled and created merchant rule

  1. Go to https://staging.new.expensify.com
  2. Create a Collect workspace
  3. Navigate to the Workspaces list
  4. Click the ⋮ menu on Workspace A (Control) and select Copy settings
  5. On Select workspaces, select Workspace B (Collect) and click Next.
  6. On Select settings, tick Merchant Rule and click Next.
  7. Click Upgrade.
  8. Click Continue
  9. Click Copy settings
  10. Navigate to the Workspace B

Expected Result:

Rules should be enabled when copying Merchant rule to the Collect workspace

Actual Result:

Rules are not enabled when copying Merchant rule to the Collect workspace

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7268359_1790263504998.Recording__3053.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7268359

Upwork Automation - Do Not Edit
Issue OwnerCurrent Issue Owner: @mallenexpensify

Activity

  1. gleitebr
    added this to #expensify-bugson Sep 24, 2026
  2. applause-bot
    added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Sep 24, 2026

  3. applause-bot commented on Sep 24, 2026

    @applause-bot
    applause-botBot
    on Sep 24, 2026
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/a2bf935adbdd998b5fbb807e85f16ebc3f22b5dd01639c509f0baabb603b4256

  4. melvin-bot
    assigned
    marcochavezf
    on Sep 24, 2026

  5. melvin-bot commented on Sep 24, 2026

    @melvin-bot
    melvin-botBot
    on Sep 24, 2026 – with Melvin Bot

    You have been assigned to this deploy blocker because you recently merged this PR: #101710

  6. github-actions
    added
    Engineering
    HourlyKSv2
    on Sep 24, 2026
  7. melvin-bot
    assigned
    JmillsExpensify
    on Sep 24, 2026

  8. github-actions commented on Sep 24, 2026

    @github-actions
    github-actionsBot
    on Sep 24, 2026 – with GitHub Actions
    Contributor

    👋 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.
  9. melvin-bot
    assigned
    daledah
    on Sep 24, 2026

  10. melvin-bot commented on Sep 24, 2026

    @melvin-bot
    melvin-botBot
    on Sep 24, 2026 – with Melvin Bot

    @marcochavezf @JmillsExpensify @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #101710

  11. melvin-bot commented on Sep 24, 2026

    @melvin-bot
    melvin-botBot
    on Sep 24, 2026 – with Melvin Bot

    💬 A slack conversation has been started in #expensify-open-source

  12. MelvinBot commented on Sep 24, 2026

    @MelvinBot
    MelvinBot
    on Sep 24, 2026
    Contributor

    🔍 Investigation Summary

    Classification: Frontend bug
    Causing PR: Fix copy settings from Control to Collect workspace - "Show the Upgrade step when copying rules to a Collect workspace" by @MelvinBot (Medium-High confidence)
    Related Issues: Auto - Workspace - Unable to "Copy settings" from Control to Collect workspace (the issue #101710 fixed)

    Recommendation: ROLL FORWARD

    The copy part for Merchant rules (codingRules) copies the merchant rules themselves but never copies/sets areRulesEnabled, so the target lands with the rules data but the Rules feature toggled off. Reverting #101710 would just restore the older, worse "Copy failed" bug (#101456) without fixing the missing flag, so a small roll-forward is the right call.

    Assigned: @marcochavezf, @JmillsExpensify, @daledah (approving reviewers of #101710) — already auto-assigned; the PR author is a bot so there is no human author to add.
    Labels: No changes. DeployBlockerCash is kept (App-side fix). DeployBlocker was not present, so nothing was removed.

    📋 Detailed Analysis

    Evidence

    • The bug is staging-only because #101710 is the only change in Deploy Checklist: New Expensify 2026-09-24 that touches this flow. Before it, selecting Merchant rules with a Collect target skipped the Upgrade step entirely and the copy failed outright — the user never reached a completed copy, so the "Rules stayed off" end state was unreachable. The PR added CONTROL_ONLY_COPY_PARTS = new Set<Part>(['rules', 'codingRules']) and short-circuits getControlOnlySelectedParts, which now routes this case through Upgrade → Confirm → a copy that actually succeeds: CopyPolicySettingsUtils.ts#L309-L341.
    • The PR's own test plan only asserted that the Upgrade step is displayed for Merchant rules ("2. Merchant rules behaves the same") — it never verified the post-copy state of Workspace B, which is exactly where this fails.
    • The underlying omission is older than this release (identical on production), but it was unreachable in this flow until #101710 unblocked it, which is why it surfaced now as a staging-only regression.

    Verification

    Affected files (confirmed against staging code):

    Root Cause

    Three places each assume someone else turns Rules on, and nobody does:

    1. The codingRules part copies no feature flag. PARTS_TO_POLICY_FIELDS.rules starts with 'areRulesEnabled', but codingRules maps to ['rules'] only — and that single field is explicitly skipped in buildPolicyFieldPatch because the merchant rules are applied through a dedicated patch instead. Net effect: copying Merchant rules writes zero policy-level fields. See CopyPolicySettings.ts#L48-L67 and the skip at L315-L317.
    2. The merchant-rules patch only writes rules.codingRules, leaving areRulesEnabled untouched on the target: CopyPolicySettings.ts#L430-L437.
    3. The Upgrade step doesn't enable the feature either. bulkUpgradeToCorporate flips type to CORPORATE and sets glCodes/eReceipts/receipt thresholds, but never areRulesEnabled: Policy.ts#L6159-L6206 and getCorporateUpgradeOnyxFields.

    So Workspace B ends up Control, with the merchant rules stored under policy.rules.codingRules, but areRulesEnabled still false — the Rules feature reads as off and the copied merchant rules are invisible. Copying Rules (rather than Merchant rules) works precisely because that part carries areRulesEnabled across.

    Suggested fix (one line, plus coverage): include the feature flag in the codingRules part so it is copied from the source the same way the rules part does it:

    codingRules: ['rules', 'areRulesEnabled'],

    'rules' stays skipped in buildPolicyFieldPatch, so this only adds areRulesEnabled: sourcePolicy.areRulesEnabled (true for any source that has merchant rules) to the target patch, and it automatically gets the right pending-field handling.

    Two things to check alongside the fix:

    • The server-side copy has to persist the same thing for the merchant-rules part, otherwise the server push will flip the toggle back off after the optimistic update.
    • The same gap exists in the duplicate workspace flow, where areRulesEnabled is derived from the rules selection only and ignores the merchant-rules selection: Policy.ts#L3535 vs L3557. Worth fixing in the same PR.

    There is also no test coverage for the codingRules part in tests/actions/CopyPolicySettingsTest.ts, which is how this slipped through — the fix should add one asserting the target ends up with areRulesEnabled: true.

  13. daledah commented on Sep 25, 2026

    @daledah
    daledah
    on Sep 25, 2026
    Contributor

    checking now

  14. 44 remaining items

  15. melvin-bot commented on Oct 13, 2026

    @melvin-bot
    melvin-botBot
    on Oct 13, 2026 – with Melvin Bot

    Payment Summary

    Resolving PRs:

    BugZero Checklist (@mallenexpensify)

    • I have confirmed assignees, roles, and Upwork contracts look correct
    • I have paid out Upwork contracts / manual NewDot requests
    • [BugZero Assignee] I have created a GH issue for creating/updating the regression test once above steps have been agreed upon
  16. melvin-bot
    added
    Overdue
    on Oct 15, 2026

  17. melvin-bot commented on Oct 16, 2026

    @melvin-bot
    melvin-botBot
    on Oct 16, 2026 – with Melvin Bot

    @mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

  18. mallenexpensify commented on Oct 16, 2026

    @mallenexpensify
    mallenexpensify
    on Oct 16, 2026
    Contributor

    @daledah this issue and/or PR mention a deploy blocker or a regression. Before the payment date, post one of the three options in step 20 of the C+ doc: it was a regression, it was not, or you did not review the offending PR. If you don't post, the default is to reduce payment.

  19. melvin-bot
    removed
    Overdue
    on Oct 16, 2026

  20. daledah commented on Oct 19, 2026

    @daledah
    daledah
    on Oct 19, 2026
    Contributor

    @mallenexpensify This issue is a follow-up to our previous PR and required a BE fix. After the BE fix was deployed, I worked with Melvin on this PR to fix the issue in the offline case.

    There are no deploy blockers related to our issue or PR.

  21. melvin-bot
    added
    Overdue
    DailyKSv2
    and removed
    DailyKSv2
    Overdue
    on Oct 19, 2026

  22. mallenexpensify commented on Oct 19, 2026

    @mallenexpensify
    mallenexpensify
    on Oct 19, 2026
    Contributor

    This issue is a follow-up to our previous PR and required a BE fix.

    @daledah can you link to a discussion or details? I'm seeing this issue was created after the offending PR was merged. Thx

  23. daledah commented on Oct 20, 2026

    @daledah
    daledah
    on Oct 20, 2026
    Contributor

    @mallenexpensify we discussed this here on Slack

    I don't think this should be considered a regression from our PR, since the actual root cause was on the BE side, not in the changes introduced by our PR

    cc @lakchote @marcochavezf

  24. mallenexpensify commented on Oct 20, 2026

    @mallenexpensify
    mallenexpensify
    on Oct 20, 2026
    Contributor

    Payment Summary

    Contributor+: @daledah due $175 via NewDot

    @daledah please include links about deploy blockers and regressions before payment is due so I can pay quicker.

  25. mallenexpensify
    closed this as completedon Oct 20, 2026
  26. github-project-automation
    moved this to Done in #expensify-bugson Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions