Scope: managed applications, ordinary applications.
1. If there are a lot of roles in a configuration (from a few dozen), do not use role-based visibility settings in form items (view and edit attributes by roles, user visibility of form fields by roles, and use commands by roles). Instead, use the following approaches:
- If there are large differencies between form appearance and its functionality based on user roles, develop separate forms customized to a set of user access rights.
- If differencies are insignificant, check access rights in code. Note that visibility program control can slow down form opening. Therefore, you need to consider this feature when choosing between the proposed approaches.
These measures allows you to:
- Make it easier to use controls from code, which go missing from the Items collection (the Items.ItemName.PropertyName code becomes non-operational).
- Increase the code robustness when configuration roles are revised.
- Ensure control over roles used in a configuration. Otherwise, it is extremely difficult to analyze access rights by flags assigned to roles in various items of generic configuration forms.
2. Avoid using role-based visibility settings in the configuration command interface, main section command interface, or home page work area. Instead, set up access rights to command interface sections, common forms, and objects included in the command interface or work area. Thus, you can improve the predictability of the managed interface behavior for users and make it easier to view errors.
3. To check access rights in the code, use the AccessRight method.
Incorrect:
If RoleAvailable("AddChangeWorldCountries") Then ...
If RoleAvailable("ViewPopularCountriesReport") Then ...
Correct example:
If AccessRight("Edit", Metadata.Catalogs.WorldCountries) Then ...
If AccessRight("View", Metadata.Reports.PopularCountries) Then ...
This approach allows you to increase the code robustness when configuration roles are revised.
4. When a role does not grant access rights to metadata objects and defines an additional access right only, use the RoleAvailable method. If Standard Subsystems Library is used in a configuration, use the RolesAvailable function of the Users common module:
for example, when Standard Subsystems Library is unavailable:
If RoleAvailable(...) Or <IsFullUser> Or PrivilegedMode() Then ...
Or similar check when Standard Subsystems Library is available:
If Users.RolesAvailable(...) Then...