The authority profile in the 1C:UPP program combines:

· Restricting access to objects, determined by the list of roles

· Access to functionality, is set by setting additional rights.

Examples of profiles:

· operator - ability to create shipping documents

· Sales Manager - In addition to creating documents, it is possible to change the price

· senior sales manager - ability to disable settlement control

Thus, the authority profile in 1C:UPP fully describes the user’s functionality.

For a profile, you can set the main interface, which will open by default in the user session for which the current profile is assigned. However, you can also set your own interface for each user.

Exchange of profiles in 1C:UPP

In the "Administration" submenu there are tools for exchanging profiles between databases:

· Upload profiles - allows you to upload profiles to an exchange file.

· Load profiles - allows you to load user profiles from an exchange file that was created using the "Upload" service.

Service functions

A user profile has a useful feature for copying configured additional rights to other profiles. It is convenient to use when creating several profiles. You can call the function using the "Copy" button on the command panel of additional rights. In the window that opens, you must select one or more profiles in which you want to install the same additional rights as in the current profile.

In order to see which user has installed this profile, you must click on the “Show users with current profile” button.

It is also possible to set the current profile to several users at once. To do this, in 1C:UPP you need to use processing from the “Administration” -> “Group processing of users” menu. In the window that opens, you can add users manually or using selection.

Roles in 1C:UPP

Each profile can be assigned multiple roles.

In this case, access to objects is determined by the rule: an action is allowed if it is allowed for at least one role of this profile.

There are three types of roles:

1. Mandatory. Without these roles it is impossible to work in the configuration. The only required role is "User". It is assigned by default to users of any profile.

2. Special. These roles provide users with functionality and determine access rights to directories and documents.

3. Additional. These roles determine user access to various service or regulatory configuration mechanisms.

Special roles in 1C:UPP

Shift master

The role determines the ability to enter operational production accounting documents: "Shift foreman's report", "Shift composition report" and "Shift completion".

User Administrator

Provides access to objects of the "User Administration" subsystem: directories "Users", "Profiles", setting up access at the record level and others.

Full rights

Grants full access rights to all system objects (with the exception of direct deletion from the database). This role can only be assigned to database administrators and should never be assigned to users.

Because the system does not perform any checks for this role:

· Monitoring the sufficiency of inventory items

· Control of accounts receivable level

· Control the date of prohibition of editing

· And others.

Additional roles in 1C:UPP

Administration right

Provides access to the administrative functions of the system: deleting objects from the database, configuration, managing totals and others.

Administration of additional forms and processing

The role allows you to add entries to the "External Processing" directory, which stores:

· External processing of filling tabular parts

· External reports and processing

· External processing connected to reports

Administering Saved Settings

Assigned to users who need to work with saved report settings based on a universal report. That is, it determines access to delete and create entries in the “Saved Settings” information register. This role is also required to be able to add custom fields in reports built on the access control system.

External connection right

If the user will connect to the database via an external connection (web extension, connection using OLE technology), he needs to install this role.

The right to launch external reports and processing

Allows users to run reports and processing located in external files. This feature should only be provided to responsible users.

Additional user rightsth

Allow document posting without control of settlements

This option affects the visibility of the "Disable settlement control" flag in the "Sales of goods and services" document. Typically, ordinary employees are prohibited from shipping inventory items if the terms of mutual settlements are not met, but for management users this should be possible.

Directory "Users" in 1C:UPP

The directory stores users working with the system. Elements of this directory are indicated in all documents in the “Responsible” field.

There is a classification of users into groups. Moreover, there are two types of groups.

1. The first ones affect the hierarchy in the “Users” directory and are used primarily for ease of navigation through the directory. In this case, each directory entry belongs to one parent group.

2. Also exists directory "User groups", which is designed to restrict access at the record level. In this case, one user can be a member of several user groups. User inclusion in groups is ensured through the menu item “Users” -> “User Groups”.

Figure 1 - Directory "User groups"

