Add this as a superclass of any Django model to allow making copies of instances of that model: class Entry(models.Model, CloneableMixin): [...] e = Entry.objects.get(...) e_clone = e.clone() e_clone.title = 'Cloned Entry' e.save() The new object is saved during the clone process and ManyToMany relations are copied as well.
Every now and then you need to have items in your database which have a specific order. As SQL does not save rows in any order, you need to take care about this for yourself. No - actually, you don't need to anymore. You can just use this file - it is designed as kind-of plug-in for the Django ORM. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts). Usage example: Add this to your `models.py` from positional import PositionalSortMixIn class MyModel(PositionalSortMixIn, models.Model): name = models.CharField(maxlength=200, unique=True) Now you need to create the database tables: `PositionalSortMixIn` will automatically add a `postition` field to your model. In your views you can use it simply with `MyModel.objects.all().order_by('position')` and you get the objects sorted by their position. Of course you can move the objects down and up, by using `move_up()`, `move_down()` etc. In case you feel you have seen this code somewhere - right, this snippet is a modified version of [snippet #245](/snippets/245/) which I made earlier. It is basically the same code but uses another approach to display the data in an ordered way. Instead of overriding the `Manager` it adds the `position` field to `Meta.ordering`. Of course, all of this is done automatically, you only need to use `YourItem.objects.all()` to get the items in an ordered way. Update: Now you can call your custom managers `object` as long as the default manager (the one that is defined first) still returns all objects. This Mix-in absolutely needs to be able to access all elements saved. In case you find any errors just write a comment, updated versions are published here from time to time as new bugs are found and fixed.
View mixin and utils to generate PDF documents from html using *xhtml2pdf*. The most interesting thing here is *PDFTemplateResponseMixin*. Adding this mixin to class based views allows automatic pdf generation using the view context and a customized template. There is also the lower level function *render_to_pdf*, similar to what can be seen in [snippet 659](http://djangosnippets.org/snippets/659/). See the docstrings for a detailed explanation.
**[Improved and Released as Save The Change.](https://github.com/karanlyons/django-save-the-change)** Django 1.5 added the `update_fields` `kwarg` to `Model.save()`, which allows the developer to specify that only certain fields should actually be committed to the database. However, Django provides no way to automatically commit only changed fields if they're not specified. This mixin keeps track of which fields have changed from their value in the database, and automatically applies `update_fields` to update only those fields.
Code for a RelatedMixin I whipped up, useful in instances where you wish to expose details of a single object, including a related group of owned objects, in the same view. Works well with Django's generic DetailView and UpdateView, or any subclass of SingleObjectMixin. It's a little cleaner than overriding get_context_data differently for every model you want to expose, uses `only('id')` on querysets it doesn't need anything but relational data from, and makes pulling ownership out of distantly related objects much easier. Supports simple nested hierarchies of models, ie: * View a company and all people belonging to it Detail(Company < People) * Edit a company and all computers belonging to its members Update(Company < People < Computers). Tested with non-generic One-To-Many and reverse object_sets only. Just provide an OrderedDict called `related_chain` in your DetailRelatedView that describes the progression of querysets to follow, in the format: model=Foo, relation_chain=OrderedDict([ ('foreign_key_from_foo_to_bar',Bar.objects.all()), ('foreign_key_from_baz_to_bar',Baz.objects.all()) ]) It also takes two optional attributes: context_list_name="baz_list" which provides an alias for the final related `object_list` (default=`related_list`), and keep_intermediaries=True which, if providing a list deeper than one relation, also passes any intermediary related lists into the context, named after the connecting foreign key, like `bar_list` (default=False).
Provides a mixin view class that requires logged-in user.
Enables convenient adding of fields, methods and properties to Django models. Instead of: User.add_to_class('foo', models.CharField(...) User.add_to_class('bar', models.IntegerField(...) you can write: class UserMixin(ModelMixin): model = User foo = models.CharField(...) bar = models.IntegerField(...)
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
First off: This snippet is more or less obsoleted by [snippet #259](/snippets/259/). The way that snippet #259 uses feels cleaner and more usable. It is basically the same code but the magic works a little bit different. In case you prefer this way, I've left this snippet as-is. Maybe you know this problem: you have some objects in your database and would like to display them in some way. The problem: the Django ORM does not provide any way to sort model instances by a user-defined criterion. There was already a plug-in in SQLAlchemy called [orderinglist](http://www.sqlalchemy.org/docs/plugins.html#plugins_orderinglist), so implementing this in Django was basically not a big deal. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts).
Implements necessary permission checks on a user model to be compatible with django admin, but just return true on all permissions without actually checking it against anything. Useful when you have a user model that should always be allowed to use django admin, and you don't care about using django's own PermissionsMixin and don't want to have those models added to your database.
What the docstring says. To not use some functionality, e.g. managing the value in the User's Profile model, delete the corresponding lines (when getting the page_size and when saving it. Add the Mixin before the View class. e.g.: `class ItemList(PaginationMixin, generic.ListView):`
Mixin to support pagination when randomizing querysets. Requirements: Postgres, Django Sessions Note: This shouldn't be used on large complex datasets. It utilizes the relatively slow method of '?' randomized sorting. Use with caution. Todo: MySQL support, Support for larger datasets
Basic Authentication mixin for Django. Use in your class based views.
Simplified version of the snippet that renders model to PDF [http://djangosnippets.org/snippets/2540/](http://djangosnippets.org/snippets/2540/) This PDF view mixin for Django Class Based Views. See working project example: https://github.com/elena/django-pdfmixin-example --- This is based on the case scenario where you have a model which has a `DetailView`. You then construct a bespoke PDF for the same model that is unrelated in any way to the `DetailView`. The PDF needs to be returned as a `HTTPResponse` object. The model object is provided.
Mixin for Django Rest Framework View/Viewsets to use different response data/serializers without unnecessary hacks. Just extend your DRFs view/viewset with this mixin after the DRF's APIView (sub)classes.