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


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?



4 answers

1 accepted

1 vote
Answer accepted

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.


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

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.

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)

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?

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.

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.

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...

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.

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.

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.

@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?

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.

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

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.

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)

Dirk -

This is also being discussed over here.

If interested, email me at 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

Let me know if interested.



>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 :-)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

612 views 0 7
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you