Board based on filter with a tag does not allow for administration of sprints, bug or feature?

Marcus Malcom January 1, 2013

When I create a board based on the following sample filter:

(labels = SomeLabel OR project = Project1) ORDER BY Rank ASC

I am unable to administer sprints, even though I have Project Administator permissions. The above query is returning issues that are in 5 projects, if I alter the query to look like this:

(project = Project1 OR ((project = Project2 OR project = Project3 OR project = Project4 OR project = Project5) AND labels = SomeLabel) ) ORDER BY Rank ASC

All works just fine - that is I am now able to administor sprints. Note: the query returns the same number of issues.

Versions:

  • GreenHopper v6.0.6
  • Jira: 5.1.3

Any help would be appreciated.

Thank you,

Marcus

1 answer

1 accepted

1 vote
Answer accepted
sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 1, 2013

This is because the 'project context' of your first query is global (labels = SomeLabel could include any project from the entire system). If you are a project administrator for every project on the system you should be able to administer it, but not otherwise.

Your second filter explicitely indicates which projects are included which is why it works as you would expect.

Thanks,
Shaun

Marcus Malcom January 2, 2013

Well, your answer kinda makes sense; however, the documentation on Green Hopper has this all over the place:

"Note that you can only create a new sprint if you have the 'Administer Projects' permission in all projects included in this board's filter."

This seems to imply that any project included in the filter no matter how it got there should be enough. I'm not sure about the "project context = global". I have to say as an end user this was certainly not clear at all and in fact, after reading the above documentation over and over, I came to the conculusion that all projects included in the filter, no matter how it got in there, should be good enough.

I would have to say that this is a bug, because my 2 cents on this is that users don't care if they are in global context or not, they just care that the filter they are using returns a list of issues and if they have the correct permissions on that list. If not, then certainly the documentation needs to be better.

Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 2, 2013

I have added an extra explanation in the document for that point specific for the global scope in the filter.

John Garcia
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 6, 2013

In that case, I recommend filing a feature request at jira.atlassian.com.

Marcus Malcom January 6, 2013

So it is nice that the documentation has been updated, but I was actually hoping to see a change in how GreenHopper works. Can't you just base the project list on the returned issues from the filter? I don't believe that would be an expensive operation.

Suggest an answer

Log in or Sign up to answer