Restrict the view of subtasks

Saida February 28, 2018

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?

2 answers

1 accepted

2 votes
Answer accepted
Saida March 1, 2018

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]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 1, 2018

(Y)

Like david@720.io likes this
0 votes
Gezim Shehu [Communardo]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 1, 2018

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

Kapital March 1, 2018

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 March 1, 2018

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:

 1.png

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. 

Gezim Shehu [Communardo]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 1, 2018

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

Suggest an answer

Log in or Sign up to answer