Evolutility web control has built-in features for user identification, row level security, collaboration, and user comments. You may use them or bypass them with your own custom code in the page nesting the control.
The SecurityModel property of the web control determines if users need to authenticate and which records they are allowed to view, update, or delete.
In order to use Multiple_Users_RLS, and Multiple_Users_Sharing, the driving table must have a column called "UserID" (of type integer). Multiple_Users_Sharing also need a column called "Publish" (of type bit or integer).
The DBReadOnly property can prevent users from editing the record, making the form Read-Only.
DBAllowDelete, DBAllowInsert, and DBAllowUpdate properties can be used to allow or disallowed database functions like Delete, Insert and Update.
All these properties can be set at runtime in code.
Note: For Single_User_Password, Multiple_Users_RLS, Multiple_Users_Sharing to work, the driving table must have a column called "UserID" (of type integer). Multiple_Users_Sharing also need a column called "Publish" (of type bit or integer).
Notes: At the field level security is handled in the metadata. Individual Fields can be editable or Read-Only, using the readonly attribute of each field element. Fields can be required or optional value (attributes required and optional). In addition, you can choose to have different XML documents all together for different users.
When the SecurityModel is set to any of the models requiring user authentication (Single_User_Password, Multiple_Users_RLS, Multiple_Users_Sharing, or Multiple_Users_Collaboration), Evolutility will prompt users to login the first time the page is displayed.
The stored procedure for user/password validation can be specified in the XML using the splogin attribute of the data element.
A sample stored procedure for user identification called "EvoDemoSP_Login" is provided with our software evaluation copy. It can be modified to fit your specific needs.
Sharing login information between different pages: Evolutility forms will share their login information with other Evolutility forms on the same web application which uses the same value for their DBApplicationID property. This way, users will only log-in once for all (or some) Evolutility forms.
Let’s take an example: two users can look at product information, and one is allowed to see the price of products but the other is not. You can create two component definitions (mapping to the same set of database tables), one including the product price, the other not. Then, use custom code in the page to identify the user and bind the Evolutility web control to one definition or the other.
In situations where users are already logged-in with another system, it is possible to use Evolutility without forcing users to login again. To bypass Evolutility users authentication, set Evolutility UserID session variable called "EVOLUserID".
For example, we can set the user ID to 2 (which should be a valid user in EVOL_User table for comments to work) with the following code:
When using Evolutility property SecurityKey, it is possible to change the name of the "UserID" session variable by adding a prefix to it.
Example, Evolutility Dictionary uses SecurityKey="EvoDico", therefore the session variable is "EvoDicoEVOLUserID".
should be used to bypass its authentication.
By using different prefixes for different applications it makes it possible for users to be logged in to specific applications but not others.
This practice works with all Evolutility SecurityModels. In addition, to prevent users from logging-out by mistake, the "Logout" button can be removed from the toolbar with the "DBAllowLogout" property to the control.
Managing users is as simple as any other entity; you just need to use Evolutility to map the users table.
You can create different pages as follows:
4.1
Properties
Events
Database