I need to separate secure projects for 2 customers in our JIRA on demand instance. I will most likely need to create more secure projects in the future so I need to get this right. They can't see or even know about each others projects. The initial customer1 was created using defaults; workflows, screens, schemes, etc. So here's what I've done so far:
When I login with my admin access and select projects tab-> all projects, I only see customer 1 project. If I click recent projects I still only see customer 1 project. But if I select projects from the Admin cog pull down menu it shows both projects.
When I login as test1 user I can see in the activity stream that a new project for the other customer was created. This is bad! Please tell me how to get rid of that activity stream exposing the secure project. Customer 1 should not know that I created a project for customer 2. If I select Project, view all projects or Recent Projects as test1 user I can only see customer1 projects, as desired. So it seems the only thing giving it away so far is the activity stream.
When I login as test2 user I can see both customer 1 and customer 2 projects. I assume this is because I haven't moved customer 1 users out of old default folder into it's own customer 1 group and applied the applicable security scheme settings.
Please let me know how to complete this so I don't expose one customer to another and can see both projects with administrator login. As of now the activity stream is exposing the information so I need to know how to get rid of that info. And please don't point me to any more documents. I've read many but need human support to make sure this is completed correctly.
Ok, there's two things here.
First, Admin rights really are for admin rights. They do not mean "can do everything", or even "can see everything". They do simply mean "can administrate the system". A lot of admins do blur this line in JIRA systems by using the admin group in permissions, so that admins do get to see a lot of stuff, but it is perfectly possible to have an admin who can look after a system and not see a single issue or project within it. Of course, they can put themselves in the groups to give them access, or change the permission schemes so they can see things, but the line is still there. Most importantly for what you're seeing - even though an admin might not have the rights to see a project and hence have an empty project list on the user project list, they can still see the project in the admin screens (i.e. the admin cog, as you're seeing)
Secondly, you are right about the visibility of updates, and I think you're pretty close to where you need to be. Check the exact rules for "browse" permissions in both projects and compare them with the two users. You need the users to only match the rule for the project they should see. A common problem is "browse: group = jira-users", as everyone has to be in that group to be able to log in.
Thank you for responding so quickly Nic. I really appreciate it. Also, thank you for clarifying that even though you're an admin you don't get all rights. I didn't realize that.
New Permission scheme has Browse projects=Project Role (Users) and Group (Customer2). Old default permission scheme has Browse projects=Project Role (Users). I'll add a Group (Customer 1) later.
Rolls has customer 1 with users=JIRA-users and customer 2 has users=customer2 group. I believe all admins would have automatically been included in the jira-users group when their accounts were created. But it won't allow me to add an admin group to the customer2 group. So I should add each individual admin username to the customer2 group and when I create the customer1 group I'll replace users=JIRA-users with users=customer1 and will also need to add each admin username to that group as well, correct?
And if I want our developers to be able to see both groups I'll need to add their group to both customer 1 and customer 2 rolls, because once I remove jira-users from customer1 roll they won't be able to see that either.
Please confirm if I'm on the right track now.
Sorry, I'm struggling to see what you're setting up here. I think you're close, but I can't follow what you're doing. I can show you what I would do, in the most simple case. Assuming we have two projects, AAA and BBB, and we have two customers, ACME and BobCorp. The use case is AAA is for ACME and BBB is for BobCorp, and they should not see each other's stuff at all. Finally, all your users are in the group "jira users" so that they can log in. So: - Add a group like Customer-ACME and add all the ACME users into it - Add a group like Customer-BobCorp and add all the BobCorp users into it - Set up one permission scheme that says Browse: Project Role = Users - Apply that scheme to both projects - In project AAA, go to the roles and put the group customer-Acme into it. Remove jira-users from it - In project BBB, go to the roles and put the group customer-BobCorp into it. Remove jira-users from it The second config is a bit more intuitive but can become a pain to maintain, and doesn't allow your project administrators to look after their own users: - Add a group like Customer-ACME and add all the ACME users into it - Add a group like Customer-BobCorp and add all the BobCorp users into it - Set up a permission scheme that says Browse: Group = customer-Acme - Apply that scheme to AAA - Set up a permission scheme that says Browse: Group = customer-BobCorp - Apply that scheme to BBB The third option is a hybrid of the two above - Two schemes as per the second option, but the browse line has both "group=" and "role=users" - Again, remove jira-users from the roles completely This will let your project admins maintain the users in their projects and still let the groups in, even if the project admin removes them from the roles. I only use hybrids when I can trust the project owner to understand it fully, as in "you can maintain the users in your projects, but there are some groups who will always have access, whatever you put in there"
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs