id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
29012	Coordination of Authorization Backends in Permission Checking	Mehmet Dogan	nobody	"Long story here: https://github.com/django-guardian/django-guardian/issues/49

Short story: for authorization backends checking object level permissions (like guardian) usually requires calling the django's default authorization backend as a fallback to the more general set of permissions:


{{{
if user.has_perm('foo.change_bar', obj=bar) or user.has_perm('foo.change_bar'):
    ...

}}}

However, this not only looks ugly, but also requires polling of all the backends twice, and thus, is a performance loss. 

First, and possibly the best, solution to this is that, django does not deny permission if obj argument is provided, but just ignores it. This way by properly ordering backends in the settings, it could be a fallback solution for the lower level checkers. This might be the move in the right direction, although it is backwards incompatible. 

A second solution is a keyword argument, such as fallback_to_model=False, that will allow lower-level checkers mimic the model level permissions that django does. Although this looks not DRY at first, it would give other backends more control whether to fallback to django or not (in case first solution is also accepted of course, otherwise, this is needed to get the necessary permissions with one round of polling). 

"	Uncategorized	new	contrib.auth	2.0	Normal				Unreviewed	0	0	0	0	0	0