JIRA permissions [Controlling]

[GilK]

Hi,

How do I control JIRA permissions?

I'd like to enable some of my users to Add Gadget to the Directory; how do I achieve that?

I'd like to enable some of my users to Add new versions/releases (includeing GH versions/releases); how do I achieve that?

Thanks,

Janiv

[Nic Brough -Adaptavist- · Accepted solution]

See http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions for most of what you need to know about permissions (for this question, it covers versions)

For adding gadgets, no, only administrators can do that. See http://confluence.atlassian.com/display/JIRA/Adding+a+Gadget+to+the+Directory

[GilK]

Thanks,

So when some of our developers write its own gadget, how does he test it before I (as admin) upload it?

Thanks again.

Janiv.

[GilK]

So, all Greenhopper users (scrum masters) are actually project administrators?

Thanks,

J.

[Nic Brough -Adaptavist-]

Your developers should be administrators in their development systems. They probably should be administrators in your test system if that's necessary, but the flavours of testing and how you do testing might do determines that.

No. Greenhopper users are ordinary users. Generally, scrum masters would have project admin rights so they can do Greenhopper organisation, but that's not always the case - depends on how you work.

[GilK]

I have a problem:

Each one of our developers may release a new version to the qa (for example, an iPad developer, fixes few bugs, and releases a new version to the qa for testing).

That means that he needs to create/add a new release/version in GH.

That means that all developers must be project admin.

It doesn't make sense does it?

Your help is appreciated,

Thanks,

Janiv.

[Thomas Schlegel]

no, this does not make sense, in my opinion. There should be someone, who is planning, managing and controlling the releases. In our company, the developers make their private builds, of course, but not everyone of them is building an official release. The changes are consilidated and only one release build is done.

[GilK]

Thanks,

At our company there are two circles of testers: QA and Integration.

As my team is responsible for 15-20 products, I cannot sync all the products to a single release to the qa team.

The qa team accepts releases from developers, at the end of the sprint, they gather all good products and deliver it to the integration team for further testing.

What method would you recommend then?

Thanks,.

Janiv.

[GilK]

We have over 100 products!

My team is responsible for 15-20.

Yes and no, there is one release per product at the end of the sprint, but we might have few internal releases for the same product during a sprint.

We use continuous QA: the developer releases a new internal release to the qa, if there are bugs, he fixes them and releases another one.

The latest stable release is than goes out from my team to the integration team.

We can have 1-3 internal releases per product in a single 4 weeks sprint.

Thanks,

Janiv./

[Thomas Schlegel]

How much Jira projects do you have ? Are there different releases for one product per sprint ? I hope not. ;-)

If you have 20 products, you should have 20 Jira projects (at least). Every product has its own releases and sprints. I think that's the only solution for your problem.

[Nic Brough -Adaptavist-]

I'd like to see "version and component" management as a separate permission to "project admin" myself, but it's not been done yet. On the other hand, I've seen what happens when you let developers set their own versions, and it quite often *really* needs to be out of their hands...

[Thomas Schlegel]

hmm, ok., another aproach: create one main-version per sprint and per product. With GreenHopper the developers can create subversions of this main-version as much as they like. If the sprint comes to its end, you can combine all the fixed issues from the sub-releases to the main sprint-version and release this main sprint-version.

I do not know, if this is practicable, but you can try it out. Good Luck :-)

[Renjith Pillai]

@janiv. I am not sure whether I completely understood your situation. But my guess is that there is a slight mix-up between the usage of Version and the Build. What I could understand is that what developers releases mulitple builds for the same version.

To manage which build the changes are going (if you are not using a continuous integration system like Bamboo or Jenkins), then create a custom field (text type) which can be filled by developers (since they decide how to build and release) so they need not be project admins. I would have preferred that builds are always done outside of developers machines as by all probable means, uncommitted code that is getting built.

[GilK]

Thanks Thomas,

This is good enough for me. That's how we work today. We have a "big" Sprint version, and under the Sprint there are sub versions for each products. I can mamange that.

However, how do the developers create subversions via GH?

Thanks Renjith,

We do use continuous integration (Jenkins), but I don't care about the builds (I don't want each build to be a release in the system); however, I''d like to have multiple releases (1-3) for each product per sprint.

Thanks you all,

Janiv,

[Thomas Schlegel]

Hi Renjith,

so we go round in circles, back to the original question :-)

Developers need the project admin role to create subversions of a main version...

Best regards

Thomas

[Renjith Pillai]

May be then Janiv's releases has to be managed in a custom field rather than a version (textfield type).

[GilK]

We tried having a custom field, but we had lot of errors (as it is free text after all).

I prefer having a close list (and an option to update that list) of version.

Thanks,

Janiv.

[Thomas Schlegel]

A custom field can also be a drop down list box with preconfigured entries

[Renjith Pillai]

Oh then we are back to square one.

I had a workaround which I did for achieving this (a dirty hack though). Had a custom field of type select list. Since custom field values can be updated only by Administrators, published a seperate application which can be run on the developers desktops which internally does a http post to the page that adds value to this custom field (addionally performs a sorting of the values too). This application internally uses an username/password which has admin rights (known only to me). So as far as the developer is considered he/she runs this application whenever they need to annouce a new release number.

Additionally this application also does some validation of the string input so as to ensure that the format is correct. A duplicate check before doing the http post also was done by doing an http get in the beginning with for the createissue page (the page will contain all the values in the select list), do a regexp and load all the values, so that a client side validation can be done for duplicate values before posting to Jira.

[GilK]

Thanks,

But it is not good enough for me.

1. The developers must be admin

or

2. one hell of a hack (too complicated for us)

Any other idea?

[GilK]

Just press the Show Comments link above...

[Renjith Pillai]

Had typed a long comment here, but seems to be lost now and also I saw a comment from Thomas which has disappeared.

[Thomas Schlegel]

Hi,

for adding new versions you need the project administration role.

For adding gadgets to the directory, you must be Jira administrator.

Best regards

Thomas