Custom Field | Description | Modification | Configuration | View example |
|---|---|---|---|---|
Assignee Chain
| The chain of previous users who were assigned to an issue |
Note: field represent user/chain without including current assignee. Limitation for the Text view: no more then 8 users can be displayed |  |  |
Child Statistics
| Collect statistics of child issues/tasks inside their parent. |
|  |  |
Modified By Chain
| The chain of users who made last updates to an issue |
Limitation for the Text view: no more then 8 users can be displayed |  |  |
Parent Field Mirror
| Mirroring value in a Sub-Task from the custom field in a parent issue. Field available only for the subtask issue type. | Don’t have default value, should be defined in the configuration. Note: next types supported and will be presented as string: group, user, option, date, datetime, string, number Other field type will be converted to String JSON. |  |  |
Parent Status
| Mirroring value of a issue status in a Sub-Task. Field available only for the subtask issue type. | Don’t have modification, just represent parent status as string. |  | |
Time in Statuses
| Amount of time that an issue has been in previous statuses |
Note: less then 1 day = 0 e.g: 47 hours → 1 days, 48 hours → 2 days, 30 minutes → 0 hours, 65 minutes → 1 hour. |  |  |
User Notification
LIMITATION: NO MORE THAN 20 FIELDS | Notify selected users about issue status. Please note: if you create more than 20 fields with the type: User Notification, we can’t guarantee the stability according to Jira limitation. We recommend that you do not go beyond this limit. Notification will be send within one hour after ‘time in status’ will be exceeded, next message will be send starting from this time + interval time. e.g: You have changed issue status to 'In review' at 13.00, and your configuration: interval: 2 hours, time in status 1 hours, status 'in review'. Notification will be send beetween 14.00-15.00. (e.g: at 14.37 and the next will be send at 16.37, 18.37 and so on) |
Required fields should be configured: Notification subject, notification body, ticket status, how long issue should be in status before notification will be send (in hours), interval how often notification will be send until status change. (in hours from every 1 to every 24 hours) Limitation for the Text view: no more then 8 users can be displayed |  |   |
By default, forge-based custom fields compute the value of the field on every issue view request, so that the freshly computed value is shown to the users whenever they open the issue page. Jira also saves this value into the database against the issue. Thanks to this, the value is not only available for that one particular user interaction but also becomes immediately refreshed for the REST API, all other views, JQL search, etc. Because the value function is invoked only on the issue view for the viewed issues any asynchronous changes will not update the field value until the view will not be open again. For that reason, we provide an additional configuration page per project, where you might define which fields should be updated asynchronous.
Go to: Projects → Fabulous custom fields project configuration
Select specific custom fields that should be asynchronously updated per project and click Submit
Example of usage: You have configured Parent Status field and you are viewing a sub-task in the issues search screen. Someone changing the status of its parent. In case of Parent Status is not configured for the asynchronous update, and you will update the issue search screen, Parent Status field will not correspond to the real issue parent status as you did not have direct interaction with the sub-task view. In case of Parent Status is configured for the asynchronous update data also will be updated for the issues search screen without additional interaction directly with the sub-task issue view. Please NOTE: it may take some time before the value will be updated.
\uD83D\uDCCB Need additional functionality or any issues
Find a way to contact us in the Contact and Support section
0 Comments