How do i remove Agile Tab for other users of JIRA

[Shoaib Khan]

Hi,

I recently started using JIRA with Greenhopper plugin. The problem I'm facing is that I have One Admin(Myself) and Five Developers in team for whom I've created the profile and they are able to login and check the issues, resolve, close etc. But they are also able to view the Agile tab beside Dashboard and clicking on Agile tab lets them view reports, Add tasks from Product Backlog to Sprint etc. These are management task and other team members of Scrum should not be allowed to access these options. What I want is to simply Hide the Agile Tab when they login to Jira through there credentials. Is it possible? Please help me solve this issue.

[Ellen Feaheny [AppFusions] · Accepted solution]

SRK - Contact me and we can make a supported plugin that does this. Ellen@appfusions.com

[Gene Myers]

>I also really don't understand why people keep asking to hide bits of Jira

I want our customers/stakeholders to see roadmaps, and even the stories and issues are fine, but not necessaily our prioritised backlog- too much lobbying for their work to get priority.

I wanted to hide the scrum boards (Rapid Boards) from their view. I couldn't hide the tab but I figured out how to hide the boards, its easy. Instead of sharing the filter used to create the scrum board in greenhopper, with everyone, I limited to just the group that I wanted to have visibiltiy. Viola! If the filter is out of their scope, so is the board.

[Nic Brough -Adaptavist-]

Not without coding. See https://answers.atlassian.com/questions/65731/how-can-i-disable-the-greenhopper-for-some-users-groups-roles for a recent related discussion.

I also really don't understand why people keep asking to hide bits of Jira - all you're doing is hiding a view of information that users can see another way, which seems pointless to me.

[Shoaib Khan]

Hi Nic,

You didnt get my point. Neither there is any solution at the link you provided. Only people fighting over the issue and trying to prove there point. If there is an issue there must be a solution as well.

What about the Customers ? Do we really give permissions to our customers to view our taskboard, planning board, reports? If I give a customer a permission to raise an issue he is facing with the product I have to give him Browse permission on the project which results in availability of Agile Tab with all of the project details which is really nonsense. And anyone here who really have the answer kindly post it or provide a link.

Thanks in advance.

[Nic Brough -Adaptavist-]

No, I got your point perfectly, you've misread the response. See the first sentence.

The second paragraph is an opinion on how people use software. Having worked on all sort of things for many years, I've come to the conclusion that hiding views from users is almost always a sign of an over-complicated process that is broken, or it's counter productive because people can't see the same view of what's going on and have to ask. The best option is always to let everyone see everything, but be very clear that different views are aimed at different people.

[Brandon Woods]

Im sorry Nic I do not agree at all. I see what you mean if the software was only being used for a development team and they could use it for access and to see what is coming up. However I have an entire company of many different departments and its WAY too easy for a Sales Account Manager (Salesperson) to go into the the Development Sprint and make changes, even by accident.

There is no reason a sales person needs to be in the Agile Development view for our company and this is a pretty big issue for us. I want the SAMs to be able to view their own project and board, but there is no reason for them to access everything that development is doing on a granular level or especially the ability to create new boards or make changes to any board.

How are companies supposed to be able to put their entire staff into Jira and Confluence? Anyone can access the Sprint boards of development with the potential to make deliberate or accidental changes. No permissions for Greenhopper is a pretty gross oversight. Even turning off the "Agile" drop down for restricted users would be an option for some companies. Technical Account Managers (TAMs) only need access to a bugs list, not full boards, they dont develop at all, why in the world would a Customer Service person collecting a customers complaint or bug need access to all of the Development Agile Boards?

I hope someone makes a plugin for this soon, if you know of one, let me know.

[Nic Brough -Adaptavist-]

Er, no, you've missed a large point here.

If the information presented is of no use to them (whether it really is, or they don't understand it), humans will simply ignore it. But you're going to find some of them do find it useful and then you've blocked people from sharing. The most obvious case for me has been a case where a salesman asked "where's the project at". Didn't understand the answer fine. But all the explanations, bodged attempts at fiddling reports and the rest failed miserably to explain it. 2 minutes work explaining how scrum boards work and what they're showing him and he's fine.

The miising point here is that there's absolutely no need to give the npn-developers any rights to change anything. Use anonymous access, you don't even need accounts. Use permissins to allow visibility, use education to inform the users of what they might find useful (And give insights into how development teams work - the most effective organisations share and understand information across teams and silos), and use permissions to stop people doing things they should not do.

[Leon Thompson]

This is disturbing. I have worked in IT for too many years, I love innovation, and I would say I am not backwarrds,

Nic, if you are still around. In simple terms, ... Oh my goodness. Your reply is incedibly poorly thought through. 
i hope this experiance gets better,

LT

[Nic Brough -Adaptavist-]

I did think it through, very carefully.  I had to because I was challenged, and well, by people who were also thinking about it.

They couldn't change my mind because they were essentially wrong.  The principle is still the same, and I don't think you've grasped the arguments.

Now, 5 years later, you can remove access to Agile functions.  The users who don't have it end up demanding it when they notice other people do.  So there's still no point in hiding it (except that now it saves you money)

[Ola Olajid]

Why hide project info from everyone involved in the project? Clearly this goes against one of the three PILLARS of Agile(Scrum) i.e. Transparency.

PILLARS of Scrum = Transparency + Inspection + Adaptation

[Nic Brough -Adaptavist-]

Very good point (I may be biased because it directly supports what I was saying and the others here REALLY failed miserably to understand)