Listeners script to block the project admin roles to block the creation of new versions

[Ramesh Penuballi]

Dear Team,

As a part of process improvement, we are planning to instruct all the project team to use the pre-defined  releases versions(fixversions,affect versions) in a specified format.To achieve this we are trying to block the project admin roles users to block the creation of new versions(fixversions,affect versions) while creating an issue in a project and updating any existing issue.

Written the the below script and placed in listeners but always allowing the user who is in project admin roles of a project  is able to create the new releases.

Below is the script and please help me  if there is any logic error in the below script.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.security.roles.ProjectRoleManager
import com.atlassian.jira.event.type.EventDispatchOption

def log = log // Use the log object provided by ScriptRunner
def issue = event.issue as MutableIssue
def user = event.user
def project = issue.getProjectObject()
def projectRoleManager = ComponentAccessor.getComponent(ProjectRoleManager)

// Check if the user is in the project admin role for this project
def projectAdminRole = projectRoleManager.getProjectRole("Administrators")
def isUserInProjectAdminRole = projectAdminRole && projectRoleManager.isUserInProjectRole(user, projectAdminRole, project)

if (isUserInProjectAdminRole) {
log.warn("Blocking field updates for project admins.")

// Block updates to fixversions field, including adding new versions
def currentFixVersions = issue.getFixVersions()
issue.setFixVersions(currentFixVersions)
log.warn("fixversions field has been blocked from update for project admins. Current fix versions: ${currentFixVersions}")

// Block updates to affected versions field, including adding new versions
def currentAffectedVersions = issue.getAffectedVersions()
issue.setAffectedVersions(currentAffectedVersions)
log.warn("affected versions field has been blocked from update for project admins. Current affected versions: ${currentAffectedVersions}")

// Save the issue without triggering another update event
ComponentAccessor.getIssueManager().updateIssue(
user, issue, EventDispatchOption.DO_NOT_DISPATCH, false
)
} else {
log.info("Allowing field updates for non-project admins.")
}

Thanks and Regards,

Ramesh 

[Nic Brough -Adaptavist-]

Why don't you just archive the versions they are not supposed to be selecting?

[Ramesh Penuballi]

Hi Nic,

Thanks for the reply and our requirement is to add the  versions  in the specified format (yyyy_mm_date_weekoftheyear) and allowing the users to select the versions from the availability versions.As per the permissions scheme the non project admin users are able to select the versions from the availability list but we are unable to block the project admins to create the newer versions while creating or updating any issue.Admin users are getting the below message and able to create the newer versions.

We tried to achieve this via groovy script to place it in the listeners in both create and update events, but the above script is allowing to create new versions for the project admins.

Could you please help us to block the project admins to create new versions of versions while creating and updating any issue.

Thanks and Regards,

Ramesh Penuballi

[Ramesh Penuballi]

Can anyone help me here to resolve the issue.

Thanks,

Ramesh

[Nic Brough -Adaptavist-]

Oh, I see, you're wanting to stop your project admins doing their job.  Your code is looking at issues, not the version, so it's not looking at the right place.

By far the best route is simple education - explain to them that they are required to use the format you want when they create versions.

This is not a good thing to do.  Versions are free-format text so that the team can create the versions that work best for them.  Inflicting a scheme on them is unproductive and slows them down, so I would not recommend it.  

Also, versions already have dates on them, you don't need to repeat it in the name, especially if you're doing anything like Scrum, because the date is likely to change.

And, of course, versions are different in different projects, so if you are doing this in more than one project, you're effectively breaking all your search and reporting - people won't know which project they are looking at when they search one of several versions with the same name.

Your listener approach is also going to be very clunky, wasting more of your user's time.

So all the reasons that this is a bad thing to do (the opposite of "best practice"), the technical answer is:

You can write a listener that can catch "version created", scan the name, check if it looks valid, and if not, do something about it.

You have two basic options in there:

• Correct the input - this will confuse or annoy your users because the version won't be named correctly as they entered it, and you will need to come up with some rule for how to correct the name.
• Delete the version immediately - this will confuse and annoy your users because data they are entering is being destroyed without warning.

Which of those would you prefer?

[Ramesh Penuballi]

Hi Nic,

Thanks for the update and we are planning to go with the below option.

• Correct the input - this will confuse or annoy your users because the version won't be named correctly as they entered it, and you will need to come up with some rule for how to correct the name.

Also we explored the "except" option in behaviour but it is still allowing the other people to create the versions after adding my name  as a current user.

Kindly suggest me how can proceed further.

Thanks,

Ramesh Penuballi

[Ramesh Penuballi]

Hi Nic,

Could you please helps us to get the way to proceed further.

Thanks,

Ramesh

[Nic Brough -Adaptavist-]

You have created a condition on it that says "don't do this for project administrators".  Project administrators are the people who maintain the versions!