Skip to content

Users, Groups & Permissions

So far we've been logged in as the admin account, a superuser, which can do anything, such as deleting animals or creating user accounts.

Info

Django doesn't check a superuser's permissions at all.

Two kinds of people at the rescue work in the admin:

  • Employees are the people the shelter pays. They handle animals and adoption applications.
  • Volunteers help with intake: they add animals and keep their records up to date. They don't see adoption applications.

Neither should be able to do everything the admin account can.

Staff Status

Every account that logs in to the admin needs staff status: the user's is_staff field. Staff status alone lets an account log in to the admin, and nothing more. What it can do there comes from permissions.

Django's Built-in Permissions

Permissions are Django's authorization: what a logged-in account may do.

When we run migrate, Django creates four permissions for every model: add, change, delete, and view (CRUD).

Groups

We can give permissions to a user directly, but then we'd have to set them for every volunteer.

A group holds a set of permissions, assigned to every user in the group.

Groups and accounts are rows in the database, so a command can create them. The seed command's --accounts option makes our two groups, and an account in each, with staff status:

  • Employees can add, change, and view animals, and view and change adoption applications. The account is employee, with the password rescue-employee.
  • Volunteers can add, change, and view animals. The account is volunteer, with the password rescue-volunteer.

It also creates admin / rescue-admin if there's no admin account. In the other terminal, run:

shell
uv run manage.py seed --accounts

Without --reset, the seed leaves the animals and applications as they are, and says so: "The database already has 47 animals. Pass --reset to replace them."

Under Groups, each group's page lists its permissions. Under Users, each account's page has Staff status ticked and the account's group.

We only use permissions in the admin. Checking them in our own views, permissions on the API, and logging in outside the admin are out of scope for now.