When a form, report, or dataport is opened from a command button or menu item, C/SIDE automatically applies record-level security filters if the command button or menu item uses properties instead of code to run the form. If the form is simple, then the security filters that you apply at the user level ensure that the degree of security that you want is implemented.

Find('+') and Calcsums

If the report or form contains complex C/AL code, such as Find('+'), or contains a calcsum, then the security filters that are applied at user level do not ensure that the form or report can run successfully. In this case, the user may receive an error message about not having read permission to a particular table.

This situation generally arises because the form or report contains functionality that requires access to all records in the table. This conflicts with the user’s security filters, which only allow access to some records in the table. For example, if the form needs to read the last record in the table before it can insert a new record and the last record in the table lies outside the range of the security filter that has been applied to the user, then the user sees the error.

The user has already been assigned a role that allows access the records in the table. This role was then limited to only some records in the table by a security filter. To resolve this conflict, you must augment the user's permissions by assigning a new role that allows indirect read access to all records in the table.

Granting the user indirect permission to read the entire table does not compromise the integrity of the security system. The user still cannot see the records that are outside the range of the security filter. But the application can perform the calculations and read all data that is necessary to function correctly and give the user the required information.

This solution works because security permissions are added together and are not mutually exclusive.

See Also