Skip to content
This repository has been archived by the owner on Nov 13, 2019. It is now read-only.

Schema #1

Open
ghost opened this issue Nov 2, 2019 · 0 comments
Open

Schema #1

ghost opened this issue Nov 2, 2019 · 0 comments

Comments

@ghost
Copy link

ghost commented Nov 2, 2019

We currently have django's default user table, which has the following fields (from the documentation):

first_name¶
Optional (blank=True). 30 characters or fewer.

last_name¶
Optional (blank=True). 150 characters or fewer.

email¶
Optional (blank=True). Email address.

password¶
Required. A hash of, and metadata about, the password. (Django doesn’t store the raw password.) Raw passwords can be arbitrarily long and can contain any character. See the password documentation.

groups¶
Many-to-many relationship to Group

user_permissions¶
Many-to-many relationship to Permission

is_staff¶
Boolean. Designates whether this user can access the admin site.

is_active¶
Boolean. Designates whether this user account should be considered active. We recommend that you set this flag to False instead of deleting accounts; that way, if your applications have any foreign keys to users, the foreign keys won’t break.

This doesn’t necessarily control whether or not the user can log in. Authentication backends aren’t required to check for the is_active flag but the default backend (ModelBackend) and the RemoteUserBackend do. You can use AllowAllUsersModelBackend or AllowAllUsersRemoteUserBackend if you want to allow inactive users to login. In this case, you’ll also want to customize the AuthenticationForm used by the LoginView as it rejects inactive users. Be aware that the permission-checking methods such as has_perm() and the authentication in the Django admin all return False for inactive users.

is_superuser¶
Boolean. Designates that this user has all permissions without explicitly assigning them.

last_login¶
A datetime of the user’s last login.

date_joined¶
A datetime designating when the account was created. Is set to the current date/time by default when the account is created.

We can create a separate profile model for each kind of user. One for EMTs or Fire, and one for administrators. These will be groups the users can be added to, with certain permissions on them.

We can have another table called status_logs, which records the current heart rate and location of a first responder. It can have the following fields:

  1. user_id (fk to users table)
  2. heart_rate (decimal)
  3. coordinates (string)
  4. ?
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants