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.

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....