I have a Redmine installation and would like the ability to grant a user the ability to view (and maybe update) a single issue (not all issues in the project). The catch is that the issue is reported by someone else.
Use Case:
Users A,B, and admin C
admin C creates two bug reports 1 and 2
admin C wants to grant view access to user A on bug 1
admin C wants to grant view access to user B on bug 2
User A should not be able to access bug2
User B should not be able to access bug1
Can this be done with Redmine? I have been messing around with the settings, but I don't see an easy way to accomplish this use case.
If not, are there other bug trackers that do allow for such a use case?
You have at least a couple of more options.
Create a new role 'View Own Issues'. Give it issue visibility to just created or assigned issues, flag "Issues can be assigned to this role" and enable just "View issues" and "Add notes".
Then, you can assign each issue to the proper user.
The advantage with a private issue is that you can have a set of privileged users as Reporters that will still be able to inspect the issue, since it is still public.
The downside is that just one user can be assigned to the issue, therefore you have limited freedom.
Create a subproject that represents a visibility context and add members as needed. Move the issue to the subproject. You can still see the issue at the upper level, where assigned visibility is shown by the 'Project' field.
You cannot assign view permissions on single issues in redmine.
From the top of my head, you may use one of the following approaches in your scenario:
If you have only a limited number of users, you may be able to add different trackers (ACIssues and BCIssues), create two roles (AC and BC), associate user A and C with role AC, user B and C with role BC, and set permissions so that role AC has access to ACIssues, and role BC has access to BCIssues.
Private issues work the way you describe if issue 1 is assigned to user A, and issue 2 is assigned to user B.
Related
Hello again every one,
I have a question: I successfully implemented django-auth-ldap, the LDAP users can request successfully my DRF API. But nows, for my projetc needs, I have to define permissions depending of the group.
Indeed, I will have like 12 groups in my app. Depending of the group, I will authorize or not the user to request a given route, BUT even if I defined the global var AUTH_LDAP_MIRROR_GROUPS = True, and saw in my database the are linked to a group (see capture):
Users in database
Groups from LDAP inserted in db thx to django-auth_ldap settings
User linked to the groups defined
But now, I have some other problems: I do not know how to implement permissions depending of the group the user belong. In fact, if a user belong to the group ServerAdministrator, I want to allow him to access to every route accessible, but I dont know where to see this in the received request in my view?
As I understood, I should implement custom permissions I should write programmatically in a User object (which should inherit from django AbstractUser)
If yes, How does it work? Should I empty my whole Database and then let django-auth-ldap insert users and it also will create the given permissions defined inside the database?
Maybe it is not clear, do not hesitate to ask questions if I can be more precise.
Kind regards.
Benjamin
I am working with a lot of MODX since 2010. From time to time i coudl need another user group with restricted permissions. Like "Can edit content, but not change settings". So the user can't break anything which is relevant for die CMS itself.
I added users, placed them into roles and groups, but somehow it never works the way I expect it to work. A role is not a "role" but a level of authority. A group is just a link to a set of permissions, which is already setup as a ruleset. Still, if I create and setup the group "content editor", I never get it running as expected.
Is there a guide (or even an extra?) to setup restricted user account without breaking ones brain?
There's a basic tutorial available in the official documentation: https://docs.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/giving-a-user-manager-access
My personal recommendation would be to ignore roles altogether. Whenever you need to enter a role (when adding a policy to a user group, or when adding a user group to a user) just pick "Super User - 0". They're an added complexity to allow, essentially, different permissions within the same user group, that 99% of the people don't need.
The primary thing to do is to create a policy, based on the "Administrator" policy set, that contains the permissions you want the user to have in the manager. Those would include the relevant resource/document permissions, but not settings, for example.
Then you add that policy to the user group of your choice as a "mgr" context policy.
The usergroup will also need context permission to be able of interacting with specific contexts. So on the contexts tab in permissions, add the different contexts you want, with the contexts policy.
As #optimuscrime commented, ACLs can be a little complicated, but that's the general approach.
I am trying to model some complex permission management system using apache shiro.
English not being my native tongue I am afraid I might be missing some of the subtleties of terms such as "Roles", "Permissions", "Rights" & "privileges".
For example lets say I want to create a system that manages resources such as printers located inside buildings.
A DB holds the information of which printer is located in what building.
Users of that system should be able to reset a printer or print to it.
Its clear to me that some users will be "Super Admins" and be able to reset and print to any printer ('printer:*:*')- I guess that we could say that those people have a "Super Admin Role".
But what if someone should be allowed to reset the printers in a specific building ('building:A:*') ? Is "Building Admin" a (prarametric) role? or is this just a permission on a specific building? How would you model this using apache Shiro?
n.b.
When tagging this Q I added the user-roles tag and it says:"A user role is a group of users that share the same privileges or permissions on a system. Use this tag for questions about how user roles work in a particular security framework, or questions about the implementation of user roles in your program."
Would I be correct to assume that based on this definition there is not such role as a "Building Admin" because being an Admin of Building A does not give you the same permissions as does being an Admin of building B?
and if so, what would be the correct terminology to describe a "Building admin"?
Have you considered using more than three tokens within the WildCardPermission format?
There is no limit to the number of tokens that can be used, so it is up to your imagination in terms of ways that this could be used in your application.
— WildCardPermission Javadoc
Instead of the domain:action:instance syntax commonly used in Apache Shiro examples and documentation, you could add another token to represent the building, e.g. printer:print,reset:*:buildingA.
The downside of this scheme is that whenever you are checking if an action is permitted on a particular printer, you'd now also have to specify the location, even though the token representing the printer instance might already uniquely identify that printer:
// let's say the role for buildingA-admin has permission of "printer:*:*:buildingA"
subject.isPermitted("printer:print:epson123:buildingA"); // returns true
subject.isPermitted("printer:print:epson123"); // returns false
Depending on your application domain, maybe a structure like buildingA:printer:print,reset:epson123 might even be more appropriate or useful.
To answer your other question regarding user roles, you'd be correct to assume that if you have both buildingA-admin and buildingB-admin roles, they are different user roles, if the permissions assigned to them are not the same.
You might conceive a general user role of Building Admin for permissions that all admins for the different buildings might have in common, to avoid duplicating those permissions across the different building-specific admin roles.
I guess this question basically boils down to some misunderstanding that I have about how the SonarQube LDAP plugin works in general. We have integrated the LDAP plugin and our users are authenticating against our corporate LDAP server. When we we want to create a new group and add users to that group for a new project, we have assumed that the users themselves must authenticate into SonarQube first so they get added as a user to SonarQube. After that, then we are able to put them into the appropriate groups that they belong to. This is a pain for our administrators since the people that need to be added are logging in at differing times or forgetting to log in at all. What we would like is something that Nexus provides where we can do a lookup of that user's account id, then add them and place them into the appropriate group(s). In that way, the user is not bothered by having to login first and then the administrator has to give the privileges and then the user logs out and logs back in. Is this a misunderstanding on my part? I ask because when I go to the users page and click on 'Create New User' it not only asks for the user's id but also the user's password which I obviously don't know so this is telling me that this will be a local account.
By default SonarQube's LDAP plugin works like you think it does. You can configure LDAP group mapping so that when the user enrolls, he/she is automatically added to the appropriate group.
In other words, create the group for the project in SonarQube, and then create the same group in LDAP and add users to it. Then when users login for the first time they will be in the appropriate group, and on each subsequent login any group changes will be reflected in SonarQube.
This, in my opinion, is infact better than adding users manually.
It's my 1st time i'm working with Yii2's RBAC system.
I used http://www.yiiframework.com/doc-2.0/guide-security-authorization.html to get myself familiar with topic.
As i needed some kind of administration for roles / permissions, i installed this extension: https://github.com/mdmsoft/yii2-admin
I'm working on application that let's users submit articles. There are two kind of users, Administrators, and normal Users.
I created 2 roles for that purpose. Admin role and User role.
Users (both admins and users) must have ability to edit articles. Admins should be able to edit any article, while users can edit only their own articles.
For that i created 2 permissions. "Edit" permission and "EditOwn" permission. Than i created "IsOwner" rule and attached it to "EditOwn" permission.
I assigned "Edit" permission to Admin role, and "EditOwn" to User role and everything works great.
Now i'd like to create "lock" status for each article. If Article is locked, user can not edit it even if it's he's own article. Admins should be able to edit it even if it's locked.
For that i created new rule "IsLocked" but i dont know how to add it to "EditOwn" permission. I don't know is it even possible to have 2 rules attached to one permission?
EDIT:
Right now, i have this "dealt with" in way that i have additional permission "EditOwnIsLocked" to which i attached "IsLocked" rule which is than child of "EditOwn", which is child of "Edit".
This works, but it feels dirty and plain and simple wrong.
As it turns out, there is (for now) no way to attach multiple rules to a permission.
You can deal with need of multiple rules in way i do right now, by creating additional permission and attach rule to it and than make child<->parent connection, or you can edit your rule to check for all situations (in my case to check for IsParent and IsLocked).
Those solutions arn't perfect but it's what it is for now. First solution spawns unnecessary permissions, and clutter your permission list (in case you are using yii2-admin or similar extensions), but keeps your rules clean, and second solution keeps your permission list clean but makes you retype same code in multiple rules which is kinda oposit of what OOP stands for.