To Data

Access to data is divided into two separate mechanisms. The first is a restriction on data retrieval, i.e., on all get (SELECT) requests, including internal ones; the second is restrictions on all other methods, both basic and custom.

Data Retrieval Restrictions (method get)

Data access verification works based on an access list and is applied with every request, including internal ones. That is, unlike operation access verification, which is checked only on the way in from the outside, the data access system imposes restrictions when requesting data from the database in the get method.

Such a check is, of course, performed only if the access-by-list setting is enabled for the given class and method.

An important and not entirely obvious feature of this mechanism is precisely the restriction of data access for internal requests—those where the initial request passes the access check (whether limited by a list or not), and then sub-requests for other data are executed within this method; if there is an access-by-list setting for that data, it will be applied. Let’s consider an example of a hypothetical Product.getAvailable method that should return goods available for purchase. Suppose this method first retrieves active Categories, and also suppose that for certain categories of clients, we restrict the set of Product Categories by granting access by list (the list is adjusted automatically during separate business processes). Then, during the method execution, when Categories are retrieved, the access-by-list mechanism will trigger, and the method will receive a limited set of Categories, for which available Products will then be collected. In this example, access to the get method of the Product_category class must be configured with the Access_by_list attribute.

This mechanism guarantees that if a user is restricted to a set of data, they will not be able to obtain it due to a developer’s oversight when implementing complex algorithms.

If necessary, the developer can bypass these restrictions in internal methods by passing the doNotCheckList parameter. In this case, the developer must be aware of why they are doing this and how it will affect business processes.

Access Restriction for Specific Data for Other Methods

Not only data retrieval can be restricted by a list, but also other methods, both basic (modify/remove…) and custom (for example, the getAvailable method described above).

This allows for flexible configuration of user capabilities for interacting with data—for example, you can view all Requests of your organization, but process (Accept, Reject, Execute) only those that correspond to your specialty (and therefore to which access for the corresponding operations, such as setAccepted, has been granted).

The mechanism is applicable to operations working by a specific id or ids and cannot be applied to operations with an undefined data set, such as a hypothetical applyAll method. In this case, the operation is skipped. However, inside methods with an undefined data set, there are usually queries to obtain already defined sets that are filtered by the list, if such a setting exists for the user role for the requested class.

For operations working by ids (excluding the get operation), there are two restriction modes in case at least one id fails the check. In the first case (default), access for the operation is denied; in the second, the ids not found are excluded from the parameters. The setting is called access_by_list_filter_only. It makes sense to enable it (so that there is no denial, but the input list is simply filtered) for custom operations of the get type.

Often it is simplest (if it fits the business logic) to configure access such that access to an operation, e.g., modify, is allowed for the same list as the data retrieval operation (get). This can be done by checking the is_access_by_list and Is_access_by_list_like_get boxes for the specified operation (e.g., modify).

You can also make the list inherited from the get list, but with its own additional list applied; to do this, set is_access_by_list_like_get_plus_self.

Hierarchical Propagation of Access from the List

The access list is a link table between a class operation, a specific record in that class, and the user or role granted access to that record.

Of course, granting access to a branched data structure is quite costly, even if done automatically, so the system provides the possibility of access inheritance both for child records of the same entity (if the entity is hierarchical) and for child entities. The configuration of such access can be set very flexibly.

For example, we can grant a user access to a specific Project and specify that access will extend to all its child Subprojects, as well as to Project_images (of each one where access is inherited), Project_characteristics, and other child entities (optional). In turn, access can also be inherited by Project_image_authors, for example, and so on.

Settings for access to operations with the “Access by list” attribute and the access inheritance structure are regulated at the Role level, which is subsequently granted to the user.

Automatic List Management

To grant access to a specific record, a record must be added to the link table. It is best to do this automatically, for example, by overriding and supplementing the method for adding a record to an entity that defines the relationship of users to a specific entity. Using Projects as an example, this entity could be Project_participants or, for example, Project_administrators. That is, upon changing the composition of Participants, a synchronization method can be called (it needs to be written, but it is quite simple) to sync users in this list and the Access List for the required operations. For Administrators, for example, records for get/add/modify/remove operations will be added to the access list for these users, while for Project_participants, only for get/modify operations. At the same time, of course, Administrators must be given the “Project Administrator” role, for which access to these operations will be configured with the “access by list” checkbox, and Participants, accordingly, their own role with their own settings. Thus, the synchronization method adjusts the set of roles and the access list for the user.

Connecting Participants or Administrators or any other connection is implemented through the system interface, for example, using TwoColumnEditor.