Erik,

We have done nothing but consider alternative to Jira. Frankly, it shocks me what Atlassian gets away with. I'm assuming the business environment and legal system in Australia is out to lunch.

That said - can not find alternative as of yet. AND THIS IS WHY ATLASSIAN GETS AWAY WITH MURDER. Developing a competing product is not a big deal and would take far less energy then what Jira users have pissed away with this hack product.

Atlassian should focus on customer-satisfaction. We are using JIRA for support, less than 10 people supporting more than 100 customers (so we need to buy a 500license, so far so bad).
Only internal user should have access to AGILE. We did not accept to pay a AGILE license if around 490 licenses or 98% will be unused until end of earth.

I personally am less concerned on the cost component, as compared the issue of content control. In particular, my management dislikes having to have entire projects created to have a private Kanban board for organizing their work... Particularly because that means they can't share issues with non-management.

This has actually gotten to the point that they are considering a competing product (as opposed to expanding JIRA) solely because the alternative is not being able to use JIRA as desired.

Absurdo!!! Onde fica a segurança?
Favor reconsiderar a decisão, pois precisamos restringir a visibilidade do agile de acordo com os grupos ou projetos dos usuários.

I totally agree! I really don't understand why Jira Agile is not restrictable for a group of users - We currently habe 8 Users using Jira Agile and other 42 that are not, but those 42 Users can access the boards bur don't understand what they mean,... this is really stupid! On the other side, why do I have to pay for 50 Users when only 8 use it!

We're using JIRA as both our internal engineering Scrum tool and as our customer facing support ticket tool. Our external customers should not be seeing an Agile menu since it has no relevancy to them, and we shouldn't have to run two completely separate JIRA instances in order to accomplish this. With the advent of "JIRA Service Desk" in which Atlassian seems to be promoting the use of JIRA as a customer facing support ticket tool, it makes the omission of this feature even more glaring. Please reconsider opening this issue?

It's not just the separate licensing model (would be nice, yes) ... but for us it's important to restrict certain GreenHopper actions (like Backlog Grooming, Creating Boards, Creating Sprints) only to Product Owners. Developers and especially Freelancers/Contractors should definitively not be able to mangle with these things!

This is really a big mess!!!!

In our Company we use jira for nearly everything. We use a 50 User License. Greenhopper would be great for our developer and technical team that would be only between 5 and 10 Users.

Why ca't I licence Greenhopper for 25 and Jira for 50??

Seconded. Atlassian - you are flushing cash down the toilet here by missing out all the folks that would buy Greenhopper 25 user licenses for their SW dev teams but have unlimited JIRA users, versus not buying Greenhopper at all. Poor form indeed.

The current status no longer applies. Please reconsider this issue immediately. We use JIRA for far more than Agile development, out of 100 users only 20 are developers and only 20 need Greenhopper. We will not license Greenhopper for all 100 users, it is not an option.

I can second several comments here. We have an unlimited JIRA license for all kinds of users and we can use Greenhopper for developers and team leads etc, but that is like 25 people. I don't dare to request a license for Greenhopper and spend such a huge amount of money on it.

Greenhopper is tool which is useful for a subset of users, not all users. I don't understand why the license model doesn't reflect that.

Please reconsider/reopen this issue.

Now that you've resolved GHS-1800 (and I do like the rapid boards,) please reconsider this issue. It seems to be of two parts, both of which I would like to see implemented, both of which seem useful and possibly necessary for JIRA to expand into the support-center role that I've heard so much about from Atlassian.

First, hiding the agile tab: We use JIRA as a development tool for our 8 developers and as a support tool for a mix of authenticated clients and unauthenticated guests. I don't much care that our authenticated clients can see our agile boards, but our guest users should be faced with as little clutter and distraction as possible. We will hide the Agile tab entirely using one of the hacks supplied by other commenters, but JIRA/Greenhopper should support permission-based menu visualization.

Second, decoupling JIRA and Greenhopper licenses: I'd like to add my voice, perhaps less stridently, to the argument that I shouldn't have to buy a 100-user Greenhopper license for my <10 developers, just to fit a particularly stupid Atlassian business model. (OK, that was a bit strident. But it is a really stupid coupling. Is JIRA a developer-only tool, or is it a support tool?)

I understand I can buy 2 copies of JIRA, one for developers, one for support, and only tie Greenhopper to the developer instance; JIRA5 seems to have made some advances in cross-JIRA copying, but as far as I can tell I still can't move an issue between JIRAs the same way that I can move an issue between projects, so that solution won't work yet.

Perhaps the Greenhopper team doesn't see JIRA as a support tool, just a developer resource. I get that, but the JIRA documentation implies otherwise: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System

Seriously Atlassian - what are you at?!?

I have 200 JIRA users throughout my company on an unlimited license and around 7 Greenhopper users. I thought I could buy the $10 license or at most a 25 user license @ $600 and everone would be happy. Are you telling me that in addition to the big wedge of cash I gave you for JIRA (and several years maintenance) I now have to drop $8000 dollars to let 7 people user Greenhopper?!?! Seriously?? EIGHT GRAND??? Remove this absurd requirement now. You've got enough cash.

We also would be very happy to distinct GH licencing to JIRA licencing. We currently have 25 licences and plan to upgrade to 50 while we only have 10 GH users. We have today 15 unsued paid GH licence, if we can avoid upgrading to 40 unsued paid that woul be nice.

Granting Access to Agile menu is also very interresting imo.

Regards,

We just purchased a Jira / GH 25 user license. I was disappointed to discover this issue as soon as I tried to restrict the use of Greenhopper to certain people within my organization.

It is very likely we will drop Greenhopper unless this is fixed. I have 25 Jira seats which are all being used heavily... but I only am using 7 of the forced 25 seats for Greenhopper and I can't lock those other people out.

Please please please..... at the very least give me the capability to license only Greenhopper seats I need and lock out the other people. You did a great job with Fisheye/Crucible!!!

Thanks,

Paul

Does the fact that this issue incorporates decoupling GH licensing from JIRA licensing mean that implementing this will decouple from JIRA licensing? I dearly hope so.

I also work in a company (Just-Eat) where we're expanding our JIRA licensing to cover most employees (around 100 will have accounts, I think; not everyone). However, this blocks us from getting GreenHopper, since only the technology team and product management need it. If this issue were resolved, we'd probably buy a GH license for the subset of people that needed it.

This item is a No-Go for anyone really using Jira being the "enterprise" Issue-Tracker. Each company which is tracking issues for various user groups such as sales, 2nd-level support, customers, development and more has the problem to show information matching to the groups interests. Or blocking access to functions matching to the groups access level.

The fact that the "Decouple Greenhopper licensing from Jira licensing" issue has been "resolved" as Won't fix shows that Atlassian has either not given thought to the real nature of Greenhopper being a development tool (and thus not usable for Sales/2nd-level support/etc.) or just wants to cash-in the additonal license costs without delivering a greater benefit to the customer.

In my opinion, there should be some sort of "Greenhopper-User" flag that might be attached to selected users that shall be able to access Greenhopper functions. The Greenhopper license would then control the number of users that can be marked with that flag.

There you go...

I wonder why Atlassian aquired Greenhopper - being a Development-Planning-Plugin - and not give a thought to all the Jira-users that might not be involved in the development process.

Thanks for considering this matter.
Andreas

Here a more detailed version, which is now "hiding from all users exept members of showgreenhopper".
The version I posted before was "showing to all users, except members of clients".

I added the lines before and after the line which I insterted.

only line 8 has been inserted, the others are just for orientation.

7	#foreach ($headerLink in $mainHeaderLinks)
8		#if ($authcontext.user.inGroup('showgreenhopper') || (!$authcontext.user.inGroup('showgreenhopper') && $headerLink.id!="greenhopper_menu"))
9       		#set ($shouldBeLazy = $linkManager.shouldLocationBeLazy($headerLink.id, $user, $helper))

only line 72 has been inserted, the others are just for orientation.

71			</li>
72		#end
73	#end

Regards
Michael

