Related Issue Layouts

• 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
• Push Selected Attachments – When the button is pressed, attachments already selected will be copied to the new child issue being created
• 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
• Map a Push Down Field – There are some occasions when you want to push down a field from the parent issue to a different field on the child issue.  This can be accomplished by first selecting the field to push down, as described in the previous step and then right-clicking on the red button on the selected field.  This brings up a window where you can type in the name of the child field to which you want to map the parent field value
• 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.

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 for the field of the same name that is displayed to the user on the screen at the time the filters are applied to create the Related Issue Display.  This is effective for fields for fields with display types of List, User and Popup.  When you select this special value for other field display types, you may enter the name of a field as a value.  For example, if your field name to reference is ddName, enter $$ddName$$
• * Mapped Field Value From Issue * – the value will be taken from a different field when generating the Related Issue Display.  When this option is selected, a new field appears allowing you to enter the name of the field to map the value from, in the format $$ddName$$.  This only works for fields with enumerated list types of User and List fields
• $$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 a 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.

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.  With rgParameters(), the 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. 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=$

amp;p_project=$$ &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.

In the above examples, note that you may use the actual values for MY_AREA and MY_PROJECT by looking at the administration screens for the AREA and PROJECT fields to find the values.  However, this is not recommended as hard-coded actual values may change within a metadata migration but the hard-coded values in these expressions do not change in a metadata migration exercise.

Other assignment examples:

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

Multiple Add Buttons

Multiple Add buttons on the preheader are supported.  Under rare circumstances, you might want to create a specific sort order for these buttons.  There is not a place on the user interface to define the sort order of these buttons, but please contact ExtraView Support who will guide you through the process.

The attributes PREHEADER ADD BUTTON, RID PREHEADER SUBMIT BUTTON and RID PREHEADER REFRESH BUTTON each have the ability to set a Sort Order as part of their definition.  The sort order works across all the buttons defined on a single Related Issue Display.

Multiple Submit Buttons

Multiple Submit buttons on the preheader are supported, typically to allow different types of issue submissions.  Under rare circumstances, you might want to create a specific sort order for these buttons.  There is not a place on the user interface to define the sort order of these buttons, but please contact ExtraView Support who will guide you through the process.

• 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