nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

MorganT

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.

Accepted answers

All comments

Thanos Batagiannis _Adaptavist_

Hi Morgan

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

MorganT

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.

MorganT

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.

sad

Morgan

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

MorganT

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

addon-com.onresolve.jira.groovy.groovyrunner

jira-administration

jira-core