[Index]

Model: data/FieldDisplayPolicy

Field Display Policies

Full HTML Help

Overview

Field Display Policies (FDPs) define the layout and composition of fields, fieldsets, and groups on forms in the Automate Admin Portal GUI. To change these elements on the form, you can edit the FDP associated with the form, if allowed.

Via the FDP, you can define whether to group or disable fields, add online help text to a field, add a label to a field, or move a field up or down on the form.

You can apply one or more FDPs to a particular item type to present different views of the same form. You can apply a FDP for a menu layout and role so that users with this role are presented with a view of the form (defined by the FDP) for their user role when they log in. For example, a system may have users at Provider, Customer, and Site administration hierarchy levels - all of whom may access the same items, but perhaps some item fields need to be hidden for admin users at some levels. Therefore, you can create and apply a specific FDP to a menu layout designed for admin users at these levels.

You can clone an existing FDP to quickly create one, then modify the clone as required, and choose this new FDP for the model on a user's menu layout. In this way, the user's view of the GUI can be modified for their level of access to the model, from the menu.

Field Display Policy Naming Convention

The name of a FDP must be unique at each hierarchy. You can however have FDPs with the same name at different hierarchies.

FDPs that have the name default will apply to their associated model, by default.

Display Groups As Tabs or Panels

The Field Display Policy configuration screen provides a Display As Groups setting that allows you to define the default layout of some forms, as either tabs or panels.

The image shows an example of a form where groups display as Panels:

The Automate system default is Panels, except for the following models, which have as their default setting, Tabs:

• view/GlobalSettings
• data/SiteDefaultsDoc
• data/ucprep_UC_Profiles
• relation/DP_REL
• data/HcsDpDialPlanSchemaDAT
• data/HcsDpDialPlanSchemaGroupDAT
• tool/BulkLoad
• tool/DataImport

The table lists models where the layout of elements of add and/or edit form types can't be modified via FDP. These form types also do not have the action element available on the GUI to switch the form view between tabs and panels.

Related Topics

Field Display Policy Input Reference in the Advanced Configuration Guide

Introduction to the Admin Portal User Interface in the Core Feature Guide

Add and Edit Field Display Policies

This procedure adds and edits a field display policy (FDP).

1. Log in as Provider administrator or higher.

2. Choose the relevant hierarchy.

3. Go to (default menus) Customizations > Field Display Policies to open the list of existing FDPs.

4. Do you want to ...

   • Edit an existing FDP? Click on the relevant FDP in the list view to open the configuration form. Update the FDP as required, then save your changes.
   • Add a new FDP? Go to step 5.

5. To add a new FDP, from the list view, click the toolbar Plus icon (+) to open the configuration form for the new FDP you're adding.

6. Configure the FDP:

   1. Fill out a name for the new FDP, and optionally, a description.

      • If the FDP name is default, it is applied by default to the target model type you choose on the form.
      • FDPs at the same hierarchy must have a unique name. FDPs at different hierarchies can share the same name.

   2. Choose the target model type to associate with the FDP.

      Note

      The target model type defines the fields available for use in the FDP.

   3. At Display Groups As, choose how groups should display on forms. Options are Tabs or Panels.

      Note

      The default is Panels, except for a selection of models, where the default is Tabs. Within a tab or a panel, you can add a combination of fields and/or fieldsets (within one or more groups).

   4. Add groups, one or more, required:

      At Groups, click the Plus icon (+), then configure the group.

      Note

      Groups that describe a collection of attributes display together on the GUI. All fields in the FDP must belong to a group.

      At the form level, groups all display either in panels or tabs, depending on the option selected in Display Groups As, and provided the model allows the option you choose.

      You can copy or re-order (move up or down) groups, fields, and fieldsets.

      The table describes the group configuration options:

      Component	Description
      Title	Mandatory. Fill out label text to display for the attribute on the new tab. If a group displays as a tab in the Admin Portal, the value defined for Title displays as the title of the tab.
      Number of Columns	Fill out the number of columns for fields. The default is 1 (a single column). Fields in the Selected transfer box display in these columns.
      Fields	Choose fields to add. Select then move fields from the Available field to the Selected field. The selected target model type defines the available fields. Use the Move Up/Move Down buttons to adjust the position of any field.

   5. Add fieldsets, if required. Click the Plus icon (+) at Fieldsets, then configure the fieldset.

      Note

      Fieldset options (fields in the Available transfer box) show all field choices for the selected target model type. Fieldset names are added as choices within any group added to the FDP, and the fields display as a group in fieldsets in the panels.

      The Name field is the name of the fieldset. First create fieldset, then add it to a group.

   6. Add field overrides, if required. Click the Plus icon (+) at Field Overrides, then configure the field override.

      The table describes configuration options for field overrides:

      Component	Description
      Field	Name of the model field to override. Options include those added to the Selected field for groups.
      Title	New title to display for the field. If the FDP is called default at a hierarchy, the list view column header also displays this title if the field belongs to the list of summary attributes.
      Help Text	New help text to display for the field. Leave blank to use the model attribute description.
      Disabled	Sets the field as read-only.
      Input Type	Overrides the input type of the field. Select an option to choose how the input field displays, for example, radio button, grid, multi select.

7. Click Save.

   Once saved, the FDP can be applied by selecting it in a menu layout available to a role.

Clone a Field Display Policy

This procedure creates a copy, or clone, of an existing field display policy (FDP) to create a new FDP, starting with the configuration of the FDP you're cloning.

1. Login as Provider administrator or higher.

2. Choose the hierarchy.

3. Go to (default menus) Customizations > Field Display Policies to view a summary list of existing field display policies (FDPs).

4. Click on the FDP you want to clone.

5. Choose Actions > Clone.

6. Update the necessary fields for the cloned FDP.

7. Click Save.

   You can apply the cloned FDP by choosing it in a menu layout available to a role.

Rules for Creating Field Display Policies

When creating groups and selecting the field transfer boxes of a group, a number of rules apply.

To understand the rules, consider a selected Target Model Type with the fields as listed below. Where the name starts with "A", the field is an array and where it starts with an "O" it is an object. The values "x", "y", "z" are also objects. The field "F" is neither object or array.

• A, A.x, A.x.b, A.x.c, A.x.d, A.y.r, A.y.s, A.y.t
• F
• O, O.v, O.z, O.z.a, O.z.b, O.w.d

Inclusion Rules

The following inclusion rules apply:

• If a parent object or array field is included, the parent and all its children will be displayed in the GUI.

  Example: if O.z is selected, O.z is saved as the fields and the GUI will display O.z and also inner fields O.z.a and O.z.b.

• If a specific selection and order of child elements are required, select these child elements and order them.

  Example: if O.w.d, O.z.b, F are selected, these three fields are saved in that order in the FDP group fields and the GUI shows only the inner field O.w.d, followed by the inner field O.z.b and lastly the field F.

• Inclusion of child fields in a group without the inclusion of the parent fields will display these child fields at the root level of the form.

  Example: if O.w.d, O.z.b are selected, these fields are saved as is in the FDP group fields list and only the inner fields O.w.d and O.w.b are shown in the GUI.

• Array children fields without their parent fields will be ignored by the GUI. Therefore, if the child fields of an array field are selected, the parent field should also be selected.

  Example: if A.y.s, A.y.t are selected, A and A.y should be selected.

• Array fields may not be split into different groups.

• The parents of fields cannot be in one group and its children in another.

  Example: O.z cannot be in Group 1 if O.z.a, O.z.b and O.w.d are in Group 2.

• Fields of the same object and members of the same array type cannot belong to more than one group.

  Example:

  • If A.y.s is selected for Group 1, then A.y.t cannot be selected for Group 2.
  • If O.z.a is selected for Group 1, then O.z.b cannot be selected for Group 2

• You can split the first level children of object fields into different groups.

  Example:

  • O.v can be in Group 1 while O.z is in Group 2.
  • For second level children: O.z.a can be in Group 1 and O.w.d can be in Group 2.

• To hide a field do not move it to a Selected box.

  Example: To hide O.z.b, select O.z.a, O.w.d.

Ordering Fields in a Field Display Policy

You can move fields or fieldsets in a group (up or down on the form) by clicking the Move Up / Move Down buttons at the group level or in the transfer boxes.

Ordering child and parent fields depends on the presence of siblings, other parents, and children. If a child is selected in a group and not its parent, but a sibling of that parent is selected, then the sibling's order will affect the order of the fields.

The logic of order resolution starts from parents to children, according to the rules below.

For example, we select fields in this order in Group 1:

C.z, A.x.b, A.x.c, B, A.y, A.x, C, C.w

Result:

• Parent fields on their own are considered first, hence our initial order is B, C.
• However, parent A is not selected; only the children. We determine where A was mentioned. In this case the children of parent field A were mentioned before the parent fields B or C. Hence children of A will eventually be ordered before B and C.
• Next we consider the selected first level child fields: C.z, A.y, A.x, C.w. The order becomes: A.y, A.x, B, C, C.z, C.w
• We now move down the levels: A.x.b, A.x.c.

Thus the final display order will be:

A.y, A.x, A.x.b, A.x.c, B, C.z, C.w

Further examples below illustrate the presence of parents, siblings and children on the selected order.

• We add fields C.w, A, C, B, A.x, A.y.

  Result: The order is: A, A.x, A.y, C, C.w, B.

• We add fields A.x.b, A.x.c, A.y, A, B

  Result: The order is: A, A.x, A.x.b, A.x.c, A.y, B.

  Note

  Note that A.x was added and that A.y is placed after A.x, since the children were ordered before A.y while A.x was never selected.

Field Display Policies

Field Display Policies are applied to certain item types in order to modify the default form that is displayed when these items are created or accessed.

With Field Display Policies, the fields on an item detail form can be grouped, disabled, and on-line help text can be added for a field. A field can be provided with a new label and its position on the form can be moved up or down.

More than one Field Display Policy can apply to a particular item type so that the selection of a particular policy will present another view of the form.

A Field Display Policy for an item type can be applied from a Menu Layout by selecting and associating it with the item on the Menu Layout. The Menu Layout is then selected to be part of a user Role so that users who have this role and log in will be able to have the item displayed according to the relevant Field Display Policy.

For example, a system may have users at Provider, Customer and Site administration hierarchy levels - all of whom may access the same items, but perhaps some item fields need to be hidden for administration users at a certain level. Field Display Policies can then be made that are applied to the Menu Layout associated with the administration users at these levels.

New Field Display Policies can be added or existing ones can be edited. A quick way to add a Field Display Policy is to clone an existing Field Display Policy, modify it as required and then to select it for the model on a user's menu layout. In this way a user's interface can be modified from the point of user access to the model on the menu.

There is a unique constraint on the name of the Field Display Policy per hierarchy level. The same name can be used on another hierarchy, but a new name is needed at the same hierarchy.

A Field Display Policy can also be selected for a form that is part of a Wizard.

If a Field Display Policy is called 'default', it will apply to a model by default.

Clone a Field Display Policy

1. Login as provider administrator or higher.
2. Choose the desired hierarchy.
3. Choose Customizations > Field Display Policies to show the list of existing Field Display Policies.
4. Click on the field display policy that you want to clone.
5. Choose Actions > Clone.
6. Update the necessary fields for the cloned Field Display Policy. Refer to "Rules When Creating a Field Display Policy" for more information.
7. Click Save.

The cloned Field Display Policy is available to be applied to the item by selecting it in a Menu Layout that is available to a Role.

Create a Field Display Policy

A Field Display Policy can be added to any of Data, Domain models, Relations, Views, Wizards to modify the default form that is available for the item.

1. Choose the relevant hierarchy level.
2. Click Add from System Configuration > Field Display Policies or choose the Field Display Policy button on the button bar from a menu item, for example from Site Administration > Lines.
3. Enter the Name and and optionally a Description for the Field Display Policy. If the name is 'default', the Field Display Policy will apply to the target model type by default.
4. Select or verify the model reference for the Target Model Type.
5. Click Add adjacent to Groups and add a group Title. All the fields of the display policy should belong to a Group. If a group displays as a tab on the GUI, the Title is the tab title.
   • Select Display as Fieldset to show the group Title as a group header on the GUI and without tabs, or as a group title on a tab called Base if more than one group has this check box enabled.
   • Enter a numeric value for Number of Columns if the fields should show in columns.
6. On the Fields transfer boxes of the Group, select the required target model type fields from the Available box and add them to the Selected box. The available fields include fields from all versions of the schema of the target model type. Refer to the Rules When Creating a Field Display Policy topic for the caveats that apply when selecting the fields.
7. For each selected field in a Selected transfer box, its attributes can be configured in the Field Overrides group:
   • Field - Select the field to which the attributes apply.
   • Title - Select the label text to be shown for the attribute.
   • Help Text - Enter text to display as the field on-line help and form tool tip for the attribute. If no text is added, the model attribute description is shown.
   • Disabled - select the check box if the field should show as disabled.
   • Input Type - The default display of the input field can be selected. For details, refer to the Field Display Policy Input Reference topic.
8. Click Save on the button bar to save the Field Display Policy.

The created Field Display Policy is available to be applied to the model by using it in a Menu Layout.

Rules When Creating a Field Display Policy

When creating groups and selecting the field transfer boxes of a group, a number of rules apply.

Regarding notation: if the fields belong to objects or arrays, the names in the transfer boxes are shown in dot notation. Refer to the target model type on-line help field reference to distinguish object types from array types.

To understand the rules below, consider a selected Target Model Type with the fields as listed below. Where the name starts with "A", the field is an array and where it starts with an "O" it is an object. The values "x", "y", "z" are also objects. The field "F" is neither object or array.

• A, A.x, A.x.b, A.x.c, A.x.d, A.y.r, A.y.s, A.y.t
• F
• O, O.v, O.z, O.z.a, O.z.b, O.w.d

The following inclusion rules apply:

• If a parent object or array field is included, the parent and all its children will be displayed in the GUI. For example, if O.z is selected, O.z is saved as the fields and the GUI will display O.z and also inner fields O.z.a and O.z.b.
• If a specific selection and order of child elements are required, select these child elements and order them. For example, if O.w.d, O.z.b, F are selected, these three fields are saved in that order in the FDP group fields and the GUI shows only the inner field O.w.d, followed by the inner field O.z.b and lastly the field F.
• Inclusion of child fields in a group without the inclusion of the parent fields will display these child fields at the root level of the form. For example, if O.w.d, O.z.b are selected, these fields are saved as is in the FDP group fields list and only the inner fields O.w.d and O.w.b are shown in the GUI.
• Array children fields without their parent fields will be ignored by the GUI. Therefore, if the child fields of an array field are selected, the parent field should also be selected. For example, if A.y.s, A.y.t are selected, A and A.y should be selected.
• Array fields may not be split into different groups.
• The parents of fields cannot be in one group and its children in another. For example, O.z cannot be in Group 1 if O.z.a, O.z.b and O.w.d are in Group 2.
• Fields of the same object and members of the same array type cannot belong to more than one group. For example:
  • If A.y.s is selected for Group 1, then A.y.t cannot be selected for Group 2.
  • If O.z.a is selected for Group 1, then O.z.b cannot be selected for Group 2
• You can split the first level children of object fields into different groups. For example:
  • O.v can be in Group 1 while O.z is in Group 2.
  • For second level children: O.z.a can be in Group 1 and O.w.d can be in Group 2.
• To hide a field, do not move it to a Selected box. For example, to hide O.z.b, select O.z.a, O.w.d.

To order fields in a group, arrange them in the Selected box. Use the Move Up and the Move Down buttons under the box.

The following ordering rule applies:

The ordering of child fields and their parents depend on the presence of siblings, other parents and children. If a child is selected in a group and not its parent, but a sibling of that parent is selected, then the sibling's order will affect the order of the fields.

The logic of order resolution starts from parents to children, according to the rules below.

For example, we select fields in this order in Group 1:

C.z, A.x.b, A.x.c, B, A.y, A.x, C, C.w

Result:

• Parent fields on their own are considered first, hence our initial order is B, C.
• However, parent A is not selected; only the children. We determine where A was mentioned. In this case the children of parent field A were mentioned before the parent fields B or C. Hence children of A will eventually be ordered before B and C.
• Next we consider the selected first level child fields: C.z, A.y, A.x, C.w. The order becomes: A.y, A.x, B, C, C.z, C.w
• We now move down the levels: A.x.b, A.x.c.

Thus the final display order will be:

A.y, A.x, A.x.b, A.x.c, B, C.z, C.w

Further examples below illustrate the presence of parents, siblings and children on the selected order.

• We add fields C.w, A, C, B, A.x, A.y.

  Result: The order is: A, A.x, A.y, C, C.w, B.

• We add fields A.x.b, A.x.c, A.y, A, B

  Result: The order is: A, A.x, A.x.b, A.x.c, A.y, B.

  Note that A.x was added and that A.y is placed after A.x, since the children were ordered before A.y while A.x was never selected.

Add or Edit a Field Display Policy

A Field Display Policy can be added or edited.

1. Login as provider administrator or higher.
2. Choose the desired hierarchy.
3. Choose System Configuration > Field Display Policies to show the list of existing Field Display Policies.
4. Click Add on the button bar to create a new Field Display Policy and enter a new name in the Name field. Alternatively, you can edit an existing Field Display Policy by clicking on it and editing the fields as described below. If the name is ‘default’, the Field Display Policy is applied by default. There is a unique constraint on the name of the Field Display Policy per hierarchy level, so the same name as the original can be used on another hierarchy, but a new name is needed at the same hierarchy.
5. Complete the following field display policy details:
   1. Optionally enter a Description for the Field Display Policy.
   2. Choose the model reference for the Target Model Type from the drop-down list.
   3. Click Add next to Groups, and complete the following:
      • Title - Enter the label text to be shown for the attribute. This is mandatory, and is the name that will be shown on the created tab.
      • Display as Fieldset - Check this check box to make sure that all fields are shown on the same page instead of a separate tab.
      • Number of Columns - Enter the required number of columns. The fields in the 'Selected' area (see Fields below) will be displayed in the number of columns specified in this field. The default is to display the fields in a single column.
      • Fields - Configure the fields that will be displayed on the tab. Choose the fields in the 'Available' area of the screen and click Select to move them to the 'Selected' area of the screen. Fields displayed in the 'Available' area are determined by selected Target Model Type. To adjust the position of a field in relation to the other fields, click on a field and use the Move Up and Move Down buttons.
   4. Click Add next to Field Overrides and complete the following:
      • Field - Choose the field name from the drop-down for which you want to create override text (a different label).
      • Title - Enter the required label text.
      • Help Text - Enter text to display as the field on-line help and form tool tip for the attribute. If no text is added, the model attribute description is shown.
      • Disabled - Check the Disabled check box if you want to hide the field (grey it out).
      • Input Type - Choose the required option from the drop-down to determined how the input field is displayed.
6. Click Save on the button bar to save the Field Display Policy.

The created Field Display Policy is available to be applied to the item by selecting it in a Menu Layout that is available to a Role.

Field Display Policies are applied to data models and domain models in order to modify the default form that is displayed when instances of these models are created or accessed. With Field Display Policies, the fields on a model form can be grouped, hidden, on-line help text can be added, a field can be set as read-only, it can be provided with a new label and the field order on the form can be re-sequenced. More than one Field Display Policy can be created for a particular model so that the selection of a particular policy will present another view of the model form. A Field Display Policy can also be selected for a particular model in a User Role so that users that belong to this User Role will by default view the particular model according to this display policy.

Model Details: data/FieldDisplayPolicy