Firm proprietors / roles with financial permission are seemingly unable to withdraw funds. Investigate the cause and fix.
Technical notes — Withdrawals run through FirmTransactionServiceImpl.withdraw → resolveAccountId(firmId) (returns firm.getDefaultAccountId(), legacy fallback getAnyAccountId) and gate on Account.isRequiresAuthorization() + authorizer membership. Most likely cause: the firm's default_account_id is null/stale (→ PAR-62) so resolution fails, or proprietors aren't on the account's authorizer list. Reproduce with both conditions and split the error messaging so "no default account" vs "not an authorizer" vs "insufficient funds" are distinguishable. Same root cause as PAR-62 — work them together.
Fixed on develop (business-rian @ 951e270), together with PAR-62.
Root cause (confirmed by code read) — FirmTransactionServiceImpl.resolveAccountId returned default_account_id blindly. When that pointed at an archived/removed account (its firm_accounts link soft-removed) the downstream withdraw hit a dead account, and MiscCommands.withdraw mapped the resulting IllegalStateException to insufficient-business — so the proprietor was told "the business doesn't have enough funds" — exactly the "seemingly unable to withdraw" report.
Change
resolveAccountId now validates the default is still an owned, live account (isFirmAccount); if stale/unset it self-heals by re-pointing to a surviving account (getAnyAccountId) and persisting it, else throws the new NoFirmAccountException.withdraw catches NoFirmAccountException → new message business.finance.no-account ("This firm has no usable treasury account…"), distinct from insufficient-funds and not-authorizer.Authorizer angle — the other PAR-45 hypothesis (proprietor not on the account's authorizer list) is unchanged behavior: it already produces the distinct not-authorizer message, so it's now cleanly distinguishable from the no-account case.
Tests: unit coverage for unset + stale self-heal and the distinct exception. Full suite + 95% coverage gate green under JDK 21.
Code context — Withdrawals run through
business-rian/…/FirmTransactionServiceImpl.withdraw → resolveAccountId(firmId)(returnsfirm.getDefaultAccountId(), legacy fallbackgetAnyAccountId) and gate onAccount.isRequiresAuthorization()+ authorizer membership. Most likely cause: the firm'sdefault_account_idis null/stale so resolution fails, or proprietors aren't on the account's authorizer list.Next steps: reproduce with (a) a firm whose
default_account_idis unset and (b) a non-authorizer proprietor, then split the error messaging so "no default account" vs "not an authorizer" vs "insufficient funds" are distinguishable. Almost certainly the same root cause as PAR-62 — recommend linking/working them together.