nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Restrict the view of subtasks

Saida

Hi,

I need to configure the Issue level security the following way:

1) Issue A (sub task) can see dev-group1

2) Issue B (sub task) can see dev-group2

3) Issue AB (parent) can see dev-group1 and dev-group2 (not required, if this prevents 1 and 2)

As subtasks' security is inherited from the parent issue, I added the group custom field <Developers>, and filled it with dev-group1 for issue A, dev-group2 for issue B and [dev-group1, dev-group2] for AB.

But with this configuration developer from group1 can see all of these 3 issues.

Then, I cleared the field for AB issue. After that, developer from group1 cannot see the parent issue, but still see other subtasks of this parent issue on Kanban board.

How can this be configured on JIRA Software / Core 7.7.0?

Accepted answers

Saida

OK, seems that I found the solution.

As my sub-tasks are created from the script post-function, and updating security post-function is ignored, I added

mutableIssue.setSecurityLevelId(levelId);

into my script to set it while creation. With this line it works as expected.

All comments

Gezim Shehu [Communardo]

Hi,

The approach to this imo, is to run a check on issue create transition and check for a certain criteria, then set the appropriate issue security level based on it.

This could either by done by using 2 separate issue types/workflows, or by incorporating into 1 workflow and base the criteria on some field value.

Now both times you would need some kind of post function to set the issue security level.

You could use any scripting add-on and hard code it yourself, or you could try using Adaptivist ScriptRunner for JIRA (this is what I use in a similar situation to yours).

ScriptRunner has a built-in workflow post function to set the issue security level and optionally execute it only if a given condition is matched.

Having said this, your set-up steps would be:

1-Create 2 JIRA Groups devgroup1 and devgroup2

2-Create 2 Issue Security levels, available only to each group respectively

3-Create a Single Group Picker Custom Field "Dev-Group-Assigned" (and add that in the subtask screen configuration)

4-On subtask's workflow, during Create Transition, add the "Set Issue Security Level" post function, but add it twice. Make sure these are on top of other post functions.

The reason of adding it twice, is to loop through both conditions. It doesn't give you an option to set the value based on the Custom Field's value (you could write a custom script for this if you want to have just 1 post function instead of 2).

Here is the workflow transition look

create transition.PNG

And this is the post function configuration

post function.PNG Best Regards

Kapital

Hi, @Gezim Shehu [Communardo]!

Does this function work for you with Sub-tasks?

Because I tried to use the same one and another post-function to set level, and no reaction on this.

Moreover, I tested the update of the sub-task via @ScriptRunner script console this way:

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.security.IssueSecurityLevelManager;
import com.atlassian.jira.issue.security.IssueSecuritySchemeManager;
import com.atlassian.jira.event.type.EventDispatchOption;
import org.apache.log4j.Logger;

def log = Logger.getLogger("com.onresolve.jira.groovy");
def issue = ComponentAccessor.getIssueManager().getIssueObject("TEMPDEV-51");

def issueSecuritySchemeManager = ComponentAccessor.getComponent(IssueSecuritySchemeManager);
def issueSecurityLevelManager = ComponentAccessor.getComponent(IssueSecurityLevelManager);

def schemeFromName = issueSecuritySchemeManager.getSchemeObjects().find { it.name == "DEV: Issue Security Scheme" };
def schemeFromProject = issueSecuritySchemeManager.getSchemeFor(ComponentAccessor.projectManager.getProjectByCurrentKey("TEMPDEV"));
def user = ComponentAccessor.getUserManager().getUserByName("jiraadmin");

def securityLvl = issueSecurityLevelManager.getIssueSecurityLevels(schemeFromName.id).find { it ->
 it.name == "Sub-task"
}?.id;

if (securityLvl)
{
 log.debug "Security level found : " + securityLvl; 
 issue.setSecurityLevelId(securityLvl);
 ComponentAccessor.getIssueManager().updateIssue(user, issue, EventDispatchOption.DO_NOT_DISPATCH, false);
}

It returns <DEBUG [jira.groovy]: Security level found : 10302> but SL is not updated.

Saida

Sorry, accidentally posted from the corporate account.

I implemented it in a slightly different way that you suggest, but I tested both of them. It doesnt work.

Here it is my configuration:

- New Group custom field value Developers

- Added this field to the Security level of parent issue:

Now for testing I have 1 parent issue and 2 sub-tasks.

For one of sub-tasks (#1) this field contains value Group1, for the other one (#2) the value is Group2.

The field in Parent issue is empty.

My expectations: developer from group1 can see only subtask #1. Not the parent issue and #2 subtask.

The result: this developer see subtasks #1 and #2 and doesnt see the parent one.

Saida

OK, seems that I found the solution.

As my sub-tasks are created from the script post-function, and updating security post-function is ignored, I added

mutableIssue.setSecurityLevelId(levelId);

into my script to set it while creation. With this line it works as expected.

Gezim Shehu [Communardo]

(Y)

Gezim Shehu [Communardo]

Try defining the Default Security Level visible to Any User or something like a Project Role Viewer.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software

jira-core

sub-task

security