Don't understand roles

[Fré de Vries]

In Jira/Greenhopper ( still don't know wich part of my installation is Greenhopper and wich is Jira) in the default installation there are three groups: users, developers and admins.

As we are using the Scrum method, as admin I created a Scrumboard.

We have a small team of 4 developers (1 of them is scrum master) and a project owner (me), I'm also the Jira-admin.

As a project owner, i create stories. I reorder them with drag&drop, the most important story on top.

I would like to give the scrum master more permissions, like drag&drop reordering, estimate , change status. But every developer has this permissions. Every developer can rearrange the order of the issues, change descriptions, summary, components etc. Why is this the case?

Why aren't there a project owner and scrum master roles by default?

[Nic Brough -Adaptavist-]

Because Greenhopper is an add-on for Jira and not a core function. A LOT of Jira installs don't have it, and some aren't used for Agile at all. It's added complexity for users who don't need it, and the default installation of Jira is very basic. Jira is powerful and flexible, but that makes administration complex, and it's already scary enough without adding roles some sites may not need or understand.

There is already a "project owner" role as well. It's called "project lead" and is associated with the projects (even without Greenhopper). I think the simple assumption is that "project lead == scrum master == project owner" and the defaults do that, and then expect users to create the more compex situations as they discover the need for them.

That said, I think there's a request open for improved defaults, and I'd support it. (My main bugbear is that "jira users = can login" but is then used to do other things in permissions, and that's a stupid default for any site that wants to do any form of sane security)

[Fré de Vries]

I know Greenhopper is an add-on, but i assumed that Greenhopper also would add extra group/user/role levels because it's widely used as a Scrum tool

BTW: can't find a role 'project lead'

[Nic Brough -Adaptavist-]

Thing is, there's no need for extra roles - you've got users and developers, plus the project lead, to get you started. Those cover the more simple scenarios.

Project Lead is associated with projects. Look at the project administration screens, or go to Admin -> List of projects, and you'll see the project leads set there (then go to the admin screen to edit the person)

[Fré de Vries]

Ok, understand that, but.....

As i stated before, I'm ordering the priority of issues using drag&drop. So the issues at the top of the list need to be added to the next sprint and once in the sprint, the first issue needs to be solved first. But developers can also drag&drop issues, so the can reorder my priority. This i don't want.

Furthermore, they are able to change most fields when they edit an issue, this i also don't want for certain fields. Is there a soloution to this?

[Nic Brough -Adaptavist-]

Remove their right to edit issues generally.

Or, for specific fields, remove the fields from the edit screens. You'll need to create workflow transitions with conditions to allow the project lead (and others if needed) to go through different transitions which go through screens that do include the fields.