We need separate "Rank issue" permission, too

I want to vote

Hi All,

We have looked at adding a mechanism for GreenHopper to use other permissions for this procedure. At the moment, Ranking in GreenHopper 5.8.2 requires the 'Schedule' permission. There is a possibility we may be able to offer a separate permission, we are looking in to it but can't confirm it will be added.

Thanks,
Shaun

Hi Mark,

I totally agree that it is valid. The limiting factor is that getting a permission in JIRA core is non-trivial and as such it is way down the list of items that we intend to work on. Hence the Won't Fix so that everyone is clear it is not coming.

If one day there is a way to add a permission in JIRA as a plugin we will definitely reopen.

Thanks for your thoughts, I appreciate the consideration and input.

Regards,
Nick

Hi Nick:

Regarding technical perspective - I think you are referring to the ability for a v2 plugin to create a permission in the core, and how this is technically not possible.

Wider vision on this, however, GreenHopper is currently bundled into the JIRA 4.4 core if I understand correctly, and it is a key plugin that is sold for a not insignificant amount of money. I think that if the right business case existed, it could be quite exceptable to create a new permission in the core, with the understanding that this permission would only be valuable with some higher level project management plugin such as GreenHopper.

Back to my original comment: "We want to restrict ranking to Product Owner and Scrum Master, while still allowing project members to set their own Due Date. Now that JIRA and GreenHopper are more closely tied together, and provided by the same company, please consider providing a new permission for ranking."

We have a subtle problem in that we don't mind "Schedule Issues" being used for ranking - but if we do this, we prevent our project members from setting their own Due Date. Basically we don't care what you call it or how you deliver it - but we think the ability to select rank should be separate from the ability to set Due Date. Right now we either have too open or too closed, no matter what option we choose. In a sprint - the Product Owner may rank, whereas the Scrum Team will decide on Due Date as a mechanism to communicate and schedule exactly how the stories will need to be resolved into order to meet the Sprint commitment. Alternatively, if Due Date comes from customers - then we would want the customer to set Due Date, which also would not be the same people as the Product Owner who may rank. The scenario where only the Product Owner would set Due Date is too restrictive and puts micro-scheduling requirements on the Product Owner. They want to see our schedule - they don't want to define it. If they did define it - they would use Microsoft Project - not GreenHopper.

I think it's worth a little more thought as to what this permission should be called - "Rank" might be too GreenHopper specific - but the requirement is valid, and it is incorrect to conclude that there is a technical restriction here. It is a policy restriction. I believe I saw that the JIRA 4.4 release notes introduced a new permission, so it seems it is technically possible.

Hi Nick,

This is a great idea to have Rank Issue permission.

Thanks
Ganga S

Hi Nancy,

The difference is that the Schedule Issue permission is a JIRA permission. GreenHopper is not able to, from a technical perspective, create a separate permission called Rank Issue.

Thanks Nancy,
Nicholas

If you need field level security to create a 'rank issue' permission, how are you controlling access to ranking with the 'schedule issue' permission?

I like the change rank history that comes with the global rank.

Hi Folks,

Unfortunately we were not able to create a Rank Issue permission. The Global Rank (only used on the Rapid Board today) is based upon the Schedule permission.

We do win in one area though, we now record changes to the Global Rank within the History of an issue - GHS-347. Look forward to this in GreenHopper 5.7 which will be released along with JIRA 4.4.

Thank you.

Regards,
Nicholas Muldoon

Reopening this issue as we are exploring improvements to the ranking at present. While I don't want to get anyones hopes up there may be a way we can work around the field level security.

Fingers crossed.

Thanks,
Nicholas Muldoon