In the subsystem " Access control"included in the BSP, access setting to data at the record level of database tables (RLS) carried out using two directories - " Access group profiles" and " Access groups". User roles are configured through the first directory, while RLS can be configured through both directories mentioned above - at the choice of the database administrator.
I would like to note that the subsystem has the ability to differentiate access to data both by elementary and by a set of elements combined together by some attribute. Let's take the reference book as an example " Individuals", the ability to configure RLS to which is available in almost all typical configurations, and is made using a special reference" ". For each element of the directory" Individuals"it is possible to specify in its requisite" Access group"the corresponding element from the directory" Access groups individuals ", after which for each user (or a group of users) the corresponding to him (them) access group of individuals, available for work, is indicated. Thus, the reference book" Individuals"acts as a subject of access restriction (practically any object of the system can act as such), and the reference book" Individual access groups"as a means (tool) to differentiate access to the subject.
Now let's move on to the fact that let's say we needed to organize the differentiation of access to some configuration object according to a certain criterion, but there is no possibility of setting such a distinction in the program. As an example for consideration, let's take a typical configuration " Enterprise Accounting 3.0"(BP), including the subsystem" Access control", and which lacks the ability to configure RLS according to the directory" Contractors". Before making changes to the configuration I would also like to make a reservation - the changes made depend on the BSP version used in the configuration, but the principle remains the same. In this article, the BSP version 2.2.2.44 is used.
And so, the sequence of our actions in the configurator, the purpose of which is to implement the possibility of customization in the RLS configuration according to the reference " Contractors"(in our case, it is the subject of access restriction), will be as follows:
1. Filter the configuration metadata tree by subsystem " Standard subsystems" - "Access control".
2. By configuring the configuration support (if the support mechanism is used), enable the ability to change the following configuration objects:
a. Configuration root.
b. Reference " Contractors".
v. Defined type " Access Value".
d. Subscription to the event " ".
d ... General module " ".
3. Add a new directory to the configuration " Counterparty access groups".
4. Add to the directory " Contractors"new props" Access Group"reference type to our new directory.
5. For the defined type " Access Value"include references to references in the complex type" Contractors" and " Counterparty access groups".
6. To subscribe to the event "RefreshAccessValuesGroups
"also specify the reference book as a source" Contractors".
7. Open the common module "Access Control
"and insert the code snippets below into its three procedures.
8. Out of the role " Changing Members to Access Groups"copy RLS templates with names to the role you need (or roles that define access to the directory)" By Values" and " By Values Extended". Set your roles to use one of the templates for the required permission (for example," Reading"), as shown in the screenshot below.
9. Run the configuration in the " Enterprises"with launch parameter" RunDataBase Update"(or call the export procedure" RefreshParametersAccess Restrictions"common subsystem module" Access ControlService").
Let's pay attention to the rather important point: in the last procedure, you may need to add large quantity lines of code if you plan to restrict access not only to the directory "Contractors", but also to any other configuration objects associated with this directory, for example, to delimit access to documents"Sale of goods and services"by props" Counterparty"- in this case, the objects of access restriction are the document, and the reference book"Contractors"is a criterion for restricting access to a subject using a directory delimiter tool"Counterparty access groups".
Procedure When FillingAccessTypes (AccessTypes) Export SalaryFrames.Access ControlFillAccessViewProperties (AccessTypes); // + Our insert AccessOptions = AccessOnders.Add (); AccessKind.Name = "Contractor Groups"; // name of the access type (used in roles for RLS) AccessType.Presentation = НСтр ("ru =" Contractor groups ""); AccessKind.ValuesType = Type ("DirectoryLink.Contractors"); // access restriction criterion AccessAccess.ValueGroupType = Type ("ReferenceLink.AccessAccessGroups of contractors"); // access restriction tool // -Our insert EndProcedure Procedure OnFillingUsingAccessView (AccessViewName, Use) Export SalaryFrames.Access ControlFillUsingAccessView (AccessViewName, Usage); // + Our insert If AccessViewName = "ContractorGroups" Then Usage = True; EndIf; // -Our insert EndProcedure Procedure WhenFillingKinds ofRightObjectMetadataRightRights (Description) Export // + Our insert // specifying the rights of metadata objects covered by RLS Description = Description + "| Directory.Contractors.Reading.ContractorGroups | Directory.Contractors.Change.Parties. "; // -Our insert EndProcedure
After completing the IB update in the program, you must do the following:
1. Fill in the reference book just added to the system " Counterparty access groups".
2. Havedirectory elements " Contractors"fill in the requisite as necessary" Access group".
3. In the reference " Access group profiles"(or in the directory" Access groups") on the" Access restrictions"appropriately configure RLS by access groups of counterparties (below on the screen - users to whom the profile is assigned" Our new access profile", will work in the directory only with contractors included in access groups" Wholesale" and " General").
4. It may be necessary to provide in the configuration a mechanism for automatic filling of the requisite " Access group"for new elements of the directory" Contractors"(in order to facilitate its administration).
Summary: Using the subsystem " Access control"from the BSP makes it possible to control RLS for any configuration objects, while operating at least two standard directories" Access group profiles" and " Access groups". Expansion of the RLS configuration capabilities is given with minimal changes to the subsystem. In case the criterion (or subject) of access rights restriction is large and is constantly expanding (for example, the reference" Contractors"), then it is possible to divide the criterion (or subject) of access into certain areas ( in our case through "Counterparty access groups"), otherwise, as an access delimiter, you can use (and make sense) the elements of the directory themselves (for example, in the directory" The organization The indisputable advantage of using the subsystem is also the unification of the administration of access rights in the infobase.
Vladimir Ilyukov
Rights, roles, profiles of access groups and access groups allow you to configure user rights in 1C Enterprise 8.3. User rights in 1C 8.3 are a set of actions that he can perform over directories, documents, reports and settings. It is very important to understand these concepts if several users will work with the program and each of them needs to be assigned the appropriate rights.
The article describes how to correctly distribute rights between users of the 1C ZUP 3.1 program, so that each of them can work within their competence and job descriptions... The article does not imply any special computer knowledge.
Profiles and access groups in 1C ZUP 3.1
To differentiate access rights in 1C Enterprise 8.3, "Rights", "Roles", reference books "Users", "Access Groups" and "Access Group Profiles" are used.
Law and Role
Rights and roles are certain permitted actions (Read, View, Delete, Hold, etc.) over constants, references, documents and other configuration objects. Each right is a unit of action from a list of possible actions. The role is the minimum integrator of rights. Each role consists of a set of specific rights. Rights and roles are created in the configurator. The user cannot change their composition.
As in previous versions 1C Enterprise 8 user can be registered in the configurator mode and assign the necessary roles to him in the same place. However, 1C ZUP 3.1 provides for about several hundred available roles(in the user card they are listed on the "Other" tab: "Configurator> Administration> Users").
With so many roles available, it's very difficult to figure out. In addition, for the uninitiated, many role names say little. In such a situation, selecting roles in the configurator for the user is a very time consuming task. However, at the user level in 1C ZUP 3.1, it is easily solved using the “Access Group Profiles” and “Access Groups” reference books.
Access Group Profiles Reference
Each item in the Access Group Profiles directory is a role integrator. The link to this reference can be found at Administration> Configuring Users and Rights> Access Groups> Access Group Profiles. The developers have already described the most popular profiles in it.
- Administrator,
- Timekeeper,
- Personnel officer,
- Calculator, etc.
You can create your own profiles in the reference, but in most cases this is not necessary. The predefined profiles already contain the necessary sets of roles that are allowed for them (allowed actions). Note that the timekeeper has a minimum set of permitted actions. But even to describe it, it took about 50 roles, drawing.
Elements of the "Access group profiles" lookup are set as a suitable value in the "Profile" attribute of the "Access groups" lookup.
Directory "Access groups"
The meaning and purpose of this directory is that it lists the users (members) who will have all the rights of the access group profile assigned to it.
To open this directory, you need to go to the links "Administration> Configuring users and rights> Access groups> Access groups". One access group named "Administrators" is pre-installed in it. The rest are created as needed by users with full rights.
The same "Access Group Profile" can be assigned to different "Access Groups". In contrast, any "Access Group" can only have one "Access Group Profile". In many cases, it is convenient to indicate the name of the assigned access group profile as the name of an access group, a picture.
On the “Group members” tab it is necessary to list users from the reference book of the same name. When selecting, one should be guided by the fact that the access group usually corresponds to the official duties of its members. The higher the position, the more rights. Any access group can have an arbitrary number of members, picture.
The relationship between the described configuration objects is clearly illustrated in the following figure.
In general, the same user can be a member of multiple access groups.
Description of access group profiles in 1C ZUP 3.1
It follows from the above that the user's rights are determined by the profile of the access group of which he is a member. It remains to figure out how the profiles of access groups differ. For example, from the name of the 1C ZUP 3.1 profiles, it is not clear what exactly their roles differ in.
- Personnel officer (without access to salary).
- Personnel officer.
- Calculator.
Unfortunately, they are not described in the configuration. Judging by the name, it can be assumed that a user with a “Personnel manager” profile, in contrast to “Personnel officer (without access to a salary)”, has some kind of access to a salary. But to what extent it is not clear at all. Another question: is the calculator entitled to work with personnel documents?
For those who have it, you can familiarize yourself with the description of the access group profiles given by 1C. It has been published, but it is very short. The author's article contains more detailed description access group profiles. At the same time, in order not to distort the descriptions given by 1C, they are marked in a special font in the article.
Administrator
A user with the "Administrator" profile has the right to perform everything that is provided for by the standard functionality. To do this, such a user must have the "Administration", "System Administrator" and "Full Rights" roles enabled.
Auditor
View all program data, but without the possibility of changing them, 1C.
The auditor can view all sections except for the "Administration" section. He can view personnel and accounting documents and generate reports. The auditor has the right only to view the regulated reporting. The "Settings" section is also visible to the auditor, but here he can only view the existing settings.
Typically, this profile is included in the Auditors Access Group. At the same time, it is advisable to include it in the access group of those leaders of the organization who, due to their official duties, need the data of this program, but they do not know how to work with it or should not.
Timekeeper
Viewing and changing time accounting documents, 1C.
Links to magazines that contain documents on changes in time tracking are located in the sections "Salary" and "Settings". Section "Salary" contains two links: "Tables" and "Individual work schedules", figure.
The timekeeper has the right to view the rest of the objects, but he will not be able to change them. Personnel documents have information about planned charges. However, they are not displayed to the timekeeper and he cannot see them. For example, in the document "Hiring" it will display only two tabs "Main" and "Employment contract". The "Remuneration" tab will not be displayed, picture.
The timekeeper has the ability to generate some personnel reports and the report "Timesheet of working hours (T-13)".
Personnel officer (without access to salary)
It differs from the personnel officer in that viewing and changing the planned payroll is not available, 1C.
Personnel without access to salaries are deprived of the ability to view planned charges and the method of calculating the advance. They also cannot print the order for acceptance, since the accruals are displayed in it. However, unlike the timesheet, personnel officers without access to salaries can create new and correct existing personnel documents.
In addition, the "Personnel officer (without access to the salary)" has the ability to generate all "Personnel reports", edit the directories "Individuals" and "Employees". But he does not have the rights to edit the directories "Organizations", "Subdivisions", "Positions" and those related to military registration.
The profile "Personnel manager (without access to salary)" is intended for those users who should not see planned charges (salaries, allowances, etc.).
Personnel officer
View and change information about employees in terms of personnel records, including planned payroll, as well as personnel documents. Viewing directories of the structure of the enterprise, 1C.
The "Kadrovik", in addition to the rights that the "Kadrovik (without access to the salary)" has, has the right to assign, add and change in the registrars for personnel accounting planned charges, figure.
That is, "Kadrovik" has the ability not only to see the planned charges, but also to change them. This profile is advisable to apply where they do not make a secret about the accruals to employees.
Senior HR Officer
It differs from the personnel officer in that he can change the directories of the structure of the enterprise and the settings for personnel accounting, 1C.
In addition to the rights that the “Kadrovik” has, the “Senior Personnel Officer” has the ability to edit the “Organization”, “Subdivisions”, “Positions” and reference books related to military registration. In addition, senior personnel officers have the right to change the staffing table.
With regard to access to the objects listed below, the following can be noted.
- Setup> Organizations... All details are available for editing, except for the "Accounting policy" form.
- Setting> Accruals
- Setup> Hold... Can be viewed without editing rights.
- Setup> Input templates... Can be viewed without editing rights.
Calculator
Viewing and changing documents for the calculation and payment of salaries, contributions, information about employees (in the part that affects the calculations), 1C.
A user with the "Calculator" profile has the ability to view personnel documents without the ability to edit personnel information. But he has the right to change the planned charges in them. For example, the salary set by the personnel officer, the calculator can change or add some other planned accrual.
The calculator cannot independently create personnel documents. But he has the right to set a new or change the existing work schedule for the list of employees.
- "Settings> Organizations".
- "Settings> Payroll".
- "Settings> Accruals".
- "Setup> Hold".
- "Settings> Input data templates".
In other words, the calculator is not entitled to make any settings. It works with ready-made settings.
Senior Calculator
It differs from the calculator in that it is available to change the settings for payroll, accruals and deductions, 1C.
The “Senior Calculator”, in addition to the rights that the “Calculator” has, has rights to change the following settings.
- Setting> Organizations.
- Setting> Accruals.
- Setup> Hold.
- Settings> Input templates for initial data.
- At the same time, "Settings> Payroll" remains inaccessible to the senior calculator. It is advisable to assign this profile to those calculators who own the technology of forming new types of calculations.
HR-calculator
Combines the rights of a personnel officer, calculator and timekeeper, 1C.
There is nothing to add here: three in one. It is advisable to use this profile where one user simultaneously acts in three persons: timekeeper, personnel officer and calculator.
Senior HR-calculator
Combines the rights of a senior personnel officer, senior calculator and timekeeper. The last two profiles are implemented for the convenience of setting up the program in small organizations, where one user can be responsible for all areas of accounting, 1C.
A clarification is needed here. Indeed, a senior personnel officer-calculator has the right to customize "Accruals", "Deductions", "Indicators of payroll calculation", etc. But he has no right to customize "Payroll" and "Personnel accounting". This is true at least for the 3.1.4.167 release.
Opening external reports and processing
All users, including auditors and timekeepers, are entitled to work with external reports and processing. However, for security reasons, the ability to use external reports and processing is disabled by default. If the report (processing) is received from reliable sources, then the ability to work with external reports and processing can be updated as follows.
Run the payroll program in user mode on behalf of the administrator. On the system panel, go to the link "Main menu> Tools> Options". In the form that opens, update the flag "Display the command" All functions "and click on" OK ".
We set the flag of the same name in it. After that, in the sections “Personnel”, “Salary”, “Payments”, “% taxes and reporting” and “Reporting, references”, in the subsection “Service”, the links “Additional reports” and “Additional processing” will be displayed.
Managing change inhibition dates
To set the date for prohibiting changes to documents of past periods, go to the links "Administration> User and rights settings> Prohibited change dates", figure.
Users who do not have the "Administration" section displayed means that they are not entitled to configure the date of prohibition of changing documents of past periods.
Synchronizing data with other programs
This profile allows you to customize the communication mode. In the future, in accordance with the settings made, an exchange between the salary and accounting programs is provided. By default, the roles of this profile are available only to administrators: "Administration> Data Synchronization".
It should be remembered that the profiles "Opening external reports and processing", "Managing banned dates" and "Synchronizing data with other programs" are not self-sufficient. This means that if you create an access group with any of these profiles and connect the user only to it, then when they try to open the program, we will receive a message.
It indicates that the created access group does not have the required roles connected, which make it self-sufficient.
Conclusion
Planned charges may be assigned not only by users with the "Calculator" profiles and higher, but also by users with the "Human Resources" profiles and higher. But neither planned nor one-time personnel officers have the right to appoint deductions.
Only users with full rights have access to the "Personnel accounting" and "Payroll" settings. The senior personnel officer-calculator does not have such rights.
In order to differentiate user rights, as a rule, there are enough pre-installed profiles. New profiles can be created as needed. At the same time, in order to create a self-contained profile, it should include some mandatory roles such as "Launch thin client"," Basic rights ", etc. In practice, it is easier to make a copy of the profile closest in terms of rights, and then edit it as needed.
In this article, I will tell you how the "record-level access restriction" configuration mechanism works in 1C: UPP 1.3. Information for the article was compiled for May 2015. Since then, the UPP has not been radically updated, because 1C chose 1C: ERP as the flagship. Still, SCP is working well in many enterprises, so I post the results of my research on RLS in SCP in this article. Someone will definitely come in handy.
Everything is dry, compressed and without water. How I love))).
Access rights settings.
The scheme of object interaction.
In UPP 1.3, access control is carried out by the "Access Control" subsystem from BSP version 1.2.4.1.
Metadata used in the SCP access control system:
- User Authority Profiles Reference
- Information register "Values of additional user rights"
- Plan of characteristic types "User rights"
- Directory "Users"
- System directory "Information security users"
- Directory "User groups"
- Register of information "User settings"
- Plan of characteristic types "User settings"
- Enumeration "Types of access objects"
- Register of information "Assignment of access restriction types"
- Access Object Data Areas Enumeration
- Register of information "User access rights settings"
- Session parameter "Use restriction by<ВидДоступа>».
Enables access restrictions at the record level.
Record Level Access Restriction (RLS) is enabled on the interface
User Administration -> Record Level Access -> Options.
Record-level access is defined via access object types. List of types of access objects (the corresponding reference books are indicated in brackets):
- "Contractors" ("Contractors")
- "Organizations" ("Organizations")
- "Individuals" ("Individuals")
- "Projects" ("Projects")
- "Warehouses (" Warehouses (storage locations) ")
- "Candidates" ("Candidates")
- "Notes" ("Types of note entries")
- "Subdivisions" ("Subdivisions")
- "Subdivisions of organizations" ("Subdivisions of the organization")
- "Nomenclature (change)" ("Nomenclature")
- "Specifications" ("Specifications")
- "Item prices" ("Item price types")
- "External treatments" ("External treatments")
* The list of possible types of access is fixed and is contained in the enumeration "Types of access objects".
Reference "User privilege profiles".
Setting up access to objects information base begins by setting up a user permissions profile.
Profile brings together
- set of roles - access rights to objects
- additional user rights - rights to functionality programs.
The result of setting up a profile is an entry in the information register "Values of additional user rights".
This register is not used in the radar setup.
Additional rights can be recorded for a profile or user. Moreover, if additional rights are configured for the profile and the profile is associated with the user, then the additional rights cannot be configured individually for the user.
* The list of rights is listed in terms of the types of characteristics "User rights"
The profile itself in the table section "composition of roles" contains all those roles that are enabled for it. When the composition of the profile's roles is changed, the "Roles" tabular section of all users of the infobase (not the "Users" directory) to whom this profile is assigned is re-filled.
The link between the "Users" directory and "Information base users" is implemented through the "IBUserID" attribute of the "Users" directory, which stores the IB user GUID.
The composition of user roles is also unavailable for editing if the user is assigned a specific profile.
It is possible for the user to specify "User settings". These are various service settings for the typical automatic behavior of the system in certain situations.
The result of the settings is recorded in the "User settings" information register.
The list of settings and their possible values is contained in the chart of characteristic types "User settings".
* Not used in the settings for restricting access at the record level.
Directory "User groups".
Used to group users together and, among other things, to set up access restrictions at the record level.
One user can be included in several groups.
In the form of a user group, you can configure a list of access types.
Record-level object access rights are configured only for groups of users, not for individual users.
If the configuration uses record-level access restrictions, then each user must be included in one of the groups.
IMPORTANT! Users who are not included in any group will not be able to work with those objects to which access is defined at the record level. This applies to all objects - regardless of whether the corresponding access object types are used or not.
If the user belongs to several groups that have different settings access rights at the level of records, then the accessibility of the object for the user will be determined by combining the settings from several user groups by "OR".
IMPORTANT! Enabling the user in a large number of groups can lead to a drop in performance. Therefore, you should not include the user in a large number of groups.
After the changes to the user group are recorded, the Information Register "Assignment of Access Restriction Types" will be filled. This register stores records of correspondence to a group of users with a certain type of access.
* Case is used in access restriction templates
Access settings form.
The form for setting access restrictions at the level of records is invoked by the command "Setting access" of the form of the list of the directory "User groups".
In the right part of the form, tabs represent tables with settings for each type of access, marked with checkboxes in the form of a user group.
The access rights setting form has a separate form page for each type of access with its own set of settings. Desired page turns on when the associated access type is checked in the user group.
Comparison of access types and possible settings:
|
Access type |
Access type settings |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Reading |
Recording |
Access rights inheritance type |
List visibility |
View additional information |
Editing additional information |
View data |
Editing data |
Company prices |
Partner prices |
|||
|
Reading |
Recording |
Reading |
Recording |
|||||||||
| Contractors | ||||||||||||
| The organization | ||||||||||||
| Individuals | ||||||||||||
| Projects | ||||||||||||
| Warehouses | ||||||||||||
| Candidates | ||||||||||||
| Notes | ||||||||||||
| Subdivisions | ||||||||||||
| Subdivisions of organizations | ||||||||||||
| Nomenclature | ||||||||||||
| Specifications (edit) | ||||||||||||
| Item prices | ||||||||||||
| External treatments | ||||||||||||
Access rights.
"Reading" - the user will see the reference book item in the list and will be able to open it for viewing, he will also be able to select it from the list when filling in the details of other objects.
"Record" - the user will be able to change:
- elements of some dictionaries - types of access objects (not all - there are exceptions, see below),
- data (documents, registers, subordinate directories) associated with these directory elements
Exception: access to elements of some directories - types of access objects - does not depend on the "Write" right. These are directories of Organizations, Departments, Organizations' Departments, Warehouses, Projects. They refer to reference data objects, therefore, they can only be changed by a user with the role "Configuring reference data ...".
For the access object type " Nomenclature (change)"The" write "access right is defined only at the group level of the" Nomenclature "directory, there is no way to set the" write "right for individual element reference book.
Restriction of access to “reading” the “Nomenclature” reference book and related information is not provided, because in the general case it is not clear what access should be to the document if the list of the nomenclature, which is in the document, contains both “allowed” and “prohibited »Position.
Restriction of access for the directories "Departments" and "Departments of organizations" does not apply to information on personnel data, on personal data of employees and data on payroll.
Data areas.
Data areas are defined for the following types of access objects:
- Contractors
- Individuals
- Item prices
For the type of access object "Contractors"
- Contractors (list)- determines the visibility of counterparties in the list of the directory "Counterparties". Depends on the value of the checkbox in the "Visibility in the list" column.
- Contractors (additional information)- determines the ability to "read" / "write" an element of the directory "Contractors" and related add. information (contracts, contact persons, etc.). Depends on the value of the checkbox in the corresponding columns "View additional. information "/" Editing add. information ".
- Contractors (data)- determines the ability to "read" / "write" data (directories, documents, registers) associated with the directory "Contractors". Depends on the value of the checkbox in the "Data View" / "Data Edit" column.
For the type of access object "Individuals" the following data areas are provided:
- Individuals (list)- determines the visibility of an individual in the list of the directory "Individuals". Depends on the value of the checkbox in the "Visibility in the list" column.
- Individuals (data)- determines the ability to "read" / "write" data (directories, documents, registers) associated with the directory "Individuals". Depends on the value of the checkbox in the "Data View" / "Data Edit" column.
For the access object type "Item prices" the following data areas are provided:
- Company prices - defines the ability to "read" / "write" company item prices.
- Counterparty prices- determines the ability to "read" / "write" the prices of the nomenclature of counterparties.
* Data Areas is a closed list of items contained in the "Access Object Data Areas" enumeration
Access groups.
For the following types of access objects, rights are configured only through access groups (the names of the directory are indicated in brackets):
- "Counterparties" ("Counterparty Access Groups")
- "Individuals" ("Individuals Access Groups")
- "Candidates" ("Groups of candidates")
- "Item Specifications" ("Specification Use Purposes")
The access group is specified for each element of the directory (in a special attribute).
Access settings from the "access group ..." are made in additional form settings of access rights, which is called by one of two commands:
- "Access to the current items",
- "Access to the directory as a whole"
in the form of a list of directories "Access groups ..."
Example: The document "Receipt order for goods" is limited by the types of access objects "Contractors", "Organizations", "Warehouses".
If you provide access to an empty value for the "Contractors" access type, the user will see documents in which the "Contractor" variable is not filled.
Access to a catalog item or group.
Depending on what access is configured to - to a catalog item or to a group, the setting acts either on the item itself or on subordinate groups.
Accordingly, in the form "Setting access rights" in the column "Type of inheritance of access rights of hierarchical directories", the following values are set:
- For current right only- for a catalog item, the rights apply to the specified item
- Extend to subordinates- for a directory group, the rights apply to all subordinate elements
After recording the settings for restricting access for user groups in the system, the Information Register "User access rights settings" will be filled.
* The register is used in templates of access restriction.
Using templates.
Templates in SCP 1.3 are written for each type of access separately and for possible combinations of types of access, as a rule, for each user group.
For example , the Procurement user group is configured in the demo version of the UPP. For this group, the use of the access types "Organizations", "Contractors", "Warehouses" is enabled. Accordingly, a number of access restriction templates have been created in the system:
- "Organization"
- "Organization_Record"
- "Counterparties"
- "Contractors_Record"
- "Warehouses"
- "Warehouses_Record"
- "CounterpartyOrganization"
- "CounterpartyOrganization_Record"
- "OrganizationWarehouse"
- "OrganizationWarehouse_Record"
- "CounterpartyOrganizationWarehouse_Record"
- "CounterpartyWarehouse"
- "CounterpartyWarehouse_Record"
That is, all possible combinations of access types that can be used in access restriction texts.
In general, the template construction scheme is the same for all types of access and looks like this:
- Checking the inclusion of the checked type of access.
- The "User groups" lookup is attached to the main table and it is checked that the user is included in at least one group.
- To the register of information "Assignment of types of access values" is attached the register table "Settings of user access rights" according to the connection conditions - The access object is the access value passed to the template parameter. - Access object type - depends on the context of template development - Data area.- User.
The result of the connection determines whether access is allowed or not.
End of the second part.
21.09.2014
The task is to delimit the access of information by branches of separate subdivisions to the ZUP for the personnel officer and the calculator.
The types of access objects will be by organizations and individuals.Configuring the inclusion of access control at the record level
Main menu - Service - Program settings - Access restriction tab
Since we initially took a clean database, let's fill it with data.
Let's start an organization with a name.
Central Organization
Branch of the central organization (as a separate subdivision)
The second branch of the central organization (as a separate subdivision)
We will establish access groups for individuals:
AC (for individuals of the central office)
Central center branch (for individuals of the branch)
The second branch of the central center (for individuals of the second branch)
CH + CH branch (for individuals working in CH and CH branch)
DH + Second DH branch (for individuals working in the DH and the second DH branch)
Central office branch + Second central office branch (for individuals working in both branches)
Let's create user groups:
Central heating group
CH Branch Group
Group of the Second Branch of the Central Organ
Let me remind you that we set the types of access objects for all the checkboxes - Organizations and individuals.
After entering user groups, you can assign them to physical groups to which the action will be applied.
In the case of setting up RLS differentiation in separate branches, you need to know the following point - according to the laws of the Russian Federation, personal income tax and insurance premiums are calculated from the beginning of the year and, most importantly, on the basis of the organization as a whole. This means that the accountant of the branch, when calculating taxes, must know how many taxes have already been charged and benefits for this individual are provided in all other separate divisions. And this is access to the data of all other branches, including the central office.
After this fact, it may seem that it is impossible to correctly delimit access to separate branches, but this is not so and here's why. The developers of the standard configuration of the ZUP have developed a data structure when, when calculating taxes, the calculation data is always written to the branch, and the head organization at the same time, and when calculating for the purpose of calculating the tax in the branch, the data is taken from the head organization. It turns out that access to all branches is no longer needed, but only to the parent organization. It's warmer, but firms tend to want to restrict branch offices' access to central organization data. It would seem that nothing will work again!
I can safely assure - everything will work out! Taking into account the concept of RLS, no document will be visible if there is at least one object prohibited for the user, i.e. documents of other organizations will not be visible if there is at least one object (individual) prohibited to the user.
Based on the above, we make the following access settings (the "Rights" button) for user groups.
For a central organization
For CH group branch
For the element "Group Second Central Office Branch" we also make the settings:
On the “Organizations” tab - the Central Organization and the second branch, and on the “Individuals” tab, all access groups of individuals in which the name of the second branch appears. All flags are cocked.
Let's get users of organizations:
Personnel officer - personnel officer of the central organization
HR officer1 - branch HR officer
HR officer2 - HR officer of the second branch
and set all users to the corresponding user groups from the list of users
or we do it in the user group itself
Now we will hire employees.
CO First Employee (central organization)
Branch First Employee (branch employee)
Second Branch First Employee (employee of the second branch)
Branch_CO First Employee (employee hired at the branch, transferred to the central organization)
When accepting, we assign access groups to individuals
CO First Employee - "CO"
Branch PerviyStrudnik - "Branch of the Central Organ"
Second Branch First Employee - "Second branch of the Central Center"
Branch_CO PerviyStrudnik - "CO + Branch of CO"
All employees were hired on 01/01/2014, and from 01/09/2014, the employee of "Branch_CO PervyySotrudnik" was transferred from the branch to the central office.
We open the journal "Human Resources of Organizations" under the administrator, which is not subject to RLS restrictions and we see all the documents
We open the list of employees, and we see only two employees selected according to the restriction setting.
We open the journal "Organization personnel accounting" and see 3 documents selected according to the restriction setting.
Log in as user Kadrovik1
We open the list of employees, and we see only “our” employees.
In the journal "Accounting for personnel of organizations" also only "their" personnel documents.
Log in as user Kadrovik2
A list of employees
Journal "Accounting of personnel of organizations"
The RLS delimitation works in the same way for calculated information, but I will not give examples here.
That's it, the task set in the title is completed - users see only "their" documents.
Also, you can familiarize yourself with the nuances of writing requests when setting delimitation
At the record levelin my article "Using the Allowed Directive"
The strange and undocumented mechanism has finally cleared up.
The text below will not make it normal, but I will at least somehow try to describe this miracle, in the hope that my story will help save time for study.
Under the cut there are many letters from the category "tanks", using argo 1C, not for specialists - it is not interesting.
All settings were made for version 1C Document flow CORP 1.4.12.1, client-server version, platform 1C: Enterprise 8.3 (8.3.6.2152).
So, access groups are intended for setting up rights and restrictions on access rights for specific users and groups of users of the system. The set of rights and the possibilities for their restriction are determined by the specified profile of the access groups. For example, the access group "Sales managers for business software" with users Ivanov and Petrov can refer to the "Sales manager" profile, which provides the ability to restrict type of access "Types of nomenclature". Then if for this type of access for all values you specify the option" Forbidden ", and add the item type" business software "to the list, then Ivanov and Petrov will have access to only those data and operations that are associated with business software.
This definition is given by the help in the program. The Internet mainly cites two sources: 200 questions and answers and a book with training courses 1C, which, in fact, do not really clarify anything. In particular, for me personally, it was completely incomprehensible how to set up restrictions on several criteria at once: organizations, types of documents, issues of activity and access labels. I didn't find anything useful, so I had to get to the truth by trial and error.
The essence of the whole mechanism turned out to be as simple as an ax: if you want the user to have access to a certain object, all the details of this object from among the regulated types of access must be explicitly and, which is fundamentally important, simultaneously allowed in at least one access group assigned to the user ...
A little more detail. The plan of characteristic types is responsible for organizing access types in 1C document flow " Access types ", nine attributes are predefined in it, according to which, in a typical solution, it is possible to set restrictions on objects at the record level (RLS):
- Types of internal documents
- Types of incoming documents
- Types of outgoing documents
- Types of events
- Activity issues
- Access vultures
- Correspondent groups
- Individual access groups
- The organization
We take as a basis a very simple model- two organizations: Firm-1 and Firm-2, two types of documents: Account and Agreement and two issues of activity: AXO and Salary. All users will use one common access group profile.
Our goal is to divide all users into groups with access only to a specific organization, and in each of them there are those who work with contracts and those who work with accounts. Let's complicate our life with one more restriction: some users should have access to Salary activities, the rest should not.
So, to solve this simple task, we need to configure no less than EIGHT access groups:
- Firm-1, Accounts, Salary Issues
- Firm-1, Accounts, AXO Questions
- Firm-1, Contracts, Salary issues
- Firm-1, Agreements, AXO Issues
- Firm-2, Accounts, Salary Issues
- Firm-2, Accounts, AXO Questions
- Firm-2, Contracts, Salary issues
- Firm-2, Agreements, AXO Issues
There is no hierarchy or inheritance in the program. The number of access groups is obtained by multiplying the number of possible restrictions. Therefore, if you decide to set up restrictions on a dozen issues of activity, for a dozen types of documents, in the context of at least two organizations, then be prepared to administer 10 * 10 * 2 access groups. Add to this, or rather multiply by two or three profiles - users, reception, clerks and your hair will never fall back on your head again.
