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

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

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

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.

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

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

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
Community showcase
Posted Friday in Jira Service Desk

Looking for anyone who has switched from Zendesk to Jira Service Desk

Hi Community! The Jira Service Desk marketing team is looking for customers who have successfully switched from Zendesk to Jira Service Desk!   We’d love to hear your thoughts on the pros and ...

158 views 8 3
Join discussion

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