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

[Morgan Thunder]

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.

[Thanos Batagiannis [Adaptavist]]

Hi Morgan

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

[Morgan Thunder]

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.

Cheers,

Morgan

[Thanos Batagiannis [Adaptavist]]

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.

[Morgan Thunder]

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.

Morgan

[Thanos Batagiannis [Adaptavist]]

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

[Morgan Thunder]

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.

[JamieA]

As Thanos said...

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

[Morgan Thunder]

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? 

[JamieA]

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 http://www.groovy-lang.org/ and the SR docs.

[Jeremy Gaudet]

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.

[Jeremy Gaudet]

Something very basic such as:

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

[Morgan Thunder]

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?

[Jeremy Gaudet]

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.");
    }
}

[Morgan Thunder]

Thanks again Jeremy - this gives me:

...the variable 'componentManager' is undeclared

and

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

Cheers,

Morgan

[Jeremy Gaudet]

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.

[Morgan Thunder]

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.

[Jeremy Gaudet]

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?

[Morgan Thunder]

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

[Jeremy Gaudet]

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.

[Morgan Thunder]

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!

[Jeremy Gaudet]

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?

[Morgan Thunder]

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