1s 8.3 get the current user on the client. How to get information about configuration roles

• CURRENT RELEASES 1C
• EXAMPLES OF CODE ON THE 1C PLATFORM

Roles, access rights in 1C 8.x

How do I know if a certain role is available to the current user?

If Not RoleAvailable("Manager") Then Report("Viewing requests from customers is not allowed!"); endIf;

How do I get information about configuration roles?

Function List of Possible RolesConfiguration() List of Roles = new List of Values; RolesConfiguration = Metadata.Roles; For each Role from RoleConfiguration Loop RoleList.Add(Role.Name); EndCycle; returnListRole; EndFunction

How to execute code without checking permissions?

1. Use a privileged module 2. Place program code that must be executed WITHOUT CONSTRAINT CONTROL in common module with the module's PRIVILEGE flag set. Use a privileged mode of execution of program code Similar to the mode of operation of code of privileged modules. The mode can be turned on/off using the built-in language: SetPrivilegedMode(<Включить>) Parameter<Включить>(required) Type: Boolean. Determines whether privileged mode will be enabled: True - enable the mode; False - turn off the mode. The PrivilegedMode() function allows you to determine whether privileged mode is enabled or not. Using privileged mode allows, firstly, to speed up work, since restrictions on access to data will not be imposed, and secondly, it allows you to perform operations with data on behalf of users to whom this data is not available. Privileged mode is recommended when you logically need to disable permissions checking, or when you can disable permissions checking to speed things up. It is acceptable to use privileged mode when working with data on behalf of a certain user does not violate the access rights established for this user.

  5
 When more is required fine tuning access, the RLS - Record Level Security mechanism comes to the rescue. System configurations "1C:Enterprise" 8 was initially positioned as a program for multi-company accounting, and one of...   3
 Starting with platform 8.0 of the 1C Enterprise system, it is possible to restrict user access rights at the record level. For this purpose, the RLS (Record Level Security) mechanism is used. Such “fine” tuning can be...   3
 I often come across questions regarding software creation and user rights settings. In this article I will give examples for Normal and Managed applications that programmatically create a user in...   2
 Question: I have added a new user. I create a new interface (by copying an existing one) and specify this interface as the main one for this user. The problem is that the new interface created...

1C 8.3 session parameters— a variable that stores the value of the desired parameter for the duration of the user session. Essentially, this is a kind of global variable tied to the current user's session.

Using session parameters in 1C

Session parameters are set only programmatically; there is no universal interface for setting session parameters in the system. They are usually set at system startup, in the “Session Module”. If a parameter is not defined, an error will be raised when accessing it.

Example of setting a 1C session parameter

Let's look at a typical example of using session parameters - setting the current user. I will take an example from preparation for.

In the metadata tree we will create new parameter session - CurrentUser, assign it a type - DirectoryLink.Individuals:

Get 267 video lessons on 1C for free:

In the session module, we will create a procedure in which the current session parameter will be determined:

Procedure code:

Procedure Setting Session Parameters (Required Parameters) // looking for physical person by username TechUser = Directories. Individuals. FindByName(UserName()) ; //if not found, create a new one If TechUser. Empty() Then NewUser = Directories. Individuals. CreateItem() ; NewUser. Name = UserName() ; NewUser. Write() ; CurrentUser = NewUser. Link; EndIf ; //assign to the session parameter CurrentUser a link to the directory of individuals Session parameters. CurrentUser = CurrentUser; End of Procedure

The parameters under consideration in 1C:Enterprise are presented as a metadata object. Essentially, it is nothing more than a global variable that is bound to the current session.

A global variable is the same variable as any other, but its peculiarity is that it can be accessed from anywhere in the program, and in the case of a session parameter, this only works within the current session.

Because the session parameter is a metadata object, it has certain features:

• It may be of a certain type. The types allowed are determined by the platform. The list of them is quite extensive, but even if in this list there is no need for you, you can always serialize the value and store it in a parameter as a string.

• Rights to it, like to any other metadata object, can be limited by roles (both writing and reading). However, there is a peculiarity when using it in RLS, but this will be discussed below.
• It has a limit on the amount of data that can be placed in serialized form. Their volume should not exceed 4 GB.

If the session parameter type is:

• FixedArray
• FixedCollection
• FixedStructure

Then the value of the collection element could be Undefined.

The main area of ​​parameters is the use of their values ​​in RLS (Record Level Access Restriction) queries.

For example, we need to set a condition for the current user in the RLS request. To do this, we set up the “CurrentUser” session parameter and set the value from the built-in language code:

SessionParameters.CurrentUser =<значение>

Table.User = &CurrentUser

When using the session parameter in this way, read permissions for the parameter are not taken into account, but you can try to get their value from the built-in language:

CurrentUser = SessionParameters.CurrentUser;

You can set a session parameter, that is, its value, only programmatically and only on the server. To do this, you will need to call a server procedure from the client. When accessing a session parameter (setting, receiving), if the parameter is not initialized, the procedure will be called SettingSessionParameters in the session module. This procedure has one parameter Required parameters– an array of set session parameter identifiers. SettingSessionParameters also called when establishing a connection with information base before calling all other handlers. In this case Required parameters will be equal Undefined.

It is recommended to use delayed (lazy) initialization, that is, initialize session parameters on demand, and not at system startup, since not all session parameters are required directly at system startup. Lazy initialization is done like this:

Procedure SettingSessionParameters(SessionParametersNames) If SessionParametersNames is Undefined Then If ParameterName = "CurrentUser" Then SessionParameters.CurrentUser = ; ElseIf ParameterName = "CurrentOrganization" ThenSessionParameters.CurrentOrganization = ; // etc. endIf; endIf; EndProcedurevalue>value>>

Because the session parameter is bound to the session, you won't be able to access the session parameter from a method running in the background because it will be a different session. This nuance may come as a surprise, so it is better to prepare for it in advance by passing the desired value as a method parameter and initializing it from the session parameter at the beginning of the procedure.