Substitute the default Admin Class for User objects

Brainstorming of features

• custom filters; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L18 and https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L80
• default ordering of the list; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L83 and https://github.com/django/django/blob/master/django/contrib/auth/admin.py#L63
• remove Django's default bulk delete-action; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L103
• provide a condensed way to provide the user's status
  • by a simple string; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L118
  • by coloring the username; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L130
  • by tagging the username; see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L144
  • provide a legend, if color-status or tagged-status is used
• combine the email-address with the respective verification status
  • see https://github.com/Mischback/django-miniuser/blob/development/miniuser/admin.py#L158
  • probably the biggest challenge, because here the original User-model is connected to UserEnhancement

Some of Django's default settings should be adjusted, when using django-auth_enhanced. Write corresponding checks (level: Warn)

• LOGIN_URL
• email configuration

While django-auth_enhanced is designed to work with Django's default User-model, it should work with custom user models aswell, if some minimum requirements are met.

This issue is about implementing enough abstraction to work with these custom models, aswell as checking minimum requirements of these models.

• be as abstract as possible
  • do not assume certain model fields are always present and decouple them
    • don't reference username (use get_user_model().USERNAME_FIELD)
    • don't reference email (use get_user_model().EMAIL_FIELD)
    • implement some tests using a minimal custom user model and see, if the app still works
  • check Django's documentation about a minimal user model and try to achieve the same minimum requirements
  • implement checks for these minimum requirements
    • probable required properties: is_active, is_staff, is_superuser

Make password resettable

• Should passwords be resettable, if there is no verified email address?
• Determine, how long a password reset link should be valid (-> make configurable)
• Implement password reset view (or re-use Django's)
• Integrate with admin backend

Implement all necessary functions to register new users.

• email address has to be unique
  • Django's email-field is not unique (see: https://github.com/django/django/blob/master/django/contrib/auth/models.py#L288)
  • enforce uniqueness on this logical level during registration (probably by including an adequate check in the respective form implementation)
• different registration modes:
  • register and go: fill the registration form and the newly created account is activated by default and usable immediately
  • register and wait for approval: fill the registration form and then wait, until some staff personnel activates the account manually
  • register and validate: fill the registration form (including a required email); an automatically generated email is send to verify the address, including a verification token / link; after using the token / link, the account is activated and usable
• notification of staff members
• add actions to Django's admin IOT
  • activate / deactivate users
  • re-send the verification mail

The app should be installable using Pythons package management.

• make the package/application installable from pypi

Django does provide all necessary functions to handle login and logout, but does not really make the usable.

• provide URLs for login and logout
• provide templates for login and logout

Make the password changeable by the user

• [RESEARCH] Is there a re-usable Django implementation?

In #9 the setting 'DAE_ADMIN_SIGNUP_NOTIFICATION' was introduced and implemented.

While its documentation already mentions, that this setting should consist of valid users of the respective Django project, this is not enforced by any check.

Reason: While the checks are performed using Django's Check Framework, the database is not yet available.

When is this setting used? The setting is used during the process of user-registration. In order to not hit the database to fetch the superusers email addresses, this setting is used.

Possible workaround: Creating a custom, app-specific management command. This command could be used to verify, that the specified usernames are valid users of the Django project, that their respective mail addresses are indeed legit (and verified) and that they have sufficient permissions to actually manage User-objects.

As of this writing (currently: Django 2.0.4), while rendering forms with Django, the file https://github.com/django/django/blob/2.0.4/django/forms/templates/django/forms/widgets/input.html is used. It appends a trailing slash to input-widgets, which is not fully html5-compliant.

However, in master, this issue is already fixed and should be included NLT Django 2.1.0.

Currently, the form-widgets are included in the html-templates manually, meaning that they are hardcoded. Of course, this has to be changed to return to {{ form.field }} again.