View source | View content page | Page history | Printable version   

Projects:Security Review/Technical Documentation


Security review - Technical Documentation

Client filtering


Only the current logged client is accessible even though the role has permission for different clients. Additionally, depending on the user level defined for the role and on the access level for the table which is being accessed access to client 0 (system) is granted or denied.

In order to obtain the list of accessible clients (current client and 0 in case it can be accessed) Utility.getContext method is used, it is overloaded as follows:

 public static String getContext(ConnectionProvider conn, VariablesSecureApp vars, String context, String window)


 public static String getContext(ConnectionProvider conn, VariablesSecureApp vars, String context, String window, int accessLevel)

In the first case access level is not passed so it is not taken into account to calculate if client 0 is accessible. This is the way it is generally used for manual code. This is the way this method was called for every case before the implementation of the Security Review project. And it must remain afterwards for manual code.

The second one receives accesslevel for the table which is being accessed, this is the way WAD windows obtain the client list.

Manual code

All the queries used to show or modify data must include this client for clients. The only queries which are correct without this filter are the ones that are internally used and are filtered by a primary key obtained using the filter.

Organization filtering


There are three levels for organization access Editable, Accessible and Referenceable.


Only data in an editable organization can be modified. Editable organizations are those explicitly granted to the role.

The list of editable organizations is obtained with:

Utility.getContext(conn, vars, "#User_Org", windowId, accesslevel)

Accessible data can be viewed but not modified. The list of accessible organizations consists in the standard tree of his orgList, this is, all the granted organizations, their ancestors and their descendants organizations. To obtain it:

 Utility.getContext(conn, vars, "#AccessibleOrgTree", windowId, accesslevel)

A record can make reference to other records with data defined in the standard tree of the parent record organization.

Utility.getReferenceableOrg(vars, currentOrg)

WAD windows

WAD windows implement these three levels of filtering for organizations.

Manual code

Currently manual code implements Editable filtering. This make possible to access only to data defined in explicitly granted organizations.


Selector have two main elements: Filter and Data.


When a combo is used in a filter the list of organizations it receives is the accessible one:

 Utility.getContext(conn, vars, "#AccessibleOrgTree", windowId, accesslevel)

If another selector is used within the filter, no organization should be passed to it (it has no effect in the current implementation, see following chapter).


As main purpose of selectors is to select data to be referred from other records , they implement Referenceable filtering.

When a selector is called from a window which will not receive a record to reference to (for example a filter in a report) it will not filter by referenceable organizations but by accessible ones.

The implementation for selectors require:

Utility.getSelectorOrgs(conn, vars, readOrg);

The previously mentioned Utility.getSelectorOrgs method returns the referenceable organizations or the accessible ones depending whether the passed organization is empty or not.

This implementation allows to automatically obtain the referenceable list of orgs for the wad windows and, by default, the accessible ones for manual code. If it were desirable for any manual window to get the referenceable list instead the accessible one it only would be necessary to modify the javascript calling the selector to include the organization.


PL process should not behave in different way depending on the security parameters, they only should take into account the parameters of the current record and the generated data should be consistent with the organization defined on it.


Audit fields (created, created by, updated and updated by) are automatically displayed in the bottom side of every tab in case the "show audit" session variable is set to Yes.

This fields are treated as special ones, it is not necessary to define them in the tab (in fact, by default they are not created), in case they exist in the table as columns the fields will be created and positioned in the tab.

Retrieved from ""

This page has been accessed 5,093 times. This page was last modified on 8 June 2012, at 05:30. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.