It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How can I use an Adaptavist Behaviour to make a field required only on 1 screen?

I have been using Behaviours to make fields required on certain projects without altering the Field Configurations (which are used across many projects). It works great (create behaviour, map to particular project, and set field to required). However, I can't figure out how to do this for just one transition screen in a project. Is it possible to set a field to required for only for 1 screen in a project? I know that I can do this by adding a validator to the workflow, but I don't want to change the workflow either, as it too is used by many projects.

2 answers

Hi Morgan

You can use getFieldScreen(), in your behaviour, in order to determine in which screen you are

Hey Thanos - thanks. I just realised you may have given me this answer before! The problem is I don't know how to use 'getFieldScreen()' to do this. If it's a simple thing, could you tell me what code I can enter in? 

For example, if I have created a behaviour, as described above, that makes a field required for a particular project, is it just a case of clicking 'Add Serverside Script' in that behaviour and typing in 'getFieldScreen(NAMEofSCREEN) and that's it? 

Sorry for not being very code-savvy.





Hey Morgan 

So, you can associate screen with issue operations, then the getFieldScreen(), no params, will return to you the name of the screen, let's say Bug Screen, and after from the moment that you get the name of the screen you can add some logic to it (string comparisons). A 'lazy' way is to add some debugging 

log.debug("Name of the screen " + getFieldScreen())

and check the names of the the screen you are into.

Hope that helps.

Hi Thanos, 

I appreciate your help but I think you have over-estimated my coding skills. I'm not a coder - I administer Project Management tools here at Demonware. I understand associating screens with issue operations as that is part of JIRA's functionality. 

As to adding logic and string comparisons, I'm afraid I don't know about that. It would be extremely useful for me to have some code that I can add to behaviours (by clicking 'Add server-side script' I guess?) which would limit the behaviour to a named screen. 

Essentially what I was hoping for was some code which I can paste into 'Add Server-side script'

which effectively say 'Only apply this behaviour to screen X'.

To my mind the actual behaviour itself then wouldn't require any scripting as I can do that by adding the field and setting it to 'required' and mapping it to a project (as I've been doing until now).

Or does adding a script over-ride all of that?

I'm also not sure if what you've mentioned above should be entered in as a script, or into the 'Class or File:' and 'Method' fields. Nor do I know what I would enter into the 'Class or File:' field if that were the case.

As you can see, I don't know much.





Plan B, if you want to use a server side validation or the screen you use is not unique, as you already presumed, is to associate a validator for the specific transition or use SR simple scripted validator

Hi again!

I am familiar with validators - unfortunately I can't make changes to the workflow for this project as the workflow is shared with other projects where the field I want to make mandatory should not be mandatory.

As Thanos said...

if ( == "Resolve Issue) {
  ... // do whatever behaviour you want

Thanks Jamie. It seems that I may have to go and learn Groovy, specifically for using with Scriptrunner and JIRA. Do you have any recommendation as to where a beginner with little coding experience should start? 

Hi... in my experience, just pick a task and go for it. But previously there have been several questions about which resources to use, eg and the SR docs.

If you use a scripted validator, you can include the project you want to validate as part of the condition; that way other projects can use the same workflow without the field requirement impacting them.

Something very basic such as:

issue.getProjectObject().getKey() != "MYPROJECT" || cfValues['Some Custom Field'] != null

Thank you Jeremy - this was just the sort of thing I was hoping for. Unfortunately, when I tried putting this code in as 'Custom Script Validator' (with the project key in place of "MYPROJECT" and the custom field name in place of "Some Custom Field") I get the error:


The variable 'cfValues' is undeclared.

Any idea why that would be?

Not offhand, I copied that part straight out of the examples for simple scripted validators.  However, I don't use those much; here is a 'regular' scripted validator that should work:

import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.ComponentManager;
import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.project.version.Version;
import com.opensymphony.workflow.InvalidInputException;

ComponentManager componentManager = ComponentManager.getInstance();
CustomFieldManager customFieldManager = componentManager.getCustomFieldManager();

if(issue.getProjectObject().getKey() == "MYPROJECT") {
    CustomField mcf = customFieldManager.getCustomFieldObjectByName("My Custom Field");

    Version mcfv = issue.getCustomFieldValue(mcf);
    Boolean hasCF = (mcfv != null);

    if (!hasCF) {
        invalidInputException = new InvalidInputException("\"My Custom Field\" is required for this transition.");

Thanks again Jeremy - this gives me:

...the variable 'componentManager' is undeclared


...cannot find matching method com.atlassian.jira.issue.fields.Customfield#isEmpty(). Please check if the declared type is right and if the method exists.

I realise this isn't a forum for debugging code. Just thought I'd say what I got for anyone else viewing this.






My bad, I removed ComponentManager from my sample without paying close attention to what it was used for.  I've edited the previous comment to fix that.

Well that took care of the first error, but still getting:

...cannot find matching method com.atlassian.jira.issue.fields.Customfield#isEmpty(). Please check if the declared type is right and if the method exists.


Sigh. Sorry, I went too fast there and forgot to fetch the custom field value from the issue when I made the code generic.  What type of custom field is it, a basic string?

Hey - it's a 'Version Picker (single version)' type field in this case. The name of the custom field is 'Version Introduced'.

Okay, try that; I'e only ever worked with the multi-version type that returns a list, but hopefully this one will return a single Version, or "null" if not set.

Well, now for the line  - Version mcfv = issue.getCustomFieldValue(mcf);   

I'm getting:

Cannot assign value of type java.lang.object to variable of type com.atalassian.jira.project.version.Version

Sorry! And thank you for your help!



Try changing "Version mcfv = ..." to "def mcfv = ...".

Just out of curiousity, how are you debugging this?  Are the exceptions showing up in logs and you are mapping them back to the source lines?

That gives me a similar error. I'm just looking at the errors that show up in the custom script validator entry field. See (this site won't let me attach images for some reason).


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

967 views 7 0
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you