Opened 7 years ago

Closed 7 years ago

#5926 closed (wontfix)

Default permissions created without Admin class

Reported by: sairus.nvkz@… Owned by: nobody
Component: Metasystem Version: master
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I bad know english. But.
I have model:

class Settings(models.Model):

user_per_page = models.IntegerField(_('User per page'), null=False)
class Meta():

permissions = (('change_settings', 'Can change settings'),)

in docs is written:

Default permissions


Three basic permissions -- add, change and delete -- are automatically created
for each Django model that has a class Admin set. Behind the scenes, these
permissions are added to the auth_permission database table when you run
manage.py syncdb.

Note that if your model doesn't have class Admin set when you run
syncdb, the permissions won't be created. If you initialize your database
and add class Admin to models after the fact, you'll need to run
manage.py syncdb again. It will create any missing permissions for
all of your installed apps.

My model not have class Admin, but permissions for add,change and delete was created. Plus my custom permissions - hiccupped - four permissions.

Attachments (1)

admin_permissions.diff (825 bytes) - added by oyvind 7 years ago.
Fix for adding admin permissions only when a admin class is present

Download all attachments as: .zip

Change History (8)

comment:1 Changed 7 years ago by Simon G <dev@…>

  • Component changed from Uncategorized to Metasystem
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Summary changed from Default permissions to Default permissions created without Admin class
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 7 years ago by jacob

  • Resolution set to invalid
  • Status changed from new to closed

If I'm reading this ticket right, this is by design -- if you've added custom permissions, then syncdb will create them along with the standard ones.

comment:3 Changed 7 years ago by sairus,nvkz@…

  • Resolution invalid deleted
  • Status changed from closed to reopened

If I'm reading this ticket right, this is by design -- if you've added custom permissions, then syncdb will create them along with the standard ones.

I have following models.py:

from django.db import models
class Sairus(models.Model):
   pass

not class Meta, not class Admin, empty model. But permission for add, change and delete was created.

in docs - "Note that if your model doesn't have class Admin set when you run syncdb, the permissions won't be created."

I execute SQL: TRUNCATE TABLE 'auth_permission';
I run syncdb.
I view auth_permission table.
I see

+------------------------+---------------+
| name                   | codename      |
+------------------------+---------------+
| Can add sairus         | add_sairus    |
| Can change sairus      | change_sairus |
| Can delete sairus      | delete_sairus |
+------------------------+---------------+

Why?

comment:4 Changed 7 years ago by jacob

Ah, it does appear that Django is creating permissions even for classes without inner admin classes (see the post_syncdb handler in django.contrib.auth). So the question is whether we should change the behavior to match the docs, or vice versa.

comment:5 Changed 7 years ago by sairus,nvkz@…

I think, docs is main. When I have Settings model (where I can only change fields (not add and not delete)), that perms for add and delete not necessary. When I have model for internal needs for my projects, that any perms not necessary.

comment:6 Changed 7 years ago by onno@…

This bug is very annoying if your making a standalone application without the admin.
You might not want to give your user so many confusing options in your permissions. So a custom permissions is more simple!

Changed 7 years ago by oyvind

Fix for adding admin permissions only when a admin class is present

comment:7 Changed 7 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from reopened to closed

The docs have been updated to reflect that the permissions are created regardless of the Admin class, so I'm going to declare the design decision made, and mark this wontfix.

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