Issue permissions in JIRA

[Jeremy Boynes <jb...@apache.org>]

The default JIRA permission setup has a few different types of users:
* "anyone", basically anonymous, who can view things
* "jira-user", people who have accounts, who can create issues
  and add information to them
* "tuscany-developers" who can modify issues, assign them, close them
  for the Tuscany project (e.g. a committer)
* "jira-admins" who can configure JIRA itself and modify things about
  projects

This generally works well but raises a question for people who are
actively involved in the project but who are not yet committers: what is
the policy for allowing them to modify issues?

A few options we have here are:
* restrict it to committers and have them update the issues as needed
* be fairly liberal about granting "developer" status to contributors
* create a custom permission level somewhere between "user" and
  "developer" and grant that to contributors

Any thoughts, suggestions and/or preferences?
--
Jeremy

Re: Issue permissions in JIRA

[Jean-Sebastien Delfino <js...@apache.org>]

We've never closed that discussion. Could people on the group give their
thoughts on the subject?

--
Jean-Sebastien


Paul Fremantle wrote:
> Make sure you don't let anyone (i.e. anonymous users) raise issues. Then you
> become the default project for non-logged in users and you get a whole load
> of random issues added from other projects :-)
>
> Yours talking-from-experience
>
> Paul
>
> On 1/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>   
>> I'm just starting to look at JIRA and here are some thoughts:
>>
>> I can identify the following roles:
>> - user
>> - developer (contributor but not committer)
>> - committer
>> - admin
>>
>> I browsed the JIRA docs and I'm still looking for a workflow diagram to
>> better understand the lifecycle of a JIRA issue, but here's what I think
>> each of these roles will want to do:
>> - As a user I want to be able to report and modify issues, resolve
>> (cancel?) and close/verify issues that I've opened.
>> - As a developer I want to be able to do all of the above, plus assign
>> issues that have not been assigned yet, modify issues, resolve issues
>> assigned to me (duplicate or not repro for example?) and attach patches
>> to them (assuming that this is how patches get contributed).
>> - As a committer, I want to be able to do all of the above plus resolve
>> issues (as fixed for example after checking in) and reassign issues.
>> - As an admin I want permission to do everything.
>>
>> What do people in the group think? Jeremy, does that fit with the JIRA
>> user-type / permission model?
>> --
>>
>> Jean-Sebastien Delfino
>>
>> Jeremy Boynes wrote:
>>     
>>> The default JIRA permission setup has a few different types of users:
>>> * "anyone", basically anonymous, who can view things
>>> * "jira-user", people who have accounts, who can create issues
>>>   and add information to them
>>> * "tuscany-developers" who can modify issues, assign them, close them
>>>   for the Tuscany project (e.g. a committer)
>>> * "jira-admins" who can configure JIRA itself and modify things about
>>>   projects
>>>
>>> This generally works well but raises a question for people who are
>>> actively involved in the project but who are not yet committers: what is
>>> the policy for allowing them to modify issues?
>>>
>>> A few options we have here are:
>>> * restrict it to committers and have them update the issues as needed
>>> * be fairly liberal about granting "developer" status to contributors
>>> * create a custom permission level somewhere between "user" and
>>>   "developer" and grant that to contributors
>>>
>>> Any thoughts, suggestions and/or preferences?
>>> --
>>> Jeremy
>>>
>>>
>>>       
>
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>   

Re: Issue permissions in JIRA

[Paul Fremantle <pz...@gmail.com>]

Make sure you don't let anyone (i.e. anonymous users) raise issues. Then you
become the default project for non-logged in users and you get a whole load
of random issues added from other projects :-)

Yours talking-from-experience

Paul

On 1/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> I'm just starting to look at JIRA and here are some thoughts:
>
> I can identify the following roles:
> - user
> - developer (contributor but not committer)
> - committer
> - admin
>
> I browsed the JIRA docs and I'm still looking for a workflow diagram to
> better understand the lifecycle of a JIRA issue, but here's what I think
> each of these roles will want to do:
> - As a user I want to be able to report and modify issues, resolve
> (cancel?) and close/verify issues that I've opened.
> - As a developer I want to be able to do all of the above, plus assign
> issues that have not been assigned yet, modify issues, resolve issues
> assigned to me (duplicate or not repro for example?) and attach patches
> to them (assuming that this is how patches get contributed).
> - As a committer, I want to be able to do all of the above plus resolve
> issues (as fixed for example after checking in) and reassign issues.
> - As an admin I want permission to do everything.
>
> What do people in the group think? Jeremy, does that fit with the JIRA
> user-type / permission model?
> --
>
> Jean-Sebastien Delfino
>
> Jeremy Boynes wrote:
> > The default JIRA permission setup has a few different types of users:
> > * "anyone", basically anonymous, who can view things
> > * "jira-user", people who have accounts, who can create issues
> >   and add information to them
> > * "tuscany-developers" who can modify issues, assign them, close them
> >   for the Tuscany project (e.g. a committer)
> > * "jira-admins" who can configure JIRA itself and modify things about
> >   projects
> >
> > This generally works well but raises a question for people who are
> > actively involved in the project but who are not yet committers: what is
> > the policy for allowing them to modify issues?
> >
> > A few options we have here are:
> > * restrict it to committers and have them update the issues as needed
> > * be fairly liberal about granting "developer" status to contributors
> > * create a custom permission level somewhere between "user" and
> >   "developer" and grant that to contributors
> >
> > Any thoughts, suggestions and/or preferences?
> > --
> > Jeremy
> >
> >
>



--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: Issue permissions in JIRA

[Jean-Sebastien Delfino <js...@apache.org>]

I'm just starting to look at JIRA and here are some thoughts:

I can identify the following roles:
- user
- developer (contributor but not committer)
- committer
- admin

I browsed the JIRA docs and I'm still looking for a workflow diagram to 
better understand the lifecycle of a JIRA issue, but here's what I think 
each of these roles will want to do:
- As a user I want to be able to report and modify issues, resolve 
(cancel?) and close/verify issues that I've opened.
- As a developer I want to be able to do all of the above, plus assign 
issues that have not been assigned yet, modify issues, resolve issues 
assigned to me (duplicate or not repro for example?) and attach patches 
to them (assuming that this is how patches get contributed).
- As a committer, I want to be able to do all of the above plus resolve 
issues (as fixed for example after checking in) and reassign issues.
- As an admin I want permission to do everything.

What do people in the group think? Jeremy, does that fit with the JIRA 
user-type / permission model?
--

Jean-Sebastien Delfino

Jeremy Boynes wrote:
> The default JIRA permission setup has a few different types of users:
> * "anyone", basically anonymous, who can view things
> * "jira-user", people who have accounts, who can create issues
>   and add information to them
> * "tuscany-developers" who can modify issues, assign them, close them
>   for the Tuscany project (e.g. a committer)
> * "jira-admins" who can configure JIRA itself and modify things about
>   projects
>
> This generally works well but raises a question for people who are
> actively involved in the project but who are not yet committers: what is
> the policy for allowing them to modify issues?
>
> A few options we have here are:
> * restrict it to committers and have them update the issues as needed
> * be fairly liberal about granting "developer" status to contributors
> * create a custom permission level somewhere between "user" and
>   "developer" and grant that to contributors
>
> Any thoughts, suggestions and/or preferences?
> --
> Jeremy
>
>