Django-guardian: Использование assign_perm в миграции django 1.7

+1

+1

+1

Я исправил эту ошибку, импортировав Group из django.contrib.auth , однако теперь, похоже, он не вносит никаких изменений в базу данных (см. # 333). Это на django 1.8 и guardian 1.3, поэтому, если бы кто-то мог попробовать 1.7, это было бы здорово.

В итоге я использовал две вспомогательные функции для сценариев миграции:
https://gist.github.com/xuhcc/67871719116bdc0fee6c
(django-guardian == 1.2.5)

К сожалению, до сих пор нет любви к 1.8 / 1.3. Используя ваши вспомогательные функции, я получаю сообщение об ошибке
ValueError: Cannot query "project": Must be "ContentType" instance в

perm = Permission.objects.get(
            content_type=get_content_type(obj),
            codename=codename)

obj - это экземпляр модели с именем project, который я получаю следующим образом:

projs = get_objects_for_user(user, 'api.view_project')
        for proj in projs:
                assign_perm(apps, 'api.edit_project', user, proj)

К сожалению, использование assign_perms внутри миграций (или любого другого кода, зависящего от схемы, не входящего в саму миграцию) - действительно плохая идея. Я не удивлен, что это тоже не работает.

Причина, по которой это не работает, скорее всего, заключается в том, что логика поиска модели разрешений не использует правильную модель, возвращаемую apps.get_model() требуемую для миграции. Это можно исправить.

Однако здесь есть принципиальная проблема, которую невозможно решить. То есть миграции базы данных не пытаются сериализовать функцию assign_perm() или любую из функций, вызываемых assign_perm() . Таким образом, более поздняя версия django-guardian могла изменить схему базы данных и обновить assign_perm() чтобы использовать новую схему. Ваши старые миграции внезапно прервутся, потому что теперь они запускают новый код assign_perm() со старой схемой базы данных.

Фактически, возможно, что некоторые запрошенные функции, такие как роли, могут потребовать этого изменения в схеме.

Вероятно, это не тот ответ, который вы искали, однако я думаю, что вам нужно использовать операции с базой данных более низкого уровня для установки разрешений. Под этим я подразумеваю прямое взаимодействие с моделями Permission db. Миграции Django не должны получать доступ к функциям, зависящим от схемы базы данных, вне миграции. Это также включает пользовательские функции в классе модели db.

Возможно, это ограничение можно было бы лучше задокументировать. Запросы на вытягивание приветствуются.

Как таковое закрытие этой ошибки.

Привет
У меня такая же проблема с версией 1.4.4 pf guardian и django 1.9.7
любой assign_perm внутри миграций не работает ... :(
есть идеи, как это можно полностью исправить или обезьяну исправить внутри миграций?

Причина, по которой это не работает, скорее всего, заключается в том, что логика поиска модели разрешений не использует правильную модель, возвращаемую apps.get_model (), необходимую для миграции. Это можно исправить.

Возможно, группы авторизации можно обернуть так, чтобы они вели себя как группа-хранитель.

Я публикую это здесь на случай, если это будет полезно для кого-то еще, но я написал этот относительно общий метод assign_perm для начальной миграции настройки, делает несколько предположений, но, вероятно, полезно:

def assign_perm(perm, user_or_group, obj=None, apps=None):
    permission_model = apps.get_model('auth', 'Permission')
    permission = permission_model.objects.get(codename=perm)

    # Assumes object permission models live in the same app as the model they govern
    # and are named like `ProjectUserObjectPermission`/`ProjectGroupObjectPermission`
    obj_permission_model = apps.get_model(obj._meta.app_label, '{}{}ObjectPermission'.format(
        obj._meta.object_name,
        user_or_group._meta.object_name,
    ))
    obj_permission_model.objects.create(
        # `object_pk` and `content_type_id` keys if you're not using direct foreign keys
        # https://django-guardian.readthedocs.io/en/stable/userguide/performance.html#direct-foreign-keys
        content_object=obj,
        permission=permission,
        **{
            user_or_group._meta.model_name: user_or_group
        }
    )