Michael Wagner added a comment - 11/Aug/10 3:12 AM - edited

We solved this by hiding the menu item. This is not perfect, because a user can still access the pages by providing the correct link.

we did these changes to WEB-INF/classes/templates/plugins/webfragments/system-navigation-bar.vm

In which section of system-navigation-bar.vm do I insert this code?

One more voice in favor of decoupling jira-greenhopper licenceses. We are a 60+ company with about 90 users right now and growing really fast since we started creating jira accounts for our customers.

Only a very small subset of the company uses greenhopper and we wont pay a licence for everyone.

We solved this by hiding the menu item. This is not perfect, because a user can still access the pages by providing the correct link.

we did these changes to WEB-INF/classes/templates/plugins/webfragments/system-navigation-bar.vm

 
4d3
< 
8d6
< 	#if (!$authcontext.user.inGroup('clients') || ($authcontext.user.inGroup('clients') && $headerLink.id!="greenhopper_menu"))
72d69
< 	#end

Regards
Michael

Please explain why this is important in your organisations. As GreenHopper respects all JIRA permissions I would like to better understand why the display of information that is presently available in JIRA is not desirable in GreenHopper.

Consider a case such as this:

• create several an issues not visible by the client, set a version for them
• client creates an issue, which you incorporate into the same version

So given that Green Hopper only shows what is available in JIRA - when the customer looks at the release time for the version (since they only see issues visible to them) it is different to the release time for someone who can view all of the issues.

• Customer complains asking why we can't deliver the version in the time frame they see in Green Hopper.

To save us the hassle we'd rather not let the customer see Green Hopper at all.

Regards,

• Marcus

With our JIRA instance we have:

1. customers and developers with access to the same project
2. development tasks hidden from the customer

Green Hopper contains sensitive raw project information that we would not want the customer to see. As such we'd want to disable the 'Agile' menu for the customer user group. We are in the last stages of our evaluation of Green Hopper - this will block it.

Similar to other comments here, we have a 15 person development team that would use GreenHopper functionality but have the unlimited license version as we are dumping our existing web request tracking system and incorporating all into Jira. This means we have a lot of casual users that would never use the GreenHopper functionality and it seems painful to pay basically double the Jira price ($6K -> $12K) just for this functionality - in fact it is prohibitive.

thank you for the information. question: what does "LTE" mean? thanks – rainer mueck

Hi Rainer,

We are exploring this further and have scheduled it for review in July, after Atlassian Summit. As such, it will not be addressed in the next six months.

Thank you for your feedback to date.

Regards,
Nicholas Muldoon

+61 2 8916 9125 (Australia)
+1 415 408 6147 (US)

Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com

Any chance, this can be implemented a) at all b) soon?

Thank you for the feedback Rainer, it is greatly appreciated.

Regards,
Nicholas

our product managers use GreenHopper to perform product backlog ranking via drag&drop. such ranking modifications are not logged with the issue (http://jira.atlassian.com/browse/GHS-347). so, anybody who has access to the Jira project in question (in our case nearly everybody) can change product backlogs intentionally or not and nobody gets aware of it - nor can changes be tracked.

so we need a way to secure such ranking operations. GHS-1374 would solve this problem.

Rainer Mueck, Software AG, Germany

Hi Thomas, Rainer,

Please explain why this is important in your organisations. As GreenHopper respects all JIRA permissions I would like to better understand why the display of information that is presently available in JIRA is not desirable in GreenHopper.

Thank you.

Regards,
Nicholas Muldoon

Register now for Atlassian Summit 2010, June 9-11 http://summit.atlassian.com

Can we please raise the priority of this issue to high?

Hi Kevin,

Oof you used the big hack
Well if you are welling to hack JIRA you might want to do the same with GreenHopper.
You can modify the atlassian-plugin.xml and add your own conditions for the menu item and issue operations to appear or not based on the groups by overriding the existing Condition.

For example you could replace the current Condition which is:

By

I think this should work and answer your need.

Cheers,

If you're hiding fields from end-users such as priorities using this method, Greenhopper becomes a loophole because you can't hide the fields in the same way.