|
Please review this post
and consider this issue as a part of a greater whole. Ahmad Ahmad,
Can you explain more your situation, why it's bad if people who can create issues can also create subtasks? Or conversely, why people should be able to create subtasks if they can't create issues? I guess this feature request comes under the banner of JRA-5865 (permission schemes per type). Jeff, thank you for checking back!
Basically it's not a bad thing - as long as users don't add additional feature requests or more detailed descriptions as sub-tasks to their issues (very active JIRA community over there There are some users who loves to add all they can think of as sub-tasks - others like to give detailed task orders how to implement this or that (no, I won't name them - I hope they discover this issue after the release of JIRA which incorporates this improvement So, it's the same reason why Ahmad (as an Atlassian customer) is not able to edit, close or assign issue to JRA-8521 (like the JIRA developer team) :
Without restriction, it leads to frequent housekeeping = convert, move, or delete sub-tasks or re-create issues etc. (besides talking to the people who comments already to sub-tasks, etc. etc. etc.)
Hmmmm .... .. you're right - let me re-word it:
Nearly, it's a twin pack:
Jeff, please let me know if you need more input to clarify the requirement. Thanks for the explanation Ahmad.
Unfortunately I appended by mistake a '_' character to the URL – this leads to a dead link
And because of Please review using the corrected link: http://forums.atlassian.com/thread.jspa?threadID=9146 Ahmad We have Jira in use for both internal and public (client) access. Our external clients can create issues. However, because we use sub-tasks this means that clients can play around adding subtasks to the main issue. This is something we would badly like to see fixed by the addition of a 'Create Sub-Task' permission.
Also... Once sub-task creation is locked down, we would also like to be able to limit who can view the sub-tasks. We don't really want our client seeing the 7 subtasks we spawn on their issue.
Dear Atlassian/Jeff,
We are working on a Project where we would like to control who can create subtasks. The way we are thinking of implementing it would ideally be as follows: A small group who control the Main Initiatives, create a new Parent Issue detailing the overall request. These people can then create the necessary, separate subtasks which are required to fulfill the Parent objective, and then can manage those subtasks and see the progress bars acordingly. The people who are assigned the subtasks, can then fill out which ever, different, forms that are required, and update individual status/workflow actions, and add attachments, reassigning it etc, until it is complete. But, only the controller of the Parent case can update "his or her" issue's status with the next step etc, once they are satisfied that the child/subtask is actually properly complete. This would require the feature of restricting who can create subtasks at that particular project level, and would be much easier than having to create a separate project just for the smaller tasks.
kind regards, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Add permission type Create Sub-Tasks ( better: Create Sub-Issues )
for pro project leads.
)
As I have mentioned in one of my e-mails, we try to implement the issues in order of their popularity:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
Thanks again for taking time to express your feedback.
Anton