Hiding Screen on Subtask Creation

[Keir_Lumsden]

Hello everybody.

I'm using the new JIRA issue view and adding a subtask.

When I click the + sign to create a subtask and fill in the Title field and click the create CTA (as below)

Then the next step is for it to pop up a screen.

How can I prevent this screen from appearing?

The Team field is a mandatory field, but it gets automatically filled from the parent in the workflow (along with Theme and Labels) so I don't need the screen at this point.

I can't find the configuration that would prevent this from appearing.

[Birgit Strompen]

Keine Ahnung, ob das jetzt noch jemanden interessiert, aber meine Lösung ist die, dass ich für Subtasks das Team-Feld als nicht "required" gekennzeichnet habe (field configuration) und dann im workflow in die post-function das Team vom parent übernommen habe.

[Tom]

Hi @Birgit Strompen , how did you manage to make the field mandatory for standard issues but not for sub-tasks? From what I can see, there's only a single toggle to mark it as required or not. Or did you duplicate the field?

[Earl McCutcheon]

Hello Keir,

Looking at the screenshot you added it is showing the "Team" field is set to required but has a value of "None", meaning a NULL value.  As there is not a value set the create screen will pop up to prompt for input on the value.

On Jira cloud a required field is set on the create screen in the workflow via a workflow validator on the create issue transition.  However depending on where the field is coming from you have a few options and Im not sure if the Team field is being set on your instance as a custom field created by you or added as a special field by an add-on.  EXE on special field types would be Tempo time sheets which creates a team field, and Jira Portfolio also create a Team field,  In tempo I do believe a default value can be set for the custom field it creates but portfolio is a Locked field that cannot be edited and the value is inherited from the parent issue on subtask issue types.

So if this is a custom field you created or one by an add-on app that can be edited in the field configuration you can add in a default value for the field that is not a value of "NONE", but for a locked fields like the one created by portfolio you would need to remove the required validator from the workflow to not trigger the requirement.

An alternate approach if you did need the team field to be required on one issue type but not the subtask you could create a workflow specific to the subtask issur type without the team field validator present, Check out "Configuring workflow schemes" for more details on this approach.

Regards,
Earl

[Keir_Lumsden]

Hi Earl,

Thanks for your response. For clarity, the Team field is a custom field we have created. It is key for organising items between the teams in our organisation, hence why we need it filled in for all Epics, Stories and sub tasks.

What I was looking to do is fill the fields in for sub-tasks from their parent (which the JIRA workflow is doing).

When creating the subtask, the screen pops up, you can fill the fields in, but they are ignored and overwritten anyway as the workflow is set up to inherit the fields from the parent.

Given this is the case, do I need to configure the team field as not required and deal with the validation in the create step of the workflows rather than using the field setting?

The workflow create step is show below. I've tried moving the Team population step earlier to no avail.

[Earl McCutcheon]

Hi Keir,

Since the field is being set via the post function and required this is where the conflict is occuring.  Basically the field on create has no value initially as the issue is being created it runs the validators first then the post functions.  The validator triggers the popup to get a value entered, then after the validator confirms the requirement the post function is run as the last step in issue creation so regardless of the value entered in the field manually the post function is setting the value to the defined value.

So Yes, as you noted the best approach here is to not have the field set to required on the validator as the post function is setting the value from the parent issue on the follow up action.

Regards,
Earl