Setup > Users > Row-level permissions 

Ergonomics | Index

The management of roles is used to define in object management, the data filters in a very selective fashion as a function or the user concerned. It is particularly useful for filtering the data to be presented to users when connected via the Web interface or other external connections. For example, it is used during order entry to only display the orders passed by a specific customer or ordered by this customer (which in this case is the user).

This management is based on :

    definition of the role codes (customer, payer, representative, supplier...), which can be freely carried out in a miscellaneous table (table number 60)

    the association, for the objects for which a filter is to be established, of a field in the principal table with the role code. It is this association that will be used to establish the data filter criterion. The roles management documented here is used to define these associations.

    in an operational fashion in the user record, the assignment of one or more roles with the corresponding codes (a maximum of 30). It is this assignment that will define the automatic filters in the object management concerned.

Once these parameters are defined and the roles (and the corresponding codes) have been defined in the user record :

    A filter is created in the object (left list, selection window) using the code(s) defined in the user record.

    A control is made during the creation of the filtered fields.

    A filter can be carried out in the requester.

Warning, the filters have the following limitations :

    The left list filtering is only made in the fields of the principal table in the object (no filtering in the picking either)

    In the case where the entry of a key is prohibited without passing by a selection, the entry is accepted initially, the control being carried out at the end.

In the case where several roles are defined in the user record, the rule is the following :

    if the roles are identical and the associated key is different, an or logic is made between the conditions.

    if the roles are different, an and logic is made between the conditions.

In the next section are several examples to illustrate this logic : Imagine the following filter :

    the products by buyer code (BUY field associated with the object ITM for the buyer role)

    the purchase orders by supplier (BPSNUM field associated with the POH for the supplier)

    the purchase orders also by buyer code (BUY field associated with the POH for the buyer role)

If the user JOHNDOE possesses the buyer role for the codes MARTIN and DURAND, and the supplier role for the codes DUPONT, DUPUIS, and DUMONT, the filters will be as follows :

    In supplier order entry, only the orders passed to the suppliers DUPONT, DUPUIS, or DUMONT, and involving the buyers MARTIN or DURAND will be available.

     If an order created, the selection window for the buyers and suppliers will correctly filter the authorised buyers and orders. On the other hand, if a prohibited code is entered, it will only be controlled when an attempt is made to confirm the order.

    The products ordered will also be filtered on-line at the time of their selection as a function of the buyers. Even here, if a product that is not bought by one of the buyers is entered, the checks will only be made at the time of confirming the order.

    On the other hand, no filter on the display of an order for the product (if the supplier orders have been passed on products normally filtered for the user it is possible to select them, their modification will be refused).

The technical implementation is made by the automatic addition of the filters to the table managed by the object management. These filters are both active in the standard selection and in the left list. Below is a more technical example. If the following associations are defined for the customer role (defined for example with the code BPC), and the commercial role (defined for example with the code REP) :

    in the object SIH (customer invoice), the BPC role introduces a filter on the BPR field (invoiced BP code).

    in the object SOH (customer order), the role BPC introduces a filter on the field BPCORD (sold-to customer).

    in the object BPC (customer), the role BPC introduces a filter on the BPCNUM filed (customer code).

    in the object SOH(customer order), the role REP, introduces a filter on the REP field (sales representative).

If a user possesses the role BPC in its record associated with the code MARTIN, a filter on the object SIH will automatically be carried out : (BPR="MARTIN"), on the object SOH (BPCORD="MARTIN"), and on the object BPC (BPCNUM="MARTIN").

Of course, only the filters corresponding to a role associated with the user are active. This, if the user does not have the role BPC in its record, the filters defined above will not be carried out : the user will get all the orders, all the invoices and all the customer (provided no other filters - by group of sites, by other roles - have not been defined for the user).

The following illustrates the composition of several filters :

    if the user has the role BPC three times with the customers MARTIN, DURAND, and DUPUIS, the filter on the customer record will be :
(BPCNUM="MARTIN" or BPCNUM="DURAND" or BPCNUM="DUPUIS")

    if the user has the role BPC associated with the code MARTIN, and the role REP associated with the code DUPUIS, the filter carried out on the order management will be :
(BPCORD="MARTIN") and (REP="DUPUIS")

A final important point : a mass filter on the data in a table where the left list is not strictly sorted according to the filter criteria can be very heavily penalised in terms of the response time. It is therefore advisable to use optimisation indexes and declare them in the left list.

Finally, it is important to note that the filter introduced by the roles is not managed by the standard reports (this will be impossible due to the possible extremes of the parameterisation), nor by the standards enquiries. It is therefore necessary to create specific reports if they should be made accessible to external users (but this is possible by playing with the access codes in order to dedicate reports specifically filtered for these users).