Dependents
A dependent is a gift recipient who doesn’t have a GiftWrapt account: a pet, a baby, a grandparent who never wanted to sign in, anyone with no expectation of autonomy in the app.
Dependents have a name, an optional photo, an optional birthday, and one or more guardian users who manage their lists. They never sign in.
Dependents vs. Children vs. Users
Section titled “Dependents vs. Children vs. Users”GiftWrapt has three different “people” concepts; here’s when each one applies:
| Has an account? | Manages own lists? | Typical use | |
|---|---|---|---|
| User | ✓ | ✓ | An adult family member or friend |
| Child (role) | ✓ | with help | A kid old enough to have a login but young enough that a parent helps manage things |
| Dependent | ✗ | ✗ | A pet, a baby, or anyone who shouldn’t have an account |
If the person is going to sign in - now or later - make them a user (or a child user). Use a dependent only when there will never be a login.
What a Dependent Has
Section titled “What a Dependent Has”| Field | Notes |
|---|---|
| Name | Required. Used everywhere the dependent’s identity is rendered. |
| Photo | Optional. Falls back to a Sprout icon. |
| Birthday | Optional, and it does less than you’d expect - see below. |
| Guardians | One or more user accounts who manage the dependent’s lists. Same model as guardian-of-a-child. |
What a dependent does not have:
- An email address (better-auth’s “users have emails” rule stays intact)
- Roles, partnerships, or access levels
- A way to sign in or be impersonated
What the Birthday Actually Does
Section titled “What the Birthday Actually Does”A dependent’s birthday is mostly a display field today. Concretely:
- No birthday reminder emails go out for a dependent. The reminder crons read birthdays off user accounts only.
- It doesn’t drive auto-reveal. Lists with a dependent as their subject sit outside the auto-archive schedule entirely - there’s no spoiler-protected recipient reading the list, since the guardian managing it is a giftgiver to the dependent, not the one being surprised. So no reveal date is computed and no archive badge renders.
- It does set the deadline for orphan-claim cleanup. If a giftgiver’s claim is orphaned on a dependent’s birthday list, the cleanup uses the dependent’s birthday as the date to resolve it.
Set it if you want it on the record. Don’t set it expecting a reminder.
Guardianship of Dependents
Section titled “Guardianship of Dependents”A dependent’s guardians have the same full view + edit access on the dependent’s lists that guardians of a child user have. See Guardians for the full grant.
A dependent can have any number of guardians (a pet in a multi-adult household is the obvious case). Removing one guardian doesn’t affect the others.
How a List “Belongs to” a Dependent
Section titled “How a List “Belongs to” a Dependent”A list can have a dependent as its subject. The list itself is still owned by the user who created it (ownerId, which is the guardian), but the recipient of the gifts is the dependent.
Permission checks key off the subject, not the owner:
- Any guardian of the subject dependent has full view + edit access.
- An explicit None from any guardian denies the viewer (every guardian has to be willing).
- Public / private toggles still work the same way.
The guardian doesn’t accidentally see the recipient view of their dependent’s list. If they open it, they get the gifter view - they’re a gifter to the dependent, not its recipient.
How the Dependent Shows Up in the UI
Section titled “How the Dependent Shows Up in the UI”Everywhere GiftWrapt would normally render “whose list is this?”, a dependent-subject list renders the dependent’s avatar and name instead of the guardian’s. Specifically:
- List rows in feeds, dashboards, and pickers swap to the dependent’s avatar and drop the Crown badge (a dependent isn’t a list owner).
- The list-detail header shows the dependent’s photo and name.
- The recent feed shows the dependent on items and conversations from those lists.
- Purchases / received-gifts summaries swap the recipient-rendered fields to the dependent.
The guardian’s identity isn’t hidden anywhere it’s relevant - it’s just that “the person this gift is for” is the dependent, not the guardian who created the list.
Claiming on a Dependent’s List
Section titled “Claiming on a Dependent’s List”The list’s guardian can claim items on their own dependent’s list. Same rule as guardians claiming on a child’s list: the guardian is the gifter, the dependent is the recipient, and gift credit follows the normal partner-aware predicate.
The “you can’t claim on your own list” block only fires when the list has no dependent subject and the gifter is the owner.
Setting Up Dependents
Section titled “Setting Up Dependents”Creating a dependent is an admin action. Every write - creating one, editing it, deleting it, adding or removing a guardian - goes through the admin panel and is refused for everyone else on the server, not just hidden in the UI.
Your own /settings/dependents page is read-only. It lists the dependents you’re a guardian of so you know what you’re managing, and points you at an admin for anything else.
Guardians are chosen explicitly when the dependent is created, from the ids submitted with the request. The admin who creates the dependent is recorded as its creator but is not added as a guardian unless they were named as one, so an admin setting up a pet for someone else’s household doesn’t quietly gain access to it.