Chapter 6: Exploring the Django Admin Site

This chapter will introduce the Django admin site, which is a feature allowing developers to register certain models into a model-centric interface where only permitted users can manage database content. This feature is designed to read the metadata related to models as well as the fields and field constraints set on those models to build a set of pages that search, sort, filter, create, edit, and delete records found in those tables.

The admin site is an optional feature of the Django framework that can be used in projects. It allows us to use user-based roles and permission settings that are built into the Django framework, allowing only permitted users to edit, add, or delete objects. User roles can be modified to only grant permission to edit certain models and can even be set to a granular level, such as only letting a user edit or view data but not add or delete data. This feature can be deactivated if it is not desired or needed...

Technical requirements

To work with the code in this chapter, the following tools will need to be installed on your local machine:

• Python version 3.9 – used as the underlying programming language for the project
• Django version 4.0 – used as the backend framework of the project
• pip package manager – used to manage third-party Python/Django packages

We will continue to work with the solution created in Chapter 2, Project Configuration. However, it is not necessary to use the Visual Studio IDE. The main project itself can be run using another IDE or run independently using a terminal or command-line window from within the project root folder, which is where the manage.py file resides. Whatever editor or IDE you are using, a virtual environment will also be needed to work with the Django project. Instructions for how to create a project and virtual environment can be found in Chapter 2, Project Configuration. You will need a database to store...

Using the Django admin site

Django makes it easy to use the admin site right out of the box. In order to use this feature, we need to add an app to the settings.py file and register a URL pattern to handle any project's admin links. By default, these settings should already exist in the code when a project is created using the startproject command or by using the IDE. However, some tools and versions may generate code slightly differently and so it is always good to just double-check that these settings are configured in this way.

Activating the Django admin site

To make sure the Django admin site is activated in your project, follow these steps:

1. In the main settings.py file, add the following app to the INSTALLED_APPS variable and make sure this is at the top of the list:

   # /becoming_a_django_entdev/settings.py
   ...
   INSTALLED_APPS = [
       'django.contrib.admin',
       ...
   ]

2. If the /chapter_6/urls.py file does not...

Configuring admin class options

Django provides admin class options for customizing the Django admin site interface directly. In this section, we will go through some of the most important and widely used options and provide examples of how to use them. We don't have enough room to discuss them all in great detail.

For a complete breakdown of how to use any of the options available, visit the official Django documentation, found here: https://docs.djangoproject.com/en/4.0/ref/contrib/admin/#modeladmin-options.

The following options have been broken down into categories based on what view type they relate to (changelist view, change or add view, and just the add view).

Note

Before adding any of the options to your admin classes, remember to remove the pass statement that was previously written for that class as a placeholder.

Changelist view-related options

These options relate to an admin class on the changelist view page, such as those listed here:

...

Adding admin class methods

Admin class methods allow us to add or change the default behavior of a ModelAdmin or UserAdmin class. Any of the options available in an admin class can have its value dynamically calculated by writing a method. Those methods use the get_ naming convention and then the name of the option, as in get_ordering() or get_form(). Django also provides many built-in methods that add extra actions when something happens, such as when an object is saved or deleted using the save_model() or delete_model() methods.

Next, we will explore just some of these methods and also provide a demonstration using a dynamic value, specifically for the form option. That will prepare us to use a separate form class later in this chapter.

For a complete breakdown of how to use Django admin class methods, visit the official Django documentation here: https://docs.djangoproject.com/en/4.0/ref/contrib/admin/#modeladmin-methods.

Method – get_form()

The get_form() method...

Writing custom admin form classes

Admin forms can be created and used just like the standard form classes we discussed in Chapter 5, Django Forms. For admin form classes, we need to use the Django ModelForm class instead of the standard Form class found in the django.forms library, because the fields in these forms will link to model classes. Refer to the examples found in Chapter 5, Django Forms, to learn more about how to customize and change your form class behavior, for either a Form or ModelForm class. Here, we will demonstrate just initializing your admin forms and enabling all fields that exist, to allow any of the engine change and add view pages to load without the errors mentioned earlier.

Initializing an admin form

If you have not already done so, in the chapter_6 app folder, create a file called forms.py. We need to create the three different form classes used in the previous examples of this chapter and call them EngineForm, AddEngineForm, and EngineSuperUserForm...

Using the Django authentication system

Django provides a very powerful authentication system to grant permission rights to users. By default, a superuser has the authority to do everything, which is why we had to create at least one superuser in Chapter 2, Project Configuration. That superuser is needed at all times within the Django system to maintain control of your site and your data. The superuser granted us the ability to take control of our system and establish user roles and groups for every other user in the system. Creating a user and superuser can be done via the command line using a Django management command or through the IDE, just like when we explored those subjects in Chapter 2, Project Configuration. It can also be done through the Django shell, as we did in Chapter 3, Models, Relations, and Inheritance, when we created and saved models using the Django shell. user and Seller are just other model objects that we create and save. Now that we have access to the Django...

Summary

We activated and customized the Django admin site for a project, otherwise known as the admin panel. This powerful tool helps us to get up and running with search, filter, sort, create, edit, and delete capabilities for all of the models that we choose to register on this site. With the concepts provided in this chapter, you should be able to make your admin panel a very useful tool that your users will enjoy.

With the authentication system that Django provides, many different types of users can all access and use the same site but have very different roles and uses. Each type of user could even be given entirely different templates and flows if we venture down the road of extending templates or building onto that templating system using the concepts provided in previous chapters.

In the next chapter, we will discuss sending emails, creating custom email templates, as well as creating PDF reports using the Django template language.