Is it true that Microsoft Business Solutions has purchased Omni Field Security?
Yes, Microsoft Business Solutions has purchased the Omni Security and Omni Field Security modules out of the Omni Tools suite for Release 7.00.  Until that time the complete 8 module suite is still available from Winthrop Dexterity Consultants and afterwards a 6 module suite will be released.

Please click here for more details of the announcements and timelines.

Can I achieve all my security requirements with Omni Field Security?
You could but it would be a large amount of work.  It is recommended that you use Omni Security to perform the bulk of your security configuration and then use Omni Field Security for the finer points, such as field or record level security.

Why doesn't Omni Field Security always work?
Omni Field Security uses triggers to perform specified actions as required.  These triggers are usually executed when the window is first opened or the window is restarted (after a Save or Delete).  It is possible that other code on the window is being executed after the Omni Field Security trigger and is undoing the changes made by Omni Field Security.  To get around this you may have to use a different action; for example: Hide instead of Disable, or Disable instead of Lock.  Also see the answer to the next question.

Why doesn't Omni Field Security work when accessing fields in tables or on other forms?
There is an issue with the default form and default window commands which means that accessing fields in a table or fields on another form will sometimes fail to work as expected.  To work around this issue please comment out or remove the two default lines and then fully qualify all references to resources in the script.

Why doesn't Omni Field Security work for fields not on the main window?
Sometimes Omni Field Security will not work if the field you are attempting to Hide, Disable or Lock is not on the Main window of a form; i.e. it is in a scrolling window or secondary window.  To get around this issue you will need to use a small amount of scripting.  Below are the steps:

Make a note of the window name where the field you wish to Hide, Disable or Lock is, and make a note of the field name.
Change the Field Security settings to use any field that is on the Main window, Save Button or OK buttons are good for this purpose.
Activate conditional scripting and change the Default window command to use the window name noted earlier.
Change the OUT_Active=true; to OUT_Active=false;, this will stop the field that is now selected from being affected.
Then, add a line with the command hide, lock or disable, leave a space and then the field name surrounded by single quotes.
Finally, terminate the line with a semicolon (;).

The result is that the timing of the trigger has been moved to when the main window on the form is opened or restarted, and the script is now performing the action on the scrolling or secondary window.

How can I use Omni Field Security to provide Record Level security?
You can use conditional scripting to create record level security.   The best way to explain this is with an example:

Your customer has multiple warehouses and certain Users are only allowed to sell from certain warehouses. By using the Country field on the Site Maintenance window and putting a User Class ID into it and then associating Users to the same User Class, we can create a many to many relationship between Users and Sites. Attached are 3 screenshots demonstrating how this relationship can be used to limit warehouses in SOP.

Screenshot/Script of Field Security settings to control access to Site ID field in SOP (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Site Lookup (under LAN only).
Screenshot/Script of Field Security settings to limit Site Lookup (under SQL only).

How can I restrict access to my Customers/Debtors using Record Level security?
Here are examples of restricting access to Customers based on a User's Class and the User Defined 2 field of the Customer Master table:

Screenshot/Script of Field Security settings to limit Customer Maintenance (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Customer Maintenance (under SQL only).
Screenshot/Script of Field Security settings to limit Customer Lookup (under LAN only).
Screenshot/Script of Field Security settings to limit Customer Lookup (under SQL only).

Screenshot/Script of Field Security settings to limit Customer Address Maintenance (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Customer Address Maintenance (under SQL only).
Screenshot/Script of Field Security settings to limit Customer Address Lookup.

Screenshot/Script of Field Security settings to limit Customer ID in any other window. 

Note: The Field Security to limit Customer ID in any other window will need to be repeated for other windows as required.

Also see Customer Maintenance defaulting example below. The example code will ensure any new Customers will have the correct value in the User Defined 2 field depending on the User Class of the User adding the Customer.

 

How can I restrict access to my Vendors/Creditors using Record Level security?
Here are examples of restricting access to Vendors based on a User's Class and the User Defined 2 field of the Vendor Master table:

Screenshot/Script of Field Security settings to limit Vendor Maintenance (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Vendor Maintenance (under SQL only).
Screenshot/Script of Field Security settings to limit Vendor Lookup (under LAN only).
Screenshot/Script of Field Security settings to limit Vendor Lookup (under SQL only).

Screenshot/Script of Field Security settings to limit Vendor Address Maintenance (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Vendor Address Maintenance (under SQL only).
Screenshot/Script of Field Security settings to limit Vendor Address Lookup.

Screenshot/Script of Field Security settings to limit Vendor ID in any other window. 

Note: The Field Security to limit Vendor ID in any other window will need to be repeated for other windows as required.

Also see Vendor Maintenance defaulting example below. The example code will ensure any new Vendors will have the correct value in the User Defined 2 field depending on the User Class of the User adding the Vendor.

How can I restrict access to my Employees using Record Level security?
Here are examples of restricting access to Employees based on a User's Class and the User Defined 2 field of the Employee Master table:

Screenshot/Script of Field Security settings to limit Employee Maintenance (under LAN and SQL).
Screenshot/Script of Field Security settings to limit Employee Lookup (under LAN only).
Screenshot/Script of Field Security settings to limit Employee Lookup (under SQL only).

Screenshot/Script of Field Security settings to limit Employee Pay Code Maintenance Part 1/3.
Screenshot/Script of Field Security settings to limit Employee Pay Code Maintenance Part 2/3.
Screenshot/Script of Field Security settings to limit Employee Pay Code Maintenance Part 3/3.

Screenshot/Script of Field Security settings to limit Employee ID in any other window. 

Note: The Field Security to limit Employee ID in any other window will need to be repeated for other windows as required.

Also see Employee Maintenance defaulting example below. The example code will ensure any new Employees will have the correct value in the User Defined 2 field depending on the User Class of the User adding the Employee.

How can I used Omni Field Security to set default values on a window?
By using the Lock, Disable or Hide Field modes on any field on a window, you can now use the conditional script to set default values.  To stop the field selected actually being Locked, Disabled or Hidden just set the out parameter to false.  This script will run each time a window is restarted, which is the correct place to set defaults.  If you are changing the value of a field, it is recommended that you use the "run script" command to force the code behind that field to run, so your change is processed correctly.

Screenshot/Script of Field Security settings to set default values in Customer Maintenance (field on main window).
Screenshot/Script of Field Security settings to set default values in Vendor Maintenance (field not on main window).
Screenshot/Script of Field Security settings to set default values in Employee Maintenance (field not on main window).

Note: When a field is not on the main window, it works better to use code to lock/hide/disable the field and associate the Field Security ID with a dummy field (eg 'Save Button') on the main window.  This will ensure that the defaulting works anytime the form is restarted and not just when the secondary window is opened.

Can I use Omni Field Security to Auto Generate the next Master number?
Yes, you can.  It is just a variation of the setting of default values, please see the examples below.  There are a few different styles, some require more than one script.

Screenshot/Script of Field Security settings to Auto Generate Customer ID's in Customer Maintenance Part 1/2 (Prefix based on Customer Name with next number).
Screenshot/Script of Field Security settings to Auto Generate Customer ID's in Customer Maintenance Part 2/2 (Change focus to Customer Name on restart).

Screenshot/Script of Field Security settings to Auto Generate Vendor ID's in Vendor Maintenance (No prefix, next number in sequence).

Screenshot/Script of Field Security settings to Auto Generate Employee ID's in Employee Maintenance (Fixed prefix with next number).

Can I change behaviour of Great Plains functionality with Omni Field Security?
Yes, you can.  Here is an example where the option to add a customer "on-the-fly" has been disabled.  The option to open the lookup is offered instead.

Screenshot/Script of Field Security settings to limit the User from adding a Customer "on-the-fly". 

Can I use Omni Field Security to add Named Printer support to a 3rd party product?
Yes, you can.  Here is an example adding Named Printers support to the Quick Print Facility in the Explorer.

Screenshot/Script of Field Security settings to Add a Printers Task into Named Printer Part 1/3.
Screenshot/Script of Field Security settings to Change the Default Printer when Printing Part 2/3.
Screenshot/Script of Field Security settings to Restore the Default Printer after Printing Part 3/3.

Can I make Record Level Security work across multiple products?
Yes, you can.  Here is an example where the the Excel Budget Wizard has been restricted so that you cannot add a new Budget ID that is the same as an existing Customer ID.  Please note that the script is executed in the context of the Great Plains dictionary even though the security settings are against the Excel-Based Budget dictionary.  To be able to read the value of the Budget ID from the Excel Budget Wizard window, we need to execute some code in the context of that dictionary (Product ID: 1878).

Screenshot/Script of Field Security settings to limit Budget ID's added via the Excel Budget Wizard. 

Note: It is recommended that you execute the code in the context of the dictionary which contains the table you are comparing to, and then use the execute() function to read the values off the windows in the other dictionary.  Remember to change the execute() function's first parameter to the appropriate Dictionary ID.

Can I use Omni Field Security to Audit changes on my system?
Yes, you can.  Here are some examples logging changes to the Customer/Debtor Name and the Hold field on the Customer Maintenance window.  You will have to apply similar scripts to each of the different fields you wish to log.

Screenshot/Script of Field Security settings to log changes to the Customer/Debtor Name field. 
Screenshot/Script of Field Security settings to log changes to the Customer Hold field. 

Note: Depending on the base data type of the field you are logging, you will need to use the str() function for any non-string data type when writing the log.  Also you will need to change the field used to obtain the old value and the data types of the l_old_field, l_new_field and the parameter passed to the execute() function.  Here is a list of the available fields and the data types.

'WDC Field Security Boolean' of globals for Boolean and Check Box data types.
'WDC Field Security String' of globals for String and Combo Box data types.
'WDC Field Security Long' of globals for Long Integer, Integer, Tiny Integer, all List, Visual Switches and Radio Groups data types.
'WDC Field Security Currency' of globals for Currency and Variable Currency data types.
'WDC Field Security Date' of globals for Date data types.
'WDC Field Security Time' of globals for Time data types.
'WDC Field Security Account' of globals for Account Number data types.

Can I change default behaviour with additional dialogs?
Yes, you can.  Here is an example where the Receivables Transaction Inquiry and the Payables Transaction Inquiry windows have been adjusted to allow the Document Zoom for SOP, Invoicing and POP transactions to select whether to zoom back to the Receivables and Payables transactions or the originating source transactions.

Screenshot/Script of Field Security settings to allow selection of Receivables Transaction zoom, please ensure latest build is installed for this example to work. 
Screenshot/Script of Field Security settings to allow selection of Payables Transaction zoom. 

 

Can I use Field Level Security to only allow Items on Omni Price Contracts?
Yes, you can.  Here is an example which forces SOP to only allow Items which are on an Omni Price Contract. For this to work please ensure that the "Do not show standard price on initial Item Number entry" option is checked and the "Do not log details when Customer Pricing System is used" option is unchecked in Omni Price Setup (Cards >> Omni Price >> Setup Omni Price).

Screenshot/Script of Field Security settings to limit items in Sales Transaction Entry. 
Screenshot/Script of Field Security settings to limit items in Sales Item Detail Entry. 

Note: For this to work correctly Omni Price MUST appear before the Omni Tools or Advanced Security in the DYNAMICS.SET launch file.

 

Why do some of the examples scripts have the default form and default window commands commented out?
This is because when accessing table fields or fields on other windows, we don't want the fields affected by the default form and default window commands.  If only accessing fields on the specified form and window, you can leave them in and then do not have to fully qualify fields.  If accessing tables or fields on other forms it is recommended to comment them out and fully qualify all resources.

I want to use Conditional Scripting, but I don't know how to code Dexterity SanScript?
Easily solved, we can recommend a Dexterity Developer who would be willing to assist.

What is SanScript, how does it related to Field Security?
SanScript is the name of the scripting language built into Dexterity.  All Dexterity code is written in SanScript, and it is this language that is used for the Conditional Scripting in Field Security.

Do I have to use Conditional Scripting to use Field Security?
No, if your security settings are system wide or based on the user and/or company currently being used, there is no need for Conditional Scripting.  You can control who has the security applied by selecting the users and companies to apply it to.

It is only when you want to apply security based on other business rules that Conditional Script can be used to read data and make decisions.

Does Field Security Class settings roll down when changing a User's class
Yes, as of version 6.00 build 8, Omni Field Security settings at the class level will roll down when changing a user's class or giving a user (who belongs to a class) access to a new company.

Does Omni Field Security work for 3rd Party Products?
Yes, Omni Field Security and in fact the entire Omni Tools Suite has been designed from the ground up to be fully aware and compatible with all 3rd party products.

Can't I do everything with Modifier and VBA anyway?
Modifier and VBA can do some of the functions that Field Security is capable of.  They can also perform some changes that Field Security cannot do.  Omni Field Security does not have the ability to add additional fields, windows, forms or tables.  Omni Field Security can access any table defined in any dictionary, it can access any field in any window of any form of any dictionary and can call any global or form level procedures and functions in a dictionary.  As it is SanScript it can also use any of the standard Dexterity commands, functions and function libraries.  Omni Field Security can also access the actual table buffers associated with a form, this allows access to the actual record currently being used, whether in a permanent or temporary table, and it allows functions such as range where (SQL only) to be applied to that table buffer.

 

Does Omni Field Security work for Fields added with the Modifier?
Sadly, No. Dexterity is unable to address fields added by the Modifier, it can only address fields in the main application dictionaries.  It can see and address fields in original windows or in alternate windows created by a 3rd party developer.  This is a Dexterity limitation, not a Omni Field Security limitation.

What effects will Field Security have on Performance?
The answer depends on what you are doing and how many Field Security ID's are active for the user.  Field Security is registered just after logging in, so if you have a very large number of active Field Security ID's you might have to wait an extra second or two for the login to complete.

The majority of functions you can perform with field security will have very little effect on performance.  The exceptions to this is if you create a conditional script which takes a long time to execute or if using the Hide Scrolling Line mode on a large table to hide a large number of records.

For those who like technical development explanations:  Hide Scrolling Line mode is slow because it uses the Dexterity Reject Record command.  The behaviour of this command will stop a line showing in the scrolling window, but Dexterity will keep searching the table (checking line by line) until it either fills the scrolling window or hits the End of the File.  This means that a large table with a large number of records being hidden can be very slow.  If you are running on MS-SQL server it is recommended that you use the Range Scrolling Line mode which uses the Dexterity Range Where command.  The Range Where command will force the SQL Server to reject the records at the server so that the table appears smaller and the client does not need to do any extra work.

What is a Get Change Operation on table WDC_Field_Security_MSTR Error?
This is caused by an incorrect installation of a later build of Omni Tools.  The structure of the WDC_Field_Security_MSTR table was changed for build 6 of Omni Tools.  The conversion to the new structure should be automatic during the installation of a new build (say "Existing" when asked).  We have seen the conversion fail due to selecting the "New Install" option and also due to a corrupted Omni Tools dictionary.  Please follow the steps below to fix the problem.

1) Delete the OMNITOOL.DIC file from your application directory and reinstall the chunk file.
2) Launch Great Plains and say "Existing".
3) Go to Cards >> Omni Tools >> About Omni Tools >> Install to bring up the Installation window.
4) Click on the Advanced button to enable the Convert Table buttons and press the System Convert Table button.

This should manually start the conversion process and you should be able to access the table after this has completed.