First, please read the Key Concepts section on Business Areas to understand the terminology used on this page. The principle is that a specific business area or project will use a layout that is defined specifically for it. If none exists, it will inherit a layout in a defined manner as follows:
- If a layout exists for the given business area and project, this is used
- If this does not exist, the layout that exists for this business area’s master project will be inherited and used
- If this does not exist, the layout that for the global level will be inherited and used. Every inbuilt layout always exists at the global level, and therefore is always available to be inherited if a junior layout does not exist to override its use
Inheritance is an important principle to understand, as it governs how layouts are selected for each purpose throughout ExtraView. Further, if you decide to create a layout for a specific purpose such as the Add screen within a newly created business area, this does not imply that you must create layouts for all the other layout types, such as search filters and email layouts. Each layout is inherited independently, giving tremendous flexibility and reducing the amount of setup required.
Inheritance and User Role layouts
Layouts can be defined for each user role you have created within your system. This is described more fully below. However, note that you may combine the definition of layouts for user roles, business areas within these user roles, and projects within these business areas. For example, if you have a business area named Customer Calls, which may or may not be broken down into individual projects, you may define different layouts for different user roles such as Technical Support and Managers.
Inheritance of layouts
Note: You should set a default value in the data dictionary, for both the Business Area and the Project fields if you have their display type set to Tab and you intend to place the AREA and PROJECT fields on the Add screen layouts. However, the overriding setting is Remember Last Value. When this is set against Business Area and / or Project in the data dictionary, then the tab displayed upon entering the Add Issue screen, will be the one last used, not the default value.
Using rules, security permissions and layout cell attributes, you can make decisions on whether field-level data entered on one tab is either displayed on a second tab or is both displayed on the second tab and the values are stored with the record when it is inserted or updated. Consider an application where you insert and update customer information on a tab named “Customers”. You may have a second tab named “Customer Issues” where you record issues the customers report. The approximate configuration may be something like this:
With the addition of each customer issue, the Customer details are saved in the Customer Issues Business Area as the Customer is selected. To not allow the user to edit the customer details, you should set the permission of each field to read/write and then use a layout cell attribute on each filed in the Customer Issue layout to have a READ ONLY IF value. For example, set the CUST_ADDRESS field to be read only if the ID is not null. This will always be true, and therefore the field will display as read-only to the user, but the details will be saved in each record. If you only give read access to the user, the Customer details will not be saved in the record.
How Layouts are Selected
With inheritance, and the ability to define or override an individual layout for any combination of Display Target, User role, Business Area and Project, there is the potential for a large number of layouts in your system. Inheritance strictly controls the method by which an individual layout is either selected or inherited for display by the user.
When there is a choice of layouts, for the current display target the layout is chosen using the following diagram:
The Wildcard Role infers that any role is used to determine the selection for the inheritance.
Optional Layouts
For efficiency, and to minimize the configuration effort, a few layouts are optional and are ignored if they are not present. When this happens, ExtraView may then default to another layout, and use this other layout instead.
| Layout | Defaults To | Comments |
| ADD_CONFIRMATION | ADD_PROBLEM | When an issue is inserted, the behavior is to use the ADD_PROBLEM layout from the inheritance path to display a verification of the issue just entered. For most purposes this works in an obvious way and displays all the fields that the user just entered. Occasionally, you as the administrator may want to display a different set of fields. To accomplish this, create a layout of type ADD_CONFIRMATION in the business area and project of your site, or in the inheritance path. The fields that you place onto this layout will be those that are presented to the user when an issue is saved, as opposed to those on the ADD_PROBLEM layout. If the ADD_CONFIRMATION layout is not present, the ADD_PROBLEM layout is used as the verification screen |
| POST_EDIT_UPDATE | No Default |
If this layout exists in the inheritance path, and the issue being updated is a member of a relationship group, then this layout is rendered to give the user the opportunity to apply the same updates to the related issue. If the layout does not exist, nothing is rendered, and only the current issue is updated This layout is deprecated, and only included in the documentation for fullness. Existing implementations may continue to use this, but new installations should not configure this layout type |