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
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).
property can prevent users from editing the record, making the form Read-Only.
DBAllowInsert, and DBAllowUpdate properties
can be used to allow or disallowed database functions like Delete, Insert and
All these properties can be set at runtime
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
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
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: