How to: Customize Pages & Forms

This paragraph describes the necessary page customizations that will be used to monitor the invisibility and non-editability. To execute these customizations, you need to have the Application Builder license. We recommend you to add, test and accept the customizations in a test environment.

Note!: filtering for visibility works only when default editable is unchecked (false) on the dataset security.

Using dataset security you can filter lines from a table presented on a page for default NAV-tables using eventing. This can be extended to any table desired by adding the pages on which custom visibility is necessary to code unit 2C Page Event Subscribers (id 11112024). To add a page, a function OnOpen(page name) coupled to the code unit. Configuration and code can be duplicated from functions for other pages. After any change the code unit needs to be compiled. Furthermore, the dataset security needs to be set up with dataset type Visible as if for regular NAV-objects and the NAV-client needs a restart before a change in this configuration works.

Example:

LOCAL [EventSubscriber] OnOpenPageLocationList(VAR Rec : Record Location)
Rec.FILTERGROUP(200);
RecRef.GETTABLE(Rec);
FormSecurity.SetFormFilters(RecRef);
Rec.SETVIEW(RecRef.GETVIEW(FALSE));
Rec.FILTERGROUP(0);

Field security has the ability to hide values from certain fields for users, i.e. present an empty field instead of the value it actually has. This does not work with eventing, but requires the same modification of objects as for Dynamics NAV 2015 and older.

For versions of NAV without eventing and (at the moment) editability of fields in any version, customizations are necessary.

There are two options to customize pages:

Transformation from form to page: for the correct adjustments in the form see Customization for Field and Dataset Security (Forms).
Customize the page manually: follow the instruction below.

1. Determine the page(s) and field(s) that need to be customized. Keep in mind that the number of customized pages should be minimized to avoid conversion issues during upgrade of your software.

Keep in mind that you might need to modify multiple lists and cards which present the same information.

2. Open the relevant Page in the Page Designer (Ctrl+F2).
3. Add a global variable (type Boolean) for each field you want to control:

For example: Vendor No.Editable

<Fieldname>.Editable;
<Fieldname>.Visible;
<Fieldname>.Enabled;
<Fieldname>.HideValue.

4. Set the attribute IncludeInDataset of the above variables to Yes.

5. Set in the trigger OnInit these Booleans on TRUE: For example: “Vendor No.Editable”:= TRUE ;

6. Assign the new variables to the properties Visible, Enabled, Editable and HideValue for each field you want to manage editabiliy / visibility of.

7. Add a new function called “SetFormSecurity”.

Create the Parameter:
- “OnOpenForm”
  - DataType = Boolean
Create the Local Variables:
- “RecRef”
  - DataType = RecordRef
- “FormSecurity”
  - DataType Codeunit
- Subtype = “2C Form Security”

Follow the instructions below if you want to add the possibility to make fields non-editable and not visible with Field Security.
Note that you have to add the code per field.

1. Add the code below to the newly created function SetFormSecurity, based on this example on the field Vendor No. on Page 30 Item for the RTC.

Note! Make sure that the EDITABLE property of a field is always set before the VISIBLE property.

Visibility for Dataset Security

To add the code to use the visibility option in Dataset Security follow the instruction below:

1. Add at the end of the function “SetFormSecurity” the following code:

1. Add at the end of the trigger OnOpenPage the code:

2. Optional: if in the trigger OnAfterGetRecord existing code is adjusting the visible and editable properties of the protected fields or one of the filter fields. Add at the end of the trigger the code

Note! Calling the function SetFormSecurity () from this trigger can have negative effects on performance. If this is disturbing, the real necessity of calling this function from the trigger should be reconsidered (and possibly removed) or you can opt for a “second” smaller SetFormSecurity () function in which only the relevant fields are checked.

3. Update the section Documentation by adding the following:.

4. Compile and test the page.

5. Check the modification after setting up the secured fields.

This paragraph describes the necessary page and form customizations that will be used to monitor the invisibility and non-editability. To execute these customizations, you need to have the Application Builder license. We recommend you to add, test and accept the customizations in a test environment.

1. Determine the form(s) and field(s) that need to be customized. Keep in mind that the number of customized forms should be minimized to avoid conversion issues during upgrade of your software.
2. Open the relevant Form in the Form Designer (Ctrl+F2).
3. Add a new function called SetFormSecurity.

Create the Parameter:
- “OnOpenForm”
  - DataType = Boolean
Create the Local Variables:
- “RecRef”
  - DataType = Record Ref
- “FormSecurity”
  - DataType Codeunit
  - Subtype = “2C Form Security”

Follow the instructions below if you want to add the possibility to make fields non-editable and not visible with Field Security.
Note: You have to add the code per field.

1. The example below is applicable to the field Credit Limit in form 21 Customer for the Classic client.

Note! Make sure that the EDITABLE property of a field is always set before the VISIBLE property.
Note! Use the correct transformation rules when transforming a form to a page and make sure that code per field consists of two lines. The second line starts after the :=.

To add the code to use the visibility option in Dataset Security follow the instruction below:

1. Add at the end of the function “SetFormSecurity” the following code:

1. Add at the end of the trigger OnOpenForm the code:

2. Optional: if in the trigger OnAfterGetRecord existing code is adjusting the visible and editable properties of the protected fields or one of the filter fields. Add at the end of the trigger the code

Attention! Calling the function SetFormSecurity () from this trigger can have negative effects on performance. If this is disturbing, the real necessity of calling this function from the trigger should be reconsidered (and possibly removed) or you can opt for a “second” smaller SetFormSecurity () function in which only the relevant fields are checked.

3. Update the section Documentation by adding the following: