I want to make it so certain users can view and/or comment on specific issues, but not all issues. I was reading that I can use Issue Security for this but I'm not understanding one thing.
My understanding:
Enable Issue Security to a project
Issue security scheme defined with who can view/comment on issues by specifying Jira groups in the Issue Security settings:
group ABC can view
group DEF can view + comment
People get added to those groups
But, what controls the issue they can access?
If Joe is added to group ABC, what says they can view issue 123 BUT NOT issue 456?
Every issue has a security level, which can be chosen among those that are available in the Issue Security Scheme associated to that project. I suppose you haven't created them yet: then you need to edit the Issue Security Scheme and add all the security levels that you need. More info on security levels here.
In your case, if you want a simple model you could call the security levels something like "Public" and "Restricted". Issue 123 is set to Public, issue 456 to Restricted, and to view restricted issues you must belong to group DEF, so those that are only in group ABC cannot see them.
If you want to manage multiple customers/suppliers and keep things separated, you can create a group for each company, and a security level for each: visible_by_company_A, visible_by_company_B, and so on. Then each security level is configured so that they are visible only be the right groups/roles, and then users must be assigned to the right groups or roles. A user could belong to both groups, or to just one (or to none).
The catch is that each issue can have only one security level, so if you need an issue to be visible by both company A and company B you must create a specific security level for that, like "visible_by_A_and_B", and this doesn't scale well. But in general this rarely happens (at least in my experience), and I've never needed to create too many levels.
One last thing: users who want to set the security level must have the "Set issue security" permission, make sure they have it.
Related
I have been converting access to Team projects using Active Directory groups.
I am a project collection admin and we host around 40 odd team projects.
On all the other proects everything is fine, I have been able to add all the AD groups I needed to the Various TFS groups that exist in a Team Project (Contributors, Readers etc).
When I come to the problem project I can see the add button, and I am able to search for and select the AD group I want, but when I click save, I see a red banner message with the text:
Unable to add members to this group.
Failed to resolve the specified groups to join.
You do not have sufficient permissions to add members to the following groups:
[Team Project]\Build Administrators
I have looked at the oi and all I can see around the time of the issue are activities reporting a 200 response.
I am looking at the api and the database to see what I can do but not sure where to start. I thought I might be able to see something about security but it is asking for a guid that I am not sure how to get hold of.
Looking at the database I thought there might be a security table, but not sure where to start.
I'm going to keep looking at what to do, so I am going to keep this updated
update 2019-03-27
We have a support call open with Microsoft, I still have issues managing the teams, but I have been able to update the team via the Apis, I even found a useful little CLI tool to help with the tasks I needed to do.
In my case, I was trying to add someone to a group that I was in - which I don't need since I'm a Project Administrator. Once I took myself out of the group, I was able to add others again.
Got the answer and the fix worked.
After a lot of back and forth, sending files and running some tfssecurity queries, they were able to determine the problem.
What I had done was add the domain User AD containing our project collection admin account in as a project reader, as the security on tfs works on a least level principle it was then applying a deny permision on my Project collection admin account, by simply removing the AD group from the reader level, which I was able to do, the ablity to manage the securities came back.
I havent been able to find the specific group that I belonged to that then set the deny, but there is no denying that removing the AD group from the reader level fixed the issue.
I want to make a TFS 2010 project read-only so users can view the info in work items but not add any details or new work items. I think I need to change the security permission on the project but it's not clear which permission I would change from the Contributors list.
In my opinion the right way is to alter the group memberships.
Remove all users from the constributors and higher groups and move them to the Readers group.
Two choices.
Choice 1: If this is a common pattern where the prevailing default is that folks are restricted, but some people have access (i.e. devs cannot change things but Tech Leads can), modify contributors and create a secondary group (for example, 'Tech Leads') that has the additional read rights. In this scenario, the Contributors group would contain tech leads, but only specific individuals with the extra rights would be in the Tech Leads group.
Choice 2: If the prevailing default is normal contributor access, but specific individuals (i.e. external contractors) need to be denied access, and you need to be 100% sure this goes through, regardless of any other group membership, then leave Contributors as is, and add a new group called (in this example) 'Contractors' and DENY specific access as needed.
Like before, everyone is a contrib, but contractors have some absolute limitations imposed on them, and the 'DENY' in the Contractors group overrides the 'Allow' from contrib. A use case for this would be cases where specific code has to be hidden from external vendors or some other sub-group and needs to be 100% rock solid - just be careful with denies as they will trump any number of allows you inherit from other groups.
Hope that helps!
Addendum: For restricting or changing rights on workitems, you need to do two things. First, set up appropriate group mempership (noted above), then in the project, under Team Project Settings -> Areas and Iterations, click the Security button to set this up on a node by node basis (or at the root if you want to do these restrictions project wide).
I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.
I've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.
I'm required to provide functions for both users and administrators to edit account and profile details in a web application. An example of a URL for the public side of these profiles is:
http://example.com/user/joe
I'm still torn between two ways to design these URLs. I've thought of either this:
http://example.com/user/joe/edit
Or something non-specific and separate to the profiles:
http://example.com/account
The benefit of the first one is that it allows administrators to do their job through the same functions. This avoids building a whole different backend specifically for administrators. I suppose the negative here is that I'd have to be careful with authorization and make sure nobody can edit what they are not supposed to edit.
The second is a more standard way of doing things, it'd turn out to be simpler and easier to secure, though it means a separate interface for administrative users.
What is SO's opinions on this? Are there any more pros/cons for either way? Which method would you recommend to use?
I would have a different view for the administrator with such a security sensitive area. It makes things much more explicit having a separate view. It is likely even an administrator would only be able to edit certain user information and thus have a different view to the user editing themselves.
It makes the authorization much clearer even if the two views shared a common edit form
If you are using an MVC approach, then my suggestion would be:
http://example.com/user/edit/1234
or
http://example.com/user/edit/joe
Where user is the controller, edit the controller method and 1234 or joe the user id or username respectively.
But as Gumbo commented, administrators should not be allowed to edit user information. They should have some mecanism to disable the account in case of a profile has offensive content or false info. Forcing the user to update it to get the account active again.
The way we do it is the admin and the user share the same view. Items which are admin-only are protected from editing or viewing by the user.
The reason for the single view is:
It reduces the number of 'moving parts' - when a new field is added to the user screen, it only needs to be added once,
It is easier to move items to/from the user's purview. If all of a sudden, management decides to allow a user to manage their "FizzBar" then we only need make the change in one place, and
It is easier to segregate the roles and the functions at the controller level.
I think that you should go with the second approach. It's more secure and flexible, and shouldn't be harder to code than profile editing the profile inline.