Product Documentation

The RID BUTTON ACTION attribute is applied as a cell attribute to the RID PREHEADER ADD BUTTON. The action defines what happens when the user presses the add button. This attribute is applied directly to the field's global attributes, defined within the data dictionary, as opposed to being set as a layout cell attribute on the related issue display layout.

• Target Business Area - This defines the Business Area that will be used for the add screen displayed when the button is pressed
• Target Project - This defines the Project that will be used for the add screen displayed when the button is pressed
• Check Required Fields - If you check this option, then all required fields on the parent issue that will be required by the child issue, are checked that values are filled in, before the child window is displayed. This can be extremely useful if you are going to push down field values from the parent to the child issue, and you want to ensure that the child window is always initiated with a value within a field
• Action after Submitting the Child Issue - This option allows you to select the action after the child issue is created. You can either have only the related issue display that contains the newly added issue updated, or you can have the parent issue updated and the entire screen updated. The latter is only required when there are some business rules that triggered changes to the parent issue when the child issue was submitted
• Push Down Field List - Double click on the fields whose values you want to push down from the parent issue to the child issue. The selected fields are displayed in the right-hand list
• Show Generate Script - This button is provided for advanced usage. It is possible to configure button actions that are more complex than can be done with the BUTTON ACTION utility. This option allows you to generate the JavaScript that is close to what you require. You can then copy this JavaScript into the RID ONCLICK_JS attribute, and modify it for your requirement. You should not save the BUTTON ACTION if you are using RID ONCLICK_JS and vice versa.

Note that you may define more than one BUTTON_ACTION on a single related issue display.

The setting has no effect on reports where the entire contents of the related issue display will be rendered.

This cell attribute allows the administrator to specify a set of filters to apply to the selection of the related issues to display. This filter is applied to only the related issue records so the user will only see a subset of the related issues. For example, this screenshot shows the administrator about to select values for filters for the Business Area and Status fields:

Note that beyond the selection of specific values to use for filters, there are several other possibilities:

• * Any * - This value is not used.  Setting it is the same as not using the filter
• * Ask at runtime * - The user will be prompted when the related issue display is being generated, to provide a value for the filter
• * Value from issue * - The value to be used within the filter for the related issue display will be taken from the current value within the field of the same name, that is displayed to the the user on the screen
• $$SYSDAY$$ or $$SYSDATE$$ - These may be used within day or date display type fields to filter on the current day or date.  It is not too practical to filter on aa field being equal to $$SYSDATE$$, as the date includes time to the millisecond, and it's unlikely that issues will match this.  Using operators of less than or greater than with date type fields is more useful.

It is not recommended that you place SIZE layout cell attributes on the fields contained within the Related Issue Display layout when you use this attribute.  Likewise, it is not recommended that you use this option if you expect that the user will see text that wraps within the Related Issue Display.  The best results are obtained when the browser sizes all the columns and column titles.

Linking a Single Result to Populate Fields within the Current Issue

If you are using the RID LINK FIELD NAME to link the search results to a single issue and you then want to take fields within that issue and place their values within the current issue, you are likely to also configure a link and a refresh business rule to retrieve the field values you require from the search result. See Example 3.

Linking Multiple Search Results to Populate a Related Issue Display

If you are using the RID LINK FIELD NAME to link the search results to multiple issues that you want to relate to the current issue, and place these issues within a related issue display on the current layout, you are likely to also configure RID LINK FIELD NAME with these attributes:

• RID ACT ON FIELD CHANGE - This attribute indicates that an action will be taken when this field is updated as a result of being linked to search results
• RID RELATIONSHIP NAME - This is the name of the relationhip group into which the records from the search results are to be placed
• RID RELATION TYPE - This is the type of the relationship. Usually this will be CHILDREN, but PARENTS may also be appropriate

See Example 4 for details on how to configure this.

Basic Syntax

Substitutable values are possible in this string value. To create a modal popup window the basic JavaScript you use will be:

doEditAEActions(window.parent.extraview_app_home_url , '__SESSION_ID__', 
new Array('POPUP_MODAL_ADD', 'add_confirm_page=NO' + rgParameters(), 
'RELATIONSHIP_GROUP_REFRESH', '__LAYOUT_TYPE_ID__' ));

Note the two substitutable variables SESSION_ID and LAYOUT_TYPE_ID. They must be surrounded by double underlines. This provides the mechanism for ExtraView to substitute the variable at runtime. You set a value of YES or NO to the add_confirm_page parameter, depending on whether you want to display or suppress the verification layout or the ADD_CONFIRMATION layout that is typically shown to users after submitting a new issue. If you set NO, then the verification screen is never shown. There is a built-in method that generates the necessary relationship group parameters for the ADD operation. These are needed to force the insertion of the child issue into the correct Relationship Issue Display relationship group using the relation type of the Related Issue Display. This is rgParameters() and it is in scope from the button when the button is inserted into the header of the Related Issue Display.

Updating and Refreshing the Underlying Issue

There are use cases where you might want to update and refresh the parent Add or Edit screen, after you add a child issue. For example, while adding a child issue, Business Rules might execute that update the parent issue. If you want this behavior, there is an UPDATE_MAIN parameter. The workflow might be to go from an Add or Edit screen, add a child record in a modal popup window, submit the child issue within the modal popup (this executes Business Rules that update the parent issue), then close the modal popup and finally redisplay the updated parent issue, you will include the UPDATE_MAIN parameter as follows:

