We have implemented a security scheme where admins and contributors can view all issues. For other groups, they will only see issues they're assigned. This is controlled by specifying the 2 groups and "Current Assignee." in the security scheme level. Looks like if someone is assigned to a subtask, they cannot view the details in the parent story. Is there a workaround to enable people assigned at the subtask level to view the parent stories? With our setup, people are only assigned at the subtask level.
Hi Nick,
If you want them to see parent data, they will have to be given access to the parent. Or you will need to copy down data from the parent to the sub-task.
Through the Add User/Group/Project Role to Issue Security Level interface, I don't see an option to natively give them access to the parent if they're assigned a subtask. Where would I do that?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You would have to either add them as the assignee on the Parent or create a custom field to add them to and add that custom field to the Security Level and to the parent.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I followed your suggestion with the custom field addition. I did the following:
1. Added a custom Group Picker field to the stories and epics.
2. Implemented an automation rule to automatically populate my custom field with the additional group I want to have visibility to the parent issues.
Then, I logged in as an outside resource and I still couldn't see the parent issue because of permissions. Any recommendations?
Ideally, there would be a custom field on the epics and stories, and the custom field would hold all people assigned to subtasks. Then, the security level will recognize all people in the subtasks and give them visibility to the epics and stories when applicable. By the looks of the options in the security configuration, this doesn't seem possible. Can you please confirm whether or not it would be possible on a per-user basis. Just because someone is assigned something in a group, it doesn't mean everyone in that group should have visibility.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Let me see if I have it correct.
1. You created the custom field and added it to the stories and epics and populated the existing stories and epics with a value for the new field.
2. You added the new custom field to the existing security level
3. The security level is present on the stories and epics and the custom field is filled in.
4. You logged in as a user that is in a group that is shown in custom field on the existing stories and epics.
Is all of that correct?
As to your last statement - I would not use a custom group field but a custom multi user picker field.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That is all correct. After I logged into Jira as the user in that group, I still wasn't able to view the story.
I also attempted it via user custom field, and the result is the same.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You might try going to the Permission Scheme and then using the Permission Helper. It will ask for specifics such as the permission (maybe use Edit Issue), the issue key, and the username.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The permission helper shows the user doesn't belong to any of the groups specified in the Project Roles of the Security Level, and it's ignoring the specified criteria of the "User custom field value". The custom field is visible on the story, and it's value is the user.
Can it not be user based with a custom multi-select user field?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was able to use a multi-select user field in the custom field:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.