Skip to content

Profile: first-class financial identity (Phase 1)

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.