...
Custom Field
...
Description
...
Modification
...
Configuration
...
View example
...
FIELD TYPE: LIST OF USER
...
The chain of previous users who were assigned to an issue
...
Display results as UserGroup (default) or as a Text
Display chain of users (default) or last only last
Note: field represent user/chain without including current assignee.
Limitation for the Text view: no more then 8 users can be displayed
...
FIELD TYPE: STRING
...
Collect statistics of child issues/tasks inside their parent.
Field avaialble in the EPIC (for linked issues) or Issue (for subtask) calculation.
...
Sum of Story Points of sub items in all (default) or specific status based on number field type (Story Points by default) displayed as number (default) or in percentage.
...
Count of unsized sub items in all (default) or specific status displayed as number (default) or in percentage.
...
FIELD TYPE: LIST OF USER
...
The chain of users who made last updates to an issue
...
Display results as UserGroup (default) or as a Text
Display chain of users (default) or last only last
Ignore some users who made modifications but should not be displayed in the field (empty by default)
Limitation for the Text view: no more then 8 users can be displayed
...
FIELD TYPE: STRING
...
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.
...
FIELD TYPE: STRING
...
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.
...
...
FIELD TYPE: LIST OF STRING
...
Amount of time that an issue has been in previous statuses
...
Display only last ‘time in’ status (default all time in statuses)
Hide ‘time in’ for current status (default show)
Display value in hours or days (default)
Note: less then 1 day = 0
e.g: 47 hours → 1 days, 48 hours → 2 days, 30 minutes → 0 hours, 65 minutes → 1 hour.
...
FIELD TYPE: LIST OF USER
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)
...
Display results as UserGroup (default) or as a Text
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.
...
Once the configuration is ready the next Fabulous Surveys functionality is available for the user:
Issue Preview Surveys
Force Send Survey
Issue Survey Answers
Surveys Responses
Issue Preview Surveys
| Anchor | ||||
|---|---|---|---|---|
|
Force Send Survey
| Anchor | ||||
|---|---|---|---|---|
|
Issue Survey Answers
| Anchor | ||||
|---|---|---|---|---|
|
Surveys Responses
| Anchor | ||||
|---|---|---|---|---|
|
Find a way to contact us in the Contact and Support section
...