In Jira cloud how to validate a custom field value at runtime ?

[Anurag Bharati]

In Jira cloud how can I validate a custom field value at runtime and stop user from giving incorrect value? I know about workflow validations but I cant wait till next state transition and want to stop user if he set incorrect value. Also what if user input incorrect values in the final state of workflow, I think it will be bad idea to add another state just to validate?

[Shawn Doyle - ReleaseTEAM]

Hi @Anurag Bharati 

My first approach would be to ask why this is a free form text field and not a select list.

If you can not change the field type, you could use Automation.  When the work item is modified check the field values against your correct values and update if needed.  This will require you to implement the logic, based on the level of complexity you intend to achieve.

Otherwise put guardrails around when this field is first filled in, add validators where it makes sense in the workflow and possibly remove the field from screens where you do not want the user to modify them.

There are a number of addons that can help with limiting the content of a text field, script runner comes to mind (one of the only addons I will name directly).

Lastly, have you tried talking with the users and finding out why they don't fill in the field correctly? Is this more of a training issue? When tools are shackled with safeguards for every bizarre edge case, they stop being sharp instruments and start being blunt headaches.

[Anurag Bharati]

Hi @Shawn Doyle - ReleaseTEAM

Thank you, for replying!

To answer your question about why this is a free form text field and not a select list?
Because "Select List(single/multiple choices)" is also not much helpful. Since users work in very dynamic environment even though the listed values are valid but are not always good based on different conditions. These conditions are derived from business processes.
Example: List of allowed values for a custom field is -> Option-1, Option-2,...,Option-N. Now its fine for any selection while the work item is in new state, but in the following states I want the user selection to be validated and only good values should be saved. Lets say Option-1 is good but Option-2 is not good. Now how should I inform user that his selection of option is not good. And worst part is what if after the transition validation, again user selects a value which is not good, how should I support my users not making errors?
I feel the problem is absence of validations on update, scriptrunner is also not much helpful here and what surprises me most is that validation can be put on custom fields created via forge application but not on the custom fields that we create from the Jira cloud web settings!

We can not use forge app based custom fields because they will go away if application is removed!

[Tim Pettersen]

Hi @Anurag Bharati

For the custom validation logic you're describing I'd typically recommend building a Forge custom field (or Forge custom field type if you need to adapt the behaviour for different field schemes). The Forge platform has features for validation and providing feedback to the user. It does require some JavaScript knowledge, but customers often build their own Forge custom fields to achieve this sort of use-case.

Could you expand a bit on your concerns around using Forge to build a custom field to solve for this problem? Presumably you would not uninstall the app while the field is in use.

cheers,

Tim

[Anurag Bharati]

Hi @Tim Pettersen  

Thank you, for your message!

Apart from uninstalling the app, there aren’t many reasons to dislike it, but here are a few concerns I have:

1. Custom fields created using a Forge app cannot be edited from the field settings (Settings > Work items > Fields). To make changes, we need to update the app and redeploy it, which is inconvenient.
2. There appears to be a memory limitation - Forge apps cannot be allocated more than 1024 MB (memoryMB). I'm not entirely sure, but what happen to the custom-field data if the app tries to use more memory than this? Will the data be safe?

[Tim Pettersen]

Hi again @Anurag Bharati

Custom fields created using a Forge app cannot be edited from the field settings (Settings > Work items > Fields). To make changes, we need to update the app and redeploy it, which is inconvenient.

If you need to allow administrators to customise the field behaviour, iIt might be worth having a look into creating a Forge Custom Field Type. These allow administrators to create new custom fields based on that type, but with individual configurations. 

There appears to be a memory limitation - Forge apps cannot be allocated more than 1024 MB (memoryMB). I'm not entirely sure, but what happen to the custom-field data if the app tries to use more memory than this? Will the data be safe?

Forge custom field data is stored in the Jira database alongside other custom field data. Just like regular custom fields, there is a limit of 32KB of data that can be stored in an individual field.

The memory limit you're referring to is the amount of RAM available to the Forge function that implements any backend logic used to render or update your function. As an aside: many Forge custom fields don't require a backend function at all, with the logic being implemented purely client-side (usually in UI Kit).

Each function only processes a single custom field render or update operation at a time, so this memory limit is not shared across invocations, and it is very unlikely that you will exceed it unless your custom field needs to load large amounts of data into memory for some reason. In the unlikely event that you exceed the memory allocated to your Forge function while attempting to update a custom field value the operation will fail, but your custom field data will still be safe (it will stay the same value that is was prior to attempting the update). 

Hope this helps!

cheers,

Tim