Remove Django Permissions Default

Using Django Using the ORM
1

My system should not have model-based permissions, how do I disable the default permissions (add, edit, delete, view) that are created for each model in the first migration?

I need to disable this, as I cannot actually have permissions linked to the model.

2

This is added by a post_migrate signal.
You can disable this in two ways:

  • Remove django.contrib.auth from your installed apps (some things may stop working)
  • Unregister the post_migrate signal from one of your apps

For the second option, here’s an example…
I have created a IAM application because i wanted to have more control about the accounts and login proccess, as well as the permissions, for me it was crucial that the migrations were generated on a specific language, and by default they are generated on english. So to accomplish this i had to disconnect the default signal connected to the post_migrate signal, and register my own.
I believe that for your use case you only need to disconnect the signal.

from django.apps import AppConfig
from django.db.models.signals import post_migrate


class IAMConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "iam"

    def ready(self) -> None:
        from iam.post_migrate import create_permissions

        post_migrate_disconnected = post_migrate.disconnect(
            receiver=None,
            sender=None,
            dispatch_uid="django.contrib.auth.management.create_permissions",
        )
        if not post_migrate_disconnected:
            raise ValueError(
                "Expected to disconnect the post_migrate signal, in order to reapply it"
            )

        post_migrate.connect(
            receiver=create_permissions,
            dispatch_uid="django.contrib.auth.management.create_permissions",
        )

Hope this helps, cheers.

1 Like
3

I need permissions to be based on each view. Rather than being model-based.

Does anyone have any idea how they can do this?

The default is that with each new model in the first migration, permissions are created. However, not every view has a mOdel.

That’s why I wanted permissions to be created automatically for each View. Example below

permission_required = {
    'GET': ['app.view_myview'],
    'POST': ['app.add_myview'],
    'PUT': ['app.change_myview'],
    'PATCH': ['app.change_myview'],
    'DELETE': ['app.delete_myview'],
}

Remembering that, all isos based on Views.

4

It appears you might have an incomplete understanding of how the current permissions system works and how it’s intended to be used.

Permissions aren’t tied to models. Yes, permissions are associated with models, but that’s primarily for the benefit of the admin app. You are free to use permissions as you see fit.

Read the complete threads at Conditional content rendering, based on permissions for a perspective on this.

Your views check what permissions are granted to the user, the permissions aren’t “associated” with the view. (In most cases, a user is going to need to use more than one view - you may, or may not, want to use the same permission to grant access to more than one view.)

The Django permission system can effectively be used as the foundation of a “Role-based” access system, where the Group model is used for the roles, and the permissions granted to those groups identify what actions the members of that group can perform.

5

Given that my frontend is decoupled from django… For this reason, permissions cannot be associated with models. In fact, I need to create custom permissions without any links or dependencies on the Models. So if different from the django pattern that creates 4 permissions on the first migration of each template I could change it to create whenever a new view was added, it would be very interesting for me. In fact I don’t use this django admin, but I want to use django auth…

6

This has nothing to do with anything related to this. You are creating constraints and limitations for yourself that don’t exist.

Please read the complete thread I referenced for you. You’ll see that the association between a permission and a model is not a limitation, constraint, or restriction for what you’re trying to do.

If you want to effectively use the Django permission system, you’ll want to change your perspective on what those permissions mean and how they’re used by the views.

The phrase I use frequently around here is “Don’t fight the framework”. Do things the way that Django wants you to do them, don’t try to change Django to match whatever your current “mental model” may be.