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...

I totally agree with this! We had a support process where customers could see issues reported by eachother - to reduce the number of duplicates, and to be open with that product status. BUT there was certain information that was specific for the customer and often this was sensitive information. Using sub-tasks would have been a great solution...

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.