Profile: first-class financial identity (Phase 1)

Runa the Artificer — Backend Engineer

In one breath

Financial identities are now first-class SQL entities with a UUID, name, and payment share — the prerequisite that unlocks groups, per-profile encryption keys, and multi-device sync in every phase that follows.

By the end of this chapter you’ll understand:

• Why promoting payers from a flat JSON file to a SQL profiles table was the right first move
• How the Phase 1 no-behaviour-change approach let the new schema land safely before any data migration
• What the profiles table unlocks for groups and encryption in later phases

Profile: first-class financial identity (Phase 1)

Status: Delivered
CAS: CAS-460
Delivered: 2026-04-24
PRs: #158

What’s new

Casaconomy now stores financial identities — the people whose spending is tracked — in a dedicated profiles database table. Previously, payer data lived in a flat JSON file with minimal structure. Profiles are first-class database entities with a UUID, name, initials, default payment share, and a main-payer flag. This is Phase 1 of a multi-phase migration; the existing UI and CSV import behavior are unchanged.

How to use it

There is nothing new for the board to interact with in Phase 1. The existing payer management screens continue to work as before. The underlying data is now backed by a proper SQL table, which unlocks group membership and group-scoped encryption in the Phases 2 and 3 work that has already landed (CAS-468, CAS-496).

Phase 2 will migrate existing user data into the profiles table and switch the frontend to the new commands.

What changed under the hood

• New profiles table (migration 29) with columns: uuid, name, initials, default_payment_share, main_payer.
• New ProfileService and profiles_db repository layer in Rust, with Tauri commands get_profiles, add_profile, edit_profile, delete_profile.
• Auto-generated TypeScript binding Profile.ts (via ts-rs).
• The legacy get_payers JSON path is preserved unchanged so existing code continues to work during the transition.

Why we built it

The original “payer” concept was a lightweight CSV field — good enough for a single-user app, but too thin to support groups, per-profile encryption keys, or multi-device sync. Promoting profiles to a first-class SQL entity is the prerequisite for all of those features. Doing it as a no-behaviour- change Phase 1 lets us land the schema safely and validate the new layer before migrating data.

Known limitations / follow-on work

• The frontend still reads payers from the legacy JSON path; the cutover to get_profiles happens in a follow-on phase.
• No data migration from the old users JSON is included in this phase.
• CSV import remap to reference profile UUIDs is deferred to a later phase.

See it as

Replacing a sticky-note on the fridge with an entry in the household address book. The sticky-note worked fine for one person, but the moment you need to write someone a letter, share a key, or invite them to an event, you need a real record with a real identity — not a note that blows away in the wind.

Recap

• profiles replaces the flat JSON “payer” concept with a proper SQL entity: UUID, name, initials, payment share, and main-payer flag.
• Phase 1 is a schema-only change — existing UI and CSV import are untouched, and the legacy get_payers path is preserved in parallel.
• This table is the load-bearing foundation for group membership, per-profile encryption keys, and multi-device sync in subsequent phases.

What changed {#what-changed}

See: CHANGELOG → 2026-04-24