Access groups for individuals 1c. Adding a new user and assigning rights to him

21.09.2014

The task is to limit access to information on branches of separate divisions in the ZUP for the personnel officer and the accountant.

Types of access objects will be by organizations and individuals.Setting up access control at the record level

Main menu - Tools - Program settings - Access restriction tab

Since we initially took a clean database, let’s fill it with data.

Let's create organizations with a name.

Central organization

Branch of a central organization (as a separate division)

Second branch of the central organization (as a separate division)

Let's create access groups for individuals:

CO (for individuals of the central office)

CO branch (for individuals of the branch)

Second branch of the CO (for individuals of the second branch)

CO + CO branch (for individuals working in the CO and CO branch)

CO + Second branch of the CO (for individuals working in the CO and the second branch of the CO)

CO branch + Second CO branch (for individuals working in both branches)

Let's create user groups:

CO Group

Group Branch CO

Group of the Second Branch of the Central District

Let me remind you that we set the checkboxes for all types of access objects - Organizations and individuals.

After entering user groups, you can assign them groups of individuals to whom the action will apply.

In case of setting up RLS delimitation 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, based on the base of the organization as a whole. This means that the branch accountant, when calculating taxes, must know how much taxes have already been accrued and benefits provided for this individual in all other separate divisions. And this is access to data from all other branches, including the central office.

After this fact, it may seem that it is impossible to properly delimit access to separate branches, but this is not so and here’s why. The developers of the standard ZUP configuration have developed a data structure when, when calculating taxes, the calculation data is always recorded for the branch and the parent organization at the same time, and when calculating for the purpose of calculating taxes in the branch, the data is taken for the parent organization. It turns out that access to all branches is no longer needed, but only to the parent organization. This is already warmer, but firms, as a rule, want to limit the access of branches to the data of the central organization. It would seem that nothing will work out again!

I can confidently assure you that everything will work out! If we take into account the RLS concept, not a single 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 the central organization

For Group branch CO

For the element “Group Second Branch CO” we also make the following 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 create users of organizations:

Personnel officer - personnel officer of the central organization

Personnel officer 1 - branch personnel officer

Personnel officer 2 - personnel 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 let's hire employees.

CO First Employee (central organization)

Branch First Employee (branch employee)

SecondBranchFirstEmployee (employee of the second branch)

Branch_CO FirstEmployee (employee hired at the branch, transferred to the central organization)

Upon acceptance, we assign access groups to individuals

CO First Employee - “CO”

Branch First Employee - “Branch Central Office”

SecondBranchFirstEmployee - “Second Branch of the Central Organ”

Branch_CO First Employee - “CO + Branch CO”

All employees were hired on 01/01/2014, and from 09/01/2014 the employee of “Branch_CO First Employee” was transferred from the branch to the central office.

We open the journal “Human Resources Accounting for Organizations” under an administrator who is not subject to RLS restrictions and see all the documents

We open the list of employees and see only two employees selected according to the restriction setting.

We open the “Organizational Personnel Accounting” journal and see 3 documents selected according to the restriction setting.

Login under the user Kadrovik1

We open the list of employees and see only “our” employees.

The journal “Personnel Accounting for Organizations” also contains only “their own” personnel documents.

Login under the user Kadrovik2

A list of employees

Magazine "Personnel Accounting of Organizations"

The RLS distinction operates in the same way with regard to calculated information, but I will not give examples here.

That's it, the task stated in the title is completed - users see only “their” documents.

Also, you can familiarize yourself with the nuances of writing queries when setting delimitation

At the record levelin my article "Using the Allowed directive"

Edition 2.0" create a new user and assign him the necessary rights. To do this, go to the “Administration” section. Select the “User and Rights Settings” menu item. Here we go to the “Users” directory.

Let's add a new user. Let's indicate his name - Ivanov Ivan Ivanovich. Let's check the box that access to the infobase is allowed. We will automatically fill in your login name to the information database. We can also assign a password for the user. It will be requested upon login. We fill it out twice. We can also use operating system authentication if we have it configured. Where we can select users and user lists in our system. And then it will be possible to disable “1:C Enterprise Authentication”. The user will automatically log in to the system without entering a password. This type of authentication is most convenient for working in distributed network systems.

In the next step, we need to specify an individual for our new user. Let's go to the directory "Individuals". Let's create a new one. We indicate the last name, first name and patronymic. Please indicate your date of birth – it is required. And at the next stage, perhaps a surprise awaits us.

We need to specify the access group for an individual, since we use record-level access to the directory of individuals. Those. Each user of the information base can have access to a certain section of the “Individuals” directory, specified in a separate hierarchy called “Access groups of individuals”. In this case, it is not filled in, so we cannot select it in our details.

Let's go back to "User and Rights Settings". Let’s find “Access groups for individuals”. And let's create the elements of this directory. Let’s create an access group – “Enterprise Employees”. And let’s create an access group – “Counterparties”. You can use different access groups for individuals in your information database. For example, you can also divide them into customers and suppliers. You can use the division of individuals by specific managers who work with them. You can arrange a regional branch of groups of individuals.

So, we have set our access groups for individuals. We return to “Individual”. And now we can select a specific element. In this case it is “Employee of the enterprise”. Let's indicate it. And click the “Save and close” button.

Let's return to the user. Now we can select the individual Ivanov Ivan Ivanovich. And write down our element in exactly the same way. The new user is recorded and now we must grant our new user the rights under which he will work in the system.

There are several reference books for working with rights in the system. This is, first of all, the “Users” directory. These are "Access Groups". These are “Access Group Profiles”. And there is also a hierarchy of users - these are “User Groups”. Here it is marked with a tick.

Thus, we have a rather complex structure for granting user rights. In order to understand it, I suggest turning to the following picture. In this picture we see the hierarchy of granting rights to users in the enterprise management system.

At the lowest level of granting rights are the so-called “user roles”. They are set at the system configuration level and cannot be changed in user mode. The set of roles in the system is quite wide and it allows you to configure quite complex sets of rights for users.

The next level of our entitlement system is “access group profiles.” In this case, we have rights represented by an accountant, a sales manager and a purchasing manager. Each access group profile is represented by its own set of roles. They can intersect with each other and can be exhibited independently. Those. There are some roles that are common to all access group profiles. Those. for example, some basic rights. And there are also specific roles that are assigned to each profile individually.

The next level of rights granting is “access groups”. One access group corresponds to one access group profile. However, we can use the same access group profile in several different access groups. What is all this for? Access groups expand the ability to restrict user access to the database. What does it mean? This means that we have one profile with certain roles, but in access groups we describe what additional restrictions are imposed on this profile.

Thus, we get several groups with the same profile, but with different levels of access to the database. Those. for example, we have a sales manager, and we can create an access group - a sales manager who has access, for example, to the Moscow region. Separately, we can create an access group for sales managers who have access to the Moscow region. And thus configure rights in our information system.

Now let's turn to our new user Ivan Ivanovich Ivanov. And assign him an access group. Well, as we can see, on the left it has “Groups” and “Access Rights”. Access groups are assigned in access rights. To be included in any access group, we need to click the “Include in group” button. A list of groups opens, and select the “accountants” group for it. The user is assigned the "accountants" access group, which has the "accountant" profile. And in the future, our user can already work with the system.

Let's see what kind of group this is, how it is structured, what it consists of. As we can see, a profile is specified for the group. And we can also see the members of our access group. Here, as there are individual users, for example, Ivanov Ivan Ivanovich, whom we added. There are also user groups here, which we will talk about a little later. Those. You can add both an individual user and a group of users. And it also further describes restrictions for access to individual directories.

Let's see how the access group profile is structured. Open the Accountant profile. And here we see a set of roles that are inherent to this access group profile. Also on the “Access Restrictions” tab, the restrictions inherent to this profile are indicated.
Now let's figure out what user groups are. Let's move on to the groups of Ivan Ivanovich Ivanov. Here's just a list of groups. As we can see, Ivan Ivanovich Ivanov is not included in any of the groups. Let’s include him in the “accountants” group by simply clicking on the checkbox. And click the “Record” button.

Now let's go to "Access Rights". And here we will see that Ivan Ivanovich Ivanov automatically got through the “accountants” user group into the “accountants” access group. Those. Thus, we have two ways to assign rights to users. For example, let’s add our Ivanov Ivan Ivanovich to another group, for example, “storekeepers”. Click “Record”. Let's go to the "Users" directory. Here we see just a list of users without hierarchy. If we go to the “accountants” group, then we will see Ivan Ivanovich Ivanov in the “accountants” group. Also if we go to the “storekeepers” group. We will also see Ivan Ivanovich Ivanov in the “storekeepers” group.

Thus, we have a fairly complex branched network to provide rights to our users. You need to approach its use wisely and not create additional entities that you will not use.

Print (Ctrl+P)

User and rights settings

The program provides for the simultaneous operation of several users. The number of program users is technically unlimited (the number of concurrent users is limited only by the number of available licenses).

If only one user will work with the program, then there is no need to add him to the list of users.

The list of users and their rights are configured in the administration section

a list of users

Users of the program are described in the reference book of the same name. After adding users to the list, when you start the program, you can specify which user it should be run as. Launching on behalf of a specific user can also be done implicitly (for example, according to its authentication in the operating system).

Maintaining a list of users allows you to:

■ customize the appearance, reports and some other parameters of the program for each user in a way that is convenient for him. These settings may differ for different users: the settings of one user do not affect the settings of another;

■ when working with program documents, indicate on behalf of which user the document was created and who is responsible for it;

■ restrict access to certain data stored in the program and to its functionality.

When you add the first user to the list, he is automatically assigned administrative (full) rights. He can add other users to the program and limit their rights (discussed below). In this case, the administrator has full access to all data and capabilities of the program.

In the user list it is possible to use user groups. Uniting users into groups is convenient when there are many of them, for quick search and selection. In addition, this allows you to configure access rights for all users included in the group at once.

When there are a small number of users (or when there is only one user), groups are usually not needed.

User Settings

The user's card contains basic information about him: name, contact information, settings for logging into the program, information about his relevance, etc. Initially, these settings are usually set by the program administrator.

During the work process, each user has access to these, as well as his other personal settings, through the Personal Settings form. It is available in the Main or Settings section.

In this form, the user can both view and change his account information (for example, change his password) and set some other settings. For example, set an arbitrary working date instead of the current one. Then, when creating new documents, their date will be filled in taking into account this working date.

While working with the program, the user can customize the content and appearance of various forms - for example, turn off the display of individual details to free up space on the form. To do this, all forms have the Edit Form command.

The user can also change the settings of analytical reports and save their own options.

It is possible to copy all these settings between different users, as well as clear them (return to the settings provided in the program delivery).

Access rights

The program provides the ability to restrict user access rights to certain objects (directories, documents, etc.).

You can restrict access:

■ to all objects of a certain type (for example, all payroll documents are not available to a personnel officer);

■ to some of their copies (for example, the payroll documents of another organization are not available to the payroll clerk of one organization) - the so-called access restriction at the record level.

In addition, different users are provided with access only to certain details of the same object. Through this feature, the so-called multifunctionality of documents is realized.

Note
You should not use configuration mode to configure users and access rights. Setting up user access rights should only be done using access groups in 1C:Enterprise mode.

Access groups and access group profiles

Access rights are not assigned to a user directly, but by assigning them to a specific access group (or several different access groups).

The program comes with one access group - Administrators, into which the first user is automatically included.

The administrator can create other access groups to include users whose rights need to be restricted.

As a rule, access groups correspond to the various job responsibilities (or types of activities) of program users. A user can simultaneously be a member of one or several access groups, which together form his personal access rights settings.

Note
If a user is a member of several access groups, his total access rights are added (combined by “or”) from the access rights of each group.

In a simple case, if access restriction at the record level is not used, to describe an access group it is enough to select the corresponding Access Group Profile.

Access group profiles are pre-configured templates that can be used to conveniently describe access groups.

The program already includes pre-configured profiles, the rights of which correspond to the generally accepted job responsibilities of employees responsible for maintaining payroll and personnel records (a brief description of the rights assigned to these profiles is given in the next section).

For example, you can create an access group “Senior HR Officers”, set it to the profile “Senior HR Officer” and include one or more users responsible for HR records there.

It may be necessary to create several different access groups with the same profile if you use record-level access restrictions (discussed below).

If the access group profiles supplied in the program are not enough for a particular enterprise or the set of rights with which they are allocated is not suitable, then it is possible to describe your own access group profiles without changing the program (also discussed below).

Access Group Profiles Supplied

In addition to the Administrator profile, which has full rights, the program includes the following access group profiles:

■ Personnel officer. View and change information about employees in terms of personnel records, including planned payroll, as well as personnel documents. Viewing directories of enterprise structure;

■ Personnel officer (without access to salary). It differs from the personnel officer in that viewing and changing the planned payroll is not available;

■ Senior personnel officer. It differs from a personnel officer in that it is possible to change directories of the enterprise structure and personnel records settings;

■ Calculator. Viewing and changing documents for calculating and paying salaries, contributions, information about employees (to the extent that affects calculations);

■ Senior accountant. It differs from the calculator in that it is possible to change the settings for salary calculation, accruals and deductions;

In the subsystem " Access Control", included in the BSP, access settings 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 elementally and by a set of elements combined together according to some characteristic. As an example, let's take the directory " Individuals", the ability to configure RLS for which is available in almost all standard configurations, and is done using a special reference book" ". For each directory element " Individuals"It is possible to indicate in its details" Access group"the corresponding element from the directory" Individual access groups", after which for each user (or group of users) the corresponding access group of individuals available for work is indicated. Thus, the directory " Individuals" acts as a subject of access restriction (almost any system object can act as such), and the directory " Individual access groups"as a means (tool) of delimiting access to the subject.

