This section of behavior settings deals with the Workflow settings. The available settings are:
| Workflow menu- Workflow Settings | Typical Value | Description |
| ADMIN_OVERRIDE_ROLE | ADMIN |
Name of the user role that bypasses several security controls, and has special properties. Users who have this set as their current role have the following properties:
|
| ALLOW_BILEVEL_GROUPS | NO | This setting is provided for backwards compatibility. From version 5.0 onwards, bi-level relationship groups have been superseded by many-to-many and one-to-many relationship groups. Only set this to YES if your system was created prior to version 5.0 and you previously used bi-level relationship groups. With a value of NO, you cannot select bi-level as a value for a new relationship group. |
| ATTACHMENT_CONTROL_FIELDS | NO | This setting is only used in conjunction with the Java user custom exit named ucAllowAttachmentOperation. This setting enables the functionality within this method. When the value is NO the user custom exit is not called. When the value is YES the code within the method is called and acted upon |
| ATTACH_SELECT_CHECKBOX | UNCHECKED | This setting controls behavior of the Attachment Select box (ATTACH_SELECT) on the Add and Edit layouts. Valid values are UNCHECKED, CHECKED and CHECKED ON ADD. A value of CHECKED or UNCHECKED will set the checkbox for an attachment on entry to the screen or when a new attachment is added. A value of CHECKED ON ADD will cause the checkbox to be checked only when the attachment is first added, otherwise it will be unchecked |
| AUTO_POPULATE_ALLOWED_VALUES | YES | When this setting is YES, then in a popup from an add or edit screen that adds a new value to a list, and that list is the child within an allowed value relationship, then the new value will be added to the list and will be automatically added to the currently selected parent(s). If the value is NO, then the user will be prompted to select the Business Area, Project and the specific parent values to which the newly created child value will be added within the allowed value relationship. |
| AV_INTERSECT_WITH_NULL_PARENT | NO | When there are multiple allowed values defined with the same child field, and one of the parents does not have any children defined when the selected value is *None*, the default behavior is to show no values in the child field, as there are no valid values for *all* parent field selected values, and the default value for this setting is NO. However, older installations may have configurations where they expect that if one of the parent selected values is *None* that this parent field is not included in the determination of which child values to display, and the child field should display the intersection of the permitted child values for the other parent(s) field(s). In this case, set this behavior setting to YES. |
| AV_NULL_PARENT_IS_NONE | YES | If the value of this setting is NO and no parent value is selected in an allowed value relationship, then child fields will be populated with all the possible child values. If the value of this setting is YES, then the values displayed in the child field will be those defined for the parent value of * None *. If the allowed value relationship utilizes reverse lookup, this setting is ignored. |
| CLONE_RELATION_GROUP | Relationship group name for clone relationships | |
| COMPANY_OVERRIDE_FIELDS | This setting contains a comma separated list of field names with a display type of User, that must exist and that contain the users that the company name security feature works with. By default company name security works with only the ORIGINATOR field. This setting extends the feature to these other fields | |
| COPY_ATTACHMENT_ON_CLONE | YES | When this setting is YES, attachments will be copied to the new issue when an issue is cloned |
| DEFAULT_USER_ROLE | GUEST | Default role for users, if they have not been assigned a role |
| DISABLE_INACTIVE_UDF_WARNINGS | NO | When this value is set to YES the warning message caused by references to inactive UDF list values will be disabled. The default value is NO. |
| DISALLOW_AREA_0_DATA | NO | When this setting is NO, issue data may be entered into AREA 0. This is provided for backwards compatibility for installations created prior to version 4.2. Installations created with version 4.2 and greater should not allow issue data to be placed in AREA 0. With installations from 4.2 onwards, this should be set to YES |
| DISALLOW_PROJECT_0_DATA | NO | When this setting is NO, issue data may be entered into PROJECT 0. This is provided for backwards compatibility for installations created prior to version 4.2. Installations created with version 4.2 and greater should not allow issue data to be placed in PROJECT 0. With installations from 4.2 onwards, this should be set to YES |
| EMBEDDED_LAYOUT_REFRESHES | NO | This setting is provided for full backwards compatibility with all versions prior to 6.0. When the value is NO (the default), sublayouts such as those rendered with the LAYOUT SELECTED mechanism and with the FIELD/LAYOUT VISIBLE IF mechanism are refreshed using AJAX calls to the server. This is fast, but browsers do not have the capability to retain the initial presentation of the fields refreshed. If you set the value to YES, then the sublayouts are refreshed by a return to the server, and the alignment is retained. The tradeoff is between speed and the alignment of the fields on the screen. For many purposes the precise alignment of embedded layouts is not significant and not noticeable by users |
| ENABLE_COMPANY_NAME_ACCESS | YES | When this behavior setting is set to YES (the default value), a user's company name overrides the privacy setting for an issue and gives the user access to all records that were originated by other users with the same company name. Valid values are YES and NO |
| ENABLE_GOOGLE_LANGUAGE_API | NO | When this setting has a value of YES, then the Google Language API is enabled. This relies on the presence of a JavaScript function in UserJavaScript.js. This function may be customized by the administrator. See the Application Programming Interface guide for more details on how to configure this feature. |
| ENABLE_PRIVACY_GRP_OVERRIDE | YES | This setting may have the value of YES or NO. When set to YES, any one issue in a one-to-many relationship group may only have a single parent at one time. This implies that if you set a different parent ID for an issue, then ExtraView will remove the issue as being the child of the original issue, and set the new parent ID for the issue in its place. If you have NO for the setting, then an issue may have more than one parent at one time. |
| ENFORCE_ONE_TO_MANY_RG | YES | This setting may have the value of YES or NO. When set to YES, any one issue in a one-to-many relationship group may only have a single parent at one time. This implies that if you set a different parent ID for an issue, then ExtraView will remove the issue as being the child of the original issue, and set the new parent ID for the issue in its place. If you have NO for the setting, then an issue may have more than one parent at one time |
| ENFORCE_STATE_CHANGE_RULES | NO | Switch to enforce state change rules. Valid values are YES and NO |
| ENFORCE_UNIQUE_RELEASES | YES | Enforces uniqueness of RELEASE_FOUND in a repeating record row. If the value of this default is YES, repeating rows cannot be added where the field named RELEASE_FOUND has a null value. In addition, you may not have duplicate RELEASE_FOUND values within a single record. If the value of this default is NO, a repeating row will be added if any of the writeable fields in the repeating record row on screen are not empty (including default values). Also note that the fields named RELEASE_FOUND and RELEASE_FIXED are the children of the field named PRODUCT_NAME. Therefore, if you use these fields on a repeating row record, then you must also have the PRODUCT_NAME field on the same layout. |
| FILTER_CHILD_VALUES | NO | This may have the values YES, NO or USER. The setting controls search behavior when the query filter contains repeating row values. If set to YES, only those rows that match the search criteria will be returned by the query. If set to NO, all rows are returned for any issue where at least one row matches the criteria. If set to USER, this behavior is controlled by a checkbox that appears on the search screen. |
| FILTER_MODULE_BY_CATEGORY | NO | Allow filtering of modules by category. Valid values are YES and NO. This allows selection of a subset of modules based on both the module type and a category. By selecting Category, only the corresponding module types are displayed as valid choices within the select list of modules on the add and edit screens. For example, products may have hardware, software and documentation modules. If a problem is related to software, only software the modules should be selectable. This feature relies on use of the Category field in the Item record to store a value for Module Type. When FILTER_MODULE_BY_CATEGORY is set to YES the value entered for CATEGORY is used as a second parent value for the module (MODULE_ID field) by providing a value for MODULE_TYPE in the same way that the product (PRODUCT_NAME field) is used as the first parent value. Note that this requires identical enumerated values for both CATEGORY and MODULE_TYPE. In the Data Dictionary setup for the MODULE_ID field, the following should be set: First Parent Field Name = PRODUCT_NAME First Parent SQL = where product_name Second Parent Field Name = CATEGORY Second Parent SQL = and module.category To make these changes in the data dictionary, you must sign on to ExtraView with the admin user account. |
| HIDE_ISSUE_ID | NO | Controls the title of the detailed report and the edit screens. When this is set to "YES" the standard title will be replaced with the text "ExtraView" and the current time |
| ISSUE_LINK | DETAILED_REPORT | This setting has two possible values, DETAILED_REPORT and EDIT_SCREEN. When ExtraView automatically places a link on an issue within a report, this setting defines the destination when the user clicks on the link. |
| ITEM_ID_DISPLAY | ID | When this setting has a value of ID, then the internal issue ID is used in all the main display screens as the issue number that the user is dealing with. However, if the administrator sets their own logic to process the unique reference number to each issue, then setting the ALT_ID as the value of this setting tells ExtraView to display the ALT_ID value in place of the ID value |
| LIMITED_USER_ROLE | GUEST | This role does not own and cannot be assigned problems. This is typically the guest or customer user role in your installation |
| LINK_MODULE_USER | ASSIGNED_TO | Links the module owner field to the specified user field. Can be ASSIGNED_TO, CONTACT or OWNER |
| MINI_HISTORY_FIELDS | STATUS, TIMESTAMP, LAST_CHANGE_USER | This setting defines the fields that will be displayed on the MINI_HISTORY field when it is used on a layout. The STATUS field should always be used, and up to four additional fields can be defined. The additional fields that are available are: SEVERITY_LEVEL, PRIORITY, STATUS, PRODUCT_NAME, OWNER, TIMESTAMP, ASSIGNED_TO, PRIVACY, LAST_CHANGE_USER, ALT_ID, AREA, PROJECT, CATEGORY, RESOLUTION, PRODUCT_LINE, DATE_LAST_STATUS_CHANGE, CONTACT, ORIGINATOR, and HIST_TIMESTAMP |
| MULTIPLE_FIELD_SEPARATOR | -/- | Used as a separator for child level multi- value UDF’s |
| OAUTH2_TOKEN_LIFETIME_SECONDS | 3600 | This setting defines the lifetime from token creation to expiration, of tokens created on this instance. |
| RELATION_GROUP_DEFAULT | The name of the relationship group that will be used for any issue being placed into a relationship group. This default can be overridden by using a layout cell attribute on the RELATED_ISSUE_DISPLAY, or by using the field RELATIONSHIP_GROUP on the add or edit layout to offer the user a choice of relationship groups | |
| RELATIONSHIP_GROUP_EMAIL_LIMIT | 30 | When you update the status of an issue within a relationship group, each issue will be subject to the standard notification process. When there are more than RELATIONSHIP_GROUP_EMAIL_LIMIT entries in the group, notification is only made to the users in the parent issue, and a comment is inserted on the issue with this information |
| RELATIONSHIP_GROUP_LIST_UDF | This setting is the name of a user defined field with a display type of list. This UDF is used to maintain a list of the names of relationship group for related issue display. The UDF is maintained by ExtraView as relationship groups are created or deleted. The UDF can also be aliased by other UDF's to provide an unlimited number of fields that can be used to identify the relationship group names to support multiple related issue displays on a single edit screen. | |
| RELATIONSHIP_GROUP_MAX_DISPLAY | 0 | Maximum number of issues to display on the relationship group screen. A value of 0 will display all the records. Note that if your role is the one defined in ADMIN_OVERRIDE_ROLE then all the issues will always be displayed. |
| RELATIONSHIP_LINK_DISPLAY | SELECT | Display choice for relationship group indicator on edit screen (LINK or SELECT) |
| RELEASE_SORT_ORDER | DESCENDING | ASCENDING or DESCENDING |
| RG_UPDATE_BILEVEL_ONLY | NO | This behavior setting is for backwards compatibility with ExtraView version 4.x. If you set the value to YES, then related issue updates are only triggered when a change to the STATUS field takes place. If this is set to NO then updates to related issues may be triggered on different events and many updates to different fields are possible |
| RULES_DEFAULT_CALENDAR | 24_BY_7 | This setting selects the number of business days in a week. Valid values are 24_BY_7 or WEEKDAY. The WEEKDAY calendar runs Monday through Friday. The 24_BY_7 calendar uses all days |
| SAVE_AND_CONT_ACTION | PAGE | This setting determines how the Update and Continue button on Edit screens behave. The valid entries for this setting are AJAX and PAGE. When the PAGE option is set, all LOAD directive business rules are triggered when the button is pressed by the user, after the issue is updated. When the AJAX option is set, the issue is saved, no LOAD directive rules are executed, but any values changed by the update process are displayed. |
| SAVE_AREA_PROJECT_CHANGES | NO | If the SAVE_AREA_PROJECT_CHANGES behavior setting is YES, then when a user changes their business area and/or projects while entering or updating an issue, the change will be reflected in both the current session and set as their personal default. If the behavior setting is set to NO, then any changes to the business area and/or project will not affect the user's personal setting or the value for the current session. This setting is not applied when the user is operating within a workspace |
| SAVE_ROLE_CHANGES | YES | Unless you have custom code that dynamically switches roles back and forward for a specific requirement of your site, then this should always be set to YES, allowing any change of role for a user, by themselves or by an administrator to be saved into the ExtraView database. If there is custom code that switches a user's role and you do not want to make this role change stick in the database or be visible to the user, then the value should be set to NO. |
| SEPARATE_WORK_FLOW | PRODUCT | Allow separate work flows per USERGROUP (role) or PRODUCT or NONE |
| SHOW_CLOSED_REL_GROUPS_PERIOD | 0 | The list of items on a relationship group will be displayed until all issues have been closed for a minimum number of days specified by this value. Valid values are numbers equal to or greater than 0. 0 means that as soon as all items within a relationship group are of the status specified by STATUS_CLOSED_NAME they will not be displayed on the list of relationship groups. |
| SORT_SELECTED_VALUES | NO | When this is set to NO, all multi-valued lists will be displayed in the order set by the field's standard sort sequence. When this value is set to YES, all selected values will be displayed at the beginning of the list, using their sort order, then the non-selected values will be displayed using their sort order |
| STATUS_CLOSED_NAME | CLOSED | Data dictionary name of the closed status of a problem. This value is typically set when configuring a new system, and should not be changed after that time. The consequence of changing this value, and using a different value is that history is no maintained, and it will not be possible to either know when past issues were closed. |
