Is is possible to associate permissions for certain actions in MTM to predefined groups, so that the MTM UI will only allow the permitted actions to be active, hiding or disabling the unpermitted ones? For example if we have two groups, Testers and Business Analysts, only users from the Testers group can create a new test case. So if we take a look at the image below
the New button will only be available for Testers and will be disabled for other groups, like afore mentioned Business Analysts for example.
Is it possible?
We cannot exactly achieve that, but we can set permissions on the area path for the specific group in TFS to permit or restrict access to edit or modify work items, test cases, or test plans assigned to those areas. It will have the same restriction in MTM.
Please follow below steps to do that.
Go to Area tab, right click on the area your test plans belong to
and then click on "Security"
Grant rights for the specific groups to manage test plans. (eg , In
you case set Allow for Testers group and Deny for Business Analysts group). Of cause you can also set other permissions as needed, eg
Delete this node, Edit this node etc.
Thus, the users in Business Analysts goup can click the New button, but cannot save the work item, they will receive the error message ‘TF237111: The current user does not have permissions to save work items under the specified area path.’ when save the test case.
Related
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.
Currently I'm building a web app. So far I only have regular users. However, due to some requirements I need to have special admin accounts for the app administrators. I'm wondering now how these are usually implemented. The requirement is, that they use the same login mask as regular users and behave the same except for the additional capabilities. To differentiate I could put an admin flag into the users' profile or put the admins into a separate table in my DB. Maybe the the second option scales better for potential additional user groups. Also, how could these admins be signed up? I don't want to use predefined usernames I check against in the login handler. I know the question is rather general. I'm just looking for some directions.
Since you didn't give information about the platform(s) you are using, I can only give theoretical answer. While a simple "isadmin checkbox" will do the job for only separating normal users and admins, but if you will need another user type such as "power users" etc. you will keep adding new columns to your table, which is not ideal. Basically you can use a "Role Based" or a "Permission" based approach. In Role based, as the name implies, you assign each user a role and give access to specific resources depending on the role. In the "Permissions" approach you define for each user the permissions they have (resources to access, actions they can perform). Also you could combine these two approaches, where you assign each user his role and define permissions for each role.
I am developing a POC (SahrePoint 2010) where I can demonstrate that the users can be granted certain permissions on a list for a Date range (for example contribute access for a selected week). I will be breaking permission inheritance and create unique permissions for a list.
I would like the permissions to be revoked automatically after the expiry date. Also, I would like to do this using the Manage Permissions list (_layouts/user.aspx) so that I don't have to maintain a separate list.
I have a couple of questions regarding this:
1. I assume that the custom permissions for any list must be stored n some list. How can get to know in which list the permissions are getting stored?
2. If at all I get to know in which list the permissions are getting stored, will I be able to add columns to that particular list?
I hope that the question is clear.
Permissions are not stored in any list. Rather, every securable object (including sites, lists, folders, and items) has a Role Assignments property that indicates what groups/users currently have access, and what their permissions are (if not inherited).
See the SPRoleAssignment class documentation for more information.
Note that the User Information list is not a "Manage Permissions" list; it stores profile information about users who access the site, but does not store any permission-related information. Further, it's not a typical list at all, in that it does not show up in the SPWeb.Lists collection for a subsite, and its fields are automatically populated by SharePoint's User Profile Service. While you could potentially add more columns to it, you'd be better off using a separate list to store and track your permission information instead of contaminating the site collection user info list.
To have permission changes take place based on an expiry date, you'll need to implement a time-based solution that runs on a regular basis to see if any changes need to be made, such as a custom timer job, a custom site workflow that runs on a schedule, or a Windows scheduled task.
I only want the person who I have assigned the task to see the task in the project module. I don't want other users of the project to see this persons tasks.
However currently any user who has user access rights can see all the tasks even if they were not assigned it.
Is there a work around this ?
OpenERP/Odoo has two kinds of security restrictions that can be assigned to a user group:
Access Rights are CRUD yes/no flags (similar to Unix FS permissions), and allow per-model access control. They state whether members of this group may perform a Create, Read, Update, and Delete operation on any document of a certain document model (e.g. a project task). The default policy is DENY, so by default any operation will be refused if the user does not explicitly have the right to perform it via one of her groups' access rights.
Record Rules are filters applied on CRUD operations, and allow per-document access-control, once access right are already granted. Users will only be able to perform an operation on a given document if the document matches at least one of the record rules. The default policy is ALLOW, so if no rule exists for a given model, all documents of that model may be accessed by users who have the necessary access rights.
Both Access Rights and Record Rules may also be defined globally without assigning them to a specific group, in which case they apply to everyone. There is one pitfall for Record Rules: global rules may NOT be relaxed by other rules (on purpose!), so use with care.
In your case it looks like you should define one extra Record Rule on the Project User group that explicitly restricts access on Project Tasks to your own tasks (and presumably those that are not assigned yet). You need to create a new entry in the Security Rules menu with these parameters:
object/model: project.task
name: See own tasks only
domain: ['|',('user_id','=',False),('user_id','=',user.id)]
(means: your own tasks and unassigned ones)
apply for read: [x]
apply for write: [x]
apply for create: [x]
apply for delete: [x]
groups: Project / User
The domain of a record rule is a standard OpenERP/Odoo domain that is evaluated on the records on which you are trying to perform the operation, and can refer to a user variable that contains the current user's data (technically, a browse_record on the current user). The documentation has a description of domain.
If you want to allow special users (e.g. Project Managers) to view all tasks in the system, you can relax this rule for them by adding another rule to the Project Manager group which allows access to all tasks. There is a special "domain filter" that means "ALLOW ALL" and is useful to relax another stricter rule: [(1,'=',1)].
Note 1: Have a look at the existing Record Rules to see what they're doing first, and be sure to read the explanations on the Record Rule form when you are adding yours. One important thing to keep in mind is that group-specific rules are combined with an OR operator. So if you add the rule I described above, you may not see any restriction effect because other group-specific rules are still giving access. You may have to disable them, edit them, or change the user group they apply to, to get the exact effect you want.
Note 2: Remember that if you do something wrong with Access Rights and Record Rules, you can always fix the mess with the admin account, as these security restrictions do not apply to the admin (similarly to the root user on Unix).
Note: In OpenERP 7 you have to modify or disable the defualt rule called
Project/Task: employees: public, portal, employee or following or
assigned
To get your rule working.
Create a new security rule, select Object as "project.task" ,give domain filter as [("user_id","=",user.id)]. No need to add any groups, so that it will be global. Thats it!
My problem was a bit more complex. I wanted to have users who can only their assigned tasks and some who can see the rest, too.
In Odoo 11 I found that the standard project user inherits Employees \ Employee which in turn has the rule Project/Task: employees: follow required for follower-only projects which let users see the other tasks.
What I did:
create a new group -> duplicate of Project / Users
implemented the rule from odony's answer -> ['|',('user_id','=',False),('user_id','=',user.id)]
removed the record rule Project/Task: employees: follow required for follower-only projects from Employees / Employee and added it to Project / Users
Now I can decide who is a project user, who can see all tasks of a project, and who is a worker, who only gets to see tasks assigned to them.
As already pointed by #user1534055 in openERP 7, it's a bit-different.
Find the rule named Project/Task: employees: public, portal, employee or following or assigned
Edit it and remove ('project_id.privacy_visibility', 'in', ['public', 'portal', 'employees']),
'&', from the rule definition and hit Save.
After this tasks will be visible to only those who've been assigned.
I work on a vb.net winforms app where we currently are using simple roles for security. We enable/disable specific controls based on if the current user has the required role. We are to the point where this is no longer granular enough.
Our application is based on different physical locations we call sites. A user might have permission to do something (for example, edit a site's configuration) at one site but not another. Therefore, we now need to lookup permissions based on current user AND current site. Also, a certain user's permissions may be very specific to themselves ie. no other user's permissions are exactly the same as another user's. Therefore we need a security model that's more permissions based rather than role based.
What's the best way to design a new permissions model that can meet these requirements? I want to make sure that it's easy to implement the checking in the code (I don't want a million if statements sprinkled in our SetUIPermissions methods) and we don't want to have to update every user (400+ and counting) each time we add a new permission. Because of this last requirement I think we need to keep the idea of roles but possibly add/remove exceptions for particular permissions for specific users.
Any ideas?
You're on the right track with the roles and permissions. It's a relatively common solution to have a role refer to a set of "default" permissions; by having a user have a role and a set of permissions, you allow for the role to be overridden by the set of permissions specifically granted / revoked for that user. This gives reasonable flexibility and granularity, and supports your situation of adding new permissions (in the role) without needing to touch every user.