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)),
]
Related
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 am about to start designing a multitenant CRM solution.
The interesting libraries that appear are
the list of libraries that can be used are - https://dpaste.de/vvzWw/ (you can suggest edits if you wish as to which libraries would be better for a multi tenant django crm soln)
Now my major question is every instance(tenant) of the crm will have admin.
The django admin provides an awesome admin interface, I want the admin to be able to perform only contact/user management feature from the admin interface, and nothing else, that too only the users that belong to his sub-domain.
Can this be achieved or will I have to design a separate interface for the tenant admin?
YMMV but my own experience is that django-admin is a PITA to customize beyond simple things, and that I get better results writing a custom interface when the users needs are anything more than simple low-level CRUD (and don't get me wrong, django-admin is really great).
Now restricting which ModelAdmins are available to a given user and restricting the ModelAdmins querysets according to the current user is definitly not a problem in django-admin so if that's all you need you can always start that way and only start writing your own admin interface when you find the domain requires something more complex / specialized than what django-admin provides.
I am begginer in the Django world, I developed some "information sites" (nothing complicated) but this week my boss order me to make a migration of a big software that has 7 modules.
So I went to read the documentation page and search in google for how I could design this software using Django. I know that the every "module" can named as "app", so I create a new project and one app for every module (I dont know if it was right because the modules will not be public).
The problem is that now I don't know what is the next step.
All my apps can share data (every app has its owns models but sometimes one app has a model that was related to the models in other apps)?
Where do I write the code for the login process (I create a manageUsers app that was thinked to handle the registration, edit, share and validate profile of the current or new user ) and we can be able to share this session data accross the apps?
I need one more app for put the website information (like contact, about, pricing ...)? I use Python 2.7, Django 1.3, Memcached and Mysql 5.
If someone can help me or tell me where it may clarify these questions because most explains how to develop using only one app and in the IRC got no reply or else I must be write all the code in one app?
Best Regards
A good place to start (dated, but worth reading; look at user comment bubbles too): http://www.djangobook.com/en/2.0/ . Chapter 1 - 10 are essential reading. You can pick-and-choose to read the remaining chapters, if desired.
Yes, all Django Apps can share data with one another. You make multiple Django Application's, housed under a single Django Project. The Project sets up a common database to use, and each Application creates Models which use said database. App1 can talk to App2 and vice-versa.
Django Project (one) <----->> (many) Django Application
Typically you separate Apps based on common function. User accounts get their own app (see Auth below). Blog postings get another. A Google Maps interface will get another. User subscriptions, another.
For user accounts and login, Django provides the Auth Module. You can have user accounts stored directly in Django, or configure it to talk to something else, like Active Directory. Auth works "pretty good" out of the box, though I personally customized mine a bit to allow 255-character email addresses as usernames (by default, it limits to 40 characters). Chapter 14 in the Django book might be a little easier to read than the official Auth docs. If you do use Auth, you don't have to make your own Django Application, since Auth already is one! You just install it in settings.py and you're golden.
Your Django structure will likely look something like this:
/Project/
__init__.py
manage.py
settings.py
urls.py
App1/
__init__.py
forms.py
models.py
views.py
templates/App1/
template1.html
template2.html
App2/
...
App2 can access the data-models of App1 by doing: from Project.App1.models import someModel
For me, rules are simple.
If you need to copy-paste some code from one project to another - make an app for it
If one of app's modules code is bigger than 1k lines and/or hard to maintain - look for something to move in separate app
Group functionality into apps to minimize cross-linking between them
For interconnection you can use signals and sessions
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?
According to the documentation:
An app is a Web application that does
something -- e.g., a weblog system, a
database of public records or a simple
poll app. A project is a collection of
configuration and apps for a
particular Web site. A project can
contain multiple apps. An app can be
in multiple projects.
However, what are other examples of what makes an "app"?
What makes an app (for us) is one thing:
An App Is The Unit Of Reuse
If we might want to split it off to use somewhere else, it's an app.
If it has a reusable data model, it's an app. User Profiles: App. Customers: App. Customer Statistical History (this is hard to explain without providing too many details): App. Reporting: App. Actuarial Analysis: App. Vendor API's for data gathering: App.
If it is unique and will never be reused (i.e., customer specific) it's an app that depends on other apps. Data Loads are customer specific. Each is an app that builds on an existing pair of apps (Batch Uploads, and Statistical History)
Django apps are bundles of reusable functionality. When starting off it's easy to just use one custom app for your project, but the "Django way" is to break it up into separate apps that each only do one thing. You can take a look at django.contrib for examples of really well made reusable apps.
A recent example of mine: a client needed a way to import CSV data into the Django models. The easiest way would be to just add a model with a FileField and write a quick parser for the specific format of what they are uploading. That would work fine until the format changed and I had to go make the parser match. But this is a commonly repeated task (importing data) and unrelated to the existing app (managing that data) so I broke it out on its own. This pluggable app can import data for any active model. Now the next time a client needs import functionality I just add this code to installed_apps and run syncdb.
It's a judgement call when to break out an app onto its own, but the rule of thumb for me is if I'm likely to do something again I'll take the extra time to make it a generic app. That means I've created some tiny apps (some just contain a template tag), but it's little overhead for the future gains.
User management could very well be an app, if you are not going to use Django's built in user framework.
It has user interfaces and defined models for stored data, and it is really separate from the Blog or the Wiki application (although the information will be shared).
As long as both applications are in the same 'project' they should use the same settings for the DB. You should be able to by just making sure the proper models are imported where you are trying to use them.
See this link for a little more information.