I require the functionality to create a view that redirects to the login page if the user is not logged in, but raises an exception if they are but do not have the correct permissions. In vanilla Django, I'd do the following:

@login_required
@permission_required('my_permission', raise_exception=True)
def my_view(request):
    pass

Doing this using the LoginRequiredMixin and the PermissionRequiredMixin is impossible, as they both use the same raise_exception class-level variable.

This would apply to the MultiplePermissionsRequiredMixin also.

The PermissionRequiredMixin does not allow for checking custom object permissions provided by libraries like django object permissions or django-guardian.

I was thinking of updating it to be similar to https://github.com/lukaszb/django-guardian/blob/master/guardian/mixins.py#L52

Except stripping out the parts where it does object specific actions or guardian specific things, and allow overriding to implement said functionality.

Hi lovely django-braces people, hope this is the right place for this, I wasn't sure how best to reach you otherwise. Am a huge fan of braces, use it a lot.

I have two mixins which I'm wondering whether you might be interested in. If so, I'd be delighted to do the work to get them fit for braces, they already have some tests, but not python 3 etc..

django-spreadsheetresponsemixin - https://github.com/birdsarah/django-spreadsheetresponsemixin Renders views that have a queryset e.g. a ListView, into an excel spreadsheet or a CSV. Takes headers from model or you can customize them. Can specify fields and order columns by doing so. Maybe you don't want to rely on additional libraries, so maybe just the CSV portion would be interesting.

django-sortable-listview - https://github.com/aptivate/django-sortable-listview Like OrderableListMixin but takes things a bit further, for example, if you're already sorted in one direction it'll provide context data so that the next sort can be in the opposite direction. Obviously, would be happy to pull out specific features and add them to the existing OrderableListMixin.

Thanks in advance for your thoughts.

When chaining LoginRequiredMixin and another AccessMixin, setting raise_exception = True and redirect_unauthenticated_users = True doesn't seem to do the right thing.

I have made a mixin that checks if the user is regarded as owner for an object, if not it checks if the user has the given permission. Nice to have for Django's UpdateView or DeleteView. Tests and docs are updated :)

Picking up on work done by @omerzimp in #159. Addressing concerns in #159 and adding tests. Last modified times must now also be timezone-aware datetimes.

Edit: Todos:

• [x] Initial documentation
• [x] Support for conditional retrieval (see the condition mixin)
• [x] ~~Consider sha1'ing the response from get_etag(), and rename to get_etag_data()~~ No, a separate ETag class could provide better functionality, but that's probably out of scope for now.
• [x] Add support for Cache-Control: private/public
• [x] Finalise documentation

The doc on github says that works but is not working.

1.4.x will be the last version to officially support Django 1.4.x

Django 1.4.1-final, 0

ImportError at /admin/xxxxx
cannot import name force_text

What about adding an OwnerRequiredMixin to work with the DetailView, UpdateView and DeleteView views.

Something like ...

class OwnerRequiredMixin(object):

    def dispatch(self, request, *args, **kwargs):
        self.object = self.get_object()

        if request.user != self.object.user:
            raise PermissionDenied

        return super(OwnerRequiredMixin, self).dispatch(request, *args, **kwargs)

The LoginRequiredMixin was lacking the ability to customize login_url, redirect field, or redirect path per view because it was using a decorator. Since these things need to change based on instance, we are using the redirect_to_login view directly instead of the login_required decorator, and we are adding methods and properties which allow us to micro-manage the view instances.

I wanted to use a custom exception with SuperuserRequiredMixin (Http404) and added support for it.

raise_exception can now be True, False, a custom exception or a callable (that should return a response).

I have then factored the no-permission handling into a separate function, and moved redirect_unauthenticated_users to the base mixin.

This does not include any documentation changes yet, because I wanted to gather feedback on it first.

E.g., I am not sure if handle_no_permission should fall back to raising an exception for any non-HTTP-response (not isinstance(ret, (HttpResponse, StreamingHttpResponse))).

I've added here a mixin we use intermittently when the normal flow of a class-based view becomes awkward. It allows you to place permission and/or existence checking earlier in the process in a more reusable way, especially useful when dealing with permissions of related objects. It also allows you to do more than just 404 if permissions are different which is hard to do from within a normal integration point (e.g. get_object). Hopefully my documentation makes sense!

Personally I find this updated dispatch method a much cleaner way to do checking early in a view compared to messing around in the dispatch method, mainly as args, kwargs, request are all set already. Perhaps some of the other mixins here could be made cleaner using this, I've not looked too closely.

I'm open to changes of terminology if you think the naming is unclear.

There are small typos in:

• docs/other.rst
• tests/test_access_mixins.py

Fixes:

• Should read respond rather than responsed.
• Should read passing rather than passsing.

Semi-automated pull request generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

need change:

class AjaxResponseMixin(object): def dispatch(self, request, *args, **kwargs): request_method = request.method.lower()

    if request.is_ajax and request_method in self.http_method_names:

here modify: if request.headers.get('x-requested-with') == 'XMLHttpRequest' and request_method in self.http_method_names:

its work now

This PR introduces a backwards-compatible change to the HeaderMixin. Our existing method works but feels kind of heavy-handed. This approach is more in-line with Django's design, IMO, and doesn't feel as blunt.

Unfortunately, it only works if render_to_response is ultimately called, so I had to leave in the old approach as well. Maybe we should split it up into a new mixin?

Our tests seem a little overly complicated. We should make sure they're as easy to write as possible.

Maybe we should have a "how to write a test" guide