#31633: Permission objects not automatically created for ManyToMany fields
without
a through model
---------------------------------------------+------------------------
Reporter: Alexander Todorov | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
In `django.contrib.auth.management.create_permissions()` there's this
snippet
{{{
ctypes = set()
for klass in app_config.get_models():
# Force looking up the content types in the current database
# before creating foreign keys to them.
ctype = ContentType.objects.db_manager(using).get_for_model(klass,
for_concrete_model=False)
ctypes.add(ctype)
for perm in _get_all_permissions(klass._meta):
searched_perms.append((ctype, perm))
}}}
This doesn't take into account automatically created models because
`app_config.get_models()` doesn't return them.
I think we should call `app_config.get_models(include_auto_created=True)`
here! I can work on a PR + tests if necessary b/c I need this
functionality.
My use-case is that the application I am working on has been designed to
check permission labels for the intermediate model of a m2m relationship
b/c many of the places in the app specify a through model (that's how it
was designed, nothing to do with the current issue).
In the same app a newer model called Bug has a m2m relationship with Tag
but doesn't specify a through model.
So it is possible to design the app to use logic like "let a user only be
able to apply tags to a TestPlan, without being able to edit the 2 related
objects", however it is not possible to design "let a user be able to
apply tags to a Bug without being able to edit the 2 related objects"
because the permissions for the intermediate model are missing.
The above use-case looks a bit odd but actually gives us very high
granularity and allows our users to design whatever groups they want and
partition the permission within the system at a very granular level.
If the proposed change isn't implemented the possible workarounds for us
are:
1) Specify a through model - kind of ugly, we've been trying to get away
from these and let Django do what it is supposed to do. May break existing
installations when they decide to upgrade.
2) Specify a custom permission for the model - will result in a new DB
migration and the permission will be created automatically - app code will
be different from anything else though. Kind of inconsistent with
everything we have so far.
3) Redesign around the logic "if you want to modify m2m then you need
permission to modify what would be considered a main object" - would case
a major redesign of the entire app so that everything is consistent but
also there's no "main object" in a many to many relationship.
Please advise!
--
Ticket URL: <https://code.djangoproject.com/ticket/31633>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/051.c77ea83091e905b3262c6d822f9cc5f3%40djangoproject.com.
