New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add roles #23
Comments
+1 But I do agree roles is something that is almost never needed in the majority of apps that are written in django. the optional part is easy though. just like using django doesn't make you use groups, don't make people have to define roles. thx for the app btw. |
+1 for roles, depending on implementation. |
+1 for roles and inheritance |
I think about roles to be a "group of permissions", I don't know if this is the same for you. With this class of roles assigning a bunch of permissions is easier. I suggest to implement this using Python sets in order to substract one role to other, or get the intersection, and so on: http://docs.python.org/library/stdtypes.html#set-types-set-frozenset +1 for roles, inheritance and optional |
Hi all, I understand from this discussion that for very good reasons it is not a priority for django-guardian. So I will create my own app. However, I think most of the features and components of django-guardian, are fine and if possible, I would not want to re-invent the wheel but reuse those. So my question is, if you are willing to make django-guarding a little bit more pluggable. For example (that is just the first thing the poped up in my mind, while going through the code): make the a setting for ObjectPermissionChecker, that will allow other apps to replace the Checker class with something that takes care of roles? What do you guys think? Thanks |
Hej @schacki, that's actually pretty nice idea. Tests would most probably fail for not-default checker class but we can mark those or make sure they are run with default checker only. Can you create a specific task for it, please? |
I would make any non-default checker classes not part of django-guardign but of the "other" app - so it is the job of the other app to the non-default checker classes. Please let me do a more thorough analysis of what might need to be adapted and changed before opening a task. With "task" I assume you mean a separate issue? btw: it might take a couple of weeks before this moves forward. |
this[1] project help with anything? [1] https://github.com/vintasoftware/django-role-permissions |
Copied following text by @suriya from #330: There has been some discussion in the past #23 about adding roles support in django-guardian. However, it did not move far. This is probably because adding roles to django-guardian seems like a very complex task. I think I have a very simple proposal. I would like to put it forward and if there is interest, implement it. At present, I have my own fork of django-guardian which this functionality. It would be great to see this used by others as well. The core of django-guardian's permission checking for a view is implemented in the function has_permissions = all(request.user.has_perm(perm, obj) for perm in perms) Supporting roles is a minor change. Instead of checking that a user has if require_all_permissions:
has_permissions = all(request.user.has_perm(perm, obj) for perm in perms)
else:
has_permissions = any(request.user.has_perm(perm, obj) for perm in perms) should do it. To add this support, all we need is to define a new flag in |
I opened #386 and I am realizing that this is probably the same. What I would need is that in the code where I am checking for permission I can do "does this user has edit permissions on this object", but when I am assigning to users permissions, I assign them "moderator" permission, which is a superset of multiple permissions, including "edit" permission. This allows me later on to add more permissions to "moderator" without having to assign them manually to all users. We can name this hierarchy of permissions, of roles. |
+1 for roles, inheritance and optional |
I implemented a role concept like bellow: customize
|
Really interesting approach @jokiefer. I like that, I had originally been trying to implement Would your sample allow for that? i.e. the global |
But i didn't focus on the sample above. In our project we implement a simple as possible Maybe this acl app helps you more than the sample above. With some extra work on the |
@jokiefer That acl app would be really interesting to take a look at if you ever have time to separate it out and post some code. Even just as snippets. |
First of all, let me explain why we didn't add roles in the first place. In short, Django's policy is to include simple but well done batteries. django.contrib.auth is best example. How many times people need to exchange auth with own implementation? I believe not so many. guardian is intended to be kind of "extension" to auth app, with sane & simple interface. And thats it. No much of extra functionality included (except some shortcut functions - but this refer to "sane" part).
Now, whats with roles? All they always needed? In fact, I believe not. Same with groups, really. User is needed as it is a fundamental entity for vast majority of all applications.
Ok, here we are, v1.0 almost out there. So for v1.1, roles support would be probably most important feature. Still, in my view, it should be "optional" in some way.
The text was updated successfully, but these errors were encountered: