If your organization has the ScriptRunner plugin, you can easily work around this by adding a post-function on the create transition using Script Post-Function [ScriptRunner]. Select the option to "Set issue security level depending on provided condition". If the condition is always true, just type "true" in the condition box and then select the name of the security level.

i tried with the above approach but it did not worked out for my case

Thank You @irenemweu . It was awsome and worked,

Super disappointing.  @Dave Meyer can you elaborate on why this won't be implemented? Seems like a huge gap in the security and usefulness of coordinated subtasks.  Thanks -EK

I have managed to implement a workaround for cases where you have your users in groups:

1. Go to custom fields
2. Add a Group picker custom field and configure it to apply just the sub-task issue type.
3. Add another Group picker custom field and configure it to apply all the other issue types apart from the sub-task.
4. Go to Issue Security Schemes, add an issue security scheme and also select the project it will be applied.
5. Go to security level of that security scheme and select Group Custom field Value then add the two group picker custom fields you added above.
6. To test it create an issue for the above project with a sub-task, assign the issue this security level.
7. For the parent issue, use the Group picker custom field to select all the groups you would like to view that issue and save.
8. For the sub-task issue, use the Group picker custom field to select all the groups you would like to view that issue
9. For now, I think for every issue you create that has a sub-task you will need to assign it this security level, i haven't figured out a post function to update a custom field of an issue based on the issue type. For multiple issues I use bulk update.
10. The other challenge is hiding or disabling the group picker custom field so that it can't be edited.

t

I am really struggling with the reason Atlassian chose to not fix? If the default configuration is to not allow them, but whether by system or project, allow the client's administrator to decide what is best for them – how does that cause issues for Atlassian? Allowing your clients the flexibility to configure and manage a solution that aligns with their processes seems to be a much better value-add than deciding for the clients what is best for them.
It seems that Atlassian wants all clients to follow their processes vs opening their market to support a variety of use cases --especially when they have a solution that can without causing issues for others..but, management decides that they 1) don't want to pursue organizations, processes, and enterprises that are not development-only 2) don't want to have the burden to validate the flexibility when changes are made (however, good engr practices, unit tests, and automation mitigate this risk) 3) don't care about clients' needs that have valid use cases to support those needs 4) they don't want to increase usage/adoption amongst users that aren't in their product all day/every day...let's not make it easy to support those that want to use the product for their needs..but, again, they aren't engineering/scrum teams.

Very disappointing that this was marked as "Won't Fix"... Our situation is similar to the HR one above. We have clients who log tickets and we create various technical subtasks to complete the client request - we don't want our clients seeing our development discussions etc...

That's unfortunate as you seem to have misunderstood the use cases.
Parents are used to track larger types of processes that are common and allow for end users, especially those who don't work ALOT in JIRA to be able to locate key processes and their associated tasks. Parents are also used to track processes tasks - those that are related and you should not call such a process complete until all subtasks are done. Finally, they allow for creating a template one and then cloning and assigning as that process arises.

The need for different security levels is that often some of the subtasks may be more a client where the client shouldn't see everything associated with the overall process. Others, the information may be employee sensitive.

For example: Termination and Hiring process - there are several subtasks when hiring and terminating an employee - some of which are sensitive; others are not. However, you want each to relate to the action associated with that ONE employee and you create a standard set of items as a parent/subtasks that you want to copy each time that it happens.

Another example: Setting up a client's database. The client should have subtasks that are validation; however, other tasks may contain information that the client should not be involved or know about as they are internal tasks for the internal team. We've turned on a specific feature/configuration for a client and the client has specific items that they are doing; again, we may have subtasks that we don't want to allow clients to see because of their contents. This allows allows the users or those assigned to the task to feel free to comment without forgetting to secure every comment on that issue as it is the same as the issue's security level.

What we are asking is that you give the flexibility to your users/administrators and not force a process that Atlassian has onto your customers, allowing them to gain the most of your system. You seem short-sighted in terms of how your customers want to use the product - not just be development-focused, but enterprise-focused.

There are workflow rules that you can put in place to apply the same security level; however, give those you can change the security level (again, another type of permission) to change it.

The JIRA development team does not currently have any plans to implement this feature. For situations where you need different permission for subtasks than the parent issue, we recommend that instead you create issues of another type or in another project and link them.

Dave Meyer
Product Manager, JIRA Platform

bonsoir,
un petit Up sur ce post. J'ai le même besoin que karie kelly. le level de sécurité des Jira parent se fait selon l'appartenance d'un groupe interne.
le niveau de sécurité des subtasks sont elles pilotées lors de leur creation.

si on modifie le niveau de la jira parent "interne" à "rien", les subtasks se réinitialise à "rien". il nous faut absolument une option permettant de ne pas modifier le niveau des subtasks tout en modifiant le niveau de securité des jira parents.

merci pour vos développements.

(la solution de jason ne convient malheureusement pas).

There is a workaround to this issue - define a security group with two security levels - one based on internal project role to have access and another based on custom customer group field. When creating the parent issue - have issue security turned on (and don't allow change by customer role permission), and set custom customer group to be equal to the customer who should have access to parent issue (note - internal project role will automatically gain access). When creating the sub-task DO NOT include the customer group in the custom customer group field.

This will (if set-up correctly) allow internal users to see both parent and sub-tasks but the customer (external user) will only be able to see parent.

Our team just started using Jira for issue tracking. Our customers require and are allowed to see the issues but we don't want (cannot let) them to see all issue data. For us, subtasks would be the right and logical place to contain the 'hidden' work data. Without this feature (independent sub-task security) or another decent workaround, we loose a lot of productivity potential offered by Jira. Now we are restricted to use Jira only for managing customer tickets and not for supporting our team work.

Any progress on this?

I need this because I want to use issue-level security to expose epics and userstories to a client login (for the purposes of product backlog prioritisation), but I want to hide the sub-tasks that are associated with those userstories as they contain far too much sensitive data.

Exposing the Epics works fine, as they userstories are only linked to epics (the inheritance does not apply).

However as soon as I expose the userstories, all of the sub-tasks underneath those suddenly become exposed. This is not acceptable.

If we could simply have a (issue-level security scheme?) setting to disable this cascading of permissions that would solve my problem...

We are in definite need of this. Linking is not a workaround for us as it makes reporting nearly impossible; the only option with linking and reporting is the jql tricks plugin, but that consumes too many resources. It also opens up issues with user errors in not remembering to link.

It should work similar to Confluence; if I can get to the parent page, then I may or may not be able to get to that page's children when viewing the parent.

We need the parent opened to everyone and we need to control the security at the subtask level. Our use case - every employee has a profile as an issue. Subtasks relate to onboarding activiities, training, education, etc - some of which anyone can see and some that everyone cannot see.

This would still work with jql as you should still only be able to see the query results for which you have security.

This seems like a really straight forward request, assuming that JQL interprets an issue's security level when rendering. You could even make it an admin option to allow subtasks have the ability to edit security level. But, really, the admin has control of this why choosing to add the field to a subtask screen or not.

By making this improvement, you provide the flexibility to admins that need it vs imposing a requirement that eliminates some use cases and causes issues.

It would be nice if Atlassian could start to focus on addressing improvements that have been open for years vs working on the user interface, and providing some feature value - especially now that 6.0 is out.

sigh +1 vote

add this to the list of features i've looked for and found it is unresolved since early 2000

any progress on this?

This would be a huge win for our company. We definitely have the need to have 'private' sub-tasks for internal use, while having the parent open to the client or a larger audience.

We wanted to use the feature of "Hidden Sub-Tasks" to bundle attachments which should not be visible to all. This is to work around JRA-3893 (open since 2004). Seeing that this doesn't work, too (since 2005) is bad.

Autoreply at work not really relevant to this....

Hello.

At my company we're using JSS to set the issue security level at the creation of the issue. It works fine. However in sub-tasks details Security Level still says wrong (parent issue's) security level. So it's a bug in my very humble opinion.

