|
[
Permlink
| « Hide
]
Bob Cameron added a comment - 04/Dec/03 12:53 PM
I also place a very high value on this functionality. Derek's method of permissions or assigning a scope to the Issue type field (e.g. which projects does it apply to).
Same thing for me. It's really required in our organization.
This is also very important for us. Other way to implement this would be to restrict the available issue types per project. That would be enough for us.
Same requirement for me too. The list of Issue Type offered at issue creation, may be dependant on the selected Project or on the User Group membership.
We also would like to be able to limit the visibility of certain users/groups to only issues of certain types. It would be nice to be able to specify a group/groups or user who should be able to see issues of a given type (unless overriden by issue level security) when the issue type is created/modified.
Yes, we have the same need as described by Eric Broyles. We'd like the public to be able to Create and View Feature Requests, Improvements and Bugs, but we'd like hide Tasks and a few other custom issue types from the public.
This this exactly the same problem that we have for permission and for notification too. We need to associate permission and notification by issue type.
For example we'd like to enable group of users (the test users) to create only bugs and not features or tasks, and to be notified only for this kind of issue. I was about to send a question to support for this when I noticed this is already requested. Any idea when this might be possible?
For me, I only want to create a custom issue type and set security on that issue type so that certain users can only view those custom issue types. I am also getting asked if we can implement this kind of functionality in my organization. Any plans in implementing this?
This issue was created over 3.5 years ago and it appears that it's never been looked at by anyone at Atlassian. Is there something we can do to get it noticed?
Daniel,
The reason this has not been addressed is that it is a complicated change to the architecture of the system. It also needs to be done very carefully to minimise the number of secuirty holes the change introduces. We have a lot of popular feature requests that unfortunately have not been resolved for a long time: The main reason is that there are a lot of requests which require a lot of effort, and we only have a limited amount of resources. We are doing our best to deliver as much value as we can as quickly as possible. Cheers, Unfortunately it is the lack of addressing these issues that make it less
desirable to renew our licenses with you. Dave Mitchell Anton,
I understand the reasoning here, but almost 4 years before anyone from Atlassian even comments on an issue of this nature seems like a pretty long turnaround. I've seen (and been part of) complete overhauls and major architecture changes in other software in a fraction of that time. This functionality seems very worthwhile. I guess what really irks me here is that it hasn't been addressed at all. I understand prioritization of a large number of issues is very difficult to manage, but this issue is in the top 100 unassigned issues by vote. I don't think it's unreasonable to expect a comment (at the very least) on an issue like this in 4 (!!!) years. Daniel,
You are right. We are hoping to improve on providing feedback on high profile issues in the future. Cheers, I believe the logical place to associate permissions for each "Issue Types" would be in the context of the "Issue Type Screen Scheme" in the Enterprise version or "Issue Types" for all versions. It should be possible to set/clear a (subset) permission scheme for each issue type. The "Issue Type" permission scheme should only support adding project roles since group and user association cannot be configured across multiple projects reasonably. The PermissionManager class would have to be modified so that it first checks the permission scheme of the issue type associated project and if the specific permission were not defined fall back to the permission scheme associated with the project. The standard actions "create", "edit", etc... would not need to be changed if they are all using the PermissionManager class (as they should
 .
Now this task does involve some effort but I think you can manage the task within a couple of weeks with two or three developers. Basically you just need to: -define an "Issue Type Permission Scheme" with a limited permission sub-set and create admin edit and view screens I just had a request for this same functionality. Is there any chance for an update on this?
Any plans to implement this for a future release?
I agree with this feature request: In our organisation we need a kind of this feature too: Some issues to be created by normal users and others by specialists or other specific roles only.
This feature is very much needed for us as well:
For example: The Convert To Task/Sub-Task operation should be restricted as we would like to limit the conversion to specific issue types (some of our issue types are automatic created and no regular user should be able to open them manually or use them for convert). Hello,
we also need this kind of scheme (Issue Type Permission Scheme). Are there some news till now or implemented already? Regards, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
"Issue Type" Security