Note that you do not require the RELATIONSHIP_GROUP_REFRESH and accompanying LAYOUT_TYPE_ID parameters, as the REFRESH_ID takes care of refreshing the entire parent issue. If this is executed from an Add screen, the parent issue is displayed within an Edit screen, as the underlying Business Rules submitted the parent issue to the database, thus meaning it is no longer in the add state, but it is now in a state where it can be updated. The p_rg_relate_this_to parameter and its value are used on the Add screen to identify the parent issue to which you want to relate the child issue you are adding, when you are including the UPDATE_MAIN parameter. It has no effect otherwise on Add screens, or Edit screens and may be omitted in these cases.

Setting Additional Parameters to Push Values from the Parent to the New Issue

Other parameters may be added to the array value immediately following the POPUP_MODAL_ADD entry. An example is to set the Business Area and Project of the issue to be added. To accomplish this, you will need to know the AREA_ID and PROJECT_ID where the issue is to be added. These can be found on the administration screens for these items. With rgParameters(), an example becomes:

Note that the values for the p_area and the p_project parameters must correspond to the AREA_ID and PROJECT_ID into which you will add the related issue. These values can be seen on the list maintenance screens for the Business Area and the Project. Another possibility is that you might want to pass the values of one or more fields from the parent issue to the child issue you are creating. To achieve this, you may use either the pushDownFields('p_fld1;p_fld2;p_fld3;...') function to pass several fields at once or use the getValueFromParent() function to pass individual fields. For example, let's say that you want to pass the FIRST_NAME and LAST_NAME fields from the parent to the child. The string then becomes either:

or using individual parameters:

doEditAEActions(window.parent.extraview_app_home_url , '__SESSION_ID__', 
new Array('POPUP_MODAL_ADD', 'p_area=1&p_project=5
&p_rg_relate_this_to=' + getValueFromParent('p_id') + 
'&p_first_name=' + getValueFromParent('p_first_name') + 
'&p_last_name=' + getValueFromParent('p_last_name') + 
'&add_confirm_page=NO' + rgParameters(), 
'RELATIONSHIP_GROUP_REFRESH', '__LAYOUT_TYPE_ID__' ));

Note that if a field name that you pass within the pushDownFields() or the getValueFromParent() function does not exist, it will be ignored when the user presses the button to add the issue, and no error will be generated. This can be used to advantage in configurations where you want to use a single button for multiple purposes on different forms.

Opening the Modal Popup Window in Edit Mode

There is a feature within ExtraView that allows the user to open up a new issue in Edit mode, as opposed to the Add mode.  This configuration assigns an ID and / or an ALT_ID and saves the initial issue within the database before then placing the user within Edit mode on the screen.  This can be configured within the modal popup window, by altering the POPUP_MODAL_ADD parameter to POPUP_MODAL_OPEN_IN_EDIT.

Repeating Rows Fields

The function getValueFromParent may be modified to access repeating row field values. Repeating rows are indexed, beginning with zero, therefore to access the first repeating row, the call will look like:

To access the third repeating row, the call will look like:

Although you may target any repeating row to obtain a value from a field, the value will always be placed in the field on the first row of the child record. The following technique will allow you to get values from successive repeating row fields, and populate these into successive repeating rows within child records:

This example gets the field value from the third repeating row and places the result in the first repeating row child record, and then gets the value in the fourth repeating row field and places its value in the second repeating row child record

• MEMBERS - This is the default value for this attribute if you do not override it with one of the other values. In this case the related issue displaywill show all the members of the group(s), containing the reference issue, i.e. the reference issues parents, children, and other issues not directly related to the reference issues in the group(s).
• CHILDREN - The related issue display will only contain issues that are the children of the reference issue
• PARENTS - The related issue display will only contain issues that are the parents of the reference issue. Note that in the ExtraView data model it is possible to define more than one parent issue for a specific issue. See the section on Relationship Groups for more information.
• RELATED - In this instance ExtraView will display the parents and the children of the reference issue within the specified group(s), within the related issue display. The parents and children of these related issues will not be displayed.
• SIBLINGS - ExtraView will display all the issues at the same level in the hierarchy. For example, if a parent record has five children, and you create a related issue display with all the children, using a relationship group relation type of SIBLINGS, then you will see the four siblings to the current one.
• GRANDPARENTS - This allows the display of the grand-parents to the current level in the hierarchy
• GREATGRANDPARENTS - This allows the display of the parents of the grand-parents in the hierarchy
• GREATGREATGRANDPARENTS - This allows the display of the parents of the great-grand-parents in the hierarchy
• GRANDCHILDREN - This allows the display of the grand-children to the current level in the hierarchy
• GREATGRANDCHILDREN - This allows the display of the children of the grand-children in the hierarchy
• GREATGREATGRANDCHILDREN - This allows the display of the children of the great-grand-children in the hierarchy
• LINKED - This type does not use a relationship type per se, but relies on the Related Issue Display filters to retrieve the associated issues. For example, you might have a filter that selects all the open issues for a particular product, and display these on a related issue display of each issue that you call up.

If you are using the related issue display to add new issues, the value should be CHILDREN or PARENTS. If you choose another relationship type then the issue will be added, but will not be displayed as the relationship is indeterminate

Beginning with version 10, you can no longer use a SIZE layout cell attribute on the individual fields within the related issue display to control their width. This allows the enabling of a new feature, to freeze the titles of the related issue display.  This is very beneficial when you have a significant number of related issues within the display, as the titles always remain visible.