Field and Control Security - Cost Control Software

Field and Control Security 

Field & Control Security is a 

trigger-based security function. It 

can be used to enhance the 

Security Roles and Permissions 

provided by Navision, or in 

conjunction with any clientspecific 

roles, permissions, and 

modifications. 

Field & Control Security gives 

security control to individual 

Navision objects, including 

tables, forms, buttons on forms, 

and even specific fields within a 

form. 

In the example shown here the Bank Account Number is the only field desired to 

have security on. When the user tries to change the Bank Account Number to 

something different the Yellow Warning Dialog Box Pops up on the screen. 

Typically the administrator would come to the user’s screen, enter the Admin ID 

and Password to enable the change. The user could also just hit Cancel. An 

access attempt would be entered into the Log. 

For another example, Navision will allow all employees access to the Sales 

Order form, but Field & Control Security will require managers permission to 

change the Unit Cost field, all using the same form. Note: The user does not 

have to exit the form to get this done. 

Field & Control Security allows a variety of security responses. 

1. Just allow or deny access based on user login code. 

2. Dialog Box, Allow access if authorized login is entered with password. 

3. Dialog Box, Allow or deny access, and log login codes. 

4. Dialog Box, Allow or deny access, log login codes and edited field 

values. 

5. Each type of response can be specific to the secured area. 

Benefits: 

1. Higher Levels of data protection. 

2. Log entries of who, what, when changes were made. 

3. Different Managers can control different fields.

There are three areas within this documentation for your review: 

A. Installation – Importing the new objects and running the “setup” process. 

B. Setup and Test Data – Review the test forms and security created. 

C. Programming – Creating your own security. 

Installation Instructions: 

PLEASE READ ENTIRE INSTRUCTIONS BEFORE BEGINNING. 

THE INSTRUCTIONS AND OBJECTS INCLUDED HERE ARE FOR 

USE WITH A 3x and 4x Navision DATABASE. 

These instructions require a working knowledge of the C/SIDE development system. 

Add-on object files will arrive with all objects necessary to run the add-on including the 

dependencies. We bundle all add-on products that are needed to work together. This 

allows a one time installation of all the necessary objects. 

The following is a list of all objects that will be modified when Field and Control 

Security is fully implemented. 

1. Import the object “FC Security.fob”. 

Type Count ID Name 

Table 1 14005118 FC Security Controls 

Table 2 14005119 FC Authorized User 

Table 3 14005120 FC Where Used 

Table 4 14005121 FC Security Setup 

Table 5 14005122 FC Access Log 

Form 6 1 Company Information 

Form 8 14005230 FC Authorization Dialog 

Form 9 14005231 FC Security Control Card 

Form 10 14005232 FC Security Control List 

Form 11 14005233 FC Authorized Users 

Form 12 14005234 FC Where Used 

Form 13 14005235 FC Function Test Form 

Form 14 14005236 FC Access Log 

Form 15 14005237 FC Security Setup 

Form 16 14005238 FC Access Log (Wide) 

Report 17 14005118 Purge Access Log 

Report 18 14005119 Access Log Report 

P:\Click here for Manuals\Field_Control Security Instructions.doc 10/13/09 

2

Instructions for integrating Sales Field and Control Security into your 

Database— 

Before starting, you will need to determine a couple of things about your 

database. 

• IMPORTANT: Compile ALL existing objects before starting the installation. Resolve 

all compiling errors before starting installation. This assures that when you compile 

objects after the installation, any compiling errors at that time will be caused by the 

installation and not something before the installation started. 

• Determine if any of the above listed objects have been modified in the database in 

which you are going to add Field and Control Security. This is easily accomplished 

by starting an import of the appropriate fob file and looking at the import worksheet. 

• Even when there are no conflicts you will need to import the .FOB file in two(2) 

passes. 

1. Once the Worksheet is open, go to the Action column and select SKIP on all the 

“base” Navision objects, and make sure the Higher numbered objects 

(14004000+) have the “Create” or “Replace” action and then select OK. 

2. Next do the File, Import process again on the same .FOB file. This time use the 

“Replace All” Button to flag ALL the objects with the Replace action. This will 

guarantee that all of the objects in the .fob actually get imported. 

• WE HIGHLY RECOMMEND THAT YOU READ OUR TIPS AND WARNINGS 

PAGES LOCATED AT THE BACK OF THIS DOCUMENT BEFORE STARTING. 

• If this is the first time that you are importing Field and Control Security, then the only 

objects that may have conflicts are the base Navision objects. If you find that you 

have modified the same base Navision objects then you will need to manually 

integrate the Field and Control Security changes found in those objects. To assist 

the manually integration process we have supplied a detailed Change Log. 

• Files available for importing are: 

Field and Control Security Objects.fob 

Start by importing this one file. It contains all the Field and Control Security 

objects and all dependant addon objects. If you have conflicts. Then use the 

following Change Log to read about where the modifications exist and manually 

integrate the changes. 

1. Copy the supplied “fob(s)”, Documents (This manual), and optionally any 

provided sample databases to your local hard drive for integration and testing. 

2. Start Microsoft Business Solutions-Navision. 

3. Open the database that you are integrating into. 

4. Go to Tools, Object Designer 

5. Go to File, Import 


3

6. Go to provided “fob” - Field and Control Security Objects.fob 

7. Select Open 

8. You should get the following message. 

9. Say NO. Open the Import Worksheet for review. (always) 

If none of the objects listed above have been modified in the target database you 

can import the object file. When you start the import, you will get a different 

message than the one shown above that states that no conflicts were found, select 

yes to import the objects immediately or select no to open the Import Worksheet. It 

is recommended that you select no so the Import Worksheet will open in all cases. 

Once the Worksheet is open, select “Replace All” and select OK. This will guarantee 

that all of the objects in the .fob actually get imported. 

You will get a worksheet that looks like this: 


4

If there are conflicting objects the Import Worksheet will indicate which objects are in 

conflict. If you have any conflicting objects make a list of these objects. These are the 

objects you will have to hand integrate the Field and Control Security changes into. 

Instructions for hand integration of individual objects can be found in the Change Log. 

If some, but not all, of the above listed objects have been modified in your database you 

can import the ones that have NOT been modified by using the Import Worksheet to 

indicate which objects to replace and which objects to skip. Choosing replace next to an 

object in the Import Worksheet will cause that object in your database to be replaced by 

the import object of the same number. Choosing skip will prevent the object in your 

database from being replaced. Select “replace” for all objects NOT on your conflicting 

object list and select “skip” for all objects ON your conflicting object list. Using the 

merge option is not recommended as a means of dealing with modified objects. 

Using this option could make your task much harder. 

10. Select OK ONLY after you have decided to Replace All, OR you have edited the 

Action column on the import worksheet. (Reminder: Please read our Tips and 

Warnings about Navision’s Import process at end of this manual.) You must 

remember the objects that you selected to be skipped due to conflicts, so that 


5

you can manually integrate the changes later. (Write them down now or take a 

print screen.) 

11. After saying OK, the Navision Import dialog box will say: create: X and replace 

XX. 

12. At this stage there are new tables, forms, and reports added to your database. 

But they have no data in them. 

13. If you were able to import and replace ALL objects then Compile all the objects. 

Problems or objects that were not able to be compiled will be “marked”. Use the 

View, Marked only choice from the tool bar at the top of the Navision screen 

while still in the Object Designer. If you exiting object designer will remove the 

marks!! And you will have to compile again to know which objects failed. 

14. If there were Conflicting objects or compile errors, please continue reading and 

compare the Change Log to the database objects. 

15. If there are not conflicts or compile errors then you have completed the 

installation and you can skip the change log area and continue on with the Addon 

Setup & Workflow section. 

WE HIGHLY RECOMMEND THAT YOU READ THE 

INSTRUCTIONS ALL THE WAY THROUGH BEFORE STARTING. 


6

Initializing and Testing Field and Control Security: 

A. Initialing First: 

1. After importing the objects you need to add access to to Field and Control Setup on 

the Navigation Pane or Menu Tree. Our suggestion is the following: First select Tools, 

Navigation Pane Designer then setup the following. 

Company: Administration 

General Menu Group: 

Right click to action options 

Select Create Menu Item – enter as seen below 

2. The result will be the following: 


7

3. The next step in setting up Field & Control Security is to run Initial Setup. After 

saving your menu changes, go into the Field & Control Setup. On that form you will 

find the “Initial Setup” button which reveals a drop down menu with two choices: 

• Initial Setup - This choice will run the Initial Setup process described 

below. 

• About Initial Setup - This choice displays a message window describing 

the purpose of the Initial Setup process: 

• The Initial Setup will create five permissions records. These 

permissions must be added to a universal Group, one that all users 

share. By default, the Initial Setup process adds these permissions to 

the ALL Group. 

• The following permissions include Read and Execute permissions 

only: 

• Table Data 14005118 FC Security Controls 

• Table Data 14005119 FC Authorized User 

• Table Data 14005120 Field Security Setup (Table) 

• Table Data 14005121 Field Security Setup (Field) 

• Table Data 14005123 FC Where Used 

• The following permission includes Read, Insert, and Execute: 

• Table Data 14005122 FC Access Log 

• The Initial Setup process will also create a sample Field & Control 

Security for use with the Field & Control Test Form. This form is 

provided to offer samples of where to use the Field & Control Security 

function calls. The User Group that is created for testing purposes with 

the sample function is SECURITY. 

• After the Initial Setup has been run you will not be able to run it again. 

A message will appear stating that the process has already been run. 

4. Run the Initial Setup process by clicking the Initial Setup button and choosing 

Initial Setup. The following window appears: 


8

Choose Yes. 

4. When the following message appears, click OK. 

B. Testing Field & Control Security 

From this setup form, choose the Field and Control Security button, and then List. Notice 

that the initialize function created two Security Controls, 1) Company Info and 2) Field 

Control Test. Select a different control or Esc back to the Card view. The card view 

contains the criteria chosen for the security test and demonstrates how the options will be 

displayed for your security choices. 


9

There are three tabs on this form. 

• On the General Tab, the following fields are available: 

• Function ame - This is the name of the Field & Control Security 

being created. This is also the primary key that is used when the 

function call is referenced from the appropriate object. 

• Description - Enter a brief description of the purpose of this Field & 

Control Security. 

• Dialog Message - When the password prompt appears, the message 

entered here will be displayed on that form. 

• Error Type - There are three choices: 

• User Defined - This allows the user to enter the specific 

message to be displayed upon denial of access. 

• Generic - The system displays a standard “You do not have the 

correct permissions” error. 

• o Message - This option is used with the function call 

RestrictedWithoutErrors to allow users to define in code 

exactly what happens when unauthorized users try to access 

restricted areas. 

• Error Message - If a “User Defined” error type is selected, enter the 

message to appear when access is denied. 

• Log Access – Choose the option for logging entry attempts specific to 

this security card: 

• Do not log 

• Password Access Only 

• All Authorized Access 


10

• Unauthorized access only 

• Password Access and all unauthorized attempts 

• All Attempts & Accesses 

• Secure - This boolean field determines whether the restriction defined 

here is active. A check indicates that the security is on; no check 

indicates that any user will be considered authorized. 

• The Authorized Users Tab displays the list of Groups and or individual 

users with permission to perform this specific action. The user type field 

allows selection of either group or user. Authorized user field looks up to 

the Groups List or user list dependent upon the type field. Note that users 

who have any of the listed groups in their permissions will be considered 

Authorized Users. SUPER users are not restricted at all. 

Special Note for Windows Authentication: The popup dialog box has a 

login and password entry for access. If you wish to use the password 

feature you will have to setup a login and password in the Database Login 

table. 

Suggestions: You may wish to setup a “special” windows login that can 

be used in the dialog box. The “special” login would be given the 

permissions to get through the dialog box for a given area. If the user 

knows the “special” login, then they have been given access permission 

just like if they were given a password. The difference is that the special 

windows user access does not need to enter a password. Of course you 

could have a “special” database login access too, and with the database 

logins you can also have a password. 

