With this snippet, I made a set of admin actions for assigning `Quality` objects to `Package` objects. The Django docs for [ModelAdmin.get_actions][1] explain the dictionary of tuples that is returned. [1]: http://docs.djangoproject.com/en/1.1/ref/contrib/admin/actions/#django.contrib.admin.ModelAdmin.get_actions
Sometimes, we need to pass hidden fields with an initial value in forms but cannot trust the returned values because it could have been tampered. So here is a form that adds an additional 'hidden' field (called 'form_hash') that hashes all the initial value of hidden fields and checks for tampering. Pretty straightforward to use.
This is the same as [django.forms.extras.widgets.SelectDateWidget](http://code.djangoproject.com/browser/django/trunk/django/forms/extras/widgets.py#L16) but changing the order of the rendered select boxes to: day, month, year.
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
Decorator that stores the `request.path` URL in a session variable to be used later, e.g. in a "Continue Shopping" link on a cart page. Wrap and view that you want to be able to link back to easily. When those views are called, it updates the session with the current `request.path` value. This can be pulled back out of the session whenever you need to provide a link back from whence the user came.
This custom model field is a variant of NullBooleanField, that stores only True and None (NULL) values. False is stored as NULL. It's usefull for special purposes like unique/unique_together. One small problem is here, that False is not lookuped as None. This snippets is a response to [1830](http://www.djangosnippets.org/snippets/1830/)
**NOTE: I now have a better implementation of this (nicer api, less signal wrangling) available [on PyPI here](https://pypi.python.org/pypi/django-exclusivebooleanfield)** Sometimes you want to be able to make one (and only one) row in your model 'featured' or 'the default one' If you have some kind of parent model you could have a ForeignKey on the parent to hold that info, but that won't always be the case - eg you may have no parent, or multiple parent models. With the exclusive_boolean_fields() helper you can do it with or without a parent model and it possibly makes the admin interface a bit simpler.
This is a slight improvment of a previous snippet of mine: http://www.djangosnippets.org/snippets/1776/ It is an interactive shell script that greps and deletes sqlite tables USAGE: ./pdrop.sh myquery mydbfile
Allows the whole widget to be required but still have optional fields in it. For instance we have a NameField, which takes a firstname and lastname and optionally a middlename. With this we can just have 1 widget.
Regarding to a quantity, use the singular or the plural in two distincts template variables.
Middleware class logging request time to stderr. This class can be used to measure time of request processing within Django. It can be also used to log time spent in middleware and in view itself, by putting middleware multiple times in INSTALLED_MIDDLEWARE. Static method `log_message' may be used independently of the middleware itself, outside of it, and even when middleware is not listed in INSTALLED_MIDDLEWARE.
See the function **docstring** for usage. This template filter has a couple of drawbacks: * Uses **locale.setlocale** which, according to the [Python docs](http://docs.python.org/library/locale.html#locale.setlocale), is not thread safe. I don't know how this may affect Django applications. * Requires Python 2.5+. Updated 2011-03-16.
This snippet will monkeypatch `django.db.models.Model` to include 7 new methods: * `get_verbose_name` Because you can't access model._meta from templates * `get_verbose_name_plural` * `get_admin_change_url` * `get_admin_delete_url` * `get_admin_history_url` * `get_admin_changelist_url` * `get_admin_add_url` This snippet also gives you the template code to paste to your `base.html` so every front end model instance view of your site will show an admin toolbar for logged in users that have admin access.
I was using flup to run django in fcgi mode and encountered the dreaded "Unhandled Exception" page quite frequently. So apart from all the precautions about handling this except, I wrote the above code snippet, which checks the import across your ENTIRE project. Ofcourse this can be used on any python project, but I have written it for my favorite framework django. It is now written as a Django command extension, an can be run as: **python manage.py imports_checker** This is a generic command, it does not check the settings.INSTALLED_APPS setting for cleaning. But can be improved to do the same. Public Clone Url: [git://gist.github.com/242451.git](git://gist.github.com/242451.git) Update: Now it supports checking imports, just only at the app level also usage: python manage.py imports_checker <appname>
If you are an admin of a django site and many times it feels to visualize or experience how a normal website user actually sees different pages of your website. So to get this done, we create a normal user (just for testing purposes) and check the same, which is good. But sometimes we need to actually login as the same person to resolve a issue or to trace a particular exception which only one user or a specific set of users are experiencing. Usage:login_using_email(request, "[email protected]") I have mentioned only the helper or core method which is responsible for the actual user "logging-in" simulation. Proper view permissions(remember I mentioned only admins should use this) can be wrapped around it. Any thoughts on improving it? Always invited.... Public Clone Url: [git://gist.github.com/242439.git](git://gist.github.com/242439.git)