1. Identification
| Parameter | Value |
|---|---|
| Object Type | Catalog |
| Name | UserGroups |
| Full Name | Catalog.UserGroups |
| Alias | User groups (no custom alias specified separately) |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Hierarchy | Hierarchical (hierarchy of groups and elements) |
| Predefined Elements | “All users” (AllUsers) — created during the initial initialization of the information base |
Purpose. The catalog is designed for organizing role-based access and managing user rights. The system administrator groups users with the same set of rights to functionality and data. Each group contains an arbitrary number of members (links to the Users catalog) and supports a “parent-child” hierarchy. Changes to the group composition are automatically synchronized with the access control mechanism upon recording an element.
Where to find in 1C: section “Administration” → “User Groups”.
Navigation link: e1cib/list/Catalog.UserGroups
This is a service catalog of the BSP subsystem “Users”. It does not participate in the accounting circuit and is not related to monetary amounts, tax rates, or the chart of accounts — the further mentions of RK-specific features are absent, as the object is not an economic document.
2. Attributes and Table Parts
2.1 Header Attributes
| Name | Type | Mandatory | Purpose |
|---|---|---|---|
| Name | String | Standard (checked for completion) | The name of the group. Standard attribute of the catalog |
| Parent | CatalogLink.UserGroups | Standard | Link to the higher-level group (hierarchy) |
| Comment | String | Not checked (DontCheck) | Arbitrary textual description of the group's purpose, explanations for the administrator |
The standard attributes “Name” and “Parent” are automatically present as attributes of the hierarchical catalog.
2.2 Table Part “Composition” (group members)
Purpose. Stores the list of users who are part of the group. When the composition changes, the system automatically recalculates the access rights of the members.
| Name | Type | Purpose |
|---|---|---|
| User | CatalogLink.Users | Link to a specific group member |
3. Forms
| Form | Purpose |
|---|---|
| ElementForm | Key form for editing the group (≈88 controls): fields “Name”, “Parent”, “Comment”; table part “Composition” with buttons for selection, addition, deletion, moving, and sorting of rows; checkbox “Show invalid users” |
| ListForm | Form for the list of groups (≈33 controls): displays the name and comment, supports navigation through the hierarchy |
If there are no other forms in the metadata, the platform generates them automatically (selection form, group form).
4. Key Module Procedures
In the attached evidence, the source code (BSL) of the modules is not provided, so below are described the typical handlers of this type of object in configurations on BSP. Specific paths module:string are specified according to the configurator version 3.0.74.2 (version-specific).
Object Module:
BeforeWriting— control of the correctness of the composition: prohibition of duplicate users in the table part “Composition”, checking the referential integrity of the members.OnWriting— calling the procedure for recalculating access rights (updating user access groups in the “Users”/RLS subsystem).FillingHandler— filling in the attributes when creating a new element.
Element Form Module:
OnCreationOnServer— setting the visibility of columns, handling the checkbox “Show invalid users”, restricting editing for the predefined group “All users”.- Member selection command — opening the selection form of the
Userscatalog with multiple selection and adding rows to “Composition”. AfterWritingOnServer— notifying list forms of data changes.
General Module of the Subsystem (typical): procedures like UpdateUserGroupComposition / OnMemberCompositionChange, synchronizing user membership in the access group upon writing.
5. Posting and Movements
The catalog is not a document and is not posted: the attribute “Posting” is absent, accounting registers and accumulations are not affected, accounting entries are not formed.
The only “effect of writing” is the update of service data of the access rights subsystem (recount of access groups/RLS of members). No accounts from the standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) are involved when working with this object, tax rates and amounts are not calculated. The object does not generate electronic documents (ESF, CNT).
6. Related Objects and Input Based On
| Relation | Object | Nature of Relation |
|---|---|---|
| Members | Catalog Users |
The table part “Composition” refers to users |
| Access Rights | Information registers of the “Users” subsystem (access groups, RLS settings) | Updated upon writing the group |
| Hierarchy | Catalog UserGroups (itself) |
Attribute “Parent” |
Input based on for this catalog is not provided (it is not a source/receiver of the input mechanism).
7. Extension Points
- Configuration Extension: adding header attributes (for example, the attribute “External group”) and columns in “Composition” without removing from support; borrowing forms
ElementForm/ListForm. - Form Handlers: overriding
OnCreationOnServer, adding custom commands for managing the composition. - Event Subscriptions:
BeforeWriting/OnWritingof the catalog — for integration with external user cataloging systems. - BSP Programming Interface: using procedures of the “Users” subsystem for programmatically adding/removing members and obtaining the composition of the group.
Exercise caution when modifying the predefined group “All users” — its deletion and renaming are restricted by platform and application logic.