User Based Security Implementation


Integral Accounting Enterprise has user based security, and the system can easily be configured to add security to forms / screens and even to individual controls on forms / screens. This document will explain how the forms / reports level security is implemented within the Integral Accounting Enterprise program and how to use the security settings programmatically within your reports and forms, and how to have third party add-on's that you may write connect to the Integral Accounting Enterprise Security system.

Loading Security Parameters

Security is implemented in the Integral Accounting Enterprise in the following manor:

Upon login, the user enters their Company, Division, Department and a User ID and Password that grants them access to that particular Company / Division / Department.

Their User ID / Password combination is checked to make sure that they are in fact allowed to access the Company / Division / Department and the system loads their Security Matrix.


The Security Matrix

The security matrix is an important concept. The security matrix for a user consists of the set of all security settings within the Access Permissions table for that particular user. Here is a sample of the security matrix and the explanation of some of the the abbreviations:

Sample of the AR Security Matrix:

OEView  - Set View Orders permission 
OEAdd  - Set Add Order Transactions permission
OEEdit  - Set Edit Order Transactions 
OEDelete - Set Delete Order Transactions permission 
OEReports - Set View Order Reports permission

There is a security matrix for each of the system functions, AR, AP, OE, PR, PO, GL, etc, and these parameters can be set for each particular user in the system for each of the system functions.

This is a very flexible set-up, and you can easily add more fields to this table and make it as complicated as you need for your particular implementation. 


The Security Objects

You can set specific security settings in the system for each object. To set security settings for the specific form you should open correspondent file and edit the permission section there. If this section is absent for the object you are editing, you can add this section and edit it.

The permission section looks like this:


<Standard DeletePermission="Always" UpdatePermission="Always" InsertPermission="Always" SelectPermission="APView|GLView|POView|ADView|ADSetup"/>


If you remove some of the permission attributes from the description, the corresponded action will be disabled

"Always" enables action for any user

The set of flags delimited by | enables action for user that have at least one of the flags set to True in the AccessPermission table

Here is another example of how this works:

To make, for example, the Payroll Employees form editable, you should set the correspondent xml properties in the following way: 

In \Enterprise\EnterpriseServer\Schema\Objects\App\PayrollEmployees.xml) :



    <Standard InsertPermission="Always" SelectPermission="PRView|EMView|ADView|ADSetup"/>



should be replaced for  by


    <Standard InsertPermission="Always" UpdatePermission="PREdit|EMEdit|ADEdit|ADSetup" SelectPermission="PRView|EMView|ADView|ADSetup"/>



Which now allows users with PREdit, EMEdit, ADEdit, And ADSetup permissions to Update the Payroll Employees form.