In Django one of the least explored parts in documentation and by users is the Django Admin, this one with great capabilities and certain characteristics, but to be a 100% viable option these must be worked at the level of user experience, and this Is the reason for its unpopularity, of there is the question, what is the admin Dajngo for? its viable?
In essence, the admin of Django is a web interface to manage database models, in this interface you can create, view, modify and delete data from the database, as well as special operations that are also related to the data.
We do not need it when from the web client we can manage all or most of the essential data of our application.
If we think about it by observing the previous paragraph, we could conclude that there could be data that the client does not necessarily have to administer or that need to be managed, where an administrator on a different platform could manage it, this is the simplest use that could be given to this tool.
This makes the Django admin perfect for an MVP, where the client does not necessarily manage all the data, or because initially all the administration interfaces cannot be created, and the data needs to be managed by the different areas of the company such as the operators, the product team, marketing, etc, and there is where the admin comes into action, since with some lines of code you can reach good administration interfaces for the data.
But if it is so good for this because it is not used or contemplated on a regular basis to work as administration interfaces, both on the side of customers and operators? Basically because this administrator is very attached to the data side, and its incorrect administration or programming could lead to security breaches, system failures, or an intuitive interface, that is why it is not recommended to enable it for end customers of no way.
Already knowing all this, and assuming that we are willing to take responsibility, can we use it? The answer is yes, and it is important that if we want to use it we must take into account the following aspects:
It is very important to plan very well how the data will be structured even before throwing a line of code, this will affect the future development, the administration interface since this is reactive to the data, and above all it will affect the data. customers who consume our data.
Warning: an important functionality is the nested forms, these can show in a single view a lot of information towards a parent, their relationship is from children to the father, the problem with these views is that if there is a lot of nested information the template engine becomes a bottleneck since this is very slow to show a lot of data, and the performance will be much more impacted when there are children related to children and these with parents.
In this part, django admin is very good at creating a database record to manage groups and users, giving permissions to models at the level of reading, writing and modification, and according to what permission the user has, the interface adapts to Provide the options available to that particular user.
It is also important that if we want a user model with additional information other than what it already brings natively, what we need is to create a new model that inherits the native and add those fields, then tell the admin to use this model to manage the users.
By default the django admin does not show the information just by creating the models, even the administrator access url is not programmed by default, the administrator interface must be all programmed using the options addressed to the admin that the Django team gives us in its documentation, and the interface will react to the programmed options, from the presentation of the texts, the search or indexing of information, the amount of information and how it is shown to the administrator must be programmed.
This is where things get a bit complicated, because to be able to modify the way in which the native options that are given to us to program the administrator what we have to do is intervene the django admin's functionalities, when I mean intervene it means modifying or replace the functionalities to deliver the same data structure and that the administrator does not break because later functionalities expect a unique data structure, unless we also intervene that other functionality, to do this there are documentation and several examples of troubleshooting on the Internet , you also need to have more or less advanced knowledge of Python.
Here everything is much more complicated, and it is important to have advanced knowledge of Python as of the framework, since this is to make the admin do things for which it is not yet done, an example can be a confirmation window, a possible way If this is done, it would be necessary to extend the urls of the Django admin by associating it with a view with a form, this view must receive the request and show a confirmation view, at the time of confirming the action this view must post its own form url with the data necessary to continue the action, this in detail does not have the admin by default and to build it requires to have good programming knowledge.