auth.models.Permission

class models.Permission

auth.models.Group.permissions

permissions Many-to-many field to Permission: group.permissions.set([permission_list]) group.permissions.add(permission, permission, ...) group.permissions.remove(permission, permission, ...) group.permissions.clear()

auth.models.Group.name

name Required. 80 characters or fewer. Any characters are permitted. Example: 'Awesome Users'.

auth.models.Group

class models.Group

auth.models.CustomUserManager.create_user()

create_user(*username_field*, password=None, **other_fields) The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as: def create_user(self, email, date_of_birth, password=None): # create user here ...

auth.models.CustomUserManager.create_superuser()

create_superuser(*username_field*, password, **other_fields) The prototype of create_superuser() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_superuser should be defined as: def create_superuser(self, email, date_of_birth, password): # create superuser here ... Unlike create_user(), create_superuser() must require the caller to provide

auth.models.CustomUserManager

class models.CustomUserManager create_user(*username_field*, password=None, **other_fields) The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as: def create_user(self, email, date_of_birth, password=None): # create user here ... create_superuser(*username_field*, password, **other_

auth.models.CustomUser.USERNAME_FIELD

USERNAME_FIELD A string describing the name of the field on the User model that is used as the unique identifier. This will usually be a username of some kind, but it can also be an email address, or any other unique identifier. The field must be unique (i.e., have unique=True set in its definition), unless you use a custom authentication backend that can support non-unique usernames. In the following example, the field identifier is used as the identifying field: class MyUser(AbstractBaseUs

auth.models.CustomUser.REQUIRED_FIELDS

REQUIRED_FIELDS A list of the field names that will be prompted for when creating a user via the createsuperuser management command. The user will be prompted to supply a value for each of these fields. It must include any field for which blank is False or undefined and may include additional fields you want prompted for when a user is created interactively. REQUIRED_FIELDS has no effect in other parts of Django, like creating a user in the admin. For example, here is the partial definition

auth.models.CustomUser.is_active

is_active A boolean attribute that indicates whether the user is considered “active”. This attribute is provided as an attribute on AbstractBaseUser defaulting to True. How you choose to implement it will depend on the details of your chosen auth backends. See the documentation of the is_active attribute on the built-in user model for details.