Hidden gems of Django Admin. Part 1 - Maxim Danilov

My name is Maxim Danielev and today I want to speak about an important part of Django. I want to speak about Django Contrib Admin. Uh I work with uh Django Country Padmin around uh seven years. I start to work with Django from uh Tw twenty thousand thirteen and from twenty uh two thousand uh fifteen I work explicitly uh with uh Django Country Padmin. I want to say thanks for my team. Uh Anastasia Sen uh created this presentation thanks Anastasia

uh our senior developer Pelikin Pavel uh tested all my uh created all my crazy ideas and Martin Achenreiner is our intern. He tested all uh of whole code Thank you Martin. I'm owner from uh Webasoft company and uh mostly what we do at work we drink. Yeah, we drink wine. We serve a bitgest database about alcohol about wines in Europa. And uh Everyone had one incredible project in

own life or pet project. And my my pet project or mine crazy idea, I want to use Janga Country Padmin. uh so much as possible and I won't I don't want to change uh much or I don't want to overwrite a much in this library I think this library is really powerful. First words. DjangoConTrip admin is buggy and has uh hardcore. What I mean. Django country padmin is bugged and in Django Country Padmin we have many hardcodes. All is hard-coded.

URLs, names, variables , constants , settings all is uh into the code. If we want to change something we should to override it. And of course, all of that is not documented. Completely not documented. Something what we can find on Django project, this is a one person from this library. Okay. And right now we should speak about different undocumented feature in Django Country Padmin. At first to start, I want to create one app in my project.

In this app I need only two uh files uh I need files app and some other files. And uh to start to work with um admin panel in Django uh we can create uh config class which can uh set up our uh admin panel. Somebody understand or if I say admin panel in Django? Who can understand it? Okay. And uh admin config help us to uh um to set up uh the this admin part of Django

and Of course, we can create additional site admin class which shows us the whole information. And I already defined this class And it's all normally this you can still find in documentation, and we can override some small elements. And after that uh we should uh to define um to write uh my new application with uh admin site uh class and uh with admin config In setup of my project, and in documentation we can find this

example. And I think this is wrong. Really this is wrong. Why? I can define it normally. I can define it simply to write name of my project. I don't uh write to I I should not I don't need to write the full part to the uh admin config. I can it uh Django take it from my uh application automatically. And uh why I think we should do it like this If we start to work with big projects, the good praxis we should

define at first. uh bulletins application at second part we should define the third party application and at the end we should define our local application. And if I should to define something above on in the uh other art uh mm I don't like it. If a new developer come to my company they don 't cannot understand uh um for from the first glance how it works, what he should to do. And of course we can do it a little bit better. We can split our setup on the three parts and after that if

we want to override something automatically it's uh mm lighter to override. The one undocumented feature is we cannot in early parts of Django we cannot define uh admin uh after the admin docs uh application it not works but thanks for last uh last update from django right now it works i can define admin behind the um admin docs uh probably it's it's here. Yep. Uh uh I can add okay. Admin docs right now we can put admin docs

in uh our uh apps uh install it apps everywhere. Thank you for developers of Jenga. And The last part what we should do, we should define the URLs, which contains the whole part of URLs of admin site. And in documentation we can find this example. And a little bit later I show you this is wrong, or probably wrong. Okay, next step. If we start our admin panel, we see it works, but something wrong here, I think.

What uh what I mean Next our feature as is this is uh model uh model admin auto registry If I start to work with my new project, I create for example three models. I have a product, I have a shop and I have images for products. And I want to register it on the admin site. I should create model admin classes. I should import models from model PI and I should also import admin registry to register my model admins. It's really

complicated and it's a really Not clear why it's so and if I start my new project only with two model admins I receive What the what the hell? Uh I have my um model admins and something uh comes without uh without me self Of course I know this is uh uh already registered uh mm model admins for model But why it happens? Okay, answer mentioned in documentation. Uh we can um uh don't use uh We can use simple admin config and this is not happens.

And uh admin config uh On RAIDI of all apps created out a registry for all mo all uh applications. And I think this is a good point to create something bigger. What I mean? If I override this method and after call super , I can collect all uh apps config After that, I can ask for every appconfig. Hey appconfig, are you have a model PI? Wait, admin PI? Um if model admin asked me, yeah, you have admin PI for this app, I can go through full

models in this application and I can register these models with classes with which I can find in admin PI. But the important thing I should name these classes like model name and admin For example, I have product, I should have in uh admin PI I should have a class which named product admin. What I can to receive In if I do it all manual uh with hands I should import models, I should I should uh import registry and uh I should create uh

classes uh model admins. If I do it automatically, it happens automatically. If I don't want to register something, I can uh simple to change name for model admin class. Uh oh yeah for yeah for model admin class. And uh they have uh the uh we use it uh from young uh uh Junga version and uh we um It happens automatically and I can say it's easy. Right now, if I start a new project, I uh add this uh this method. uh at uh first what I do I add this method this is simply we can register our models

automatically If somebody don't understand what I want to uh to tell right now, you can read uh article on Medium about this possibility. Then next uh out ordering of admin list. If I start uh if I start my project, what I can see I see this is the sorting of my apps and models. um without logic or without uh again humanity. It's uh automatically ordered and why? Uh yeah in our uh uh site admin

We have a function or we have a method which made many loops at first The first loop we collect all models and apps. The second loop we uh sorted it uh in uh in alphabetical order. And after that we have again one loop to uh go truth and uh there we go through every application and there we can uh sort uh also model names. We need more loops for God of loops, but not uh for our project In our project they can throw away all these uh sort uh loops and uh

healthy uh method uh of uh uh which collect uh all names for application. Uh I leave only uh loop which collect for us methods and uh applications and um uh accordingly uh declaration our application in setup uh install it apps we can receive order of apps and accordingly how I define my methods in my methods PI I can receive this order You can see I create a shop model and image model and product model and I see the model

admins in order which I want. I want to control this order and uh also I can control in which order came's application on my uh model admin uh on my admin site. The next feature has multiple admin sites. Who knows about this possibility in Django? Yeah of course developer part knows but uh somebody who worked with FET yeah who has uh for example five model admin um admin sites on pro in project Okay, nine, ten? Nobody. Okay. Multiple admin sites is

uh perfect uh perfect thing. There we can um simple grouping uh we can create Groups of model admins, and we can work only with this group. We can create permission-based URL group access. is a s really simple and easy and uh we can w work with group of my managers of my admins uh it s uh works much easy and of course If you have a big project, you can split development of every more uh admin site on different teams. and they can work uh uh independent

from uh uh uh other uh teams. Uh why we need uh many admin sites. For example A guns uh simple example I have uh e commerce platform and uh I have managers who work only with products Therefore I have uh content admin. Also we have uh stocks Manager from stocks works only with stocks admin and also we have a big bosses they want to collect uh stats of uh shops or stats of uh stocks and they uh goes uh uh with own

um admin site Ural And they receive their own, they achieve their own goals. Register multiple admin sites is easy. We should create a new class of admin site and we should create an instance from admin site and only one argument to create a new instance is a name of admin site A big problem in Django, okay, nicht problem. Big on the undocumented feature in Django is we have one default admin site, and this default admin site by default is registered the name admin. And

this brought us last 10 years some problem, but Yeah, I know how we can solve it. Uh um register admin URLs. In documentation um we For every new uh admin site we should create uh we should import admin site and we should uh put uh um path in mind dispatcher orel dispatcher but really we we really should do it now Easy registry or healthy model admin registry is every instance from model admin

is registered in admin sites. In uh sorry, in all sites uh registry. I can collect in my dispatcher URL all sites registry, I can go through I can go through every admin site. I can take name from this admin site and I can register it in path. For example, uh how it seems uh before with manual uh registry and how it seems uh when you use uh automatically registry admin site. Uh of course If you if I create a new admin site, it can be so forth registered. I don't need to change anymore

anything I like it and that's why I think it should be in documentation or it should be created automatically if I start a new project. Okay, we can go wider uh on to the next slide. Uh and there we have a problem. I take the these uh strings from documentation. Uh it's a corrected version. In documentation, uh you can find something other, but uh if you want to resolve uh a any function for model uh for admin site you can use uh this uh rule admin uh

like um like a name of admin site, twice points and after that up label and the model name. And I can only ask, really? It's really works? No, it's not works. For example, uh I open project. You can you can check all uh my idea in repository uh link uh you can find on the end of presentation. And if I uh start my project on the back end Uh this URL admin index uh works like uh uh trolls meet uh trolls me

me to the one admin site and on the front end. At the same time, this URL gives us completely other link. What we can to do, what we should to do. Of course, we should always uh use namespace Which admin site I want to start right now, or I want to call right now. This admin namespace we should use everywhere. In admin panel or in front-end. Please don't forget about it, but for backend uh uh for default templates it should all

be it should be all overridden Right now we have hard coded their namespace admin. It's wrong. For multiple admin sites, of course. Permission -based access. This is perfectly, I like it. I can uh stop uh access for everywhere uh to for the special um no for the special uh admin sites and uh we have an an uh method uh names um has permission every request which goes through for admin site every request calls

this method and there we can check If this user has permission or not. And I use here a special function from Jjango. I check really permission by this user. For example, superuser. has all permissions but they don't have it. We have a checkbox super user. With this function user has perm I can check If this super user really has this permission which I want. And additional permission, zum Beispiel this permission is is out stock managere. Ta esas inju permission.

We can kreeta it simpli uh truth model meta. Uh thanks for Jenga we can create it simply, uh we can define a new permission, but but After that we should tomate uh migration and migration created in Upermission but migration don't uh delete any other old permission and uh therefore if you have a big project more than seven years development history Probably you need also to register permission admin to check uh and remove old permissions. Most important right now we go to the most important feature in

Django Country Padmin, SS model admin class. I like it Thank you for developers. It's a beautiful uh uh really I love I love this model admin class, but I understand this is this is really uh have a many problem. Uh more than Admin class Uh it's seems like uh view set from Django Rest framework or it seems seems like uh Clays based views But uh it break uh every model admin class break down the idea from generic class based views and uh uh uh modern admin class don't have uh enough uh class based views.

uh functions, uh or the methods, features. Uh etc etc etcetera many hardcodes and But we have mostly a problem. Every model admin class, uh every model admin instance is singleton We cannot create more um more instances from uh model admin class. Why it's a problem. Uh Till today it was not a problem. Yeah? For most developers not a problem, but not for me The first problem. If we if I have two users who work in the same moment with the same instance of model

admin class, this user cannot store all data in this instance. We cannot use instance like a container for data. Why? Data from other user can be removed The second big problem, I don't like this part of model class. If we cannot store the results of internal uh method calls We should to call these methods more and more and more time. For example, for one simply get request. We should call ten methods uh thirty-seven times. Really?

We really should to do it to work with uh model admin? No And I show how we can change it. All changes last 10 years in Django Country Padmin subordinated to this singletone design. And how we can change it? Simply. Problem lays in method model admin get URLs in uh uh in last uh string we uh returns uh the returns URLs but Please, can you see what is wrapped in this return

uh in Oral in In model admin is wrapped instance, a bounded method of instance. If I compare it with uh class-based view, uh in class base view If I have Class Base View, Class Base View returned Fabric for instance. For every request for Class Base View created a new instance. For every request of model admin, always returned bounded method of instance. It's wrong How we can uh s how we can solve it? Answer lays on the some lines above. Wrap method this is uh

Method of our admin class. Admin class wrapped this instance. Okay Thanks. I can uh create a fabric uh which receive instance and after that Uh I uh get instance from bow. function. I check if this instance is model admin class instance. And after that I can create a new instance. And after that I can return call of new instance for every request. That's all. If you can do it , we achieve uh we can use a model admin class instance like data container. Hello, like a data container. Uh if um

we uh can do it, we can store our uh results Uh in um instance we can st uh uh keep user request something else. At the second we can uh cache heavy methods uh uh for uh in model admin um uh and What we can achieve to uh cache only four methods. We can increase twenty percent uh of uh our time. We can uh increase in in reality for heavy post request we can achieve it

uh till seventeen uh seventy uh percent of time. It's really huge. Uh and for n f for future. If we use it in Django uh uh and if we integrated it we can after that uh simplify model admin class. Right now as uh this is uh uh uh yeah fast uh thousand lines and uh right now uh they have around six hundred loops uh which can be cached I think we can we can uh much it better. And uh read a little bit more if you don't understand why is bad or why my solution, we need my solution

You can read it on the in article. And we right now we can go in a little bit deeper. Model admin actions. Who knows about model admin actions? Thank you. Model admin actions is a really crazy perfect thing in model admin. I like it. I I really like model admin. What is uh action in uh Django by default? Action in Django is a function. Uh we declare this function uh an attribute action in model admin. This uh beviously is a function

based uh Uh we don't have any permission. Uh admin decorator is completely wrong and uh some function added globally. Uh Confirmation page is immutable and confirmation page has really huge performance problem. That's why we should to improve it. My uh idea is I want to use my um class-based view to like a action like an an action. But I should to keep a background from model admin class. On the last post uh we should return nothing

at first and at a second I know why but at a second uh the call of every action Switch their call parameters. For normal class-based view, at first comes request. For action at first place comes model admin class, model admin instance. What we can do? We can uh in this case override uh three methods of uh standard of base class uh view and uh I uh swap on dispatch. And simply swap dispatch first hello and second. Completely no, uh-huh Uh I I work

um uh on dispatch I swap on dispatch uh two arguments, I swap on the uh setup uh two arguments, sorry, I speak mostly on German and sometimes I speak German, sorry And on the last post I returns nothing. This is uh only example how I can do it And after that I can declare my class-based view with these changes. I can create wrapper. I can create I can declare it like standard in dispatcher URLs and of course I can wrap this it in action which exists in Django

but we should not use uh this decorator We can use inheritance, we can use much more if we start to use generic class base view. In reality, uh it can be really uh huge uh declaration with some information for uh manager and only one small function process which change something uh with uh object in uh query set of object And this example is from our old uh old um project Here is shown deep inheritance in admin

classes. And of course, every uh class-based use uh action I can mm uh I can use in many other uh model admins. But uh Uh action permission, uh action decorator uh permissions. What's wrong with action decorator? Uh I know uh decorator permission required from Django. I know uh for example user permission I know it. And uh I see at first time I see action decorator I write permission. Uh user is stock manager and it simply simply don't work What why?

I start to work uh and I understand the developer of uh action declarator Created in UART of permission as a middle text in name of method in model class For example, I use word stupid and I should create a new method in model admin has stupid permission. Uh at the second problem is uh SSNU art uh how permission works. Why? Uh if I write two permissions Uh they check by any, not by all.

I mean if we first uh has stupid permission method return files After that, uh it calls uh has view permissions, and if manager don't have any stupid permission, he can call this function. And but I won't what this uh manager uh uh it should be checked the both permission not only one of many permissions And that's why I think this is completely wrong. Solution is uh please to avoid use this uh decorator. from Junder. And you can simply define a permissions attribute for function or for class based

use and We should only to override uh filter action actions by permissions. There we can uh create One liner which checks if this function is if this action has per don't have any permission or if this uh action has permission and user has this permission too. This is only one liner, uh uh fear five six uh here is three lines, but it's really uh we we should to do it if we want to work correctly with permission for actions. Uh

And uh the last thing which I want to decl uh to tell uh about uh model admin I like model admin. I can simply in two minutes change all what I want or create all what I want. But sometime we have not only uh static model admin also we have any reactive uh head who has reactive head for uh admin uh solution Reactive backend or something. Nobody, don't matter. And I want to create headless backend

uh not from scratch Django is a framework for perfectionists mid deadlines. I don't have any time, I have no deadline. That's why in Janga exists already exist two views. One is mentioned in documentation but not documented. this view give us the full translation and full localization uh by uh Ajax request and the other view give us a possibility for autocomplete

Okay, I don't know why. I can read the answer, of course. And how to idea how we can transform every admin view uh or uh every admin model admin view into uh API. It's simple. Every admin view returns one response. If we have in this response template, we have a context which should be put in this template. In this moment uh I create response for index uh for uh admin side and I wrap uh this uh and instead this response I take uh

json response and I put only a context for uh for response uh in json response. Of course I use special encoder, my JSON encoder The solution uh for works for full model admins if I override uh on admin side. Again the uh admin view. I overwrite it and I wrap every response in JSON response If I call admin site, if I call admin site um with iax method

Uh um the magic lays in the encoder. I take uh the encoder from Django, it's already exist, and probably you want only to add something how this encoder encoded action form, admin form, change list model and HTTP response redirect. And after that, every answer from admin side we can receive, uh I use postman to to check it, we can receive in JSON form. That's all. Every URL in admin site we can transform in API only with seven lines of code.

That's all I can change every model, I can change every object, and I don't write any new serializer and API. That's all. The Django admin or the Django Admin Contrib model is a really huge and powerful toy. I like it And let us to use this power. I continue my talk on the Jungle Korean United States Uh there it was it should be advanced talk. Why? Uh it it it can be a little bit harder than

uh today and there i want to tell about uh inlines i want to tell about uh djung uh nested inlines which exist from early version of Django but nobody knows about it. And yeah, I want to tell about Dumnet related widget in admin form. And I want to tell about bound that bound that autocomplete and admin forms and yeah many other things. Thank you My name is Maxine Danilov, Korean repository.