Record-level access restrictions

The mechanism of line-by-line data access control is used when it is necessary to organize access only to certain elements. This mechanism is often called RLS. For example, each sales manager works with his own group of clients. The user is prohibited from viewing documents for clients not in his own group. This problem is solved by restricting access at the record level.

Access restriction at the record level is configured for the "User Groups" directory. If a user is a member of several groups, then the data areas that will be available to him are combined. For example, for the group "MSK" data is available for the organization "MebelStroyKomplekt", and for the group "Southern Federal District MSK" - for the organization "Southern Federal District MebelStroyKomplekt". Then if the user is assigned to both groups, he will enter documents on behalf of both organizations.

Enabling restrictions at the record level can be done from the "Account Manager" interface, main menu "Access at the record level" -> "Options". Here you can configure which directories you want to use to configure the restriction.

RLS is directly configured using the access rights configuration form. You can open the form from the main menu "Access at the record level" -> "Access settings". You can also call the access control form from directories for which RLS can be configured.

Within the same user group, restrictions are combined using the logical "AND" condition. For example, for the group "MSK" access is configured for the organization "MebelStroyKomplekt", and for the access group of counterparties of counterparties "Buyer". Then users of this group will be able to enter documents only on behalf of “MebelStroyKomplekt”, and only for counterparties included in the “Buyer” access group.

If a user is a member of several groups, then his rights at the record level are combined across all groups. That is, the rights of different groups are summarized using the logical “OR” condition. For example, the “MSK” group has access to documents only from the “MebelStroyKomplekt” organization, and the “Complex Trading House” group. If both groups are assigned to a user, he will have access to documents from both organizations.

Record-level access restrictions apply only to specified directories. For example, in the figure, access to organizations and external processing is defined for the “MSK” user group. For all other directories, the "MSK" user group has full access at the "RLS" level. In order to access the group settings, you need to open the form using the context menu or the F2 key.

In the form of the directory element "User groups" it is indicated for which types of objects RLS will be applied, as well as the number of configured rules. It is also possible to change the composition of the group: include or exclude users from it.

If no rules are specified for any type of object, this means that there will be no access to the elements of this directory at all. For example, in the figure for the "MSK" group there is not a single row for the "External Processing" object. This means that external processing will not be available for the user of the "MSK" group. However, if the user is a member of two groups: “MSK” and “Trading House”, then all external processing will be available to him, both for reading and writing. Because the user group "Trading House" has not been assigned access restrictions to external processing.

Figure 2 - Processing to restrict access at the record level

Performance

Please note that if you enable the record-level access restriction mechanism, the system may slow down. This is due to the implementation of the RLS mechanism: a condition is inserted into each request sent to the database, where the corresponding rights are checked. Thus, each database access is a little slower, and the load on the server increases.

It is also important that the more groups a user belongs to, the slower the system will work in his session. Therefore, to increase speed, first of all, it is recommended to reduce the number of groups to which the user belongs.

Roles for which RLS is not configured

When configuring record-level access restrictions, be aware that some roles do not have RLS configured.

· The Full Rights role has full access to all objects without record-level restrictions.

· For the "Planning" role, it is possible to read (view) all objects without RLS restrictions.

· The "Financier" role allows the opening of many objects without checking access at the record level.

Therefore, when configuring a user's permission profile, be aware that adding one of these three roles may remove RLS restrictions. For example, a sales manager is configured to restrict access by organization: the user has access to data only for the MebelStroyKomplekt organization. If you add the “Financier” role to the user’s permissions profile in addition to the “Sales Manager” role, then the employee will see documents for all organizations in the “Counterparty Documents” journal.

Access control by levels in 1C:UPP - organizations, divisions, individuals

Setting up access for the directories "Organizations", "Divisions", "Division of Organizations"

The peculiarity of the "Organizations" directory is that it is not hierarchical. However, determining subordination in it is possible using the “Parent organization” attribute.

The directories "Divisions" and "Divisions of Organizations" are distinguished by the fact that a hierarchy of elements is organized in it. This means that any element of the directory can have subordinate divisions. In this case, all records are equal, that is, there is no division into groups and elements.

The features listed above mean that the value of the “Type of inheritance” attribute can be filled with either the value “Extend to subordinates” or “Only for the current element”.

The following restrictions are possible in reference books:

· Reading – determines the ability to view data in the “Organizations” directory, generate reports, as well as documents for the selected company

· Record – sets the ability to create and edit documents for the selected organization

Report on the rights system in 1C:UPP

To view configured user rights, it is convenient to use the “Rights System Report”.

The report displays the following data:

· By access restriction settings at the record level by user group

· Additional user rights by profile

·By user groups

· By user permission profiles

The report on the rights system was developed using the “Data Composition System”, so its flexible configuration is possible.

Figure 3 - Report on the rights system

View permissions by role

In order to find out which roles have access to certain objects, you need to use the configurator. In the “General” -> “Roles” branch, you can view the rights configured for each role.

If there is a need to get a pivot table in which objects will be displayed in the rows and roles in the columns, then you need to use the context menu for the root object “Roles”.

Thank you!

1C has a built-in system of access rights (this system is called 1C roles). This system is static - as the administrator assigned 1C rights, so it will be.

Additionally, there is a dynamic access rights system (called RLS 1C). In it, 1C rights are dynamically calculated while the user is working based on the specified parameters.

One of the most common security settings in various programs is a set of read/write permissions for user groups and then inclusion or exclusion of a user from groups. For example, a similar system is used in Windows AD (Active Directory).

Such a security system in 1C is called 1C Roles. 1C roles are located in the configuration in the General/Roles branch. 1C roles act as groups for which 1C rights are assigned. The user is then included or excluded from this group.

By double-clicking on the name of the 1C role, the rights editor for the 1C role will open. On the left is a list of 1C objects. Select any one and options for access rights will be displayed on the right (at a minimum: read, add, change, delete).

For the top branch (name of the current configuration), 1C administrative rights and access to launch various options are established.

All 1C rights are divided into two groups - a “simple” right and the same right with the addition of “interactive”. What does it mean?

When a user opens a form (for example, processing) and presses a button on it, the program in the built-in 1C language performs certain actions, for example, deleting documents. “Simply” 1C rights are responsible for allowing these actions (performed programmatically).

When a user opens a journal and starts doing something using the keyboard independently (for example, entering new documents), these are “interactive” 1C rights.

A user may have access to several roles, in which case the permissions are cumulative.

A breakdown of the possibilities for setting access rights using roles – 1C object. That is, you can either enable access to the directory or disable it. You can't turn it on a little.

For this purpose, there is an extension of the 1C role system called 1C RLS. This is a dynamic access rights system that allows you to partially restrict access. For example, the user sees only documents for a certain warehouse and organization and does not see the rest.

Carefully! When using the confusing RLS 1C scheme, different users may have questions when they try to reconcile the same report generated from different users.

You take a certain directory (eg, organizations) and a certain right (eg, reading). You allow reading for the 1C role. In the Data Access Restriction panel, you set the query text, which returns TRUE or FALSE depending on the settings. Settings are usually stored in an information register (for example, the configuration information register Accounting and User Access Rights Settings).

This query is executed dynamically (when trying to implement reading) for each directory entry. Thus, for those records for which the security query returned TRUE, the user will see it, but the rest will not.
1C rights that are subject to RLS 1C restrictions are highlighted in gray.

Copying the same RLS 1C settings is done using templates. You create a template, name it (for example) MyTemplate, and specify the security request in it. Next, in the 1C access rights settings, specify the template name like this: “#MyTemplate”.

When a user is working in 1C Enterprise mode, when running RLS 1C, he may receive an error message “Insufficient rights” (for example, to read the Xxxx directory).

This means that RLS 1C has blocked reading several records.

