Codeunits are independent objects that have their own permissions.

They are not assigned roles but rather given permission to access various tables. The permissions for a codeunit are part of its properties. These permissions are indirect because codeunits can only access an object after they have been activated by a user who has permission to run the form or report that calls the codeunit.

When a user runs a form that calls a codeunit the security filters that have been applied to the user’s permissions might be compatible with the permissions that have been defined for the codeunit. If they are incompatible, the user will receive an error message informing them that they do not have permission to access a particular table.

To resolve this conflict, you must ensure that the user’s security filters are compatible with the permissions defined for the codeunit. To do this, you need to assign the user a new role that gives them indirect read access to all the records in the table and then open the codeunit in the Object Designer, open the Properties window, and then give the codeunit read permission to the table in question.

If the error message is not informative, you need to use the Debugger to identify the point at which the code errors. This will help you identify the table involved and you can then give the codeunit read permission to it.

You should then run the form again. If you receive another error message, you can repeat this procedure until the form runs successfully.

It is also possible that your license does not allow you to modify the codeunits in question. In this case, you must contact your local Microsoft Dynamics NAV Partner.

Guidelines for Implementing Record Level Security

The following guidelines are some general rules for implementing record level security:

• Record level security and the business logic of the application must work together.

• For forms, reports, and dataports that are run by properties and not code, the security filters that you apply at user level are sufficient.

• For forms, reports, and dataports that run code, assign an extra indirect read permission at user level.

• For codeunits, assign the extra indirect read permissions at user level and at object level.

• Permissions are cumulative and not mutually exclusive.

Note

Record level security filters do not support wildcards. This means that you cannot use * and ? in the filters. You can use the other symbols, delimiters and, operators, such as, <, >, |, &, .., and =. The maximum length of a security filter is 250 characters, but all of the delimiters, symbols, and operators such as, <, >, |, &, .., and = also count as characters and can considerably reduce the length of the security filters that you can enter. Furthermore, security filters are concatenated and therefore the sum of all the security filters applied to a user or a role cannot exceed 250 characters.

Concepts