From c397597ae6585e7d3eeb5e1fcae6156e8d735501 Mon Sep 17 00:00:00 2001 From: Neil Martinsen-Burrell Date: Tue, 27 Sep 2022 13:31:42 -0500 Subject: [PATCH] ADR to go with this PR --- .../decisions/0010-user-models.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 docs/architecture/decisions/0010-user-models.md diff --git a/docs/architecture/decisions/0010-user-models.md b/docs/architecture/decisions/0010-user-models.md new file mode 100644 index 000000000..d4d9e77aa --- /dev/null +++ b/docs/architecture/decisions/0010-user-models.md @@ -0,0 +1,40 @@ +# 10. Use custom User model with separate UserProfile + +Date: 2022-09-26 + +## Status + +Proposed + +## Context + +Django strongly recommends that a new project use a custom User model in their +first migration +. +This allows for future customization which would not be possible at a later +date if it isn’t done first. + +In order to separate authentication concerns from various user-related details +we might want to store, we want to decide how and where to store that +additional information. + +## Decision + +We use a custom user model derived from Django’s django.contrib.auth.User as +recommended along with a one-to-one related UserProfile model where we can +separately store any particular information about a user that we want to. That +includes contact information and the name that a person wants to use in the +application. + +Because the UserProfile is a place to store additional information about a +particular user, we mark each row in the UserProfile table to “cascade” deletes +so that when a single user is deleted, the matching UserProfile will also be +deleted. + +## Consequences + +If a user in our application is deleted (we don’t know at this point how or +when that might happen) then their profile would disappear. That means if the +same person returns to the application and makes a new account, there will be +no way to get back their UserProfile information and they will have to re-enter +it.