Hi Thomas,
"If the user should have all permissions, then why not give him all these
permissions at database level?" - I have some use cases where there are
only 3-5 people that need to log into the admin. I don't really need to set
different levels of access for different people. I also don't want to have
to go through and add new permissions to every person every time I add a
model. So, I just mark them all as is_superuser and don't use permissions
at all. It keeps things simple.
Something like this might handle your situation:
class MyUser:
# etc
is_superuser = False
is_staff = property(lambda u: u.has_perm('admin'))
Collin
On Fri, Mar 24, 2017 at 8:55 AM, guettli <guettli.goo...@thomas-guettler.de>
wrote:
>
>
> Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>>
>> I've always felt that `is_staff` should be changed to a permission such
>> as `can_access_admin` provided by the Admin app itself.
>>
>
>
>
>> However, `is_superuser` is slightly different, in that it's not a
>> permission, but rather a flag that says "this user has EVERY permission".
>> It's also potentially nonsensical from a functional perspective, you could
>> have two permissions that are intended to be mutually exclusive, but a
>> superuser would nonetheless have both of them - potentially resulting in a
>> broken/nonsense UI.
>>
>
> Thank you for this easy to understand use case. I ask myself if "this user
> has EVERY permission" is needed at all. If the user should have all
> permissions, then why not give
> him all these permissions at database level? It's like a very special 1:N
> relation which is: 1:∞ :-)
>
>
>
>
>
>> This is the main reason why almost nobody should be a superuser (yet
>> nearly every Django project i've inherited has nearly every member of staff
>> marked as superusers).
>>
>>
> Unfortunately we detected this "best practice" too late. We need to switch
> now, but this not related to django-dev, this needs to be solved in our
> company.
>
>
>
>> `is_active` is intended to be used a little differently isn't it? It's
>> not saying "user has no permissions", it's saying "user is disabled". It's
>> not access-control, it's data.
>>
>>
> Let's look at our use case: I want a queryset of all users which have a
> given permission. Do I want to be
> inactive users in this queryset? I am unsure. But I am sure: I want this
> queryset to be simple at SQL level.
>
>
>
>> I think that most of it could do with a rethink, but `is_staff` is
>> probably the biggest wart.
>>
>> Andy
>>
>>
>>
>
> Thanky you Andy
>
> Regards,
> Thomas
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/66dc2010-eca4-409f-9dea-
> f1a4f5aa8217%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/66dc2010-eca4-409f-9dea-f1a4f5aa8217%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFO84S5fJaGgDZpXQLpKd2B9jZCfxBvEqKbjnqWceOf0w1q5hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
