Locking Issues

1. Blitz-Actions

Problem

Once in a while it happens that we want to lock an issue, where by lock I mean that only the assignee of that issue can play with it. There's an open ticket about this with Atlassian, and Power Actions™ helps resolve it.

This example shows you how to do that by using Blitz Actions Power Actions™ and the Issue Security Scheme.

...

Now you're probably wondering "Why do i need Blitz Actions Power Actions™ to do this? Why can't the user set the security level himself?". Well, there are a number of reasons for this; what if we don't want the assignee to have the "Set Issue Security Level" permission? Or what if we don't want them to be able to edit the issue at all, but only log work or comment on it? Even if they do have the "Set Issue Security Level", not having "Edit issue" permission will prevent them from locking the issue.

...

Now let's get working. First off, we must create the security level, which looks like this:

Image RemovedImage Added

Create the actions

Once we've done that, it's time to create the actions. We will create two actions Lock and Unlock.

Image RemovedImage Added

For the conditions, we will disable the Lock button if the security level is already Locked, and disable the Unlock button if the security level is empty. Of course, we will only show the buttons to the current assignee.

...

number ENABLED = 1;
number DISABLED = 2;
number HIDDEN = 3;

if( assignee != currentUser()) {
 return HIDDEN;
}

if(isNull(securityLevel)) {
 	return DISABLED;
}
return ENABLED;

Now that we have the conditions, it's time to do the actual scripts. For the Lock button we will set the issue security to Locked and for the Unlock button we will set it to none.

...

That's it! Now let's test it.

Image RemovedImage Added

Image RemovedImage Added

See also

• Disabling inline edits in Jira
• Forbidding users to create some issue types
• Hide fields from users not in a project role
• Limit Number of Characters in Text Field
• Lock an issue - a better variant (Live Fields)
• Making an issue read-only
• Require an issue to have attachments
• Require User to Log Work Before Transitioning Issue
• Restrict issue type availability by user
• Restrict workflow based on status of dependencies
• Validator for component lead