Skip to main content
Source snapshot: 13 October 2026. These pages describe the current implementation, including unfinished controls. See coverage and review notes.

Family profile

Host: admin.<ROOT_DOMAIN> · Route: /[tenant]/families/[familyId]

Purpose and access

Inspect the household, its members, house links, and family-level welfare information.You need an account session and a resolved membership context in the selected Mahallu (including the API’s current platform elevation path). The API independently checks the requested operation’s permissions and feature availability.

Screen layout

The detail view shows household information and a member roster. It offers Add new member, Add existing member, Edit, and Certificate controls. Member ID values have reveal controls.

Fields and displayed information

Displayed table columns: Members, House, Ward, Address, Contact.

Fields and filters: Family form dialog

Fields and filters: Member form dialog

Fields and filters: Add existing member dialog

Actions

Linked navigation

Interaction sequence

Open a family → Add new member creates a member linked to the household; Add existing member opens an assignment dialog → choose an existing person → save and refresh. Edit opens details/welfare. Deleting through Edit returns to the families registry.

States and rules

Certificate currently shows Coming soon and generates no household certificate. A household without members shows a dedicated empty message. House-update failures in family editing are treated as non-fatal, so the house and family can become inconsistent.Explicit validation messages in the rendered forms:
  • House Name / Family Name is required.
  • Member full name is required.
  • Please select a member to add to this family.
The rendered action controls bind loading indicators to pending state. Failed API saves keep their documented error/notification path; a loading indicator alone does not establish persistence.

Implementation references

Paths below are relative to the application repository. This is source-reviewed behavior, not a recorded browser test.
  • apps/web/src/app/sites/admin/[tenant]/families/[familyId]/page.tsx
  • apps/web/src/features/tenants/family-detail-view.tsx
  • apps/web/src/features/tenants/family-form-dialog.tsx
  • apps/web/src/features/tenants/member-form-dialog.tsx
  • apps/web/src/features/tenants/add-existing-member-dialog.tsx
  • apps/web/src/features/tenants/contribution-history.tsx
  • apps/web/src/features/tenants/record-layout.tsx
Data and access helpers: apps/web/src/lib/session.ts, apps/web/src/lib/server-api.ts, apps/web/src/lib/tenants.ts, apps/web/src/lib/business-resources.ts, apps/web/src/lib/houses.ts, apps/web/src/lib/structure.ts, apps/web/src/lib/members.ts, apps/web/src/lib/api-client.tsRelevant controller permission keys: families.view, families.create, families.update, families.delete. Keys are operation-specific; the current guard grants OWNER/ADMIN and its platform-elevation context an operational bypass. A visible control still does not establish authorization.

API behavior references

  • apps/api/src/families/families.controller.ts