Inheritance

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. 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:

  1. On both the Customer and the Customer Issues add and edit layouts, you may have placed fields such as CUST_CONTACT_NAME and CUST_ADDRESS.
  2. You create a link using rules (see the section titled Business and Email Rules on how to do this) similar to the following:
  3. 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 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. The following chart shows how ExtraView resolves the layout to choose:


    Layout Choice

    The table is read from top to bottom, with ExtraView looking for the first row that satisfies the criteria defined by the administrator for the user and their current role. The last two columns in the table are only used when selecting an embedded layout. Note the following in the selection process:
    When there is a choice of layouts, the layout is chosen based on:

  • User role
  • then Business Area
  • then Project
  • then the data dictionary name
  • and then on data dictionary name’s value

Also note that:

  • Add and edit layouts are chosen based on all the above criteria
  • The email notification layouts use the user role, business area, and the project. There is no selection based on a field in the data dictionary
  • A layout may match multiple rows in the table above. The first row in the table that matches the user’s current settings is used
  • The last two columns in the table above are only used when selecting embedded layouts.

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