Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Document for Custom User Model #48

Merged
merged 1 commit into from
Apr 15, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions docs/decisions/0003-custom-user-model.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# 0002 Use Custom User Model

- Date: 2024-04-10
- Author(s): [Chen Zhang][chen]
- Status: `Active`

## Decision

Instead of using Django built-in User model, We will use a custom User model which
is based on the Django built-in AbstractUser model and provides all the same features
by default.

## Context

Django comes with a built-in User model which provides basic authentication and
authorisation features. This model includes fields like username, email, password,
and essential methods for user management. However, there're some limitations of
the default User model.

The built-in User model is designed so users can login via username and password,
and won’t be able to login with email and password. Also, we're unable to add new
fields to the default user model.

[The official Django documentation][document] highly recommends using a custom user
model when start a Django project, because it’s hard to switch a user model out for
another once the project is deployed and being used by real users.

## Implications

This custom User model might not be perfect for all use cases, but by making a custom
user model part of the template project we can insure it is as easy as possible to
change and evolve that model later one. Something that is a lot more difficult should
we stick with the built in one.

In some cases, users might lost access to their email address before they update their
email address on the website or APP, and if the project uses email as primary user identifier
it will be difficult for them to get their accounts back.
a-musing-moose marked this conversation as resolved.
Show resolved Hide resolved

<!-- Links -->
[chen]: mailto:[email protected]
[document]: https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project