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.
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):`
I want to create Mixins for QuerySet objects that will by default filter out certain records (e.g. filter out "deleted" records, or filter out "unapproved" records, etc). I'd like those to be separate independent mixins. So in each of those, I override all() to filter out deleted or unapproved, etc. But, I also want to offer a method in the queryset to remove those filters or remove some part of those filters. That's where this code comes in. After some examination of how QuerySets work, this seemed like the simplest method for "undoing" some filter in a queryset
**CancelMixin** A simple mixin to use with ```generic.CreateView``` and ```generic.UpdateView``` view form templates to effortlessly implement a "Cancel" button. This smart mixin will add a URL to your context, ```{{ cancel_url }}```, that can be used as a cancel link in your form template. If no referrer URL is provided, the cancel button will link to ```default_cancel_url```, which can be overridden by view. ** **
PreviewMixin adds a preview page for Django's CBV (FormView, UpdateView, CreateView). After a form has been submitted, it is returned again, optionally in a different template to confirm. If the form is submitted with the same data, the default "form_valid" function is executed. Features: 1. `process_preview` - function executed after submitting the form for the first time (default is to do nothing) 2. `done` - function for the action if the confirm page is sent (defaults to whatever form_valid of the django cbv does) 3. `preview_template_name` - variable with the name of the template for the confirm page (defaults to taking the same template as for the initial form) 4. new function `security_hash` to calculate a hash which is added to the confirmation form. Works kind of like django-formtools, just as a Mixin for the default Django cbv.
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.
**[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.
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.
Allows you to include content from flatpages in class-based views. You can specify the url for the flatpage you want, or let it be determined by request.path.
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).
This facilitates unit tests for model mixins in Django. For more info, see [my blog](https://michael.mior.ca/blog/unit-testing-django-model-mixins/).
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.
This code provides a mixin and decorator which, when used together, can provide advisory locking on model methods. It provides locking by using MySQL's advisory lock system. See the example at the bottom of the code. This is a convenient and easy way to guarantee your model methods have exclusive access to a model instance. The LockableObjects class requires a MySQL backend, but it could be modified to use other back-end locking systems. The lock name generation in `LockableObject.get_lock_name()` could be altered to create much more complex locking schemes. Locking per-object, per-method for example.. Lock attempts have a timeout value of 45 seconds by default. If a timeout occurs, EnvironmentError is raised. **See the bottom of the script for an example** > **Instructions:** * **1:** Place the code in locking.py somewhere in your path * **2:** In your models.py (or any script with an object you want to lock): `from locking import LockableObject, require_object_lock` * **3:** In the model you want locking for, add the `LockableObject` mixin * **4:** Decorate the method you want to be exclusively locked with `@require_object_lock`
25 snippets posted so far.