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. 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).
`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. I think that most of it could do with a rethink, but `is_staff` is probably the biggest wart. Andy On Fri, 24 Mar 2017 at 11:31 guettli <guettli.goo...@thomas-guettler.de> wrote: > I know this is a crazy idea, and it will get the "won't fix" tag very soon. > > Nevertheless I want to speak it out. > > My use case: Get a queryset of users who have a given permission. > > I would like to get this with a simple SQL statement. > > At the moment this query is complex and results in performance issues, > since > several outer joins get created. See: > https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM > > is_superuser and is_staff could be changed to permissions easily. > > It's different with is_active. But again: a simple SQL to get all users > which have a given permission is my goal. > > I personally could live without is_active: Just remove all permissions for > this user. > > If you don't like dropping all perms to make a user inactive since you > want to switch back and forward between active and inactive ... > then this a different (bigger) problem: switching back and forward between > states. Why not solve > this for all models (not just User instances)? But this is a different > topic :-) > > I know the road to deprecate these three friends would be hard since a lot > of code uses them. > > What do you think? > > > > > > > -- > 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/961fd91c-3954-4c7f-a05e-807f2863dc5e%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/961fd91c-3954-4c7f-a05e-807f2863dc5e%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/CAOA51CV4KTQHREgQ046nCF2You7kZB407c3jKjgn%3D-%2B0ObREvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
