1. Not sure, but it seems similar to the access mixins introduced in Django 1.9: https://docs.djangoproject.com/en/1.9/releases/1.9/#permission-mixins-for-class-based-views 2. Any large feature that is twelve weeks worth of work for which you can find a mentor for should be okay. You should include a timeline of tasks in your proposal.
On Monday, March 7, 2016 at 10:33:34 AM UTC-5, Connor Boyle wrote: > > As I understand, some parts of Django-Rest-Framework > <http://www.google.com/url?q=http%3A%2F%2Fwww.django-rest-framework.org%2F&sa=D&sntz=1&usg=AFQjCNGjl9dNBVH-EtBzln4iQdn10YtnzQ> > are > being considered for integration into Django (please correct me if I'm > mistaken). I'm not sure what specifically core plans to bring in, but in my > opinion the feature that core Django needs the most from DRF has no direct > connection to APIs or JSON: it's the extremely well-designed class-based > permissions > system <http://www.django-rest-framework.org/api-guide/permissions/>. > > For those who aren't familiar, the bottom line is that it's a system that > allows the developer to run their own arbitrary code (in a clean, DRY, and > readable way) to determine whether or not to return a 403 given a > particular request and view. Any class-based view (with the provided mixin) > can be assigned a tuple of permissions to check. In other words, it is the > answer to our prayers. > > Example: > > MyApp/permissions.py: > from rest_framework import permissions > > > class IsFromTexas(permissions.BasePermission): > '''Only allow users from Texas. > ''' > def has_permission(self, request, view): > return request.user.state == 'TEXAS' > > MyApp/views.py: > from MyApp.permissions import IsFromTexas > # Other imports > > class MapOfTexasView(ClassPermissionsMixin, TemplateView): # > ClassPermissionsMixin does not actually exist yet > '''Return a map of Texas. Only allow users from Texas. > ''' > permission_classes = (IsFromTexas,) > template_name = 'map_of_texas.html' > > Checking against an object is trivial, and DRF's implementation makes it > even easier and cleaner by providing a has_object_permission() method that > gets passed the result of the view's get_object() if it has one (and makes > it so the developer doesn't have to worry about accidentally calling > get_object() multiple times). > > I'm considering applying for Summer of Code with this (adding class-based > permissions to Django) as the subject of my proposal. I would also add some > features that DRF is missing, such as permission-checking on QuerySets, > adding class-based permission checking to default class-based views, and > dividing permissions into read and write. > > A few questions for anyone who can answer them: > > 1. Is there any chance of getting this accepted as a feature? (through > Summer of Code or otherwise) > 2. Is this appropriate in scope and significance for a Summer of Code > project? I'm guessing it would be relatively little actual code, but could > potentially be a fundamental part of a huge number of projects made with > Django. > 3. I suspect that if this were to be added to Django core, we'd want to > use a name other than 'permissions' given that Django already has its own > permissions system that uses that name. How does 'authorizations' sound? > > > Connor Boyle > Macalester College > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/89a91ced-5ce2-412a-ac27-267ecdb7107c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
