Django has its well designed admin site which is normally located at your-site/admin.
The interface is very powerful. However, you have to set permissions if you have multiple users with different rights and you have to modify a lot if the user asks you for very customised features.
So now my questions are:
should I build my own login site to provide website-specific features?
is there any already built package which I can re-use and add my own features into it?
When I need to use (and probably customize) a login application I always use django-registration.
It is a very complete app, I has email activation key and some other interesting features. And if you want to add/modify some new functionality you just have to create a new backend (you can inherit the common behaviour from the default backend.
https://bitbucket.org/ubernostrum/django-registration
https://github.com/nathanborror/django-registration
Hope it helps
You can create User Groups in django-admin to simplify assigning permissions instead of setting permissions to individual users.
Django-admin has a number of limitations, but there is a lot of extensions to manage them.
The app django-userna will take your pain away.
http://django-userena.org/
But personnaly i use Pinax. When i start a project all account (login/password reset/email management etc ...) is built in and i can focus on what makes my project different instead of reinventing all the user management stuff.
Related
It's been a while since I last used Django for a project and there have been some really great advances in the core project and the ecosystem around it.
One of those is the mature API development libraries like django-rest-framework.
So far I'm loving it. But it seems that all the guides I've found are disabling the Django Admin when using Django Rest Framework.
The reasons I've seen given were essentially "We don't need it for anything" or "We aren't using sessions, which Admin uses, so it won't work, so we're not using it."
"Don't need it" is a valid reason.
But other than that, are there reasons that it's bad practice to keep the Django Admin enabled when the project is primarily used as an API?
For my purposes, I find it convenient to manage user permissions and as a simple way to code admin only functions for dealing with the underlying data.
note: I've considered whether this question is designed to elicit opinions, which is not appropriate on SO. I believe that the answers I'm asking for will be technical or security based reasons with fact or experience based reasoning.
Totally agree.
On my current project, users are getting and setting ALL data via django-rest-framework.
Like you, I find the admin site convenient to manage user permissions, permissions groups, writing emails, sms, mobile applications push and more.
More, all these models are being translated, and translation is set in THE ADMIN SITE !!!
So, if we need a new object with translation, we do not need a new app release (example in pic of a question).
objects translations are readable and clear.
Data is organized nicely with minimal effort.
Admin get cool skins (jet / grappelli etc etc)
Language activation works like a charm in the APIViews.
Do any of you know of a Django app out there for allowing users to browse for files, and upload new ones? The ones I have found seem to be built as an add-on for the admin interface (django-filebrowser, django-filer).
Not aiming for anything incredibly complex, just something that allows a user to upload files and then browse between folders (either specific directories on the server, or artificially generated "folders" out of some model field).
I recall the admin tutorial mentioned "The admin isn’t intended to be used by site visitors. It’s for site managers."
My thought from above is that it would be bad practice to simply allow users to see content via the admin interface, and that it would be better to create an app to allow for this.
To get the convenience that your end users usually expect in the age of google drive, you really want a complex javascript filebrowser that plays nicely with django.
I'm using yawd-elfinder which is a great django backend for elfinder to manage my students' association's website with great success ( About 1500 users with different groups and privileges).
Features:
Yawd-elfinder can manage local files but also use Django filesystem storages to connect to remote filesystems. A set of django options allows control over file and directory permissions, accepted mime types, max file sizes etc.
It allows you to have fairly complex management of files and different permissions for different users by activating different roots and/or mapping them differently based on the user.
Furthermore you have capabilities like drag and drop, upload by drag and drop and it's very customizable.
I'm not sure it's maintained anymore, but you can find working code here with the relevant views and templates.
I'm trying to build an online recruitment site using the Zend/CodeIgniter framework. I wanted to know which of the two frameworks is the easiest to use and which gives support for templates.I want to write minimum code as possible.
I has hoping I could use a template or some form of CMS that would allow me to quickly create (or automatically provide) an admin and user profile section. Users will need to enter their CV details, modify their account, search and apply for jobs. The admin will then be able to search for applicants based on qualifications, job role, etc.
are there any templates I can use on top of the Zend or CodeIgniter framework to get done the majority of the work?
Thanks
With your needs i like to go with cakePHP, it just need models to be ready and with scaffolding admin panel is good, with Auth and causal baking user section is ready too
With Zend, it usually takes some time to get the things done.
I'm creating a Django powered website that will have numerous applications (Blog, Shop, Portfolio, etc.) that will be edited by 5 or so people, and I have so-far been designing everything with the Django admin in mind.
I have come to realise that this is a very bad way of thinking -as really- the Django admin should really only be for top level administrators, and should be used for exactly that: administrating the website, not contributing to it.
I wrote out the feature-set and realised that the number of applications the entire website should have (sitemaps,mailers,contactforms,comments,tags etc.)is much much larger than the number of features the editor should have access to (CRUD actions for blog/about section etc).
Is it better practice to build a complex permission based Django admin, or build a second custom "editors" admin to run concurrently.
I think this is something that should be discussed in the documentation, as until I realised this, I had a lot of trouble understanding how to break the website down into applications, as I was designing everything with the admin in mind (and what actual user should see in the admin)
I'd argue that you should build a separate "diverse" admin app. Here are the pros and cons as I see them:
Pros:
No need to tamper with Admin or use hacks to get specific features. I suspect you'll need several such given your requirements.
De coupling from Admin. While Admin is very useful it is a bad idea to tightly couple your app with it. All the more so if you are tweaking it. Your would have to watch out for any changes in Admin that would break your app.
Custom styling. I guess visual appeal may not be high on your list but it is far more easier to style your apps than the Admin app.
Separate the really super users from "line admins". Let only the power users see the real innards of your system.
Cons:
You'd be reinventing the wheel. Generic views make this easier but you'd still end up duplicating features or featurelets.
Testing. The Admin app is widely used and is fairly well tested. You can use it without writing any unit tests (for most part). If you build your own you'll have to build an extensive test suite around it.
It is a matter of opinion I think. But personally I prefer to create a separate admin and link a user group to that instead of using the main admin for both.
That way you can easily see how everything looks for the other users when there's a problem. It all depends on your situation though, so YMMV
I want to gather some more information when the user signs up and also display this as part of the profile information - so that the user can edit it once he creates a login.
How can I extend the sign-up and profile form and model without changing directly pinax code?
From pinax docs
Customization
As more sites are built using Pinax,
more best practices will emerge, but
for now what we recommend is:
Always work off a stable release. The most current release is 0.7.1.
Use the pinax-admin setup_project command.
Make necessary changes to the settings.py and urls.py files in your copied directory.
Change the domain and display name of the Site in the admin interface.
Develop your custom apps under your new project or anywhere on Python path.
Develop your own templates under your new project.
This thread is very relevant to your question and discusses options for overriding the default pinax apps.
It suggests looking at https://github.com/eldarion/idios, (an extensible profile app designed to replace the profiles apps in Pinax).
This blog has some comments about overriding the default pinax apps:
Overriding build-in Pinax Applications
Assuming we want to override
$PINAX_ROOT/apps/blog with
$PROJECT_ROOT/apps/blog we can do so
simply by copying the application and
make our project-local (read
individual) changes to it. Pinax will
then load $PROJECT_ROOT/apps/blog
rather than $PINAX_ROOT/apps/blog.
Those who do not care about merging in
upstream changes nor submitting
bugfixes/features upstream would just
issue cp -a $PINAX_ROOT/apps/blog
$PROJECT_ROOT/apps and be done. Those
who consider themselves good
FLOSS-country citizens however care
about contributing back as well ...
The default pinax apps you would be looking to override (if necessary), would be:
http://pinaxproject.com/docs/dev/apps/account/
http://pinaxproject.com/docs/dev/apps/profiles/
You probably want to have a go at overriding the built-in Pinax applications, which is gone over in a little detail in this article. I imagine you'd want to extend (or override) Pinax's Profile model.
This chap seems to have been in a situation that sounds like what you want, have a quick read of his chat logs to see what I mean. Sorry that this answer isn't too specific, it's more of a pointer.