Opened 5 years ago

Closed 5 years ago

#31633 closed Bug (wontfix)

Permission objects not automatically created for ManyToMany fields without a through model

Reported by: Alexander Todorov Owned by: nobody
Component: contrib.auth Version: 3.0
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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!

Change History (1)

comment:1 by Simon Charette, 5 years ago

Resolution: wontfix
Status: newclosed

I'm not convinced we should do this, the fact many-to-many fields use auto-created models under the hood are an implementation details and Django doesn't provide other per-field permission so I don't see why we should do it here.

If your app relies on such implementation detail it shouldn't be too hard to attach another post_migrate signal to create permissions for such auto-created models but I don't think this is something Django should default to.

Note: See TracTickets for help on using tickets.
Back to Top