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

Question

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?

Tim Pettersen · Answer

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

Anurag Bharati · Answer

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:

* 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.
* 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 · Answer

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