Abstract forms meant to be inherited or concrete forms meant to be used direction in your views.
Note
These forms are unnecessary starting in Django 2.1, as Django now supports custom user models in its own forms.
UserCreationFormBases: AbstractUserCreationForm
Form to create an unprivileged user
A concrete implementation of AbstractUserCreationForm that uses an e-mail address as a user’s identifier.
email (EmailField) – Email address
full_name (CharField) – Full name
short_name (CharField) – Short name
password1 (CharField) – Password
password2 (CharField) – Enter the same password as above, for verification.
Clean email; set nice error message
Since User.email is unique, this check is redundant, but it sets a nicer error message than the ORM. See #13147.
Return all media required to render the widgets on this form.
Bases: AbstractUserChangeForm
Form to update user, but not their password
password (ReadOnlyPasswordHashField) – Raw passwords are not stored, so there is no way to see this user’s password, but you can change the password using this form.
last_login (DateTimeField) – Last login
is_superuser (BooleanField) – Designates that this user has all permissions without explicitly assigning them.
groups (ModelMultipleChoiceField) – The groups this user belongs to. A user will get all permissions granted to each of their groups.
user_permissions (ModelMultipleChoiceField) – Specific permissions for this user.
is_staff (BooleanField) – Designates whether the user can log into the admin site.
is_active (BooleanField) – Designates whether this user should be treated as active. Unselect this instead of deleting accounts.
date_joined (DateTimeField) – Date joined
full_name (CharField) – Full name
short_name (CharField) – Short name
email (EmailField) – Email address
Return all media required to render the widgets on this form.
Bases: ModelForm
Abstract Form to create an unprivileged user
Create a User with no permissions based on username and password.
password1 (CharField) – Password
password2 (CharField) – Enter the same password as above, for verification.
Run password validaton after clean methods
When clean methods are run, the user instance does not yet exist. To properly compare model values agains the password (in the UserAttributeSimilarityValidator), we wait until we have an instance to compare against.
https://code.djangoproject.com/ticket/28127 https://github.com/django/django/pull/8408
Has no effect in Django prior to 1.9 May become unnecessary in Django 2.0 (if this superclass changes)
Check wether password 1 and password 2 are equivalent
While ideally this would be done in clean, there is a chance a superclass could declare clean and forget to call super. We therefore opt to run this password mismatch check in password2 clean, but to show the error above password1 (as we are unsure whether password 1 or password 2 contains the typo, and putting it above password 2 may lead some users to believe the typo is in just one).
Return all media required to render the widgets on this form.
Save the user; use password hasher to set password
Bases: ModelForm
Base form update User, but not their password
password (ReadOnlyPasswordHashField) – Raw passwords are not stored, so there is no way to see this user’s password, but you can change the password using this form.
Change user info; not the password
We seek to change the user, but not the password. Regardless of what the user provides, return the initial value. This is done here, rather than on the field, because the field does not have access to the initial value
Return relative path to password form
Will return rel_password_url attribute on form or else ‘../password/’. If subclasses cannot simply replace rel_password_url, then they can override this method instead of __init__.
Return all media required to render the widgets on this form.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4