Skip to content

Decide how organization merge should handle billing (Pay gem) links #2378

Description

@maebeale

🤖 From Claude:

Split out from the organization deduper (#2374).

The deduper reassigns every business association from a deleted org to the kept one, reassigns analytics/audit (ahoy_events, versions), and surfaces attached files that are deleted with the record. Billing links are deliberately left out for now because moving money-related records between orgs has real side effects that need a product decision.

Affected polymorphic tables (Pay gem): pay_customers, pay_merchants, pay_subscriptions, pay_charges, pay_payment_methods, pay_webhooks (owner/polymorphic → could be an Organization).

Current behavior: these tables are in ModelDeduper::DEFERRED_REFERENCE_TABLES, so they neither block the merge nor get moved — if a merged org had billing records, they'd stay pointing at the deleted org's id.

Decide:

  • Should billing records be reassigned to the kept org on merge, left as-is, or should the merge be blocked when they exist?
  • In practice, are Pay records ever owner_type = "Organization" in this app, or only Users/People? (If never orgs, we can drop the deferral entirely.)

Once decided, update ModelDeduper (reassign / block / ignore) and remove the tables from DEFERRED_REFERENCE_TABLES as appropriate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions