Improved version of http://djangosnippets.org/snippets/2205/ Example simple code: ` from django.http import HttpResponse IP_LIST = ['192.168.101.100', '192.168.101.220', '127.0.0.1', '127.0.1.1'] @ip_auth(IP_LIST) def get_parameter(request,name): parameter = get_object_or_404(Parameter,short_name=short_name) return HttpResponse(parameter.value) `
This is an extension of the fantastic snippet "Compact list_filter" written by **onlinehero**. Follow his instructions for the installation. My version add the number of filtered objects beside the label of the filters defined by the list_filter property.
When doing a list_filter on some object in the Django interface, every single item will be displayed. This is not always smart when very long list of choices can be displayed, even though the majority of these choices might not even exist in the database at all. Using this script will only display a filtering possibility for those items actually present in the database. This script is not generic, and you will need to change the lines noted "Change this", since I cannot know what exactly you need to filter. There is possibly a way to make this completely generic, and I hope this will inspire someone to make it!
Ever wanted to add an atypical [field lookup](http://www.djangoproject.com/documentation/db-api/#field-lookups) to the Django Admin list_filter filters, like `__isnull` or `__in`? This jQuery snippet allows you to do just that. Since you can access those additional filters by directly typing them into in the Admin URL, the tricky part is to add those to the regular list_filter display. A lot of this code is spent checking on querystring matches which is ugly and error-prone -- if you see any problems or room for improvement, drop me a comment! A suggestion of where to place this code is in `templates/admin/yourapp/yourmodel/change_list.html`. Mine kinda looks like this: {% extends "admin/change_list.html" %} {% block content %} <script src="/static/js/jquery-1.2.2.min.js" type="text/javascript"></script> <script type="text/javascript"> // the JavaScript posted in this snippet </script> {{ block.super }} {% endblock %}
**Attention: this snippet depends on jQuery library to works** The Admin templates hierarchy does not allow you change the submit line (that buttons bar in the footer of the change view of a model class). This code shows how to resolve this, using a simple javascript trick. You can read the code and implement using your favorite javascript library (instead of jQuery) or pure JavaScript. This example regards to User Profile, a common used model class that adds custom fields to a user in the authentication system. To use this, you must put this template code in a file with the following name: templates/admin/auth/user/change_form.html
See the description in the blog entry at [http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/](http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/)
A subclassed version of the standard Django Paginator (django.core.paginator.Paginator) that automatically caches pages as they are requested. Very useful if your object list is expensive to compute. MIT licensed.
A revisit of [the original snippet](http://www.djangosnippets.org/snippets/311/) with simple caching.
A middleware we are using to stop "spam" on Curse. It makes the user fill in a captcha box whenever they submit a form unless a cookie is set (which expires by default after 6 hours) See also [the python script](http://www.djangosnippets.org/snippets/127/)
This template extends the change form for the flatpages inside the admin interface to use [Yahoo! User Interface Library](http://developer.yahoo.com/yui/)'s [Rich Text Editor](http://developer.yahoo.com/yui/editor/). It should be named `change_form.html` and be placed in the `admin/flatpages/flatpage/` directory of the project templates.
*I suppose I'm kind of stubborn, but I prefer to use underscores to replace spaces and other characters. Of course, that shouldn't hold you back from using the build-in slugify filter :)* ** Forcing the slug to use ASCII equivalents: ** Transforming titles like "Äës" to slugs like "aes" was kind of a trial and error job. It now works for me. I hope `_string_to_slug(s):` proves a rather stable solution. Yet the worst-case scenario is that such characters are lost, I guess that is acceptable. Other ways of dealing with this problem can be found at [Latin1 to ASCII at Activestate](http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/251871) or in the comments below. **How to use:** The slug fields in your model must have prepopulate_from set, the fields specified in it are used to build the slug. To prevent duplicates, a number is added to the slug if the slug already exists for the current field in another, previous, object. I guess there should be a cleaner way to distinguish between creating a new db entry or updating an existing one, sadly, the db back-end is kind of a black-box to me. At least this works ;) I choose not to alter the slug on an update to keep urls more bookmarkable. You could even extend this further by only updating the slug field if it hasn't been assigned a value.
I once needed to convert a Django project from PostgreSQL to SQLite. At that time I was either unaware of manage.py dumpdata/loaddata or it they didn't yet exist. I asked for advice on the #django IRC channel where ubernostrum came up with this plan: simple process: 1) Select everything. 2) Pickle it. 3) Save to file. 4) Read file. 5) Unpickle. 6) Save to db. :) Or something like that. First I thought it was funny, but then started to think about it and it made perfect sense. And so dbpickle.py was born. I've used this script also for migrating schema changes to production databases. For migration you can write plugins to hook on dbpickle.py's object retrieval and saving. This way you can add/remove/rename fields of objects on the fly when loading a dumped database. It's also possible to populate new fields with default values or even values computed based on the object's other properties. A good way to use this is to create a database migration plugin for each schema change and use it with dbpickle.py to migrate the project. See also [original blog posting](http://akaihola.blogspot.com/2006/11/database-conversion-django-style.html) and [my usenet posting](http://groups.google.com/group/django-users/browse_thread/thread/6a4e9781d08ae815/c5c063a288483e07#c5c063a288483e07) wondering about the feasibility of this functionality with manage.py dumpdata/loaddata. See [trac site](http://trac.ambitone.com/ambidjangolib/browser/trunk/dbpickle/dbpickle.py) for version history.
The snippet enables decoupling model classes, associated with a ForeignKey, for the purpose of separating them into two databases. Looking at the following example: class Reporter(models.Model): ... class Article(models.Model): reporter = models.ForeignKey(Reporter) We want to separate the `Reporter` and `Article` into two separate databases, but this won't work in Django because of the [cross model relations](http://docs.djangoproject.com/en/dev/topics/db/multi-db/#cross-database-relations). The solution is to use an ID field and not a `ForeignKey` one. This makes the access very uncomfortable. The above class will make this a bit less awkward. It doesn't support the [RelatedManager](http://docs.djangoproject.com/en/dev/ref/models/relations/#django.db.models.fields.related.RelatedManager), but it will support accessing the related field as you normally would. The article class will look like this (assuming the reporter model id field is an `IntegerField`): class Article(DecoupledModel): reporter_id = models.IntegerField() _linked_fields = { 'reporter': Reporter, } Once you have an article object, you can access the reporter as you normally would for both read and writing. For example: my_reporter = article1.reporter article2.reporter = my_reporter
Riffing on http://djangosnippets.org/snippets/1024/ I didn't want a graph; I just wanted to see what depended on a specific model. This does that nicely.
I've got a bunch of `Models` that form a tree like structure. I'd like to duplicate them all changing one field to something else. Say for example I've got a `Website` which has `Pages` and `Links` and all kinds of other `Models`. Each one of these belong to a `User` (through a foreign key relation). I could use `duplicate` to create a copy of an entire website and give it to another `User` with something like this: class Website(Model): owner = ForeignKey('auth.User') ... class Link(Model): owner = ForeignKey('auth.User') ... class Page(Model): owner = ForeignKey('auth.User') ... ################################## website = Website.objects.get(pk=1) new_owner = User.objects.get(pk=1) duplicate(website, new_owner, 'owner') For a in depth example of the problem see: [Duplicating Model Instances @ STO](http://stackoverflow.com/questions/437166/duplicating-model-instances-and-their-related-objects-in-django-algorithm-for-r) *Note* * Not tested with anything but simple Foreign Key relations - the model ordering is _very_ naive.