For what it's worth here we have other scenario - parent issues are hidden from the people who have to resolve sub-tasks.

I don't understand how this change hasn't been made? I understand the point made in 2005 about not putting in the functionality, but you should give the option for the system administrator to choose what issue level security to give the subtask. We are trying to stand up a prototype here and the business need we have is that we need to limit what our external clients can see, which includes the subtasks.

We have voted also cause we have the same need. We're using jira enterprise 3.13.5.

We have the same issue.
Given its age, is this up for implementation, at some point?

This was requested over 5 years ago. IMO sub-tasks have very little value if some very basic create/delete permissions aren't accounted for.

At least this issue is currently in the top five voted issues. Keep the votes coming!

If this feature were ever implemented, I would want to see an ability to reset the security level of all sub-tasks at once from the parent issue. For those of us who like the current functionality (i.e. where sub-task security level mirrors the parent security level), I wouldn't want to see our implementations break or become less user-friendly.

Also Voted!
We want to set a default security level to sub-tasks, which is not related to the security level of the parent.

We also need this feature. My vote is in

I would need to have this feature implemented to be able to control customer access to sub-tasks. My vote is in!

Came here looking for sub-task permission control as well. My vote is in.

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.

My vote is in.
It is already an old request, any indication on an possible ATA??

I will welcome too, if this functionality works.

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.

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,
Nick

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

Unfortunately I appended by mistake a '_' character to the URL – this leads to a dead link

And because of JRA-1100, I'm not able to correct all posts with the wrong URL

Please review using the corrected link: http://forums.atlassian.com/thread.jspa?threadID=9146

Ahmad

This would indeed be very useful. We're working around it by avoiding subtasks at the moment but with JRA-5617 and JRA-5410 just around the corner we're thinking about this more and more.

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.

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,
Brian

Hello Brian,

thanks for the clarification.
To ensure the SW supplier could see the subtask now we downgraded the complete task to the supplier's security level.
This did not work though.
The subtask's security level is now shown as "internal" in the issue navigator column, but it is shown as "supplier" in the issue's detail page.
This is just the inconsistency in the appearance.
We asked the supplier if he can access the issue, and he could not.
Now we are retrying by removing the subtask and creating it again.
This seems to work, at least the inconsistency between navigation and detail view is made away.

So I have a problem now,
but I have found a solution to the problem of Mr Daimer!

Just declare the issue first "private", create the subtasks, which will be also "private", and then downgrade the issue to "public"
and then create all "public" subtasks.
Well this is not a seriuos solution, since it is relying on a bug and poses too many constraints on issue entry timing.

Regards 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 JRA-5112 is no longer valid.

Instead is it possible for you to create a linked issue that the external supplier can see?

Thanks,
Brian

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 JRA-5442, but for Jira 3.3.3 I could not find the named file.
Is there a workaround to be able to edit the subtask security level?

Cheers

Bettina Zucker

Please review this post

• _http://forums.atlassian.com/thread.jspa?threadID=9146_

and consider this issue as a part of a greater whole.

Ahmad

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:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

Thanks again for the feedback, it is very useful for us.

Anton

Anton wrote:

The main problem [....] displaying the progress bar for it.

Keep it simple: keep the progress bar, remove the list with sub-task and add the following messages

• "x of y sub-tasks still unresolved / not closed"
• "you need the have the appropriate security level to browse the list"

Anton wrote:

If the user cannot see the sub-tasks then it might be confusing why the issue cannot be resolved.

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

• JRA-7835 - Option to remove sub-tasks from roadmap / changelog
• JRA-8522 - Option to remove / hide sub-tasks from Release Notes

And it seems that there not too much code change to enable this feature - check JRA-5442 and check back with Mark..

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.

The main problem we had with being able to see the parent issue but not all of the sub-tasks is displaying the progress bar for it. It is also possible to configure workflow such that it is not possible to resolve an issue while ther are unresolved sub-tasks. If the user cannot see the sub-tasks then it might be confusing why the issue cannot be resolved.

I see your use case, however. Thanks for reporting this.