Managing Users
Creating a User
Changing User Settings
Changing User Password
Caregiver Users
A caregiver is a user intended for a babysitter or other temporary carer. The role is a Django group, so it grants a set of model permissions and nothing more.
With the default group permissions, a caregiver can:
- view children, timers, feedings, diaper changes, sleep entries, medication, temperature, weight, notes and tummy time;
- add and edit feedings, diaper changes, sleep entries, timers, medication, temperature, weight, notes and tummy time, through both the web interface and the API;
- open the child dashboard, the timeline and the reports for those entry types.
With those defaults, a caregiver cannot:
- delete any entry, including a timer;
- see or record pumping, height, BMI or head circumference, in lists, on the dashboard, in the timeline or in reports;
- manage children, tags, users, change site settings or reach the database admin area.
The group is a starting point, not a fixed role. A caregiver is an ordinary
Django user, so the permissions can be extended per user afterwards — grant the
ones the group does not include, such as pumping or the growth measurements —
from the database admin area at /admin/, where Django's built-in permission
picker lives. The granularity is additive only: Django has no per-user deny,
so an individual can be given more than the group, not less. Take a permission
away from one caregiver and it either stays granted through the group or has to
be removed for everybody.
Group permission changes apply to all existing members, not just newly created
users. Each migration run adds any missing default permissions back to the
group and retains manually added permissions. Removing a default from the group
is therefore not a lasting restriction: the next migrate restores it.
Per-user permissions are the way to extend one caregiver's access without
changing everybody else's defaults.
Converting a timer into a feeding, sleep or tummy-time entry deletes the timer.
A caregiver can do this for the timers they started. Converting another user's
timer requires core.delete_timer, which also permits deleting any timer.
Editing a timer does not change who it belongs to, and changing the user of an
existing timer through the API also requires core.delete_timer.
Tags already attached to an entry remain visible and are preserved when a
caregiver edits the entry without changing its tags. Changing tag assignments
requires core.change_tag; creating new tag names additionally requires
core.add_tag. These permissions are not included in the caregiver group.
The role is not limited to one child
A caregiver has access to every child on the instance, and may edit entries that other users created. There is no per-child grant, and Baby Buddy does not record which user created an entry, so a caregiver's entries cannot be told apart from anyone else's afterwards.
To withdraw access, clear the Active checkbox on the user, or delete the user. Subsequent web and API requests are denied, including requests using an existing API key. Do not simply clear the Caregiver checkbox in Baby Buddy's user form: saving with neither restricted role selected makes the account a standard (superuser) user. Removing group membership directly in Django's admin does not itself change the superuser flag, but any other permissions remain.
Read only and caregiver are mutually exclusive: a caregiver creates entries,
which is exactly what the read-only role forbids. Caregiver and Staff are
also mutually exclusive in the user form and the createuser command, because
staff access opens administrative pages. When converting an existing account,
review its other groups and individual permissions as well. Changing a role
does not remove those additional grants, so switching an extended caregiver to
read only does not necessarily remove all write access.
Access Expiry
A user can be given an Access expires time in the user form, for example for a babysitter who helps out for a weekend. From that time on, the user is signed out, cannot sign in and cannot use the API, including with an existing API key. The account itself is left unchanged: clearing or moving the time restores access. Users cannot change their own expiry time.
Creating a User from the Command Line
A user's type can be:
- Caregiver (can view the child dashboard and add/edit feedings, diaper changes, sleep entries, timers, medication, temperature, weight, notes and tummy time for every child on the instance. Intended for a babysitter or other temporary carer; the default timer and tag restrictions above apply)
- Read only (can access all data but not make new entries)
- Standard (default, can access and make/edit any type of entry)
- Staff (can access user management, site settings and the Database Admin area; available actions still depend on the account's permissions)
There are 2 ways you can create a user from the command line:
- Passing user's password as an argument:
python manage.py createuser --username <username> --password <password>
This will create a user with the standard privileges.
- Interactively setting user's password:
python manage.py createuser --username <username>
You will then be prompted to enter and confirm a password.
- If you want to create a user with read only privileges, pass in the
--read-onlyflag:
python manage.py createuser --username <username> --password <password> --read-only
- To create a caregiver who can log feedings, diaper changes, sleep, timers,
medication, temperature, weight, notes and tummy time, pass
--caregiver. It cannot be combined with--read-onlyor--is-staff:
python manage.py createuser --username <username> --password <password> --caregiver
- If you want to create a user with the highest level of permission, you can append the
--is-staffargument:
python manage.py createuser --username <username> --is-staff
- Another argument you can use with this command is
--email
python manage.py createuser --username <username> --email <email>
- To get a list of supported commands:
python manage.py createuser --help