Sub-task does not correctly inherit the security level of a parent Edited

[Brett Cave]

We are busy adjusting our Jira instance to allow customers to use it to view their tickets (it is currently internal only). We have set up security levels - e.g. I have "internal" security level and a "customer X" security level defined in a security scheme.  In the "customer X" sec level,  acess is granted to "Customer X Group".  I then create a user and add them to the Customer X Group. I then create an issue, set the security level to "internal" and create a subtask.  *

If I assume the identity of a "Customer X" user and go to the dashboard, I immediately  see subtasks from "internal" sec level tasks. I am able to open them and view all details. However, if I click the parent task, I get an error saying access denied - so it seems the sec level is preventing me from accessing the task, but allowing access to the sub-task. How can I ensure that sub-tasks inherit the security of their parents?

* Note: The specific task and sub-task may have been created prior to setting up security levels / schemes.

[Brett Cave]

As I was asking, I realized that tasks and sub-tasks were created prior to implementing security levels and once they were introduced the sub-tasks did not inherit.

As such, I can manually enforce the inheritance by changing the sec level of parent to none and back to "internal". This propogates to children.

[Wen-Wen Lin]

We are new to security groups as well and figured out the trick above to get the right security group to propagate. This is clearly a defect that needs to be fixed. We're going to use tasks for now and manually link them as Child of/Parent of appropriately.