How can i disable the greenhopper for some users / groups / roles?

[Dirk Bromberg]

Hi,

is it possible to avoid the access to greenhopper boards for some users or groups or roles?

On Rapid Board there are Share Permissions which helps but what on planning and taskboard?

Thanks.

Dirk

[Nic Brough -Adaptavist- · Accepted solution]

Greenhopper is aimed at projects, not users, so you can't really do that. It's not really a good idea anyway - you don't want group A of users happily doing everything in a Greenhopper way, and then group B asking "what are they doing and why and how?". Unified and consistent view is a much better way to do it.

Of course, there's no harm in killing it off for projects that only need/want the core Jira functionality, but I really don't think it should be a user-based decision.

I think you'll need to delve into the code to disable it on a user basis.

[Dirk Bromberg]

Hm,

the usecase: internal users can use greenhopper but customers should'nt...

[Konstantin Ivanov]

>is it possible to avoid the access to greenhopper boards for some users or groups or roles?

No. the is a setup in system settings where one could enable Agile on project basis, but to no avail. - bug.

Gear->Plugins->JIRA Agile->Enabled projects.

One of the way to overcome this is to not let your Customer log in into jira and use SD plugin instead. (they still logged in but have Customer Portal UI)

But it's advantage is it's disadvantage - it's tooo simple.

p.s. right now is looking for a hack to remove "Agile" button on any basis. I expect to find it shortly :-)

[Ellen Feaheny [AppFusions]]

Dirk -

This is also being discussed over here. https://answers.atlassian.com/questions/69483/how-do-i-remove-agile-tab-for-other-users-of-jira

If interested, email me at ellen@appfusions.com and I can bring you and the other poster together for best approach/cost on this. We've already spec'd it .. could get done this week even.

(Ideally, a supported plugin that has a life on marketplace.atlassian.com.)

Let me know if interested.

Best,

Ellen

[robert Johansen]

I also would like to have only the rapid board editable by group not by project. If I have multiple scrum teams I want everyone to be able to view everything but I dont want someone not a part of the scrum team messing around dragging and dropping issues where they dont belong. Hence edit only for group permission.

[Nic Brough -Adaptavist-]

Edit, as you describe, is a slightly different matter. Forget Greenhopper for now and look at the project. If you have users who only have "browse" permissions in the project, then GH will respect those. They'll be able to see GH, set up and use their configs and so-on, but they won't actually be able to change anything, including dragging issues around. (On a complexity note - the dragging is controlled by your workflow, so you need to make sure there are conditions on your workflow transitions - something like "user must be in the role of a developer in the project" is a good generic one)

[robert Johansen]

The only probelm is I have multiple Rapid Boards, One per scrum team. So I want only who is in that scrum team to be able to access only their own board not the other teams boards. I think the best way to do this is by only sharing a rapid board between a group lets say scrum team 4. So scrum team 4 can only edit issues in scrum team 4 rapid board but can also view but not edit other scrum teams rapid boards. I would simply make scrum team groups for each scrum team. Is this not possible?

[Nic Brough -Adaptavist-]

I don't think it is - you're thinking of the boards as separate entities, but they're not, they're representations of the same underlying data. If you change something on one board, it'll reflect in all of them.

If you don't want a group to use a particular view, just tell them "here's a better one for you" and direct them at their own board.

[robert Johansen]

Right but if they have their own views and someone accedentally moves an issue that is not meant to be moved whilst looking at that specific scrum team view. Then we have an issue. People should be sticking to their own scrum team views but if the look at the others and move something by chance then we are in trouble. Seeing as Rapid board has yet to consolidate to one major view for everyone ( as I think it should ) we are left no option but to make a board for each scrum team so that they can plan and start their own sprints.

[Nic Brough -Adaptavist-]

But that's my point - if they move it in view A, it'll move in view B as well. It doesn't matter which view they used to do the move, they've moved it. I do understand that for user X, view A is more useful and makes more sense than B, and for user Y, the reverse is true. But the fact is the user has the right to move the issue around, and if they get it wrong, then they shouldn't have done it.

I have to say it sounds like you've got a partly broken process if you've got views that are so wildly different, that they can't be understood by two teams, who, I assume, should be working together...

[robert Johansen]

Okay so let me clarify what my views look like. At the moment I have about 8 rapid boards. One per scrum team. Each one has a seperate filter so that each scrum team can see their specific backlogs pertaining to them. so there for no issues will be on multiple rapid boards. That way Scrum Team 5 doesnt mess up scrum team 1. I did this because of the limitation of starting sprints. We need a sprint per scrum team and one view or a project based view of the rapid board wouldnt cut it. So in that case someone from scrum team 5 shouldnt be editing someone elses issues in scrum team 1.

[Nic Brough -Adaptavist-]

Which then begs the question - how are you stopping people from doing "bad" things in Jira?

Even if you restricted GH by group, there's nothing stopping someone poddling around Jira and breaking it all.

[FélixE]

Yeah, you'd have to use Issue Security to really enforce what you're going for. My approach to configuring security in JIRA is to give more permissions than less, and step in if someone does something wrong.

[robert Johansen]

@Nic, you said "The best option is always to let everyone see everything, but be very clear that different views are aimed at different people. " So why can I not let everyone see all the rapid boards but the scrum team that owns the rapid board should be the only ones to edit that board. Is there a way to do this with just issues that is not a condition in the workflow?

[Nic Brough -Adaptavist-]

No, you're missing the point again. The data behind the boards is the same. You're not "editing a board", you are editing the data behind the board. If a board happens not to include some of the data, that's fine, the user can't edit it on the board because it's not there. Equally, if their edit is blocked by workflow behind the board, the board won't let them breach that condition.

[robert Johansen]

I realize that so in other words no there is no way to do it except for editing the conditions in the workflow.

[Gene Myers]

Nic above says "If you have users who only have "browse" permissions in the project, then GH will respect those. " but I've found that not to be true. I have users that can only browse- they can't create or eidt issues through 'normal' jira...but once they are on the Rapid Board, they can move issues at will.

[Nic Brough -Adaptavist-]

GH is still respecting those. Moving cards around in Greenhopper is equivalent to moving issues through the workflow in plain Jira. That implies you are using workflows that do not have protective conditions. Check the conditions on the workflow actions - if there are none, then people who can see the issue can also move it around on the board. (If you look at the default Jira workflow, you'll find every transition says "must be user in project" in some way or another)