Удалить (или скрыть) разрешения по умолчанию от Django - PullRequest
21 голосов
/ 19 мая 2011

Я разрабатываю приложение Django, которое будет иметь два административных бэкенда. Один для ежедневного использования «обычными» пользователями и один по умолчанию для более сложных задач и для разработчиков.

Приложение использует некоторые пользовательские разрешения, но ни одно из них по умолчанию. Поэтому в настоящее время я ищу способ удалить разрешения по умолчанию или, по крайней мере, способ скрыть их от «ежедневного» административного бэкэнда без больших изменений.

Ответы [ 8 ]

18 голосов
/ 31 мая 2011

ОБНОВЛЕНИЕ: Django 1.7 поддерживает настройку разрешений по умолчанию

Оригинальный ответ

Следующеедействительно для Django до версии 1.7

Это стандартная функциональность приложения auth contrib.

Он обрабатывает сигнал post_syncdb и создает разрешения (стандартные 3: add , change , delete , а также любые пользовательские)для каждой модели;они хранятся в таблице auth_permission в базе данных.

Итак, они будут создаваться при каждом запуске команды управления syncdb

Youесть выбор.Ни один из них не является действительно элегантным, но вы можете рассмотреть следующие вопросы:

  1. Удаление приложения auth contrib и предоставление собственного сервера аутентификации .

    Последствия -> вы потеряете администратор и другие пользовательские приложения, созданные поверх модели пользовательского аутентификации, но если ваше приложение сильно настроено, это может быть вариантом для вас

  2. Переопределение поведения сигнала post_syncdb внутри приложения auth (внутри \ django \ contrib \ auth \ management__init __. Py файла)

    Последствия -> имейте в виду, что без базовых разрешений интерфейс администратора Django не сможет работать (и, возможно, и другие вещи).

  3. Удаление основных разрешений ( add , change , delete ) для каждой модели в таблице auth_permission (вручную, с помощью скриптаили что угодно).

    Последствия -> вы потеряете адмиn, и вам придется удалять их каждый раз, когда вы запускаете syncdb .

  4. Создание собственного приложения / системы разрешений (с вашимсобственные декораторы, промежуточное программное обеспечение и т. д.) или расширение существующего.

    Последствия -> нет, если вы хорошо его построите - это, на мой взгляд, одно из самых чистых решений.

Последнее замечание : изменение приложений contrib или самой инфраструктуры Django никогда не считается хорошим делом: вы можете что-то сломать и у вас будут трудные времена, если вам понадобитсядля обновления до более новой версии Django.

Итак, если вы хотите быть настолько чистым, насколько это возможно, рассмотрите возможность использования собственной системы разрешений или расширения стандартной ( django-guardian - этохороший пример расширения разрешений django).Это не займет много усилий, и вы можете построить его так, как вам удобно, преодолев ограничения стандартной системы разрешений django.И если вы делаете хорошую работу, вы также можете рассмотреть возможность ее использования с открытым исходным кодом, чтобы другие люди могли использовать / улучшать ваше решение =)

16 голосов
/ 07 июня 2011

Я некоторое время боролся с этой же проблемой и думаю, что нашел чистое решение.Вот как вы скрываете разрешения для приложения авторизации Django:

from django.contrib import admin
from django.utils.translation import ugettext_lazy as _
from django import forms
from django.contrib.auth.models import Permission

class MyGroupAdminForm(forms.ModelForm):
    class Meta:
        model = MyGroup

    permissions = forms.ModelMultipleChoiceField(
        Permission.objects.exclude(content_type__app_label='auth'), 
        widget=admin.widgets.FilteredSelectMultiple(_('permissions'), False))


class MyGroupAdmin(admin.ModelAdmin):
    form = MyGroupAdminForm
    search_fields = ('name',)
    ordering = ('name',)

admin.site.unregister(Group)
admin.site.register(MyGroup, MyGroupAdmin)

Конечно, его можно легко изменить, чтобы скрыть любые разрешения, которые вы хотите.Дайте мне знать, если это работает для вас.

10 голосов
/ 12 февраля 2015

Новая функция, представленная в Django 1.7, - это возможность определять разрешения по умолчанию. Как указано в документации , если вы установите это значение пустым, ни одно из разрешений по умолчанию не будет создано.

Рабочий пример:

class Blar1(models.Model):
    id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=255, unique = True, blank = False, null = False, verbose_name= "Name")

    class Meta:
        default_permissions = ()
5 голосов
/ 15 марта 2012

ShadowCloud дал хорошее краткое изложение.Вот простой способ достижения вашей цели.

Добавьте эти строки в admin.py:

from django.contrib.auth.models import Permission
admin.site.register(Permission)