• The Where Used Tab – This is a manually entered information tab. It 

should displays which fields or control buttons are secured on the table 

corresponding to the Field and Control Security function. This would be 

like the Credit limit, Payment terms, and the Customer Posting Group for 

th Customer function pictured above. 

Setup Button: 

The setup Button gives you one choice to Tables. This works in a similar 

fashion to Navision’s Change Log setup. If the security control will be on certain 

fields in certain tables then you will come here to select the Table, fields, and the 

security type (or security function) that will control the security response. You 

will read more about the security functions later in this document. 

Access Log Button: 

The Access Log Button provides two(2) choices. You can view just the 


11

logged entries for this specific control or view logged entries for all security 

controls. There will only be logged entries when you choose to use a security 

“function” that logs entries. You will see more on the security functions later in 

this document. 

Testing with F&C Sample Test Form: 

Run Form 14005235 to test the security setup created during initial setup. Try entering 

into the Test Code field and the Test Name field. Are you authorized? Can you enter an 

authorized name to allow you entry? What does the log display? There are also test 

buttons at the bottom of this form for demonstration purposes. 

Testing in the application: 

If you have installed the change log changes to form #1, you will also find examples of 

using Field & Control security in the Navision application, Form #1 “Company 

Information”. Depending on how you are logged in you will get difference responses. If 

you are logged in as a user with “super – all permissions” rights or a group/role that has 

been entered into the F&C Security Setup area with permission, you will notice no 

responses. Set up a user without SUPER or SECURITY group privileges and log in 

again as that user. Go to General Ledger, Setup then select the company information 

form. Select the Company button. Then select Responsibility Centers. You will get the 

F&C dialog box. If you continue by typing the unauthorized user name then you will not 

get in. If you type the super user name you will. Access and unauthorized access is 

being recorded in the F&C Log file. Notice that there is code on the OnPush trigger of 

the Responsibility Center menu choice that calls F&C Security. This code does require a 

global variable. 

NOTE: You will not want to give out a user ID that has the SUPER - all permissions or 

SECURITY group, so you will want to start setuping up new User names that allow 

access to secured areas, or give access to specific users. You may want to setup several 

“pass word user names” that allow access to different areas so that knowing one areas 

access ID does not give you access to another area. 

Another area setup with F&C Security is on the same Company Information form but on 

a field. Go to the Payments Tab and try typing in a new Bank Account No.. If you have 

permission you will notice nothing. If you do not you will get the dialog box again. In 

this case the code trigging the F&C security is on the OnValidate trigger of the field 

control box on the form. This code requires the same global variable used for the 

Responsibility Center menu choice and a local text variable. 

The security on the Bank Account No. seems the same as the security on the 

responsibility but it has the added feature of recording the values being typed into the 


12

field for both authorized and unauthorized access. Check the F&C Security log to see the 

logged information. 

NOTE: We put the F&C security code on the form in this sample. If you are securing a 

field that appears in several forms and you want it secure it in the same way every time 

the field is available, then the F&C security code would most appropriately be placed on 

the OnValidate of the field at the table level instead of the form. 


13

Field & Control Dialog Form 

This is the form displayed when an unauthorized user tries to access an area that has been 

restricted. When an authorized user accesses a restricted area the Dialog Box does not 

appear. 

“The Dialog Message displayed in the Dialog Box” - This dialog is defined on the 

Field & Control Security Form in the Dialog Message field. If that field is left blank, the 

standard message “This is a Secure Function!” will appear. 

When an unauthorized user accesses a restricted area, the above-pictured Dialog box 

appears. The user must enter an ID and password. The system then tests the entered data 

and verifies that it meets the Authorized User requirements for this function. If the data 

meets the criteria (has a required User Group or is a required user), access is granted to 

this restricted area. The Log form records the unauthorized User ID and the Authorized 

User that was used to access the restricted area. 

If the ID and password entered do not meet the criteria, an error message is displayed. 

The message that appears is determined by settings in the Field & Control Security Form. 

The following message is a result of User-Defined Dialog Type and the contents of the 

Error Message fields: 


14

When an error message is received, the restricted user is denied access. 

C. Field & Control Security Function Defined: 

Minimal programming is required within the code of each object where security is 

needed. Function calls are available to the programmer in Table 14005118 . The 

following are brief definitions of the Secruity Functions (also called Security Types) and 

the type of security response they will trigger. It is important to understand these 

functions because they are what you place at the point of the security. More details on 

these functions will come next in the SETUP and Programming the Function Locations 

sections. 

1. gnboUserOK(pcoFunctioname : Code[30]) : Boolean 

Checks if the user can access this function. 

No authorization dialog is called. 

No error message is generated. 

No logging occurs with this function. 

2. gnboSecurityOKWithErrMsg(pcoFunctioname : Code[30]) 

Checks security and returns true if user has access 

If user does not have access it brings up a dialog box requesting an authorized user 

ID and password 

Then generates an error if access is denied. 

3. gnboSecurityOKoErrMsg(pcoFunctioname : Code[30]) 

Checks security and does not generate it’s own error and returns false if access is 

Denied and the programmer must trap for the error. 

4. gnboSecurityOKTraceWithErrMsg(pcoFunctioname : Code[30];pteTrace : 

Text[120]) 

Checks security and generates an error if access is denied, otherwise it returns true. 

If user does not have access it brings up a dialog box requesting authorized user ID 

and password 


15

The extra pteTrace parameter allows record specific information to be recorded in the 

log whenever access is allowed. 

The pteTrace parameter allows a string to be created at the call which could 

include record number,line number,doc type,xrec etc. 

example: pteTrace could be -- rec.tablename +' '+ rec."no." +' '+ 

format(rec."line no.") +' '+ xrec.cost +' '+ rec.cost etc. 

5. gnboSecurityOKTraceoErrMsg(pcoFunctioname : Code[30];pteTrace : 

Text[120]) 

Checks security and does not generate an error and returns false if access is denied 

and the programmer must trap for the error. 

If user does not have access it brings up a dialog box requesting authorized user ID and 

Password. 

The extra pteTrace parameter allows record specific information to be recorded in the 

log whenever access is allowed. 

The pteTrace parameter allows a string to be created at the call which could include 

record number,line number,doc type,xrec etc. 

example pteTrace could be -- rec.tablename +' '+ rec."no." +' '+ format(rec."line 

no.) +' '+ xrec.cost +' '+ rec.cost etc. 

6. gnboVisibleOK(pcoFunctioname : Code[30]) : Boolean 

Allows a control's visible property to be set according to the security access of the user 

No authorization dialog is called. 

No error message is generated. 

No logging occurs with this function. 


16

Field & Control Test Form 

You used the test form above, now lets look at what makes it work. 

Form 14005235 F & C Function Test Form was created to provide examples of how the 

function calls can be used. It is used in conjunction with the sample Field & Control 

Security created in the Initial Setup process. Remember that unless additional User 

Groups are added to the sample function, only users with the Groups SUPER and 

SECURITY can test the sample function. 

A global variable was added to this form as follows: 

ame: FieldControlT 

Datatype: Record 

Subtype: FC Security Controls 

The Field & Control Security function calls were placed in the OnValidate trigger of 

each field at the form level. 

1. Field: Test Code 

The following code was added to this field at the form level: 

OnValidate() 

FieldControlT.gnboSecurityOKWithErrMsg('FIELD COTROL TEST'); 

MESSAGE ('You have Access. Test Code was changed!\'+ 

'The function "gnboSecurityOKWithErrMsg" was used\'+ 

'Check the log and the textbox OnValidate code to see what happenned.'); 

• FieldControlT - This is the call to the variable added which looks to the 

FC Security Controls table. 

• gnboSecurityOKWithErrMsg - This function call tells the system that 

either a user-defined or generic message will be displayed if the correct 

Group record is not found. 

• ‘FIELD COTROL TEST’ - This is the primary key, instructing the 

system to use this record in the FC Security Controls table. At least one of 

the User Groups listed for this function must be present in the user’s 

Groups, or an authorized user, or an error message will be generated. 

• MESSAGE ('You have Access. Test Code was changed!\'+ 



17

'Check the log and the textbox OnValidate code to see what 

happenned.'); If this message appears, the user successfully passed 

the Field & Control Security test, based on that user’s Groups or user 

name. 

• Test Boolean and Option 3 are setup with the same code as the Test 

Code field, however, may have different messages. 

2. Field: Test ame 

The following code was added to this field at the form level: 

OnValidate() 

oteOldTestame := gteTestame; 

IF OT FieldControlT.gnboSecurityOKTraceoErrMsg('FIELD 

COTROL TEST',TABLEAME+ ' Testname is '+gteTestame+' 

testname was '+ oteOldTestame ) 

THE BEGI 

FieldControlT.gnnrLogAccess('FIELD COTROL TEST',USERID,'Tried to 

change '+ oteOldTestame ); 

ERROR('You do not have access\'+ 

'The error is being handled on the form and traced.\'+ 

'The function "gnboSecurityTraceoErrMsg" was used\'+ 

'Check the textbox OnValidate to see what happenned.'); 

ED; 

MESSAGE('You have Access. Test ame was changed!\'+ 

'The function "gnboSecurityTraceoErrMsg" was used\'+ 

'Check the log and the textbox OnValidate code to see what 

happenned.'); 

• FieldControlT - This is the variable for the FC Security Controls table. 

• FieldControlT.gnboSecurityOKTraceoErrMsg- Notice that when using 

this function call, it is necessary to enter the error message the system will 

display. 

• ‘FIELD COTROL TEST’ is the primary key for the record in the FC 

Security Controls table. 

• Error() - Enter the error message to be displayed. 

• When using this call, it is possible to enter other code prior to displaying 

the error message. 

• The Option 2 was setup with same function call as Test ame. 


18

3. Test Buttons 

When using Field & Control Security on a button, it’s important to make the 

following change: 

• Move any existing “Push Action” property code into the “On Push” 

trigger of the button, making sure to remove all “Push Action” code. 

“Push Action” code occurs prior to the “On Push” trigger code. If there is 

“Push Action” activity, this will occur before the Field & Control 

Security call, thereby not restricting any of that activity 

Test Button 

The Test Button has the following code in the “On Push” trigger. All 

“Push Action” code was removed. 

OnPush() 

FieldControlT.gnboSecurityOKWithErrMsg('FIELD COTROL 

TEST'); 

MESSAGE('You have Access. Test button was pushed!\'+ 


'Check the log and the Test Button OnPush trigger code to see 

what happenned.'); 

The code entered on this button is the same code used in the Test Code field. 

Test Menu 

The call for this button was placed in the “On Push” trigger of the Test Menu 

Item menu item. All “Push Action” code was removed. The code is the same 

code used for the Test ame field. 

OnPush() 

FieldControlT.gnboSecurityOKWithErrMsg('FIELD COTROL TEST'); 

MESSAGE('Test Menu Item was selected!'); 

Field & Control Security is a powerful tool and can be used in many ways. Navision 

security Roles (Groups) can be created with certain Permissions and then used in 

conjunction with Field & Control Security. Using this tool, it’s possible to allow or 

disallow many users or a single user, access to any part of Navision, no matter how broad 

or specific the activity. 


19

Check out another Example: You by now have experienced F&C 

Security on the Company Information form. 

Using a Database Login that does NOT have the SUPER or SECURITY Roles, go to the 

General Ledger Menu. Click the Setup. Select the Company Information choice. In each 

of the following points, go to the code areas and find out what F&C Security function was 

used. Make sure you understand the results in each case. 

1. Click on the Company button, then Responsibility Centers. What happens? Enter 

the Login ID into the Dialog box. Enter the password if the login has a password. What 

happens? 

2. Esc out of the Company Information screen and then Click back into GL Setup. This 

time take the Fields & Control Setup choice. Click the Fields & Control Security button, 

than List. Select the Company Info Control then click FC Secured Functions Button and 

then the Access Log. Was the attempted entry into the Responsibility Centers area 

logged? What does the log entry tell you? 

3. Esc out again and Go back to GL Setup and Company Information. Go into the 

Designer. Can you find where the field and Control Security function call is placed? 

Hint: Where is the Responsibility Centers called? If you have an unmodified 3.01 

database, compare how Form 1 differs in the way it calls the Responsibility Centers. 

4. Next test: Go back to the Company Information form. Go to the Payments Tab and 

attempt to chance the Bank Account No. field. Did you have authorization? Why or 

why not? If you had authorization was your entry logged? Check out the access log for 

the ‘COMPANY INFO’ FC Security Control. Try a user id without authorization and 

one with authorization then check out the log. Where is the security function called for 

the Bank Account No. field? 

This ends the example of FC Security on the Company Information form. 


20

SET UP: 

There are 10 Steps to setting up F & C Security. 

1. Read the documentation carefully. 

2. Setup user logins. At least one needs to be assigned the Super role. 

Suggested: Login Roles 

SUPER SUPER …..…will get access 

RICK ALL 

SUPER(Data) ……..will not get access 

BOB ALL 

SUPER(Data) 

SECURITY …..will get access because it was 

entered into the F&C Setup 

NOTE: We highly suggest that you setup totally new security groups/roles that will give 

permissions into specific areas vs using the SECURITY role. In fact the Initialize on the 

Field & Control Setup will add an example of a User Login called ADMIN with a 

security role of ADMIN. You can NOT login into the database with this ADMIN login. 

It is simply used as a field and control access login. We did not give the ADMIN user a 

password, but in normal security situations it should have a password. 

3. Import the F&C Add-on objects and follow the Initial Setup instructions. 

4. Test the Sample form and study the Sample Test Control and Functions being used. 

5. Select and “list” the places that you want security. Use the Security worksheet. 

6. Setup some new Security Controls. Practice with two(2) and then create more. 

7. Select the Security Functions that are appropriate for each security location. 

8. If the security is on fields then click the Setup/Tables button on the FCSecurity 

Controls Card. Select the table, then select which fields in that table will be secured, 

with which Security Control and Security Type(security function). 

The Starter Database uses the Customer table, and secure the Credit Limit (LCY) and 

Payment Terms fields. We use Security Type 4 on the Credit Limit field, and type 1 

on the Payment Terms field. 

9. Next add the security trigger code to the table, or form at the secured field’s or 

control’s access point. Like the OnPush for menu items, and the OnValidate of 

fields. 

10. Log out then back in as a user that does not have automatic access to the secured 

areas. Test entring a new credit limit or payment terms. Check the 


21

A database user login that is assigned the SUPER role is always allowed permission. 

However, Security Functions that log the entries will also log entries for SUPER users. 

Report: “Access Log Report” (R14005119) (Found on Access Log Window) 

This report is a hard copy for the system administrator of the attempt log. 

Report: “Purge Access Log” (R14005118) (Found on Control List) 

This is a process report that enables you to delete old entries from the Access Log. 

The following Security Worksheet is a manual log of how you plan to setup Field and 

Control Security. We highly recommend that you start with a plan before addressing the 

computer. 


22

Security Worksheet: 

Security Location Form ID Table Security Control Security Function 

ID ID 

GL, Setup, Co. Info, Co.Button #1 COMPANY INFO SecurityOKWithErrMsg 

Responsibility Centers Menu Line 

(access dialog box only) 

GL, Setup, Co. Info, Payment Tab #1 COMPANY INFO SecurityOKTraceWithErrMsg 

Bank Account No. field 

(dialog box and access log) 

Sales & Receivables, Customer 

#18 COMPANY INFO 4, (access dialog box and full 

Table, Credit Limit (LCY) 

access logging) 

Sales & Receivables, Customer 

Table, Payment Terms 


#18 COMPANY INFO 1, (blocks access to non 

authorized logins) 

23

Security Location Form ID Table 

ID 

Security Control 

ID 


Security Function 

24

Setting up more Security Control Codes: 

How do you decide whether to use an existing Security Control Code or to create a new 

one? There are several factors to consider. 

1. One consideration is WHO is given access? If there are several fields on the 

Customer Card that will have the “same” user (LOGIN) or user 

group(ROLES) access, then you may just want to setup a CUSTOMER 

CARD CONTROL. 

However, if one field has different authorizations then another field, then you 

will need to setup separate Security Control Codes. 

2. Another consideration is if errors and messages need to be specific to the 

secured area. 

3. The third consideration is if you are interested in logging the accesses and the 

unauthorized attempts. 

The security log is maintained by each Security Control. If you use one 

Security Control for several fields on the Customer Card then the log will comingle 

the field access. 

If you thing you will want to see all the access or attempts for a particular field 

separated from the accesses and attempts of other fields then it would be better 

to setup separate Security Controls for those fields. 

An Example: Security on the Commission % field on the Salesperson List Form. 

Security Control (General Tab) 


25

Security Control (Authorized Users) 

Only Users assigned the Security or S&R-Setup Role will be allowed access to editing the 

Commission percent field on the Salesperson card. You could have selected only the 

S&R Setup Role too, or just the Security Role, but you must assign at least one 

Authorized User or Authorized Group. 

Once you have setup the Security Controls, next you select the tables and fields that 

need security access. Go to the Setup button and select Tables: 


26

Next you will see the following screen which is a list of tables: 

You will either leave the table blank (no security needed) or you will select “Some fields” 

or “All Fields”. 

The edit assist … box will bring up the list of fields in the table if you have selected 

either Some or All fields. 

Here you check if security applies and what Security Control to use and the Security 

Type. The Security Type is directly related to the following information on the Security 

functions. 


27

To finish the Setup using the Table and Fields selection, you need to put the following 

code in the OnValidate trigger of the field in the tables. The code is the same regardless 

of the field. 

First add the following global variables to the table: 

Name DataType SubType Length 

FCSecurityControlT Record FC Security Controls 

RecRef RecordRef 

xRecRef RecordRef 

Then add the following code to the OnValidate trigger of each field secured. 

Credit Limit (LCY) - OnValidate 

//FCSecurity 

RecRef.GETTABLE(Rec); 

xRecRef.GETTABLE(xRec); 

FCSecurityControlsT.TriggerSecurity(RecRef,xRecRef); 

If you want to make the security specific only to certain forms then you don’t put the code 

on the at the table level, but instead put the code on the form. If you want the security on 

“Credit Limit (LCY)” on the customer card then you open the Customer Card with the 

“Designer”. Next click on the Credit Limit (LCY) control box and then F9 to the code 

area behind the code box. Place the exact same code as above in the OnAfterValidate 

trigger as seen below. 

First add the following global variables to the form: 


FCSecurityControlT Record FC Security Controls 

RecRef RecordRef 

xRecRef RecordRef 

OnAfterValidate 

//FCSecurity 

RecRef.GETTABLE(Rec); 

xRecRef.GETTABLE(xRec); 

FCSecurityControlsT.TriggerSecurity(RecRef,xRecRef); 

The code must be placed behind each control box you wish to secure. 


28

ALERTS: 

1. You can use any Security Type Function on almost any field. However there are 

some circumstances that you will want to consider. Security on a menu item would not 

use a logging function since it is just access at that point. No data has been changed. 

2. When logging access and changes of Option fields, you need to understand that the 

option value is returned as a number in the security log when using Security Type 

Functions 4 and 5. The first option choice will appear as a zero, the second option 

will appear as a 1, and so forth. 

3. If you secure fields that have long text values such as Name, Address, and email 

address then you should use the lower number Security type functions that don’t try to 

log the entire field’s before and after value. 

Security Type Functions: Types of Security Responses: 

The following examples represent Security Functions. There are five types. These 

functions determine how the Security Control Code will be used and the security 

response. Each field or control that is being secured only needs to use one of the 

following five functions. 

These Functions are already programmed. They do the work of checking for 

authorization by user(login) or group(role), calling a security dialog box and creating the 

security log. Your task to setup Field and Control Security is to select which Security 

Function to use and to place it on the table, form, or control Textbox where security is 

needed. 

1. gnboUserOK : 

2. gnboSecurityOKoErrMsg : 

3. gnboSecurityOKWithErrMsg : 

4. gnboSecurityOKTraceoErrMsg : 

5. gnboSecurityOKTraceWithErrMsg 

6. gnboVisibleOK : 

Call the Dialog Box 


29

Security Function # 1, does not call the dialog box and does not log activity. It checks 

for authorization only and returns a simple ERROR dialog, controlled on the trigger of 

the secured area. 

Security Functions 2 through 5 call a Security Form (or Dialog Box) that allows you to 

enter an authorized userid and password to gain access. It is possible to be logged into 

Navision as Joe and know that you must type in UserID Mary into the Security Form 

with no password to gain access. Passwords are an optional requirement. Passwords 

however are required if the Database Login (such as Mary) requires a password. The 

following is how the Security Form appears. 

The “Dialog Message displayed in the Dialog Box” is controlled by what is entered on the 

Security Control. The above is what is displayed when you use the sample Security 

Control called ‘FIELD CONTROL TEST’. 

If the User Login ID has permission the Dialog Box is not activated. The user is just 

allowed to continue. Even though the permission was automatically given and 

depending on the Security Control’s Log Access, a log record of the access will still be 

recorded. 

TRACE functions: (Functions # 4 and 5) 

The Security Functions with the “Trace” term in the name 

[gnboSecurityOKTraceWithErrMsg] and [gnboSecurityOKTraceNoErrMsg] give more log 

information then the Functions without the “Trace” such as [gnboSecurityOKWithErrMsg] 

and [gnboSecurityOKNoErrMsg]. But the “Trace” functions require more code at the form 

level which provides the extra information. 

All four (4) security functions “offer” (not require) the security feature 

of logging the accesses and attempts to access a secured area. As 

mentioned above the Trace functions offer more information on the log 

such as value before and after the change. 


30

There are some places that it doesn’t make sense to store more access information with 

the Trace function. For instance, we did not use a Trace function when setting up the 

sample security on the access to the Responsibility Centers on the Company Information 

Form. But we did use a Trace function when securing the Bank Account No. field. If 

the Bank Account No. field is edited, we wanted to know the Bank Acount No. before the 

change and the value after it was changed and of course when it was changed. 

WITH functions: (Functions # 2 and 4) 

The Security Functions that include a “With” term in the name such as 

[gnboSecurityOKWithErrMsg] and [gnboSecurityOKTraceWithErrMsg] are using the 

responses setup on the Security Control Card. The “No” functions 

[gnboSecurityOKNoErrMsg] and [gnboSecurityOKTraceNoErrMsg] are using the 

ERROR messages programmed at the point of security where the function is called. 


31

Programming Security on Buttons: 

Security on command buttons will use the following: 

As you read previously, fields can be controled by using the Tables 

setup form in GL Setup, Field & Control Setup. However, if you want 

more text in messages then you would use Options 3 or 5 and place the 

security trigger code at the point of security instead of using the tables 

setup. 

Control buttons do not log changed values like can be done with fields. 

They also can not be setup using the Tables setup. The following code 

must be placed where the security is needed. Options 1, 2 and 3 are 

typically used for Control buttons. 

We have provided examples of each of the Security Functions. All the examples 

below are showing security used on the Credit Limit ($) field on the Customer Card. 

First step: is to add a C/AL Global variable to the form that contains the field or control 

being secured. 


FieldControlT Record FC Security Controls 

Second Step: Click on the TextBox of the field or control being secured. 

Third : F9 or click on the C/AL icon to go to the triggers area of the TextBox 

Fourth : Click in the OnValidate trigger area and add the appropriate function. 

Fifth : Add the following Local Variable to the OnValidate area: (only needed 

for the Trace functions #4 and #5) 


oteOldTestName Text 50 

We are making the assumption at this point in the documentation that you have already 

setup the Security Control Codes. If you have not, please read the remainder of this 

information and then go back and enter the Security Control Codes that you plan to be 

using. 

‘FIELD CONTROL TEST’ represents one of the sample Security Control Code that 

was setup as an example during the initialize stage of the Field and Control installation. 

You can use this security control (as seen below) to learn about the Field and Control 


32

functionality but we highly recommend that you setup security controls specific to your 

needs. 

Examples of Security Functions: 

1. gnboUserOK(‘…. Checks for Authorization Only 

The very simplest of security setup. o Dialog Box and o log. 

UserOK security function only checks for authorization to edit the field 

value. There is no Dialog Box asking for UserID and password. The 

error generated is coded on the form. 

Just as the other Security functions, this one is called on the OnValidate 

trigger of the field or control that is being secured. Follow the same 

first steps and then add the following code to the OnValidate trigger. 

Notice that User OK requires that you apply the security function in an IF statement. The 

response is coded at the point of security vs using the responses on the Security Control. 

OnValidate 

IF NOT FieldControl.gnboUserOK('FIELD CONTROL TEST') THEN 

ERROR('You do not have Access.') 

2. gnboSecurityOKoErrMsg(.. relies on programmer’s code on form 

Has a Dialog Box, Can log entries, logged entries are not detailed. 

Very similar to #2 however notice programmed IF statement with a specific error coded 

at the OnValidate location. This is coded similar to #1 (UserOK) but calls the security 

dialog box and can optionally log the access depending on how the Security Control is 

setup. 

Message can be User Defined Message if set to be User Defined on 

Control Card. 

Example: 

OnValidate 

IF NOT FieldControlT.gnboSecurityOKNoErrMsg('FIELD CONTROL TEST') THEN 

ERROR('You do not have access'); 

Type Log text: Authorized Access attempted Customer Credit Limit 

change. 


33

3. gnboSecurityOKWithErrMsg(.. gets code from a Security Control 

Has a Dialog Box, Can log entries, logged entries are not detailed. 

Message is set in code. “You do not have authorization.” 

Example: 

OnValidate 

FieldControlT.gnboSecurityOKWithErrMsg('FIELD CONTROL TEST'); 

Type Log text: Unauthorized Access attempted Customer Credit Limit 

change. 

4. gnboSecurityOKTraceoErrMsg(.. relies on programmer’s code on 

form 

Has a Dialog Box, Can log entries, logged entries can be detailed. 

Very similar to #4 however notice programmed IF statement with a specific error 

coded at the OnValidate location. 

Message can be User Defined Message if set to be User Defined on 

Control Card. 

Example: 

OnValidate 

oteOldTestName := FORMAT(xRec."Credit Limit ($)"); 

//oteOldTestName is a local varable which is text. So secured fields that are not 

// a text datatype must be converted to a text format. 

IF NOT FieldControlT.gnboSecurityOKTraceNoErrMsg('FIELD CONTROL TEST',TABLENAME+ 

' Credit Limit to '+FORMAT("Credit Limit ($)")+' CreditLimit was '+ oteOldTestName ) 

THEN BEGIN 

IF oteOldTestName = '' THEN 

oteOldTestName := 'Blank'; 

FieldControlT.gnnrLogAccess('FIELD CONTROL TEST',USERID,'Tried to change Credit Limit '+ 

oteOldTestName + ' to ' + FORMAT("Credit Limit ($)") ); 

ERROR('You do not have access'); 

END; 

Results: This actually triggers a response but the response comes from the 

programmer’s code on the form as seen above. 


34

5. gnboSecurityOKTraceWithErrMsg(.. gets code from a Security 

Control 

Has a Dialog Box, Can log entries, logged entries can be detailed. 

Message is set in code. “You do not have authorization.” 

Example: 

OnValidate 

oteOldTestName := FORMAT(xRec."Credit Limit ($)"); 

//oteOldTestName is a local variable which is text. So secured fields that are not 


FieldControlT.gnboSecurityOKTraceWithErrMsg('FIELD CONTROL TEST',TABLENAME+ 

' Credit Limit to '+FORMAT("Credit Limit ($)")+' CreditLimit was '+ oteOldTestName ); 

Results: Triggers a response that comes from what has been setup on the Security 

Control. 

Log Access: This method also responds to the “Log Access” setup on the Security 

Control. If the Log Access is set to trap Unauthorized only or All attempts then the Log 

entry looks like this: 

Type Log text: Tried to change Customer Credit Limit from 20,000 

CreditLimit to 0 

Log Access: The text sent to the log also comes from what is coded on the form. The 

following log text came from the above code. This choice has limited control by the Log 

Access setup on the Security Control that it calls. It responds to All Authorized Accesses, 

Unauthorized attempts and All Attempts and accesses. It will log entries regardless of all 

the other Log Access options. 

Type Log text: Authorized Access attempted Customer Credit Limit 

from 20,000 CreditLimit to 0 


35

Some examples of how the Log tracks security access. 

Other ways to use the Security Controls and Functions: 

Setting up the Security Controls will be the same. However, WHERE you place the call 

to the Security Function will make a difference. So far we have referenced putting the 

Security Function call on the OnValidate of the Field control, or on the OnPush of a 

Command Button or a Menu Button / Menu item. 

• Security on Forms: 

Placing a Security Function on the OnModify trigger on a form can also control 

who can edit. By placing the function on the form, than if any field is changed the 

security will be called. You can use Navision’s security to give a role read and not 

modify rights however Navision doesn’t give you the ability to call a dialog box. 

How this works: A user enters an editable form like Customer Card. They attempt to 

change any of the fields, it appears to let them change the values, but upon exiting the 

form, the authorization is checked and a dialog box is called (depends on the function 

used). If the user does not have authorization, all fields on the record reverts to the 

original values. 

• Security on Fields at the Table Level: 

Placing the Security Function call on the OnValidate trigger on the field within a 

table will cause the access to that table’s field to be secured on every form where that 

table’s field is called. 

• Security on the Table: 

Placing a Security Function on the OnModify trigger on a Table can also control 

who can edit the table records. By placing the function on the table, than if any field is 

changed on any form view of the table then the security will be called. 


36

It may appear like the user is allowed to edit, but upon leaving the record the security is 

triggered and the edited information reverts everything back if authorization is denied. 

You can use F&C Security on the OnInsert and OnDelete triggers of tables too. For an 

example you could setup one Security Control called ‘TABLE DELETE’. Use the 

generic message or create a user defined one that would work for several tables. Decide 

on the function to use and place the same security function call on the delete trigger on 

any table where you would like the security. Remember F&C Security not only controls 

the authorization but can log who is trying what. 

• Security on the VISIBLE Control: 

This controls WHO can change the VISIBLE properties of fields and controls. 

For instance, let us say that the Commission % field is designed onto the Salesperson 

form but has a property of VISIBLE “No”. In this condition, the Commission % field 

will be available on the View Menu bar for Show Column. You may want to give a user 

access to the form, but you do not want them to have the ability to make the Commission 

% field Visible. The Field and Control Security Advanced Function for controlling the 

Visible property will control this situation. Be aware that when a user is denied the right 

to make a field or control VISIBLE then they are also denied access to a Form that 

already has the secured field or control displayed (Visible). 

Set up the Visible Control as follows: 

1. Go to the form that contains the field or control that needs security. 

2. Go into the Designer mode on the form. 

3. Add the following Global variable to the C/AL Globals of the form. 



4. Click on the TextBox of the field you wish to secure. The example below is using the 

Zip Code field on the Customer List form. F9 or click the C/AL icon to go to the 

triggers of the field. In the OnFormat trigger put the following code. 

OnFormat 

IF CurrForm."ZIP Code".VISIBLE(TRUE) THEN 

IF NOT FieldControlT.gnboVisibleOK(‘FIELD CONTROL TEST’) THEN 

CurrForm."ZIP Code".VISIBLE(FALSE); 

5. Esc out and save your changes compiled. 


37

6. Test the control by logging in as someone that is not in the SUPER or SECURITY 

Roles. Go to the Customer List. Select View from the menu bar and then Show 

Column. Click on Zip Code. You should get the You do not have access message. 

If you get the “You do not have access” message just trying to view the Customer 

List, then that means the Zip Code is already Visible on the form. Normally by 

Navision default, the Zip Code is not Visible but can be made visible by clicking it on 

the Show Column choices. 


38

Time for you to setup security: 

Secure the “Credit Limit ($)” field on the Customer Card - Hint: The 

code used in the explaination of each security functions above was using the Customer 

Credit Limit ($) field as the example. 

1—Go to Form 21: Customer Card. 

2—Click on the TextBox control for the Credit Limit ($) field. 

3—F9, or click the C/AL icon to go to the trigger area of the field. 

4—Have this document open during this operation. Go to the section above where you 

see the samples of the Security Functions code. Copy the function code that you have 

selected from this document and then paste the code into the OnValidate() trigger of the 

Credit Limit ($) field. Depending on the security function that you selected you may need 

to edit the code to make it specific to Credit Limit ($). 

5—Exit and save complied. Exit the Customer Card form and return. Now try editing 

the Credit Limit ($) field. If you do not have access, where did the Error message come 

from? Was there a log entry to trace the edit attempt? What did the log tell you? 

If you had access, where did the messages come from? Was there a log of the edit? 

What controls if logs are made or not? What does the log entry tell you? 

What was it about your login that gave you access? 

6—Notice that we used the existing “Sample” Security Control Code called FIELD 

CONTROL TEST vs. setting up an entirely new Security Control called CUSTOMER 

CREDIT LIMIT. 

How do you decide whether to use an existing Control Code or to create a new 

one? Please review the section above that discusses the reasons for setting up new 

Security Controls. 


39

Support on this product: 

Your local Navision Solution Center will provide support. Please contact them with any 

questions or comments. 

Thank you for following the procedures. We certainly hope you will find great benefit in 

the functionality that this add-on products provides. On behalf of Navision Software, all 

Navision Solution Centers (NSCs) and Navision Service Providers (NSPs) we thank you 

for your business. Do not hesitate to contact your NSC if you are considering 

modifications or are in need of new software functionality. There may just be another 

add-on product that will work for you. Ask your NSC about getting a complete list of 

add-on available. 

Abbreviated list of other Add-on products: 

Business Snap Shot 

Calendar Views 

Defaults Setup 

Executive Summary 

Fast Find 

Field and Control Security 

Line Comments 

Quote Management 

Pop-up Notes 

Posted Line Lookup 

Purchase Resources 

Reports Pack (36 Reports) 

Status Views 


40

CHANGE LOG: 

Form # 1—Company Information: 

1—Add a Global Variable as shown below. 

Name DataType Subtype Length 


2—In design mode, click on the Company Menu Button. Go to View, Menu. Then 

select the Responsibility Centers menu item. Remove the RunObject Action property 

and (F9) to go to the C/AL code area of the menu item. Add the following code to the 

OnPush() trigger: 

OnPush() 

//Field and Control Security 

IF FieldControlT.READPERMISSION THEN 

FieldControlT.gnboSecurityOKWithErrMsg('COMPANY INFO'); 

FORM.RUN(FORM::"Responsibility Center Card"); 

3—Esc back to the form still in design mode and go to the Payments tab and click on 

the “Bank Account No.” field TextBox. Next (F9) to the C/AL code area of the TextBox 

and add the following code to the OnValidate() trigger: 

OnValidate() 

//Field and Control Security 

oteOldTestName := xRec."Bank Account No."; 

//oteOldTestName is a local variable which is text. So secured fields that are not 


IF FieldControlT.READPERMISSION THEN 

FieldControlT.gnboSecurityOKTraceWithErrMsg('Company Info',TABLENAME+ 

' Bank Acct # to '+"Bank Account No."+' Bank Acct # was '+ 

oteOldTestName ); 


41

Navigation Pane: 

1—Go into Navigation Pane Designer. 

2—Click on Administration. 

3—Click on application Setup. 

4—Click General. 

4—Insert the Field and Control Menu choice as shown. 

5—Use the following properties: 


42

Once all the changes have been made, COMPILE ALL objects again. If compile errors 

still exist, Navision will mark the problem objects and you will need to double check the 

integration in your database with the change log. If you are sure that all changes are in 

the database and compile errors continue please contact you NSC immediately. 


43

Field and Control Security - Cost Control Software

Create successful ePaper yourself

Delete template?

Save as template?