To prevent such a message from appearing, it is necessary to use the word ALLOWED () in the text of the request in the built-in 1C language.

For example:

Every novice 1C information database administrator sooner or later faces the question: how to add a user to 1C. And if in version 7 of the program the answer to this question could be given unambiguously: through the Configurator, then in version 8, depending on the version of the program, the methods for adding a user can vary significantly.

Why do you need to differentiate by users?

Each infobase user has a set of specific rights and roles. To limit access to specific configuration objects and eliminate conflict situations associated with incorrect input and correction of information, there is a list of users.

In addition, the user list allows you to:

1. Adjust the program interface, excluding from the visual display those elements to which access is not needed;
2. Record changes in the database in the context of this list.

The main rule when editing this list: a user with full (administrative) rights should always be added first.

Adding a user via the Configurator

In fact, from the programmer's point of view, the main list of users is stored in the Configurator. It is this that can be opened by going to the Administration->Users menu (Fig. 1)

In the table that opens, two columns will be visible: “Name” and “Full name” of the user. Actions with an existing user (limiting and adding rights, changing the password, etc.) can be performed by activating the line by double clicking the mouse.

To add a new user, you must click the icon on the command panel of the table or the Insert (Ins) button on the keyboard, which will open a dialog box (Fig. 2)

Rice. 2

Briefly about the form elements on the “Basic” tab:

• Name – contains text information that will be displayed in the user selection list when logging in; the name of the current user can be read in the code of program modules using the UserName() method;
• Full name – can coincide with the user name; most often the full name of the employee is written here.

1. Using internal program tools, for which you need to set a user password;
2. Using the operating system;
3. Using OpenID.

The “Show in selection list” checkbox set in the “1C Enterprise Authentication” submenu indicates that the user will be displayed in the list called up when the system starts. If you do not install it, then to log in this user will have to enter his name (as it is set in the Configurator) using the keyboard in the appropriate window.

Rice. 3

There are only four elements on the “Other” tab (Fig. 3):

• Available roles (by checking certain boxes, you can significantly limit or increase the possibilities for changing information);
• Main interface (you can adjust the visual display of the system);
• Language (main program language);
• Launch mode (managed or regular application).

Adding a user in 1C Enterprise mode

Starting from platform 8.2, adding new users became available in 1C Enterprise mode. For this purpose, the corresponding “Users” directory was added to the database.

In thin client mode, you can access it by going to the “Administration” tab (Fig. 4) -> User and rights settings -> Users

Rice. 4

In the form that opens, to create a new user, you must click the “Create” button. A window will appear (Fig. 5)

Rice. 5

As you can see, some of the elements of this window coincide with the window for creating a new employee in the Configurator. Significant differences in this method of adding:

• The user can be matched to a specific individual from the corresponding directory;
• By checking the “Require setting a password at login” checkbox, you can additionally protect the database from unauthorized access (the protection mechanism is as follows: the administrator adding a new element sets a simple password and tells it to the user, when logging into the system for the first time, this password is entered, and when the system starts, a window asking new identification data, so no one other than the user will be able to log in to the system);
• Specific access permissions for a particular user are issued not by turning his roles on and off, but by adding him to certain access groups, which can be accessed by activating the appropriate link on the form.

The profile that defines the set of rights is stored in the “User Groups” directory; you can change and add a profile in the “User Group Profiles” directory. Thus, the Administrator does not need to control each specific user; access parameters are changed for the entire group as a whole.

In the normal application mode, the “Users” directories can be found in the Operations->Directories menu (Fig. 6)

Rice. 6

In principle, the window for adding a new artist in this mode differs little from those presented above and there is no need to re-describe each of its elements.

In this article we would like to draw attention to the “Additional Information” menu (Fig. 7)

Rice. 7

It contains 4 points:

1. User Settings;
2. Contact Information;
3. Access groups;
4. Additional rights (not available when the user has a profile).

