Skip to content

Conversation

berkerpeksag
Copy link
Contributor

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...an empty query set...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it should be saying that it doesn't return inactive users but is saying something else.

@ngnpope
Copy link
Member

ngnpope commented Aug 26, 2016

Generally I think this would be useful - I've wanted to know which users have which permissions in the past. However I can think of a many other cases that would be useful:

  • Which groups have certain permissions, i.e. add GroupManager.with_perm()
  • Which users have certain permissions directly assigned, i.e. not from membership of a group.
  • I may want to know what users have permissions regardless of whether they are active.
  • I may want to to exclude superusers from the output - only show explicit assignations.

Also of note is the obj parameter which is untested. According to the documentation with_perm() should return no users if obj is not None.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new UserManger.with_perm() method returns all users...

@berkerpeksag
Copy link
Contributor Author

berkerpeksag commented Sep 13, 2016

Hi @pope1ni,

Thank you for review and suggestions.

Which groups have certain permissions, i.e. add GroupManager.with_perm()

This should probably needs to be discussed in a separate ticket.

I may want to know what users have permissions regardless of whether they are active.
I may want to to exclude superusers from the output - only show explicit assignations.

+1 for adding is_superuser and is_active parameters (or exclude_*) Tim, what do you think?

@berkerpeksag
Copy link
Contributor Author

I think I've addressed all review comments except https://github.com/django/django/pull/7153/files#r78226234 (pending discussion) Thanks!

@berkerpeksag
Copy link
Contributor Author

I've now implemented both my idea from the django-developers thread and Nick Pope's suggestions about adding is_superuser and is_active flags.

@rivol
Copy link
Contributor

rivol commented Nov 6, 2016

Two comments regarding is_active and is_superuser parameters:

  • is_active has weird behavior IMHO. It's impossible to get ALL users with a permission, including both active and non-active users. I would skip filtering by UserModel.is_active when the value of is_active parameter is None. The valid param values would then be True/False/None. The default value could probably remain True as you only care about active users most of the time (?).
  • I would rename is_superuser to indicate that it selects whether all superusers are automatically included in results. Maybe e.g. include_superusers?

@timgraham
Copy link
Member

Closing due to inactivity.

@timgraham timgraham closed this Dec 30, 2016
@berkerpeksag
Copy link
Contributor Author

I'm not sure I understand why you closed it. I didn't get any feedback or review comments from you or someone else on the Django team since September. If you think Rovi's suggestions should be addressed, you should have left a comment (for example "did you see Rovi's suggestions?" or "do you have time to address the suggestions Rovi made?") before prematurely closing the pull request.

@timgraham
Copy link
Member

Oh, it's a misunderstanding that a team member has to validate feedback from someone else. You two could at least discuss among yourselves and come to a consensus. I guess it would be better to discuss it on the mailing list thread rather than here. Anyway, I had marked the ticket as "patch needs improvement" given the unresolved comment, so it wasn't going anywhere in the current state.

@timgraham timgraham reopened this Dec 30, 2016
@berkerpeksag
Copy link
Contributor Author

Well, from a contributor's point of view, it doesn't matter whether we (the contributors) have reached a consensus on our end or not if it doesn't get accepted by the core developers. So what I was trying to say is that at some point it would be nice to know whether we are on the same page or not.

Anyway, thanks for reopening it! I will try to address all review comments this week.

@timgraham
Copy link
Member

Unfortunately, it's impossible for a team member to give feedback on every issue. The lack of feedback on the mailing list is concerning (maybe there's little demand for this) but If two people come to a consensus, that's a good start.

@rixx
Copy link
Contributor

rixx commented Apr 16, 2019

@berkerpeksag Are you still interested in pursuing this PR?

@berkerpeksag
Copy link
Contributor Author

@rixx thank you for the ping! Yes, I'm still interested in getting this merged. However, last time I discussed it on django-developers, I wasn't able to gather much positive feedback. Perhaps it should be released on PyPI or proposed to a project such as django-extensions first?

@rixx
Copy link
Contributor

rixx commented Apr 16, 2019

@berkerpeksag As far as I could see, there were still some discussions that were not resolved, and the PR is by nature limited, so there are at least documentation warnings missing ("only works with the Django permission backend" would be a start). But I still think this could make for a helpful feature in Django.

@berkerpeksag
Copy link
Contributor Author

I'm glad you found it useful :) I will try to update my branch this weekend.

@ngnpope
Copy link
Member

ngnpope commented Apr 16, 2019

@berkerpeksag I'd be happy to pick up reviewing this one again and to see some of the other improvements I mentioned up thread implemented. Will keep an eye out for your rebase...

@berkerpeksag
Copy link
Contributor Author

@pope1ni thank you again! I will make sure I've addressed your comments and ping both you and @rixx.

Copy link
Member

@ngnpope ngnpope left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, here is something to get you going...

@berkerpeksag
Copy link
Contributor Author

I've addressed most of the review comments. I will add support for Permission instances later tonight.

groups__permissions__content_type__app_label=app_label)
has_permission_q = Q(is_active=is_active) & (Q(is_superuser=is_superuser) | user_q | group_q)

return UserModel._default_manager.filter(has_permission_q).distinct()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make it more DRY and readable, e.g.

         if isinstance(perm, Permission):
            has_permission = Q(user_permissions=perm) | Q(groups__permissions=perm)
        else:
            has_permission = Q(
                Q(user_permissions__codename=codename) &
                Q(user_permissions__content_type__app_label=app_label)
            ) | Q (
                Q(groups__permissions__codename=codename) &
                Q(groups__permissions__content_type__app_label=app_label)
            )
        return UserModel._default_manager.filter(
            Q(is_active=is_active) &
            Q(Q(is_superuser=is_superuser) | has_permission)
        ).distinct()

What do you think?

I wonder if we can use Exists() to avoid distinct() call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, your suggestion definitely looks better. I'll update the PR. Thanks!

Do you mean the queryset.exists() method or does Exists() mean something else?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about Exists() subquery.

@felixxm
Copy link
Member

felixxm commented Jun 26, 2019

@berkerpeksag Thanks for this patch and your patience 🧘‍♂️ Are you able to prepare this for a final review? (rebase, squash commits, address two nitpicks from me).

@berkerpeksag
Copy link
Contributor Author

berkerpeksag commented Jun 26, 2019 via email

@felixxm
Copy link
Member

felixxm commented Jul 9, 2019

Please uncheck Patch needs improvement flag on the ticket when it's ready.

@felixxm
Copy link
Member

felixxm commented Aug 3, 2019

Superseded by #11625.

@felixxm felixxm closed this Aug 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants