Skip to content

Guardians

A guardian has full access to a child’s or dependent’s lists, public or private, with no per-list opt-in required. Guardianship is the strongest grant in GiftWrapt and bypasses every other access setting.

CapabilityAllowed?
See all of the child’s lists (public and private)
Create new lists on the child’s behalf
Edit / delete items on any of the child’s lists
See claims and add-ons that giftgivers leave
Trigger the reveal flow on the child’s behalf
Claim items on the child’s list (counts as a gift to them)
Be marked Restricted or None by the child✗ (rejected)
Inherit any access on the guardian’s own lists

The guardian effectively acts as the child for list management. The child still owns the list row (ownerId); the guardian is just the one with the keys.

Guardianship is one-way: the guardian has access on the child’s lists, the child has no special access on the guardian’s lists. If you want bidirectional coordination, that’s what partners and list editors are for.

A child can have any number of guardians. All of them have the same full-access grant in parallel. Typical setups:

  • Two parents sharing access to their kid’s lists.
  • A parent and a grandparent who help manage a young child’s birthday list.
  • Co-parents in separate households each managing their own copy of the relationship.

Removing a guardian doesn’t remove the others, and doesn’t archive the child’s lists.

A few hard rules:

  • Children can’t be guardians. A user with the child role can’t be assigned as a guardian, either of another child or of a dependent. Enforced in the admin UI today; if you build any new programmatic surface that creates guardianships, add the check.
  • Children can’t be partners. Related rule; same constraint.
  • You can be a guardian of as many children and dependents as you like. No cap.

Guardianship overrides every other access setting:

  • Marking a child or their guardian as Restricted has no effect - the resolver short-circuits to View.
  • A list-editor row is unnecessary on the child’s lists; the guardian has edit already.
  • The child can’t deny their guardian via the access-level UI; the controls are hidden for that pair.

This is intentional. Guardianship implies “I’m responsible for managing this person’s account,” which is a stronger claim than any user-set privacy override.

A guardian can claim items on their own child’s list. They’re treated as a normal gifter for that claim - the child is the recipient, the guardian is the gifter. Gift credit follows the normal partner-aware predicate.

Guardian relationships are managed from the admin panel. There’s no end-user “request to be my guardian” flow today; an admin sets up the link, and the child’s parents take it from there.