Is there an application for django which tracks CRUD for objects inside a project?
If you mean an audit trail for model changes, you could start with AuditTrail. It's a little rough around the edges but I'm not aware of anything else in this area.
I do this by using signals provided by Django.
Check out django-reversion.
It keeps a detailed log of who did what that is viewable from the admin. It also lets you go back and see any older version, and also to restore deleted versions of models. It includes a middleware component to let any model change be logged, even if it wasn't done by the admin tool. It has pretty decent documetnation as well.
Related
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.
When you create or modify an object instance in Django's admin, a changelog entry is created. This is really nice for fairly obvious reasons.
However my model's instances created by a normal user outside of the admin interface. No changelog is recorded to note its creation (not a huge issue) but I would like to track edits the user makes.
I also want to show the user this full log (user+admin edits) in the frontend so I need a way to pull the changelog out.
My question: how? Is there a one-line switch I can flick to enable full logging or do I have to dig in and do something on my user's edit form logic?
django-reversion is an app designed to help with that.
I've been successfully using Django's admin panel for internal users for a while but I recently hit a brick wall while trying to customize it and I'm curious if I'm spending too much time on it. So, my question is:
Is Django's admin panel intended to just be temporary scaffolding, that is, to be used only during the initial development of the application and to be replaced by custom code similar to Rails' scaffolding?
Obviously by using the admin panel I get a lot of functionality for free and as new features are added I get those for free too. What do other people do?
I wouldn't say the admin is meant to be temporary scaffolding but it might not be the best choice for many cases. I've worked with a very large and well known media company that used the admin as the basis for the entire workflow interface for its producers and editors. Unfortunately, your decision making process about when or when not to use the admin will benefit largely from your overall knowledge about the internals of Django; you'll probably get stuck a few times before you gain the experience to know when not to get stuck. :p
The "customizability" of the admin can be somewhat subjective. I've seen teams bend it to their will but it also requires a pretty good working knowledge of the lower level-details of Models, Forms (and naturally things like ModelForms and FormSets), and templates. I think a lot of the conventional wisdom and best practices hasn't yet surfaced into organized documentation. Be prepared to do a lot of digging around in the source code. The good news is that you'll probably come away with a much deeper understanding of how to take advantage of some of the first-class entities in the framework. The bad news is your boss probably won't be happy that it took you most of a day to change single input on a form.
Recent enhancements have made it easier to place your own views under the admin URL space so you might consider an approach of writing your own views to suit your needs and sprinkling in links in appropriate places within the standard admin pages. I generally advise people who are newer to Django or who are just getting into admin customization to strongly consider just rolling your own administrative views. After all, Django already makes it ridiculously easy to create CRUD style apps and you won't have to feel like you're fighting against a rigid system whenever you want to change presentation or behaviors.
Django Admin is for things where there's no value in doing anything more than the default add/change/delete processing it offers.
Databases are full of lookup and administrative tables. The zip-code to state mapping, for example, that no end-user should see. The log of background batch job executions.
Your app will probably have some tables which are these sort of more-or-less "administrative" -- someone maintains them, but not the large community of users.
Your app will probably have some tables which are for end-users to add/change/delete. You might want to provide extensive customized pages for this activity.
Django grew up in the news business. Writers and editors prepare data (using the admin interface). Customers read the data through customized web pages.
We have administrative staff that use the admin pages. We have customized pages for our customers. We use both.
We provide default admin pages on almost everything to our internal admins. We provide default admin on selected tables to customer-side admins. And we provide carefully crafted application-specific pages for our customers.
I asked a similar question about 6 months ago when I was first starting out in Django.
Is it worth it using the built-in Django admin for a decent sized project?
For that particular application I opted not to use Django admin, and that was a very smart decision in hindsight. Since then, I've generally not used it, but sometimes there are situations when it's great. For me, it really depends on the users. If we are building a custom data-driven app for a client and are working off a feature set provided by them, I would never want to use the Django admin. In those cases, almost certainly they will have changes that could be a real pain to try to get working in the admin. And if it's an evolving project, these changes will become more and more of a hack and you'd probably end up having to start ripping out pieces into non-Django admin parts of the site, at which point there are now two interfaces for doing stuff.
However, if the clients are more of the mindset of accepting the way the app works, then the Django admin would be fine, assuming there's generally a 1:1 correspondence between your tables and the data they're dealing with.
As Brian Luft said, it's really easy to create interfaces for CRUD apps, so if you sense you'll need any customization in the future, it might be easiest just to write your own from the start. You can always keep the django admin around for your own needs as a super-user. That's usually what I do, so I can easily have table-level access to change fields that might not be shown in the normal user admin.
No, I wouldn't compare it to Rails' scaffolding. It's not clear from your question what kind of issues you are running into-- can you provide an example?
There's a lot of customization you can do to the admin by adding custom ModelAdmin classes: hide fields, show additional fields, allow for editing of related-items on the same page or limit/ filter the options that appear in a foreign key field. You can also make things easier for users to find by adding sorting, filters to the front page, search fields. Newer versions of Django also let you create your own custom commands that can be applied to multiple objects at once.
But if the problem isn't with the basic change list and edit form, you can completely customize those by creating model-specific templates and overriding the default admin templates.
No, you can for sure use it for administrating your site, but as Django says; only for trusted users. So if you create a cms, its great. Because (hopefully) the back end users will be trusted users!
http://github.com/uswaretech/Django-Socialauth/tree/master/socialauth/
I'm a bit confused on how I should use this. Of course, I read the notes at the bottom but I'm a Django novice so I'll need a little hand holding.
The structure of this looks like a project structure since it contains a urls.py but I'm also aware that applications can also have that. It also has a manage.py which leads me to believe it's a project ( plus the subdirectories ).
So should I just be integrating portions of this into my existing project? This isn't an application, right?
The README also mentions grabbing API Keys. So if I want a standard interface where you click on a google/yahoo logo and it forwards itself via Javascript to the authentication page where you login if you already aren't logged in, kicks you back to your own page, would I need API keys?
Any other special tips are appreciated.
[We wrote this]
There are quite a few forks, which are ahead of us so you might want to use that.
If you just want openid, you dont need API Keys
If you want twitter/FB you definately need keys.
urls.py and manage.py are too show a demo app.
socialauth is the django app, which you can pull out.
I would use the fork from agiliq (same guys).
If you look at the commits in agiliq and uswaretech, you will see that the agiliq fork has more recent commits.
https://github.com/agiliq/Django-Socialauth/commits/master
https://github.com/uswaretech/Django-Socialauth/commits/master
And you could also use django-social-auth, which might seem to be another fork, but it's a completely different implementation.
I was thinking that django admin is an utility to provide trusted administrators of the site, full access to the site's data model.
However, after going through django admin in detail, I understand that it is very powerful set of views and templates that one can use to create an entire application.
How often do you create an entire application using admin alone? Is it easier to create using views itself than customizing admin that much?
How about building prototype using admin. Do we even need to build prototype? The admin customization cannot be re-used in real application.
If I want to use a part of the admin code in real application (with different templates), is there some kind of scaffolding option available?
"The Admin is not your app."
If the customization goes beyond the trivial, write your own views.
In my experience, I leave the internal admin pages relatively untouched. Instead, I override the admin index template, where I put links to custom-written views when the user needs to do nontrivial reporting or form handling.
I have done something like that before. It was a CMS for a university completely implemented by extending Django admin. It turned out it was a bad design descision. I had to jump through hoops to do some things.
It really depends on what the requirements are for your application. If there needs to be lots of ajax or some specific workflow extending the admin will not be the right thing to do. But I think 60% of cases can be covered by extending the admin.
It's also excellent for building prototypes.
EDIT
OK, that was in the 0.96 days.
So far I've built 2 "big" sites that are in production completely on top of the new admin. These are mostly case management, data entry and reporting so they could be squeezed into the workflow of the admin. But, not without a big effort going into extending the base Site, ModelAdmin, InlineModelAdmin etc. The decision to go this way is we were pressed to do it quick. But in the first case it was a perfect fit for the requirements too. Both run on an intranet in the government sector. Both do their job fine. One with 200 tables handling tens of thousands of entries. The other one manages payments.
So, yes it's true. The admin is not your app. However, it's extendable enough although much of it is not documented. And it fits in most basic enterpresey workflows. So it's worth considering in a limited number of scenarios.
I disagree with most of the other answers.
Simply put, there is no match for what you get for free using the admin app.
Your first customization of the admin will be tough as you'll be facing a steep learning curve (you will need to deal with overriding templates, Managers, ModelAdmins, probably use database views, the CSS and JS, some additional forms and validation rules, etc...). But once that is done, you'll start to feel king in bending the admin system to your needs. I have built a complex inventory and accounting web application with data-entry, reporting, and permission system all based solely on the admin interface and back-end.
The Django Admin is incredibly flexible and can be overridden in multiple ways. Unfortunately there is more than one way to do the overriding and some of the techniques are not terribly well documented.
The good news is that the following strategy seems to work well:
Override, customize and subclass the admin app until it all starts feeling a little painful and at that point just drop into your own views where needed.
There's some useful links in my answer to this question
In short:
Try out the admin part for your needs. Modify the standard views. If there is something missing, you can always develop your own view.
For me, I can't imagine an entire (bigger than rolodex) application based only on django-admin.
A.