Now let's move on to the fact that let's say we needed to organize access restrictions to some configuration object according to a certain criterion, but there is no ability to configure such restrictions in the program. As an example for consideration, let's take a typical configuration " Enterprise accounting 3.0"(BP), which includes a subsystem" Access Control", and in which there is no ability to configure RLS using the directory " Counterparties". Before making changes to the configuration I would also like to make a reservation - the changes made depend on the version of the BSP used in the configuration, but the principle remains the same. The article in question uses BSP version 2.2.2.44.

And so, the sequence of our actions in the configurator, the purpose of which is to implement the ability to configure the RLS configuration according to the directory " Counterparties" (in our case, subject to access restrictions), will be as follows:
1. Filter the configuration metadata tree by subsystem " Standard subsystems" - "Access Control".
2. Through the configuration support setting (if the support mechanism is used), enable the ability to change the following configuration objects:
A. Configuration root.
b. Directory " Counterparties".
V. Defined type " AccessValue".
d. Subscription to the event " ".
d . General module " ".
3. Add a new directory to the configuration " Counterparty access groups".
4. Add to directory " Contractors"new props" Access Group"reference type to our new directory.
5. For a defined type " AccessValue"include references to directories in the composite type" Counterparties" And " Counterparty access groups".
6. To subscribe to an event "UpdateAccessValueGroups "also indicate reference book as a source" Counterparties".
7. Open the shared module "Access ControlOverridable " and insert the code fragments below into three of its procedures.
8. From the role " Changing Group MembersAccess" copy RLS templates with names to the role you need (or roles that determine access to the directory) ByValues" And " ByValuesExtended". Set your roles to use one of the templates according to the required right (for example, " Reading"), as shown in the screenshot below.
9. Run the configuration in " mode Enterprises"with launch parameter" LaunchInformationBaseUpdate" (or call the export procedure " UpdateSettingsAccess Restrictions"general subsystem module" Access ManagementService").

Let's pay attention to a rather important point: you may need to add more lines of code to the last procedure if you plan to restrict access not only to the directory "Counterparties", but also to any other configuration objects associated with this directory, for example, to restrict access to documents "Sales of goods and services"by props" Counterparty" - in this case, the subject of access restriction is a document, and a reference book "Counterparties"is a criterion for restricting access to an item using a directory delimiter tool"Counterparty access groups".

Procedure When Filling in Access Types (Access Types) Export Salary Personnel. Access Management Fill in Access Type Properties (Access Types); // +Our insertionAccessType =AccessTypes.Add(); AccessType.Name = "Account Groups"; // name of the access type (used in roles for RLS) AccessType.Presentation = NStr("ru = "Groups of counterparties""); AccessType.ValueType = Type("DirectoryLink.Counterparties"); // access restriction criterion AccessType.ValueGroupType = Type("DirectoryLink.AccessGroups of Counterparties"); // access restriction tool // - Our insertion End of Procedure Procedure When Filling in the Use of Access Type (Name of Access Type, Use) Export Salary Personnel. Access Management Fill in Use of Access Type (Name of Access Type, Use); // +Our insertion If AccessTypeName = "Contractor Groups" Then Use = True; endIf; // -Our insertion End of Procedure Procedure When Filling in Types of Limitations of Rights of Metadata Objects (Description) Export // + Our insertion // indicating the rights of metadata objects that are covered by RLS Description = Description + " | Directory. Counterparties. Reading. Counterparty Groups | Directory. Counterparties. Change. Counterparty Groups | "; // -Our insertion EndProcedure

After completing the information security update in the program, you must do the following:
1. Fill out the directory you just added to the system " Counterparty access groups".
2. Udirectory elements " Counterparties"fill in the required details" Access group".
3. In the directory " Access Group Profiles"(or in the directory" Access groups") on the " tab Access restrictions"appropriately configure RLS by counterparty access groups (the screen below shows users to whom the profile is assigned" Our new access profile", will work in the directory only with counterparties included in access groups " Wholesale" And " Are common").
4. It may be necessary to provide in the configuration a mechanism for automatically filling in the details " Access group"for new directory items" Counterparties" (in order to facilitate its administration).

Summary: Using the "subsystem" Access Control"from the BSP makes it possible to manage RLS for any configuration objects, while operating at least two standard directories" Access Group Profiles" And " Access groups". Expansion of RLS configuration capabilities is provided with minimal changes to the subsystem. In the event that the criterion (or subject) for restricting access rights is large and is constantly expanding (for example, a directory " Counterparties"), then it is possible, through your additional directory (delimitation tool), to divide the criterion (or subject) of access into certain areas ( in our case via "Counterparty access groups"), otherwise the directory elements themselves can be used as an access delimiter (and it makes sense) (for example, in the directory " Organizations"). An undeniable advantage of using the subsystem is also the unification of the administration of access rights in the information base.