是的！

permission_required_or_403 有 accept_global_perms 参数，但没有办法用 get_obj_perms 做同样的事情

我提出了一个包含全局权限的 get_obj_perms_with_global 标签。

我不知道你是否已经开始走这条路，但我会开始制作一个补丁来做到这一点； 如果你已经开始了，请随时阻止我:)

PS 我认为有一个论点认为默认行为应该包括全局权限，在我看来，当您询问“用户 X 可以对对象 Z 执行 Y 吗”时，这意味着检查所有用户/对象、组/对象、用户/全局、组/全局权限。 但这可能只是因为我使用它的方式。

说了这么多，单独检查全局权限非常简单......嗯。

Pesticles：Guardian 上有足够多的问题证明这是多么令人困惑。 我们每六个月就会得到一点......如果 request.user.has_access('foo', obj) 应该是真的，如果他们有全局权限而不是对象级别的权限。 写两次支票很恶心。

需要做什么才能改变这种情况？

我认为有人需要编写一个拉取请求......理想情况下，它不会破坏现有代码（我不知道这是否合理可行）。

老问题，但我还没有看到拉取请求。 有这方面的消息吗？ 我遇到了同样的行为，我认为这不是很可预测。 谢谢一堆！

我在 #49 中添加了一些评论，因为这对对象级别失败时是否以及如何回退到全局变量的问题有了更多的了解。 我不确定已解决的问题是否会引发通知，所以我在这里添加了这个。

根据正在做出的设计决策，我打算解决其中的一些问题。

我很乐意帮助解决这些问题。

327 对我来说似乎是固定的。

``
Brandon=Person.objects.get(first_name='BRANDON')
Brandon.is_superuser
错误的

school=School.objects.get(pk=1)

get_users_with_perms（学校，attach_perms=True，with_superusers=False，with_group_users=False）
{}

assign_perm('add_school', 布兰登, 学校)

get_users_with_perms（学校，attach_perms=True，with_superusers=False，with_group_users=False）
{: ['add_school']}

mehmet=Person.objects.get(first_name='Mehmet')
mehmet.is_superuser
真的

get_users_with_perms（学校，attach_perms=True，with_superusers=True，with_group_users=False）
{: [],: ['add_school', 'change_school', 'delete_school']}

assign_perm('add_school', mehmet, school)

get_users_with_perms（学校，attach_perms=True，with_superusers=True，with_group_users=False）
{: [],: ['add_school', 'change_school', 'delete_school']}

get_users_with_perms（学校，attach_perms=True，with_superusers=False，with_group_users=False）
{: ['add_school'],: ['add_school']}

在#155上：

要求在get_obj_perms_field_choices (self)添加以下两行：

        if self.exclude_default:
            choices = list(set(choices).intersection(self.obj._meta.permissions))

排除模型的默认权限。 首先，我不清楚intersection将如何做到这一点。 其次，这似乎与对象与模型权限无关。 如果我遗漏了什么，请纠正我。

但是，在研究这一点时，我注意到需要在以下方面分离对象与模型权限：

    def save_obj_perms(self):
        """
        Saves selected object permissions by creating new ones and removing
        those which were not selected but already exists.

        Should be called *after* form is validated.
        """
        perms = self.cleaned_data[self.get_obj_perms_field_name()]
        model_perms = [c[0] for c in self.get_obj_perms_field_choices()]

        to_remove = set(model_perms) - set(perms)
        for perm in to_remove:
            remove_perm(perm, self.user, self.obj)

        for perm in perms:
            assign_perm(perm, self.user, self.obj)

看起来，无论缺少什么权限，它都会在对象级别保存，而在我看来，应该跳过模型级别可用的任何权限，或者为此提供一个选项。

我认为像GUARDIAN_FALLBACK_TO_MODEL=False这样的全局设置和适用方法的参数（如fallback_to_model=False需要正确描述对象权限和模型权限。 False默认值确保向后兼容。 如果全局或参数设置为 True，则应进行回退。

+1 为 GUARDIAN_FALLBACK_TO_MODEL。

根据关于 #49 的讨论，我认为设置也可以很好地控制 ObjectPermissionBackend 是否显式。

我创建了一个拉取请求（#546）。 它允许 core.py 选项中的检查器功能回退到（或包含）模型级权限。 其他模块也需要审查。 我计划在使用它们时对其进行审查。 如果有人想加入，非常欢迎。

似乎 #327 不再存在。 如果接受，#332 由上面的拉取请求修复。 只剩下与#155（上面提到的）相关的一个问题。 如果这也得到解决（或移到一个单独的问题），我认为这个问题可以关闭。

如果设置了对象级权限，全局权限仍然不受尊重，我在这里错了吗？

u = User.objects.get(id=1)
c = Client.objects.get(id=1)
assign_perm('core.change_client', u)
u = User.objects.get(id=1)  # reloading user for perm refresh
u.has_perm('core.change_client')  # True
u.has_perm('core.change_client', c)  # False
u.has_perm('change_client', c)  # False
get_perms(u, c)  # []

设置GUARDIAN_GLOBAL_PERMISSIONS_CARRY_OVER或FALLBACK_TO_MODEL什么作用？ 两者似乎都没有记录。

将它添加到core.py是否就足够

get_user_perms:126似乎是所有用户权限检查的中心； 或者可以使用布尔标志触发

def get_user_perms(self, obj):
    # ....
    user_global_perms = Permission.objects.filter(content_type=ctype)\
                                        .filter(user=self.user)\
                                        .values_list('codename', flat=True)
    user_object_perms = user_perms_qs.values_list("codename", flat=True)
    user_perms = list(chain(user_global_perms, user_object_perms))
    return user_perms