- Ya
- 11 Agosti 2026, 01:03 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 67e586e
Three things were missing and one was actively harmful. account_members carried a global unique on member_id — a member could administer exactly ONE billing account platform-wide. That is the ceiling that made every multi-payer arrangement impossible, and it was already doing damage rather than merely limiting: AccountMemberService.add() worked around it by silently DELETING the member's row on their previous account, so granting billing access to one revoked it from another with no warning; and promoteToBillingOwner threw a constraint violation on its second run, turning a double-click into a 500. The composite unique on (account_uid, member_id) already existed and expresses the real rule. Dropping it makes a derived findByMemberId returning Optional throw the moment anyone holds two rows, and nine callers rely on it. It is now a bounded query ordered by creation, so those callers keep the answer they had instead of depending on whatever the planner returns first; findAllByMemberId is there for code that wants all of them. OrgBillingPolicy is the preventive control the owner never had. The 2026-04-16 design specified billing_delegation_mode and implementation dropped it, leaving one irreversible promote gesture and no way to say in advance whether self-payment was permitted at all — while a separate consumer checkout path let members self-subscribe anyway. Where a mode forbids something the surfaces hide it rather than offering it and failing. BillingGroup names an arrangement the model already permitted: AccountSubscription is unique on (account, market, target org), so several accounts could always target one organization. It carries no roster of its own — who holds a seat is SubscriptionMember plus AccountLicense, the same answer as for anyone else, and a second roster would be a second truth to keep in step.