feat(fostering): guardian + stay records for fostered rabbits (admin-only) #20

New issue

Open

opened 2026-09-11 00:58:10 +01:00 by Hermes · 0 comments

Hermes commented

2026-09-11 00:58:10 +01:00

Collaborator

Summary

Track rabbits that are fostered from an owner (ownership stays with the owner; we act as legal guardian for veterinary treatment purposes). Entirely admin-managed — no public form, since this represents an existing relationship staff set up directly rather than a cold inbound request.

Key design goal: no duplicate records for repeat stays

A rabbit may be fostered with us multiple times (e.g. owner's annual holiday). We must not create a new rabbit/owner record each time. Guardian-centric model:

FosterGuardian (one row per owner, reusable across all their rabbits): name, phone, email, address, status (active/inactive), notes, and a legal-guardian-for-vet-treatment acknowledgement + timestamp + text version (captured by staff on the owner's behalf, e.g. from a signed/verbal agreement).
Rabbit: add nullable foster_guardian_id FK. A guardian can have many linked rabbits. No change to the existing status enum — rabbit status stays Fostering for the life of the relationship.
FosterStay: FK to rabbit_id (not guardian, since a guardian's rabbits have independent stay histories). Fields: arrival_date, departure_date (nullable while ongoing), status (booked/checked_in/checked_out/cancelled), notes.

Each subsequent visit is just a new FosterStay row against the same rabbit — owner details and rabbit record are entered once. hutch_id on the rabbit is set on check-in and cleared on check-out, so the rabbit naturally drops out of hutch occupancy between visits without needing extra statuses.

When a foster relationship ends permanently, the guardian is simply set to inactive — no rabbit status change, history preserved on the rabbit and stay records.

Admin UI (`/fosters`)

Guardian list + search (name/phone/email) — a small CRM-style view.
Guardian detail page: owner info, legal-guardian ack, table of linked rabbits each showing stay history.
"Add rabbit to guardian": link an existing rabbit or create a new one directly under this guardian.
"New stay" on a rabbit: arrival date (+ optional hutch), departure date filled in on check-out.
Check-in/check-out actions as small HTMX row-refresh POSTs, mirroring the existing "mark cleaned"/"mark played" hutch actions.

Notes

No public-facing route for this feature (contrast with surrenders/adoptions).

## Summary Track rabbits that are fostered from an owner (ownership stays with the owner; we act as legal guardian for veterinary treatment purposes). Entirely admin-managed — no public form, since this represents an existing relationship staff set up directly rather than a cold inbound request. ## Key design goal: no duplicate records for repeat stays A rabbit may be fostered with us multiple times (e.g. owner's annual holiday). We must not create a new rabbit/owner record each time. Guardian-centric model: - **`FosterGuardian`** (one row per owner, reusable across all their rabbits): name, phone, email, address, status (`active`/`inactive`), notes, and a legal-guardian-for-vet-treatment acknowledgement + timestamp + text version (captured by staff on the owner's behalf, e.g. from a signed/verbal agreement). - **`Rabbit`**: add nullable `foster_guardian_id` FK. A guardian can have many linked rabbits. No change to the existing status enum — rabbit status stays `Fostering` for the life of the relationship. - **`FosterStay`**: FK to `rabbit_id` (not guardian, since a guardian's rabbits have independent stay histories). Fields: arrival_date, departure_date (nullable while ongoing), status (`booked`/`checked_in`/`checked_out`/`cancelled`), notes. Each subsequent visit is just a new `FosterStay` row against the same rabbit — owner details and rabbit record are entered once. `hutch_id` on the rabbit is set on check-in and cleared on check-out, so the rabbit naturally drops out of hutch occupancy between visits without needing extra statuses. When a foster relationship ends permanently, the guardian is simply set to `inactive` — no rabbit status change, history preserved on the rabbit and stay records. ## Admin UI (`/fosters`) - Guardian list + search (name/phone/email) — a small CRM-style view. - Guardian detail page: owner info, legal-guardian ack, table of linked rabbits each showing stay history. - "Add rabbit to guardian": link an existing rabbit or create a new one directly under this guardian. - "New stay" on a rabbit: arrival date (+ optional hutch), departure date filled in on check-out. - Check-in/check-out actions as small HTMX row-refresh POSTs, mirroring the existing "mark cleaned"/"mark played" hutch actions. ## Notes - No public-facing route for this feature (contrast with surrenders/adoptions).

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

cpressland/rabbitdb#20

No description provided.

Rows
Columns

feat(fostering): guardian + stay records for fostered rabbits (admin-only) #20

Summary

Key design goal: no duplicate records for repeat stays

Admin UI (/fosters)

Notes

Admin UI (`/fosters`)