|
History
| Log In
|
|
|
|
James,
The exact feature you are after is not available at the moment. There are a few alternatives:
I guess the approach you take depends on how often users other than the reporter of the issue need access to an issue. I would also like to see this feature implemented - Neal suggested a user's "primary" group - perhaps this could be something like "User's issue security group". I envisage it being used as James described, when external users need to see the issues their colleagues have logged. The "Reporter" issue security level is too restrictive and the other options require too much user administration.
There is a JIRA Workflow Extension for setting issue security based on a reporters group which may be of interest to those monitoring this issue:
http://confluence.atlassian.com/display/JIRAEXT/Set+security+level+based+on+group A suggested solution here is to create a 'Keyword Reporter Group' role-based permission type.
The Keyword Reporter Group permission type would require a keyword to be specified when utilising this permission type e.g 'Customer-'. A permission of this type would grant rights to the group featuring the keyword to which the reporter belonged. For this to work, users would also have to be associated with a single group-type, a group-type that is tied together by a naming convention e.g. 'Customer-X'. Each user could also only be associated with a single group-type. The beauty of using a Keyword over a concept like Primary group allows this to be used across multiple group types that leverage their own naming convention e.g. Customer-, Dealer-, Partner-, etc. For example, let's say a JIRA Administrator wants to ensure that all users from Customer A can see all Customer A issues and users from Customer B can see all Customer B issues: 1. The user assigns the 'Keyword Reporter Group' role-based permission type, specifying the keyword 'Customer-' for the permission levels Create Issue, Browse Project and Add Comment within their customer facing project. 2. Within JIRA's user management, the JIRA Administrator ensures that all Customer A users are given an appropriate 'Customer-A' group association and that all Customer B users are given an appropriate 'Customer-B' group association. 3. Now when an issue is created by a Customer A user, all other Customer A users will be able to see that issue as they will all share a matching 'Customer-' Keyword Reporter Group: Customer-A. The only piece missing from this solution to make it really fly is to somehow allow all users from a single customer to be able to easily sign up to JIRA and then see and comment on all the issues created by the colleagues without having to add each user to the 'Customer-A' group.
I have a feature request (also linked to this issue) to track the development of a possible solution to that problem - 'Dynamic Groups': We should implement this at the same time to create a really superb solution.
Ben,
At the moment (support is an example) reporters have teh ability to edit an issue and add people to the CC field. Once a user is added to the CC field, they have permissions to view, comment..... Cheers, Hi,
Is there a plan to implement this? This is a very strong point against the deployment of jira among entities or local groups. Regards Hi Mel,
Unfortunately we still can't commit to a date on this issue. There is still the problem of gmail and hotmail users. Cheers, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Add "Reporter Group" Permission
JRA-3417and its linked issues, JRA-5276) you might want to look at. A user can belong to any number of groups, so I think in order for "Reporter's group" to work it has to be a new concept - to be able to specify a user's "primary" group to be used for thingd like default comments, permissions, etc. If, when editing users' groups, we could flag a group to be used for this, that would help.