Account Lifecycle Management#

Sure manages account state through an AASM-backed state machine on the Account model 1. There are four states:

State Transitions#

The allowed transitions 2 are:

• activate — draft / disabled → active
• disable — draft / active → disabled
• enable — disabled → active
• mark_for_deletion — any state → pending_deletion

In the controller, toggle_active calls disable! on an active account or enable! on a disabled one 3.

Scopes and Visibility#

Two named constant arrays drive query scopes 4:

• VISIBLE_STATUSES — [draft, active] — used by the visible scope; these accounts appear in the UI.
• HISTORICAL_STATUSES — [draft, active, disabled] — used by the historical scope; includes disabled accounts for balance history and reporting.
• pending_deletion accounts are excluded from listable_manual 5 so they don't appear on the manual account list.
• The included_in_reports scope further filters by exclude_from_reports: false 6.

Deletion Flow#

Deletion is always asynchronous. Calling destroy_later atomically transitions the account to pending_deletion and enqueues a DestroyJob. If the destruction fails, the destroy override rescues the error and falls back to disable! to ensure a clean recovery state 7. Before destruction, cleanup_transfers 8 destroys all Transfer records linked to the account's transactions. Linked accounts (those with a provider) cannot be deleted through the UI 9.

Transfer::Creator — Paired Dual-Transaction Pattern#

A Transfer in Sure is not a single ledger entry — it is a join record linking two Transaction rows: one outflow from the source account and one inflow to the destination account 10. This double-entry approach keeps each account's transaction history self-consistent.

How Transfer::Creator Works#

Transfer::Creator is a plain Ruby service object instantiated with family, source_account_id, destination_account_id, date, amount, and optional exchange_rate, source_fee_amount, and destination_fee_amount.

Calling #create does the following inside a single database transaction:

1. Builds an outflow transaction on the source account — positive amount (debit) 11.
2. Builds an inflow transaction on the destination account — negative amount (credit), optionally currency-converted via inflow_converted_amount 12.
3. Appends optional fee transactions to either side 13.
4. Saves the Transfer record linking both transactions, then calls sync_later on both accounts 14.

Transaction Kind Routing#

The outflow transaction's kind is determined by the destination account type 15:

The Transfer model itself also exposes kind_for_account as a class method that mirrors this routing — useful for display logic without constructing a creator.

Transfer Validations#

The Transfer model enforces 16:

• Different accounts — inflow and outflow must belong to different accounts.
• Opposite amounts — inflow entry must be negative, outflow positive; same-currency transfers must sum to zero.
• Same family — both accounts must belong to the same family.
• Date proximity — entries must be within 4 days of each other (pending) or 30 days (confirmed) 17.

Destroying a Transfer#

Transfer#destroy! resets both linked transactions' kind back to "standard" before calling super, ensuring orphaned transactions don't retain transfer-specific kinds. reject! additionally creates a RejectedTransfer record to suppress re-detection of the same pair.

Key Files#