Теперь вы можете добавлять / изменять / удалять разрешения в админке.Удалите неиспользуемые, и когда у вас будет то, что вы хотите, вернитесь и удалите эти две строки из admin.py.

Как уже упоминалось другими, последующий syncdb вернет все обратно.

2 голосов
/ 23 октября 2013

Вы не можете легко удалить эти разрешения (чтобы syncdb не вернул их обратно), но вы можете скрыть их из интерфейса администратора.Идея состоит в том, чтобы, как описано другими, переопределить формы администратора, но вы должны сделать это как для пользователей, так и для групп.Вот admin.py с решением:

from django import forms
from django.contrib import admin
from django.contrib.auth.models import Permission
from django.contrib.auth.models import User, Group
from django.contrib.auth.admin import GroupAdmin, UserAdmin
from django.contrib.auth.forms import UserChangeForm

#
# In the models listed below standard permissions "add_model", "change_model"
# and "delete_model" will be created by syncdb, but hidden from admin interface.
# This is convenient in case you use your own set of permissions so the list
# in the admin interface wont be confusing.
# Feel free to add your models here. The first element is the app name (this is
# the directory your app is in) and the second element is the name of your model
# from models.py module of your app (Note: both names must be lowercased).
#
MODELS_TO_HIDE_STD_PERMISSIONS = (
    ("myapp", "mymodel"),
)

def _get_corrected_permissions():
    perms = Permission.objects.all()
    for app_name, model_name in MODELS_TO_HIDE_STD_PERMISSIONS:
        perms = perms.exclude(content_type__app_label=app_name, codename='add_%s' % model_name)
        perms = perms.exclude(content_type__app_label=app_name, codename='change_%s' % model_name)
        perms = perms.exclude(content_type__app_label=app_name, codename='delete_%s' % model_name)
    return perms

class MyGroupAdminForm(forms.ModelForm):

    class Meta:
        model = Group

    permissions = forms.ModelMultipleChoiceField(
        _get_corrected_permissions(),
        widget=admin.widgets.FilteredSelectMultiple(('permissions'), False),
        help_text = 'Hold down "Control", or "Command" on a Mac, to select more than one.'
    )

class MyGroupAdmin(GroupAdmin):

    form = MyGroupAdminForm

class MyUserChangeForm(UserChangeForm):

    user_permissions = forms.ModelMultipleChoiceField(
        _get_corrected_permissions(),
        widget=admin.widgets.FilteredSelectMultiple(('user_permissions'), False),
        help_text = 'Hold down "Control", or "Command" on a Mac, to select more than one.'
    )

class MyUserAdmin(UserAdmin):

    form = MyUserChangeForm

admin.site.unregister(Group)
admin.site.register(Group, MyGroupAdmin)
admin.site.unregister(User)
admin.site.register(User, MyUserAdmin)
2 голосов
/ 20 августа 2013

Созданный на основе решения @pmdarrow, я придумал относительно чистое решение для исправления представлений администратора Django.

См .: https://gist.github.com/vdboor/6280390

Расширение администраторов User и Group позволяет скрыть определенные разрешения.

0 голосов
/ 27 марта 2014

Если вы хотите запретить Django создавать разрешения, вы можете заблокировать отправку сигналов.

Если вы поместите это в файл управления / init .py в любом приложении, оно будет привязано к обработчику сигналов до того, как у среды авторизации появится шанс (воспользовавшись отладкой dispatch_uid).

from django.db.models import signals

def do_nothing(*args, **kwargs):
  pass

signals.post_syncdb.connect(do_nothing, dispatch_uid="django.contrib.auth.management.create_permissions")
signals.post_syncdb.connect(do_nothing, dispatch_uid="django.contrib.auth.management.create_superuser")
0 голосов
/ 09 мая 2013

Если вы создаете свой собственный сервер управления пользователями и хотите показывать только свои пользовательские разрешения, вы можете отфильтровать разрешения по умолчанию, исключив разрешение с именем, начинающимся с «Can».

ПРЕДУПРЕЖДЕНИЕ: Вы должны помнить, чтобы не называть ваши разрешения, начинающиеся с "Can" !!!! Если они решат изменить соглашение об именах, это может не сработать.

С благодарностью pmdarrow, вот как я сделал это в своем проекте:

from django.contrib.auth.forms import UserChangeForm
from django.contrib.auth.models import Permission
from django.contrib import admin    

class UserEditForm(UserChangeForm):
    class Meta:
        model = User

        exclude = (
                   'last_login',
                   'is_superuser',
                   'is_staff',
                   'date_joined',
                   )

    user_permissions = forms.ModelMultipleChoiceField(
        Permission.objects.exclude(name__startswith='Can'), 
        widget=admin.widgets.FilteredSelectMultiple(_('permissions'), False))
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...