1Ci Support Help Center home page
Submit a request
Sign in
  1. 1Ci Support
  2. 1C:Enterprise Development Standards
  3. Setting data access rights

Checking access rights

  • Setting data access rights
    • Configuring roles and access rights
    • Standard roles
    • Setting rights for new objects and object fields
    • Checking access rights
    • Using privileged mode
    • Restrictions on the use of ALLOWED keyword in requests
    • Impact of modifying session parameter and functional option values on the performance of data access restriction mechanism

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...

See also:

  • Standard roles
  • Developing roles in libraries
© 2020-2022 1C INTERNATIONAL LLC www.1Ci.com Support policy