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.
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/).
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):`
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.
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. ** **
**[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.
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.
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.
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.
Provides a mixin view class that requires logged-in user.
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.