|
If you roll in JIRA-5863 (Task sub-task time tracking), then I think the progress bar issue goes away: The parent task estimates and logged hours will reflect those of the subtasks, and so the progress bar won't look strange.
As far as the business of not being able to resolve a task with invisible unresolved subtasks, this seems like an obscure corner case that shouldn't stand in the way: If I'm not allowed to see the subtasks, is it really reasonable for me to think about resolving the parent task? If this odd situation occurs, I'd just say tough luck - you can't resolve the parent, and you can't find out very much about why not. Anton wrote:
Keep it simple: keep the progress bar, remove the list with sub-task and add the following messages
Anton wrote:
It might be confusing without any information, but if you keep the progress bar and add the messages everything will be fine. I strongly agree to Andreas to this feature request. It would help to separate high-level feature request from technical details. Check
And it seems that there not too much code change to enable this feature - check Thanks for your feedback! Its great to see suggestions coming from our users. Otherwise it is very difficult to ensure that we build features the way our customers want them.
I should also have mentioned that the progress bar and workflow are not the only things that stand in out way. The main problem is deciding which features we should implement first. We have a lot of feature requests and choosing which ones to implement next is the most challenging part of our jobs. The way we make choices is described here: Thanks again for the feedback, it is very useful for us. Anton Please review this post
and consider this issue as a part of a greater whole. Ahmad Hello,
I have Jira 3.3.3 and need to assign some subtasks to an external software supplier who should not be allowed to see the whole task. I tried to the workaround described in Is there a workaround to be able to edit the subtask security level? Cheers Bettina Zucker Hi Bettina,
Apologies if this confused you but the scenario where sub-tasks became public while the parent issue was private is essentially a bug. The workaround was used to overcome this and ensure that the security level was at least settable. In 3.1 and later, sub-tasks inherit whatever security level the parent issue has. From this issue of course this course of action is a topic of discussion. Suffice to say, the workaround in Instead is it possible for you to create a linked issue that the external supplier can see? Thanks, Hello Brian,
thanks for the clarification. So I have a problem now, Just declare the issue first "private", create the subtasks, which will be also "private", and then downgrade the issue to "public" Regards Bettina Zucker Hi Bettina,
Thanks for the feedback. In relation to the problem with your security level, I would say that the problem was with the index. For future reference, when you see a discrepancy between the issue navigator and the issue itself, the best thing to do is reindex. Thanks, Hi,
I would actually really find this feature useful (Sub-task issue security levels). We have a number of external customers that log issues for different projects, and when the support person responsible for owning the issue needs to get some developers from different areas they create assign subcases for each to do the work. The trouble is that we don't want the customer being able to see our internal development processes, they should ideally just be dealing with the support person. Shall vote for this issue. Cheers, Rowan. 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 Our team would like to manage a single Project which can be shared by developers and external customers. To do this, we would like to create the required sub-tasks necessary to complete the customers requested feature/bug fix without sharing the information. Cloning the orignal issue, applying security to it, and then creating sub-tasks in the cloned issue is not a clean approach and requires extra work. I see this request as a new feature has not been assigned Fix Version yet. Are there any other suggestions as a work around in the meantime?
Voted for this one. Regards. Edmond,
No real workarounds at the moment. I have seen some customers use linking to fulfil this need, it is not as nice but it does work and the issues can have independent issue securities. We don't like to set a fix for until we know for certain what version it will be going in and we only usually commit to the next release. Cheers, We've also got the urgent need that subtasks have a different security-level than the task they belong to and producing duplicates with linking really isn't an option. Let me give you a bigger picture of this: We'd like to use JIRA, so that our customers can make requests and follow their status. The problem is that we cannot train our customers in the use of JIRA, so they'll probably report bugs, request features, etc. all in just one request. Internally, we'll split up the original request and open the appropriate subtasks, like bug, enhancement, improvement, separate offer, etc., but don't want our customers to be able to see the subtasks.
I will welcome too, if this functionality works.
My vote is in.
It is already an old request, any indication on an possible ATA?? I would really welcome this functionality as well. The "bulk changing" of issue security level will also need to be changed to provide an option to enable or prevent the cascading of security level to subtasks.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Sub-Task should have independent security levels
I see your use case, however. Thanks for reporting this.