Hyperlink read-only ForeignKey objects in admin to their change pages
If you set a ForeignKey field in the admin to read-only, you can use this snippet to automatically create a hyperlink to that object.
- admin
If you set a ForeignKey field in the admin to read-only, you can use this snippet to automatically create a hyperlink to that object.
This is a fairly small bit template that, if placed in your_project_dir/templates/admin/prepopulated_fields_js.html will override the template that is normally pulled by the preopulated fields templatetag in the admin. The result is that you can successfully specify a ForeignKey or other field involving choices as a source for prepopulate_from in your admin.py. It works just as well when there are multiple fields of both the text and choice variety.
Want to filter by properties on FK fields? Want to display as filters only FK objects that matter to your model? See comments in the code.
An extension of ManyToManyField for limiting the maximum number of relationships. See the docstring for more information and sample usage.
Reuse blocks of template code and content as macros. This is a small extension of https://gist.github.com/skyl/1715202 (which was based on http://djangosnippets.org/snippets/363/) to support rendering macro output into context variables. See comments for details.
http://paltman.com/2008/04/11/keeping-contenttypes-and-permissions-updated-without-syncdb/
A generic base class for extending ModelAdmin views. This can be used likewise: def myview(self, request, object_id): obj = self._getobj(request, object_id) < do something > def get_urls(self): urls = super(MyAdmin, self).get_urls() my_urls = patterns('', url(r'^(.+)/myview/$', self._wrap(self.myview), name=self._view_name('myview')), ) return my_urls + urls
Django models IntegerField that get max_value and min_value in it's constructor and validate on it. It's initialize the formfield with min_value and max_value, too.
Adds drag-and-drop ordering of rows in the admin list view for Grappelli. This is a updated version of Snippet [#2306](http://djangosnippets.org/snippets/2306/) that works with the current version of Grappelli. The model needs to have a field holding the position and that field has to be made list_editable in the ModelAdmin. The changes of the ordering are applied after clicking 'Save'.
Updated a similar snippet by "King" to work with Django 1.6. This is especially useful for overriding the admin templates without having to symlink or copy them into your project. For example {% extends "admin:base.html" %} would extend the admin page base.html.
Most other methods I've seen for splitting an app's models across multiple files involve adding a couple lines to every model. This method factors out those duplicate lines into one place.
forbidden the porn image
Wanted a simple function to concatenate n dictionaries. Each dictionary passed in is deep copied to avoid any possible mutation of dictionaries being concatenated. Dictionary m's key/values will be overwritten by dictionary m+1's key/values.
This is a different take on polymorphic inheritance, inspired by SQLAlchemy's approach to the problem. The common Django approach (e.g. snippets 1031 & 1034, [django_polymorphic](http://github.com/bconstantin/django_polymorphic)) is to use a foreign key to `ContentType` on the parent model and override `save()` to set the right content type automatically. That works fine but it might not always be possible or desirable, for example if there is another field that determines the "real type" of an instance. In contrast this snippet (which is actually posted and maintained at [gist.github](http://gist.github.com/608595)) allows the user to explicitly specify the field that determines the real type of an instance. The basic idea and the terminology (`polymorphic_on` field, `polymorphic_identity` value) are taken from [SQLAlchemy](http://www.sqlalchemy.org/docs/orm/inheritance.html). Some other features: * It works for proxy child models too, with almost no overhead compared to non-polymorphic managers (since there's no need to hit another DB table as for multi-table inheritance). * It does not override the default (or any other) model Manager. Regular (non-polymorphic) managers and querysets are still available if desired. * It does not require extending a custom Model base class, using a custom metaclass, monkeypatching the models or any kind of magic.
An emulation of "table per hierarchy" a.k.a. "single table inheritance" in Django. The base class must hold all the fields. It's subclasses are not allowed to contain any additional fields and optimally they should be proxies. They however may provide additional methods to operate on the declared field. The presented solution supports implicit inheritance, even across ForeignKeys, and ManyToManyFields. No additional database hits are imposed.