JWT ships with three custom field types to calculate field values, display live data, or even pull data from online service providers such as Google.
Each custom field type, from number to text, or date-time fields, comes with a different set of options that let you define exactly what you want to see as a result using the full power of the JWT expression editor.
Last but not least, you can individually define how the result of the calculation should appear, from different time formats to currency symbols, by configuring individual Display formats.
This type of read-only custom field contains a value which is dynamically calculated from a custom math/time expression. It can be used to obtain a date-time value depending on the value of the current issue or in other issues.
This type of read-only custom field has a value which is dynamically calculated from a custom math/numeric expression. It can be used to obtain a numeric value depending on the value of other fields in the current issue or in any other issues.
This type of read-only custom field has a value which is dynamically calculated from a custom text expression. It can be used to show a text composed from one or more field values returned by field codes.
After installing JWT, head over to Administration → Issues
Then browse to Custom fields
Create your first custom field
from the Custom fields admin section, head over to Add custom Field → Advanced then add the desired field offered by JWT:
JWT calculated fields can't be manually updated on any screen.
Therefore they won't be displayed on create, edit and transition screens, even if you added them explicitly to those screens.
Configure your custom field
On the configuration screen of your newly created custom field go to Actions → Configure
Start by adding an expression that is used to calculate the field.
A non-optimized expression can cause performant problems when re-indexing, to avoid this kind of problems there are some tips to keep in mind:
- When using field codes in the expression, if their value is null it can add some delay to the re-indexing because of the errors thrown. To avoid this it's recommendable to check with a ternary operator if the field code's value is null or not to make the calculation or not.
- When the value depends on fields belonging to issues different from current issue, for example its linked issues or issues returned by a JQL query, problems will be faced when using it in a JQL search. This happens because its index is only updated when the current issue is updated, so the value indexed might not be updated if those different issues have not been updated, even if the value is displayed correctly. It would be necessary to re-index before executing the JQL search.
Optionally: Customize the display format.
Configure the field context
Check out the result
To learn more about configuring the display formats, check out the following page.
Been there, done that? If you need even more inspiration, make sure to check out these useful use cases that will definitely get you started.