Why can't admin see all projects?

[Alicia Pena]

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:

1.  I created a new project for customer 2.
2. I created a new customer 2 group and added a test2 user in it.
3. I created a new customer 1 group and added a test 1 user in it.   (Assuming I'll need to move everyone for this default project into their own group later).
4. I created new separate schemes, screens, workflows, permission schemes and rolls for customer 2 project.
5. The browse Projects in the new permission scheme has Project Role (Users) and Group (customer2).

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.

Thank you

[Nic Brough -Adaptavist-]

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.

[Deleted user]

Further question, and forgive my ignorance:

If global admins can't see everything, what happens when a user creates "private" content and then leaves the company? How does that content ever get edited, deleted or archived?

[Nic Brough -Adaptavist-]

It find it easier to think of it as being in "modes".  I log in with an account that has admin rights, but that just means an account that can do admin stuff if I ask.  While wandering around in that mode, I can't (and don't want to) see everything.

Switch into "admin mode" by hitting an admin function, and I can see the config for everything.

So, in "user mode", the projects menu shows me only the projects I am (as a normal user) allowed to see.  In Admin mode, the project list shows me all of them (so I can configure them, not actually use them)

[Deleted user]

Thanks! That illuminates it well.

[Alicia Pena]

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.

Thanks,

Alicia

[Nic Brough -Adaptavist-]

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"

[Alicia Pena]

I temporarily solved the activity stream issue by filtering any changes made by me.  I'll look into customized dashboards per project later.