You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 13, 2019. It is now read-only.
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:
user_id (fk to users table)
heart_rate (decimal)
coordinates (string)
?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
The text was updated successfully, but these errors were encountered: