I am new to django and have gotten a bit stuck on trying to make the admin site work as I'd like it to. I am wondering if for making the admin functionality I want it is better to make a custom admin app with a template inheriting from admin/base_site.html, using the frontend login with a redirect when is_staff is true.
The initial details that make me think this:
I have a chain of foreignkeys and would like to display nested inlines on the parent admin page. I have tried using easymode, but it's got its own issues and requirements that may cause headaches later i can do without.
I would like to add a function allowing the admin to add an instance of a model, which triggers the creation of instances its related models and redirects etc. This requires adding some callables at least, which I havent figured out yet how to really do with any success in the admin model, and at the moment seems easier to just quickly do this in the views.py of my own app rather than trying to toy with the admin views.
In general, creating a custom admin app (using a is_staff=true redirect on the FrontEnd login) seems more flexible in the long run, and will result in a more designed and intuitive admin interface for the client - so I suppose my question is, what are the semi-pros doing? (if you know how to hack the admin views and templates to your heart's content you are not a semi-pro :) )
Thanks for any advice you can offer, Im still getting my feet wet and this kind of advice could save me alot of time and headache.
Slow down. Relax. Follow the Django philosophy.
You have an "app". It presents data. Focus on presentation.
You have a default, built-in admin for your "app". It updates data and it's already there.
If the admin app doesn't meet your needs update Forms and update Models to get close. But don't strain yourself messing with admin. Get as close as you can. But relax about it.
[Also, "more intuitive admin" is sometimes not an accurate description of what you're trying to do. It could be, but I've seen some "more intuitive" that actually wasn't.]
a more designed and intuitive admin interface for the client.
Is this part of the app? Does the app do more than simply present data?
If the app is transactional -- add, change, delete -- crud rules -- that kind of thing, then that's your app. If you want a fancy UI, that's not admin any more. There's no redirect. That's your app.
It's just coding. Stop messing with admin and start writing your app.
Hint: Use generic views as much as possible.
Other than that, you're talking about your app, not hacking the admin stuff that already works.
if you know how to hack the admin views and templates to your heart's content you are not a semi-pro
Wrong. All the source is there. You can read it, also. That's what the pros do. We read the source. And we don't hack the admin app.
If you have complex transactions, you have a first-class, for-real, actual application. Not default admin, but a part of your app that has forms.
If you have forms, then, well, you have forms. This does not require hacking the admin app, it's just coding more of your app.
Go through the links mentioned in this post as well. This may be helpful for you.
Is Django admin difficult to customize?
Related
I've disabled authentication for Django admin panel as described here.
I would like to go further and completely skip django.contrib.auth migrations like users or groups tables.
I've tried to remove django.contrib.auth from INSTALLED_APP and then I got error like below:
RuntimeError: Model class django.contrib.auth.models.Permission doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
Is there any way to use Django admin panel without migrating django.contrib.auth migrations?
Short answer : No
Long answer : From a security standpoint there is absolutely no reason to ever do that, you will make your database open to everyone, with personal information.
Fortunately Django is smart enough to not let anyone do that and the requirements for the administration requires the auth middleware and the django.contrib.auth dependencies.
Again, you should not do that, you could tweak the Django framework and that could work, but you will need to write a lot of boilerplate and most package won't work.
If you want to update your authentication backend Django make it pretty easy to do so : https://docs.djangoproject.com/en/4.1/topics/auth/customizing/
But be aware that would still need at least one auth backend for the admin to work.
django admin (django.contrib.admin) is tightly coupled with django.contrib.auth.
I didn't find a way to use use admin panel without auth app.
Nevertheless,
I've found a solution, which met my expectations.
I've set has_permission attribute of admin.site to True, as described here.
Next, I've unregistered Group and User models from admin panel as described here.
It's not clean solution, since django.contrib.auth migrations are still run, but normal user will not notice.
I am a total noob with Django, I come from the PHP world and I am used to doing things differently.
I'm building an app and I want to change the way the backend looks, I want to use Bootstrap 4 and add a lot of custom stuff e.g. permission based admin views, and I was wondering what is the best practice, or how do more experienced django devs go about it?
Do they override all the django.contrib.admin templates, or do they build custom templates and login/register next to it, and use the django.contrib.admin only for the superuser?
What is the django way?
Django admin is intended for administration purposes. For all intents and purposes it is a direct interface to your database. While I have seen some people building customer facing interfaces using admin, this is most definitely not the way to make a general Django web application.
You should define views for your models. You can use built-in APIs to login and authenticate users. You should most likely restrict access to admin to internal users only.
As for templates, the modern way of doing things is to dynamically fetch data using an API and do all the UI logic in Javascript. Django can be used very well to provide an API to a frontend. Look into Django REST Framework. The basic idea is to write serializers for your models and have view functions serve the serialized data to the front end.
You could go the old school way and render your pages using templates of course. In that case your views would render templates using data provided by your models.
Yes. The admin pages is actually for administering the webpage. For user login and registration you create the templates. However, if you want your backend to look different then you can tweak the template for the admin page, admin login page as well. And you can also have permission based admin views. It's okay to over ride the defaults as long as you know what you're doing. Hope that helped.
I'm creating a Django website that supports both local login backend and LDAP login (through django-auth-ldap), and maybe more in the future.
I'm getting into Django login and backends sutff and have a couple of questions - mainly is there any reason Django doesn't keep user creation backend in the database? Shouldn't user A be linked (and by linked I mean a field on User model) with the backend django.contrib.auth.backends.ModelBackend for safety/convince reason?
I'm getting around to creating a custom user model, and was thinking about adding such field. The ability to unambiguously know which backend was/is used to create/login the user sounds logically for me, but the fact that Django doesn't have that by default, and that I can't find anything similar on the Internet has me worried that I didn't think of a really good reason for why it's done the way it is.
Thanks in advance,
Paweł
Django doesn't need that info. Once the user is authenticated, and django has a User model, it doesn't care what backend authenticated it. The User model data is stored in one source. The User model (whether the default or custom) is consistent and has the same attributes, functionality and behaviour across the entire django project and schema. Nothing in the out-of-the-box django deals with different user models.
You may extend this with AbstractBaseUser, but managing really different users across the same project, especially with the core django modules, is a strech.
Django uses the User model a lot, and you will have to manually locate each place it does, and provide your own router to the correct backend. There is no API for this (like, say, db routers), it's going to be a mess of hacks that will probably even messier with each upgrade.
Django does support, in addition to the custom user model, "authentication backends". Some of the functionality your are looking for is available and exposed with this option, in a formal API. So you probably want to stick with that.
see:https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#authentication-backends
I want to use the Django user model, but I want to keep the super user to administrate the site. I want the other users to be unable to access the admin interface. But I want them to be able to access another custom admin page that deals with uploaded files. I've read a lot of documentation regarding customizing the user model and the admin pages, but I'm having trouble figuring out how to accomplish such a task.
I see that I can subclass the AdminSite that is used for the admin page and make my own, but that runs into problems with is_staff and such.
My idea was to create a custom permission and extend the user model to have it, this permission would allow access to the admin page. But I'm still unsure how to create the admin page with the method I mentioned and avoid the problems of still allowing them access to the regular admin page.
What would be the best method to accomplish this? How could I create an admin page like this and such a permission and then assign it to an extended User as well as prevent them access to the normal admin page?
I am familiar with the decorator #user_passes_test() to check for groups, but what I am concerned with is making sure they can't get into anything but the "lesser" admin panel. Basically I don't want these users to be able to access anything but their own admin dashboard.
Any examples or suggestions would be most welcome, I need advice on creating the admin page for these normal users, how to create these normal users, and how to ensure that they can access the "lesser" admin page but not the normal django admin that has control over everything.
As a side question, if I was using django-suit to customize my normal admin page, would this change anything?
Thanks
If I understood correctly:
in your views.py
from django.contrib.auth.decorators import permission_required
adn over your def:
#permission_required('is_superuser')
this page will only see is_superuser.
I am about to begin work on a project that will use Django to create a system with three tiers of users. Each user will login into the dashboard type interface (each user will have different types of tools on the dashboard). There will be a few CRUD type interfaces for each user tier among other things. Only users with accounts will be able to interact with the system (anyone visiting is greeted with a login screen).
It seems that many people recommend to simply modify the default Admin app to fit the requirements. Is this an ideal solution and if so, how do I set so the admin interface is at the site's root (instead of admin/). Also, any documentation on in-depth and secure modification of the admin interface (along with the addition of different user tiers) would be appreciated.
This seems like a bad idea.
Out of the box, the information architecture presented by the admin interface is going to be very flat where views essentially mirror what's in the database 1:1. I can imagine a slim subset of users in internal IT apps or similar where that may be appropriate but the compromises in usability are serious, without modifying the admin interface so much that you'll probably wish you had done your app the traditional way by the time you were done.
If usability and information architecture are not serious concerns or requirements for your app, then you may proceed apace.
Just need to remove admin
urlpatterns = [
url(r'^/$', include(admin.site.urls)),
]