Hello dear blog readers. I had to delay the next article a little due to intensive reporting and a large number of incoming questions about this. By the way, you can ask your questions in the chat or send messages directly to me by email. But enough advertising) Today we will talk about new useful and interesting opportunities which he gives us new platform 1C Enterprise 8.3 and configurations built on its basis: Salary and HR Management 3.0 And Enterprise Accounting 3.0.
The article will talk about how to configure user access yourself only to those documents, reference books and reports that he needs for work and limit access to the rest. This will help us command interface with flexible settings, which appeared in 1C programs version 3.0. Discuss features differentiation of access rights on program objects we will be based on the 1C ZUP 3.0 configuration, but the same mechanism can be successfully used for software product 1C Enterprise Accounting 3.0. Actually, I studied this issue when I assisted in setting up users in Bukh 3.0.
How to create a user in normal user mode of 1C edition 3.0
✅
✅
✅
I would like to immediately note that we will have to work with both the normal user mode of operating the program and the configurator mode. There’s nothing scary or complicated about this, you don’t have to program) I’ll also immediately note that the screenshots in this article will be presented from something new that recently appeared in programs 1C edition 3.0 of the Taxi interface. To switch to it, just open the service menu and find the parameter settings there. In the settings window, in the radio button group " Appearance“You should select the “Taxi” interface and restart the program. Although, for those who are comfortable staying in the normal interface, all documents, reference books and settings that I will discuss in the article are identical in these interfaces.
Let's look at a situation where you don't yet have the required user. You must create a user in normal user mode. Go to the “Administration” section of the main menu and there we find the “User and Rights Settings” item.
If required, you can immediately set a password.
Now, regarding the access rights for this new user. There is no need to install them. Setting access rights can be accessed directly from the form in which the user is configured. Just click on the “Access Rights” link at the top of the page. So, it is necessary that in the access rights (and on the tab "Access groups", and on the bookmark “Allowed actions (roles)”) everything was empty. We will configure rights not in user mode, but in the 1C configurator, a little later.
But there is an important feature in this regard. It is necessary that there is at least one user in the database who has administrative rights. My user is Administrator. He is a member of the access group "Administrator" and has roles "System Administrator" And "Full rights."
Now we should go to the configurator mode and continue configuration there. To do this, when starting 1C, select the desired database and click the “Configurator” button. Just don't log in as a new user. He does not yet have any rights, and work will be impossible. You must log in as a user with full rights, in my case it is “Administrator”.
 |
After opening the configurator window, let's make sure that the one we created is also displayed here. new user. The list of users in the configurator is stored in the main menu section “Administration” -> “Users”.
Please note that the user has a question mark. This means that no role is defined for it, i.e. in other words, no access rights are specified. "Roles" is a configuration object. Each role establishes a set of documents, directories, and reports that a user with this role has access to. We can see all available roles if we open the user and go to the “Other” tab.
Let me remind you that we need to configure an employee’s access to a random set of documents, reference books and reports. At the same time, I didn’t even specify which set we were talking about, it’s not that important. And the important thing is that for such cases there is not and cannot be a suitable role in the configuration. 1C developers are not able to provide for everything possible options restrictions on access to objects that are encountered in practice. And the end user’s requests can be very extravagant.
Editing mode for a standard configuration in 1c
✅ Seminar “Lifehacks for 1C ZUP 3.1”
Analysis of 15 life hacks for accounting in 1C ZUP 3.1:
✅ CHECKLIST for checking payroll calculations in 1C ZUP 3.1
VIDEO - monthly self-check accounting:
✅ Payroll calculation in 1C ZUP 3.1
Step by step instructions for beginners:
As you probably already understood, I am leading to the fact that we will have to create your own role. In this case, one important detail should be discussed. Creating a new role means making a change to the standard configuration. For those whose configuration has already been finalized and is not standard, nothing will change. To begin with, I’ll tell you how to determine whether the configuration is standard or not.
First, you need to open the configuration. To do this, in the “Configuration” section of the main menu, click "Open configuration". After this, a window with a tree structure of all objects will appear on the left side of the configurator information base. Secondly, also in the “Configuration” section of the main menu, go to “Support” -> “Support Settings”. A window of the same name will open. If the window looks like in the screenshot, then your configuration is standard. By this I mean the presence of the inscription "Configuration is being supported" and the presence of a button.
So, if you have a standard configuration, then we will have to enable the ability to change it, otherwise we will not be able to create a new role. Separately, I would like to note that from the point of view of updating there will not be any special difficulties, since we will be creating a new role and not changing existing ones, therefore all standard configuration objects will remain standard. To enable the ability to edit the configuration, you need to in the window "Support Setup" press the button "Enable editability".
Perhaps in future publications I will write in more detail about this kind of update. So, in this window we need to answer “Yes”.
Next, the “Support Rules Settings” window will open, where you need to select the “Supplier object is edited while maintaining support” radio button. For our task this will be quite sufficient. Just keep in mind that after clicking “OK” you will have to wait a bit before continuing.
After this, the locks should disappear in the tree of configuration objects (remember, when we opened the configuration, it opened on the left side of the configurator), and the message “Support Settings” will appear "The configuration is being maintained with the possibility of change."
How to create a new role in the 1C configurator
✅ Seminar “Lifehacks for 1C ZUP 3.1”
Analysis of 15 life hacks for accounting in 1C ZUP 3.1:
✅ CHECKLIST for checking payroll calculations in 1C ZUP 3.1
VIDEO - monthly self-check of accounting:
✅ Payroll calculation in 1C ZUP 3.1
Step-by-step instructions for beginners:
Now we can start creating a new role. Let me explain once again what a “Role” is - this is a set of rights that determine the ability to view or edit directories, documents and other configuration objects. View and edit are the most understandable permission options, but there are many others. To make it clearer, let’s select the “Full rights” Role in the object tree (General -> Roles -> Full rights). The settings window will open. In this window, all program objects (directories, documents, reports, etc.) are listed on the left, and on the right are the rights that are defined in this role for each of the objects. You can see this in the screenshot.
Now let me remind you of the problem. We need to ensure that the user can work only with a limited range of documents, reports and reference books. The most obvious option is to create a new role and define access only to the necessary objects. However, the configuration contains a large number of all kinds of service objects, such as constants, common forms, common modules, registers for various purposes, and for normal user operation it is necessary to have access to these common objects. There are quite a lot of them and it is very easy to miss some object. Therefore, I will propose a slightly different approach.
Let's create a new role by copying the default Full Rights role. Let's call this new role “Role_Frolov”. To edit the name of a role, you need to go to properties and specify a new name without spaces.
Now let's set this role for the user “Frolova”. Before this, we need to save the information base so that the newly created role appears in the list of available user roles. Press the F7 key or click the corresponding button in the toolbar. After this, we can set this role for our user. Go to the list of users (Administration -> Users) and on the “Other” tab, check the box next to the “Frolov Role” role. Click "Ok".
For now, this role is completely identical to the original one (“Full rights”). We will leave it this way. Bye. And we will set up access to documents and reference books, using the flexible configuration capabilities of the 1C program command interface.
How to configure command interface elements in 1C
Now we have to return to normal user mode, i.e. as during normal work in 1C. We need to launch under our new user - Frolov S.M. This can be done from the configurator. However, you must first set the setting so that when you start the Enterprise from the configurator, it will ask the user under which it should be launched. To do this, in the main menu, select “Tools” -> “Options” and on the “Launch 1C:Enterprise” tab in the “user” section, set the “Name” switch, click OK and we can launch the user mode directly from the configurator. To do this, use the command from the main menu “Service” -> “1C:Enterprise”. And don’t forget that we must select the user Frolov.
When the program starts under the user Frolov, all objects will be available to him, since his role was created by copying full rights, and we did not change anything. Let's assume that this user only needs to retain the capabilities of personnel records, but not everything, but only admission, transfer and dismissal. First, you need to remove all unnecessary sections and leave only one - “Personnel”.
To do this, go to the service menu View -> Setting up the section panel. In the window that opens, move all unnecessary sections from the right column to the left.
Now note that we will only have 2 sections “Main” and “Personnel”. We cannot remove the “main thing”, so it is necessary to leave only the necessary links in this section. To do this, go to this section and click in the upper right corner "Navigation settings". This window is similar to the one in which we removed unnecessary sections, and it has the same principle of operation. In the right column we leave only necessary documents and reference books.
And as a result, in the “Main” section we will have only the set of documents, reports and reference books necessary for the personnel officer.
As for the “Personnel” section, it can be left in its original form or configured more finely if, for example, the personnel officer does not have to deal with sick leave, vacations and maternity leave. In the same way, these documents can be removed from the navigation panel. I will not dwell on this in detail, since it already depends on the specific task.
I’ll just point out one more element that also needs to be configured to prevent the user from accessing data that is closed to him. This element is « Home page "or whatever they call it "Desktop". It opens automatically on startup user mode. To set up the home page, open the service menu View -> Set up home page. A window will open in which you can configure the composition of the left and right columns from the list of available forms. The choice of available forms is not so large. So, for example, for our situation, where an employee is engaged in personnel, we should not give him access to such a form as “Salary calculation: Form”. But I decided to remove all forms altogether, so as not to tempt the user again. The start page will be blank.
Final setup of the user role in the 1C configurator
So, let's assume that we have configured access to all necessary documents and reference books for our personnel officer, using the capabilities of the command interface. Now main question How to make sure that the user himself cannot open the interface settings and give himself access to prohibited documents. To do this, return to the configurator and select General -> Roles -> Frolov_Role in the configuration object tree. Let's open this role. Now in the window that opens, position the cursor on the inscription “Salary and Personnel Management”, and in the “Rights” column we look for the setting "Saving user data". Uncheck the box next to this setting. This means that the user himself will not be able to customize the contents of the section panels, navigation bar and desktop, and therefore will not have access to prohibited sections from the command interface.
To verify this, you can go to the database under the user Frolov and try to open the settings for sections or navigation. However, you will not find the “View” item in the service menu. It became unavailable because we removed the right to “Save user data” from the user role Frolov.
Thus, we limited the user's visibility of objects to only those directories, documents and reports that he really needs for work. At the same time, in the configurator mode, only one checkbox was edited in the rights of this employee.
However, that's not all. We have limited explicit access to prohibited objects. However, the user may end up in an unwanted directory or document from a document accessible to him. So our personnel officer Frolov can open the “Organizations” directory from the “Hiring” document and accidentally or purposefully change some data there. To prevent a similar situation from happening, you should review and analyze all objects that are associated with documents and reference books available to the user. And then in the configurator, open the role of our user and prohibit editing or even viewing unwanted objects. The specific option is up to you to choose, depending on the task at hand.
That's it! We solved a rather complex problem in a not very complicated way. Anyone who has read to the end can rightfully be proud of themselves) If I missed something and you have any comments, I will be glad to see you in the comments to the article.
New interesting materials will appear soon on.
To be the first to know about new publications, subscribe to my blog updates:
The purpose of the “Settings Storage” configuration object is clear from the name - to store various user settings. The scope of application of this object is wide - in any configuration, however serious, it is necessary to store some user settings.
For the convenience of programmers, in each configuration there are several standard settings stores; in addition, it is possible to create as many additional settings stores as needed.
First, let's look at the standard settings stores that are present in any 1C configuration starting from version 8.2.
Standard settings stores
So, by default, the configuration contains the following settings stores:
- Report Options Storage - to access the settings of report options.
- Storage of Custom Report Settings - for accessing custom report settings.
- Form DataSettings Storage - for accessing user settings for form data.
- General Settings Storage - to access general settings.
- SystemSettings Storage - for accessing system settings.
- Storage of UserSettings of Dynamic Lists - for accessing user settings of dynamic lists.
Each of these stores can be accessed as a property of the global context.
The programmer can use standard storage for his own needs, saving various settings in the context of the user, object and the setting itself.
To work with settings repositories (both standard and those added by the programmer), the following methods are used.
Recording and receiving settings:
GeneralSettings Storage.Save(ObjectName,SettingsName,SettingsValue,SettingsDescription,UserName); SettingsValue = GeneralSettings Storage.Load(ObjectName, SettingsName, SettingsDescription, UserName);
Removing redundant/unnecessary settings:
GeneralSettings Storage.Delete(ObjectName,SettingsName,UserName);
Getting a list of settings:
SettingsValueList = GeneralSettings Storage.GetList(ObjectName, UserName);
The parameters “ObjectName”, “SettingsName” and “UserName” must be of string type.
In the database, all settings are stored in a separate table.
Settings repositories created by the programmer
Now let's talk about those settings repositories that are created by the programmer. In general, the programmer is not limited in any way in his desire to create a new settings store, but usually separate settings stores are created for the following reasons:
- it is necessary to move settings between databases;
- reference control is required when storing settings;
- a special structure of 1C settings is required.
Settings stores are added in the corresponding configuration section.
Key Feature settings stores created by the programmer require manual implementation of methods for writing and retrieving values (Save() and Load()). In these methods, the programmer must describe saving (in information registers, files, directories, etc.) and loading settings using the built-in language.
Otherwise, the principles of working with the created repository are practically no different from working with standard settings repositories.
The created repository can be accessed this way:
Settings Storage.StorageName.Load();
In addition, the created storages can replace the standard ones in various configuration objects and in the configuration itself.
Managed forms have two properties:
- Automatic saving of data - if the “Use” value is selected, the data will be saved automatically to the standard storage of form data settings;
- Saving data in settings - if the “Use list” value is selected, then the “Save” column will appear in the form details window, with which you can specify which form details should be saved, and you will also be able to select the settings storage for this data.
That's all, I hope this article helped you.
User settings in 1C are usually divided into three parts.
Firstly, the 1C platform allows each user to make their own own settings 1C for convenience. For example, settings for 1C SKD reports.
Secondly, in each typical and non-standard configuration there are usually many processing units that perform service actions. Processing requires adjustment. It's a shame to waste time re-entering settings every time you open processing.
And finally, thirdly, for the programmer himself, in order for the program to be universal, it is better not to write some default values in the program code, but to store them in some settings.
Where to store all these settings in 1C?
How 1C settings were saved before
The platform offered the following standard option:
- When it is necessary to remember the 1C setting, the programmer uses the function
SaveValue("SettingsName", Value); - To read the 1C setting, use the function
Value = RestoreValue("SettingName", Value);
Accordingly, the programmer creates buttons for saving and restoring 1C settings, and the user uses this mechanism (or the programmer saves them automatically).
As a value, you can use not only a number or a string, but also, for example, a Structure - a type that allows you to store many values with their names, for example:
Settings = New Structure();
Settings.Insert("SettingsName", Value);
Value = Settings.SettingsName;
The 1C settings are saved for the user who pressed the programmer-developed button to save 1C settings (or under whom these actions were performed automatically). 1C settings are stored in a text file in the folder with the database (when using a file database).
Also, the programmer was free to develop his own arbitrary methods for storing 1C settings using conventional methods - for example, by working with text and XML files– save 1C settings randomly to a file.
In typical configurations, 1C report settings were saved to the information register. And the settings for 1C SKD reports can be saved to an XML file.
Standard storage of 1C settings
All these features remain in the new platform 8.2, but finally a certain “ standard method» saving settings – 1C settings storage.
The mechanism is divided into two parts - standard and custom 1C settings storages. The standard one is implemented in the 1C platform, the custom one is a 1C object that is created and programmed by the programmer.
The standard 1C settings storage is used by the platform by default in the thin client to save the user's 1C settings in the following platform mechanisms:
- Command managed interface
- Forms
- Report settings and options.
The programmer can use the standard 1C settings storage from program code in the 1C language in the following way: like that what was before:
- When you need to remember a setting
GeneralSettings Storage.Save("ObjectName", "SettingsName", Value); - To read the setting
Value = GeneralSettings Storage.Load("ObjectName", "SettingsName", Value); - To get a list of settings
List = GeneralSettings Storage.GetList("ObjectName");
1C settings are saved directly in the database, in special tables.
As you can see, compared to the old mechanism, an additional section has been added - the name of the object. Platform, when automatically saving, the name of the 1C object is used in the metadata indicating the type, for example:
Report.Sales
It is also possible to manage the user name for which 1C settings will be saved, specifying it as the last parameter.
There are the following standard 1C settings storages:
- System Settings Storage
- General Settings Storage
- FormsDataSettings Storage
- Storage of UserSettings of Reports and Storage of Report Options.
1C settings storage
The programmer can create his own settings storage in the configurator.
This is supposed to be done in the following cases:
- Reference control when storing 1C settings
- Migration of 1C settings when using
- Special structure of 1C settings (for automatic compliance)
- Overriding standard storages.
To create your own 1C settings storage, you need to add one in the configurator in the configuration window in the General/1C settings storage branch.
You can override the standard 1C settings stores used by the platform in the configuration properties (the root branch of the configuration, which programmers usually call Root or Head).
If there is an empty line in the properties, the standard 1C settings storage is used, otherwise, the selected one is used, but the standard one is not used.
It is possible to use the storage automatically:
In a thick client, to use it, you need to write a direct call to save 1C settings in the 1C language code:
Settings Storage.StorageName.Save();
When adding your own 1C settings storage to the configuration, you need to write handlers for loading and saving values in the 1C language, otherwise the storage will not work.
Actually, in these functions you yourself write the code for saving the value (in a standard storage or in a file or in a directory or in an information register, etc.), and loading the value.
To the data. When we talk about restrictions, we mean a list of users working with information and assigning them specific rights. What does this give? First of all, it creates information security The organization, secondly, will make the work easier and simpler for information users, leaving them with access only to the necessary documents.
The list of 1C:Enterprise 8 programs has two types of rights → they are called basic and interactive. Basic rights are always checked, regardless of the method of opening infobase objects. The main ones are the rights to “Read”, “Change”, etc.
Interactive rights are considered to be “View” and “Edit” rights. Interactive rights are checked while the user performs interactive actions → when viewing data in the form, when editing data in the form, etc. If the user tries to perform an action for which he does not have rights, the system will issue a warning: “Access rights violation!”
The list of rights has a hierarchy, resulting in a chain of relationships that is monitored by the system. This means that after removing permission for a certain right, the system removes permissions for rights that depend on it, and vice versa. For example, an object has “View” and “Edit” rights. When removing the rights for “View”, the right for “Editing” is automatically removed.
In “1C: Accounting 8 for Ukraine” several lists of rights have been created, each of which is necessary for a specific role. The set of roles can be seen in the Configurator by opening the database, which is displayed in “Database Configuration”.
On the left side of the window there is a tree of application solution parameters. On the right side of the window → list of rights that are allowed for the object selected on the left side of the window. All operations with a checkmark next to them are allowed. That is, for the “Accountant” role, when working with the “Advance Report” document, the actions “Read”, “Add”, “Change”, etc. are allowed.
If a user does not have the right to access a specific directory, then he also does not have the right to view and edit all those fields of objects of the application solution that uses an element of this directory. For example, a prohibition on access to the “Counterparties” directory allows the user to view and edit documents that indicate the counterparty, but cannot view or change information about the counterparty. In these documents, instead of information about the party to the transaction, the message “Object not found” will be displayed in the required field.
Database configuration
Programs created on the basis of the 1C:Enterprise 8 platform have specified settings for access rights to information stored in the database. This setting is performed by specialists in the query language "1C: Enterprise 8" in the fields "Data Access Restriction" ("Database Configuration").
User list
To restrict access to the database to unauthorized persons, you need to create a list of users who have permission to work with the system. This can be done both in the Configurator and in 1C:Enterprise mode. In the Configurator, it is opened by the “Administration - Users” command, in the “1C:Enterprise” mode → in the “Users” directory through the “Tools - User and Access Management - User List” menu.
Both lists are linked by the user name (directory code) and have the same data. Administration of basic settings can be performed in both modes. The “List of Users” displays a window for the list of users in the Configurator, and a window for changing settings for the user Bondarenko (administrator) is also open.
In the “Basic” tab, in the “Name” field, a short user name is entered. It is this that is displayed by the selection dialog during startup and by it the user, who is specified in the Configurator, is identified with the “Users” directory element; in the “Full name” field it is possible to enter any user name.
User list
User authentication
The program has two options for user authentication: using the 1C system itself (checkbox next to “1C Authentication: Enterprise”, “List of Users”) and when the user is authorized using operating system(checkbox next to “Windows Authentication”), then any user operations to enter the “Username” and password are not needed, because in this case, when launching the application solution, the system selects the MS Windows user name, and then, based on it, selects the required 1C: Enterprise user.
In addition, the window for changing user settings makes it possible to enter a password for the right to start the program on behalf of this user and activate the ban on changes specified password(checkbox next to “The user is not allowed to change the password”). The checkbox next to the “Show in selection list” setting adds a new user to the selection list when starting the configuration.
Role selection
By creating a list of users, one user can receive several roles that are available while working with the application solution. This can be done in the “Other” tab by checking the box next to the required roles in the list of “Available roles” (“Select an object. Interface”). Also remember: if at least one user role allows a specific action on an object, then access is allowed.
There are three main roles in the configuration: “Accountant”, “Chief Accountant” and “Full Rights”. Other roles (“Administration Right,” “Additional Forms and Processing Right,” and others) are auxiliary and can be used to grant rights to a user who does not have full rights (the “Accountant” and “Chief Accountant” roles).
The roles “Accountant” and “Chief Accountant” differ in their rights to change data that relate to the organization’s accounting policies. For example, “Accountant” cannot enter parameters for accounting, accounting policies, etc.
To start a program normally, you need a minimum list of rights. This set has the role "Accountant". If an ordinary user does not have full rights (and this is usually the case), he should be assigned at least this.
Selecting an object. Interface
Each directory group has the ability to specify a list of users, which will be saved in the table of the directory element (“User Groups”). In this case, one user can be a member of several user groups, and the created user groups can be used when setting up access rights to different objects along with elements of the “Users” directory. That is, in the mechanism for setting access rights in the “Organizations” directory, instead of assigning access to certain users, it is worth entering not a user, but a group of users. Thanks to this, all users who are members of the group will have access to the selected enterprise.
In addition, the directory contains a predefined element “AllUsers”, the list of users of which cannot be changed and is empty.
User groups
Data prohibition date
There is another mechanism that helps insure data against accidental or intentional correction (deletion). This is the “Data modification prohibition date” in the “Service → User and access management” tab. In the pop-up dialog box, you have the opportunity to enter a date before which you cannot add, correct or delete documents in the database. The “Date of prohibition of changing data” displays a demo example in which the date of prohibition of updating information is set to “01/31/2011”. This is due to the entry into force of Section III of the Tax Code.
Data prohibition date
There are a number of ways to enter a ban date for changing data:
→ “General date”
→ “By organizations”
→ “By organizations and users.”
Attention! A user with the “Accountant” role cannot adjust the ban date for changing information, and the restriction on the ban date does not apply to users who have access to the “full rights” role.
Then, after entering the prohibition date, when entering a new document with the date of the closed period, the software will display the message: “Editing data for this period is prohibited. Changes cannot be recorded..."
They find us: setting up user rights in 1s 8 2, editing user rights 1s 8 2, restricting rights in 1c 8 2 accounting, setting restrictions on document editing in 1c, limiting access to data in 1c 8 2 accounting, 1c setting up roles, viewing rights in accounting, how to set up limited user rights in 1s 8 2, as in the program configurator 1 p 8 3 limit user rights, how to change the user’s work period in the configurator
In order to differentiate access rights, in 1C 8.3 there are special configuration objects - roles. They can later be assigned to specific users, positions, etc. They indicate which configuration objects will be available. It is also possible to specify the conditions for providing access.
Roles are configured in the configurator. They can also be assigned to specific users, but for convenience, 1C has implemented a mechanism for access groups. In the user directory, open (“Administration - Setting up users and rights - Users”) the card of any employee and click on the “Access Rights” button. The interface may differ in different configurations, but the essence is the same.
You will see a list of entries in the “Access Group Profiles” directory. The checkboxes indicate those whose rights will be available to the user.
The directory of access group profiles (“Administration - Setting up users and rights - Access group profiles”) contains a list of roles that will be available to the user when assigned. Available profile roles are marked with flags.
Users often have the same sets of roles. Using this mechanism allows you to significantly simplify the configuration of rights by selecting access group profiles rather than the roles themselves.
Roles in the configurator (for programmers)
Roles indicate which objects and under what conditions will be available to the user to whom they are available. Open any role and you will see two tabs: Rights and Restriction Templates.
The first tab displays a list of configuration objects and the rights assigned to them for this role.
When allowing any actions to be performed with an object, it is possible to specify a restriction of access to data. This mechanism is called RLS and allows you to configure rights at the record level. It is quite interesting, but if used actively, performance may decrease.
At the bottom of the form, roles can be configured automatic installation right:
- for new objects (permissive rights);
- to details and tabular parts (rights are inherited from the owner object)
- on subordinate objects (rights are assigned taking into account the rights on parent objects).
Rights can be assigned both to bleaching objects and to the entire configuration as a whole. In any role, on the “Permissions” tab, select the item with the name of the configuration. All possible roles for it will be displayed on the right. This contains program launch modes, “All functions”, administrative and other rights. When you click on any right, its description will be displayed below. There is nothing complicated here.
The rights settings for other configuration objects are similar: reading, adding, deleting, posting (for documents), managing totals (for accumulation and accounting registers) and others. It is important to note the right to “Interactive deletion” here. If it is available, users will be able to physically delete data from the program (shift + delete). For important objects, assigning this right is extremely undesirable.
Programmatic access rights check
To check whether a user has a role, use the following function:
- RoleAvailable("System Administrator")
In the case when the role being checked is assigned to the user, the function will return the value “True”. Otherwise – “False”.
In order to perform any actions with an object that is not accessible, you can use the following method:
- SetPrivilegedMode(True)
After enabling privileged mode, no rights checks are performed. After completing actions on inaccessible objects, you must call this method again with the “False” parameter to disable this mode. Remember that in the client-server version, when executed on the client, this method does not perform any actions.
To check whether the privileged mode is set, use the function (returns “True” or “False”):
- PrivilegedMode()
User interface without access rights
If a user tries to perform any action in the program, but for which he does not have rights, a corresponding warning will be issued.
There are cases when some field displays the format “<Объект не найден>" with a GUID, the user may also not have enough rights to read the value it contains. To test this theory, just look at the value of this field with full rights. If the inscription does not disappear, there is a possibility of a broken link.