The first menu item allows you to automate some of the performer’s actions: configure automatic substitution of document details, display of calendars and events, prefixes, etc.

As experience in using the 1C system shows, the “Additional rights” menu is most often required to enable editing of printed forms of documents. This is where the corresponding checkbox is located.

The user created in the program will automatically be added to the list in the Configurator. There is no feedback in new versions of the program, which is extremely inconvenient and unusual for administrators working the old fashioned way.

The 1C program has a built-in access rights system, which is located in Configurator - General - Roles.

How is this system characterized and what is its main purpose? It allows you to describe sets of rights that correspond to user positions or types of activities. This system of access rights is static in nature, which means that as the administrator set the access rights to 1C, it is so. In addition to the static one, there is a second access rights system - dynamic (RLS). In this system, access rights are calculated dynamically, depending on the specified parameters, during operation.

Roles in 1C

The most common security settings in different programs are the so-called set of read/write permissions for various user groups and, in the future, inclusion or exclusion of a specific user from groups. Such a system, for example, is used in the Windows AD (Active Directory) operating system. The security system used in 1C software is called roles. What it is? Roles in 1C is an object that is located in the configuration in the branch: General - Roles. These 1C roles are groups for which rights are assigned. In the future, each user can be included or excluded from this group.

By double-clicking on the role name, you will open the rights editor for the role. On the left there is a list of objects, mark any of them and on the right you will see options for possible access rights:

— reading: obtaining records or their partial fragments from a database table;
— adding: new records while saving existing ones;
— modification: making changes to existing records;
— deleting: some records, leaving the rest unchanged.

Note that all access rights can be divided into two main groups - this is a “just” right and this is exactly the right with the addition of the “interactive” characteristic. What does this mean? And the point is this.

In the case when the user opens some form, for example processing, and at the same time clicks on it with the mouse, the program in the built-in 1C language begins to perform specific actions, deleting documents, for example. “Simply” 1C rights are responsible for allowing such actions performed by the program.

In the case when a user opens a journal and begins to independently enter something from the keyboard (new documents, for example), then 1C “interactive” rights are responsible for allowing such actions. Each user can have access to several roles at once, then the permission is added up.

RLS in 1C

You can enable access to the directory (or document) or disable it. You can’t “turn it on a little.” For this purpose, there is a certain extension of the 1C role system, which is called RLS. This is a dynamic access rights system that introduces partial restrictions on access. For example, only documents of a certain organization and warehouse become available to the user, and he does not see the rest.

It should be borne in mind that the RLS system must be used very carefully, since its intricate scheme is quite difficult to understand; different users may have questions when, for example, they compare the same report, which is generated from different users. Let's consider this example. You select a specific directory (organizations, for example) and a specific right (reading, for example), that is, you allow reading for the 1C role. In this case, in the remote panel Data Access Restrictions, you set the text of the request, according to which it is set to False or True, depending on the settings. Typically, settings are saved in a special information register.

This request will be executed dynamically (when attempting to organize reading) for all directory entries. It works like this: those records for which the security request has assigned - True, the user will see, but others will not. 1C rights with established restrictions are highlighted in gray.

The operation of copying identical RLS settings is performed using templates. To begin with, you create a template, calling it, for example, MyTemplate, in which you reflect the security request. Then, in the access rights settings, specify the name of this template in this way: “#MyTemplate”.

When a user works in 1C Enterprise mode, when connecting to RLS, an error message like: “Insufficient rights” (to read the XXX directory, for example) may appear. This indicates that the RLS system is blocked from reading some records. To prevent this message from appearing again, you need to enter the word ALLOWED in the request text.

The issue with access rights arises due to the need to limit the rights of a user in 1C (or a group of users), which implies a ban on performing any actions with certain objects, for example, viewing, recording, editing, etc. Or, on the contrary, due to the need to grant (expand) user rights in 1C, which in reality most often follows a system message about an access rights violation (for example, insufficient viewing rights) and the user’s request to administrators about this.

To make adjustments to the access rules and change the rights to view a particular section or for any other action, you need to go to “User and Rights Settings”, which can be done with user mode enabled on the “Administration” tab (provided, of course, that there are rights to this).

As already mentioned, access groups include specific users, and the groups themselves have access group profiles that combine roles. Essentially, a role is metadata, the variety and quantity of which depends on the configuration. As a rule, there are quite a lot of roles and it is easy to get confused in them. It is worth remembering that one extra assigned role can open access to objects to unwanted users.

A description of user rights is available on the “Description” tab.

Roles are viewed through the “Users” directory element, which can be accessed by clicking on a specific user.

A report on access rights is also generated here, which displays the status of access to specific system objects.

The rightmost column “Record-level restrictions” are additional conditions that restrict actions with database objects. Essentially, this is a query that is executed at the time of operation and tells whether it is possible or not to work with the object.

The screenshot shows that the document “Entering opening balances” is available to the user, but access is only possible to certain warehouses.

Thus, you can establish access or change rights in 1C by adding a user to a particular group in user mode.

The group itself can also be changed, for example by adding a value to the access restriction.

Administrator rights allow you to manage rights in the configurator mode, where standard roles are already defined. For example, a role with a very explanatory name “Basic rights”, as a rule, provides the ability to only read or only view an object.

To manage rights to change objects, special roles for adding/changing data are provided.

If you know which object the user does not have enough rights to, you can:

• From the opposite: look at the “rights” tab for a specific object, at the top we will see all the roles available in the configuration, and in the lower window - the rights. The presence of certain rights to the object is marked with a tick. Rights for new objects are set in the same way.

• Open the role assigned to the user, and by selecting a specific object in the left window, see the list of rights in the right window, that is, the actions that a user with this role can do with this object - reading, adding, viewing, etc.

Thus, all possible rights in the system are predefined. Read, add, modify, view, edit and other rights can be turned on or off in any role for any object. It is impossible to assign rights separately without using roles. To differentiate user rights, you must assign the appropriate role. The “All roles” table, created in the configurator, becomes a convenient tool for analyzing rights and roles.

The screenshot shows that the “Full Rights” role has the maximum amount of rights. And if the task of limiting users’ rights is not worth it at all, you can safely assign this role to all users, forever getting rid of user questions.

In practice, as a rule, in most cases, “fool protection” is still necessary. All more or less large companies need to insure themselves against unwanted data changes. This is where the roles built into 1C come to the rescue. Understanding the diversity of roles is not easy and takes a lot of time. Therefore, creating your own role to solve practical problems can often be the only way out. Let's consider this point in more detail. You can add a role in the metadata tree.

In the new role, you can differentiate rights by simply checking the boxes next to the corresponding right.

The checkboxes at the bottom of the window indicate that rights will be automatically assigned to new metadata objects/for details and tabular parts of the object for which rights are assigned, and also whether rights will be inherited relative to the parent object.

Access rights restrictions are set in the lower right window of the new role. This is a powerful tool that allows you to restrict rights at the record level, i.e. provide access to exactly the necessary data. If a simple assignment of rights can only “straightforwardly” give or take away rights to act with an object, then the restriction mechanism allows you to flexibly configure access rights regarding data. For example, limit reading and viewing data for only one organization.

The data access restrictions designer allows you to create a condition by which access will be limited.

Restricting access rights is described in the form of language constructs. To facilitate their creation, the use of constraint templates is provided. It should be noted that the use of this mechanism directly affects performance, because the system, when accessing any object, needs to read and comply with these restrictions. This process takes up computer resources and slows down work.

In conclusion, I would like to note that 1C, as a developer, has taken care of the availability of ample opportunities for administrators in terms of editing rights in their software solutions. And if at first glance these tools may seem complex and redundant, then later, especially when trying to build an effective access scheme in the context of a multi-level, branched personnel structure in an enterprise or organization, it becomes clear that the functionality of the program fully corresponds to real needs.