Every 1C:Enterprise administrator knows that the task of separating user rights and correspondingly changing the working interface is one of the main ones when implementing an accounting system or adding new users to it. The efficiency of work and data security depend on how well this task is completed. Therefore, today we will talk about the features of setting up user rights and interface in a managed application.

First of all, I would like to note the main aspects of this type of settings. Many approach this issue one-sidedly, considering them purely as a measure of protection against unauthorized access to data or unqualified modification. At the same time, they forget about the other side of the coin: creating a simple and convenient working environment. In cases where the user's working interface is overloaded with unnecessary items, the meaning of which is not completely clear to him, a false impression arises about the excessive complexity of the program and there is a fear of making a mistake. It is clear that this does not in any way contribute to increasing employee productivity.

Ideally, each employee should see only those interface elements that he needs to perform his immediate duties. Then it will be easier to work, and there will be no temptation to climb where you shouldn’t. Moreover, it makes sense to perform such settings even when some subsystems are simply not used or restricting access to them is not required. This will make the interface simpler and more understandable, and, therefore, the user’s work will be easier and more comfortable.

If we go back a little, we can remember that in conventional configurations Roles And Interfaces were part of the configuration and for them fine tuning it was necessary to enable the possibility of making changes, and in basic versions was impossible at all.

The disadvantages of this approach are obvious: this complicates the maintenance of information bases, and possible conflicts during subsequent updates, when changed configuration objects require changing access rights.

In the managed application, settings for rights and interfaces were finally moved to user mode and can be configured directly from the program interface. A user's rights are assigned based on their membership in access groups. Let's go to Administration - User and rights settings - Access groups - Access group profiles, where we will see pre-installed profiles for the main access groups.

A user can be a member of several access groups at once, in which case the resulting rights will be summed up. In general, everything is quite clear and familiar, except that the settings are now performed in user mode, and not in the configurator.

But if we try to find interface settings, we will fail. In a managed application, the workspace interface is generated automatically, based on access rights. For example, let’s compare the interfaces of the Administrator and Sales Manager section panels:

In general, the idea is sound, if there are access rights to the object, we show it in the interface, if not, we hide it. It's much better than popping in regular application messages about access violations when the latter do not correspond with the designated interface. If you add rights to an access group or, conversely, remove them, the interface elements associated with them will appear or disappear on their own. Comfortable? Yes.

The user can also independently configure his workspace within the limits of his access rights. At first glance, everything looks good, but there was a fly in the ointment. There is no mechanism that allows you to centrally configure and assign a “default” interface to users in a managed application.

If we look at Administration - User and rights settings - Personal user settings - User settings, we will see there a list of all objects whose settings have been changed by the user, but we cannot change them in any way.

Those. we are asked to log in directly to the user and configure the working interface on his behalf. Controversial decision, especially if there are not two or three users. Fortunately, the developers have provided the ability to copy user settings, which allows us to customize the interface of one user the way we need to quickly apply the settings to everyone else.

In order not to be unfounded, let's look at a practical example. In preparation for the transition to online cash registers, it was decided to automate the cash registers of a small network of dental clinics. The basis for clinic automation was industry-specific software not based on 1C and not providing the ability to connect a fiscal registrar, so it was decided to use the Enterprise Accounting 3.0 configuration, which contains all the necessary functions, to automate cash registers.

Here we are faced with two difficulties, although if we look more closely, we will find that these are two sides of the same coin. In short: the personnel had never worked with 1C before and therefore it was necessary to create a working environment that was as easy to learn as possible, while protecting the information base from possible unqualified influence of personnel. Managed Application allows you to quite simply combine business with pleasure, making it so as to limit the user, and at the same time allow him to work comfortably, without noticing the restrictions.

Let's begin. First of all, you need to create a user group profile. If we open the standard profiles, we will see that there is no option to change them. This, in our opinion, is correct; history knows a lot of examples when, in a fit of official zeal, standard rights were shoveled to such a state that they had to be restored from the standard configuration. This can also mislead other users or administrators of this database, who expect to see standard sets of rights under standard profiles.

Therefore, we will find the most suitable profile for our tasks, in our case it is Sales Manager, and make a copy of it, which we will give the name Cashier. Now we can configure the rights at our own discretion. However, the flat list offered by default is not entirely convenient to work with, unless you need to quickly find an option you already know; in most cases, it is much more convenient to work with the list by enabling grouping by subsystems.

We will not dwell on this issue, since the assignment of rights depends on the specific tasks facing the user; we can only advise exercising prudence and not going to extremes. Remember that your task is to create a comfortable and safe working environment, and not to completely prohibit everything possible.

Having created a profile, we assign an access group to the required users and launch the program under one of them. Depending on the assigned rights, you will see an automatically generated interface.

In principle, this is already quite good, but in our case everything is just beginning. To our surprise, many users and administrators still have no idea how to configure the “Taxi” interface and continue to complain about its “inconveniences.”

Let's go to Main menu - View, where we will see a number of settings regarding the interface.

Let's start with section panel settings, in our case, the range was limited to a short list of services, so the warehouse section turned out to be superfluous, in order not to complicate or burden the interface, we’ll just remove it.

Then, in each section, by clicking on the gear in the upper right corner, we will sequentially configure the navigation and actions. Here we will also remove everything that is not necessary in everyday work, and, on the contrary, we will bring to the fore what is necessary.

You can even compare how it was and how it became:

Finally, let’s configure the panels. Since we have few partitions, it makes sense to move the partition panel up and the open panel down, thereby expanding the workspace horizontally, which is important for monitors with a small diagonal or 4:3 format.

After completion, you should check all the settings again, it is best to do this by simulating real action cashier, which will immediately help you evaluate the ease of working with the interface. In our case it turned out simple and convenient workplace cashier, in any case, there were no problems with the staff’s mastery of it:

Now let’s log into the program again as an administrator and go to Administration - User and rights settings - Personal user settings - Copy settings. Our task is to distribute the changes we have made to the remaining users of the Cashiers group. The operation itself is quite simple: select the user whose settings we are copying, indicate to whom and select what exactly.

And finally, you can prevent the user from customizing the interface on their own; to do this, return to the group profile again and uncheck the action Saving user data.

As you can see, setting up the interface and user rights in a managed application is quite simple and, despite some shortcomings, provides administrators with much greater flexibility and convenience, allowing them to quickly create convenient and secure working environments.

• Tags:

Please enable JavaScript to view the

"1C: Enterprise 8. Managed application." New features

Nikita Zaitsev

We continue our review of the capabilities and architectural concepts of the new generation technology platform - “1C: Enterprise 8. Managed Application”. The article will discuss various types of client applications, a new principle of using configuration subsystems, mechanisms for functional options and managed reports, and some other innovations of the “Managed Application”.

Types of client application

In previous versions of 1C: Enterprise 8 there were no options for launching a client application. For any user to work with any information base, only one type of client application was used, which was called “client”. To organize remote work of users with the information base, various technologies were used (and are still being used), each of which has its own advantages and disadvantages. Remote access can be organized using standard 1C: Enterprise 8 tools:

Building a distributed information base. Each group of remote users works with its own local infobase, and data is regularly synchronized between the main infobase and remote databases. The advantage of this technology is that remote users do not require direct access to the “main” information database. But there is also a drawback - data changes made in one of the nodes of the distributed information base are not transmitted to neighboring nodes immediately, but after some time.

Work via a Web interface (based on the 1C: Enterprise 8.Web extension platform). Advantages – the ability to work on low-speed communication channels; no installation of “1C: Enterprise 8” is required on the user’s computer. Disadvantages – significant functional impoverishment user interface Compared to the “thick client”, the need to attract programmers proficient in ASP.NET technology to develop a Web application.

Remote access to the information base can also be organized using non-system means:

Work via terminal service. Advantages - the ability to work over low-speed communication channels; there is no need to change anything in the configuration. But this requires additional licenses for server software and additional hardware resources (ideally, a dedicated server for “terminal” users).

Work through a VPN connection. Advantage - the user works with the remote infobase as usual, as if it were located in his local local network. Disadvantage: a trouble-free high-speed communication channel is required, large amounts of traffic are consumed.

Client-server interaction

The “Managed Application” is designed to simplify as much as possible and minimize the costs of organizing remote work of users with information bases - now users can work with the information base online both within the enterprise’s local network and via the Internet.

In the Managed Application you can use three different types client application.

"Fat client" Similar to the client application of previous versions of 1C: Enterprise 8, but compatible with two modes of operation - normal and managed. The main difference between them is the principle of constructing a global command interface(more details about the new interface model of the “Managed Application” are described in the previous article in our series). The “thick client” consumes more system resources on the user’s computer, but does not impose any functional restrictions on working with the configuration.

"Thin client". A completely new application included in 1C: Enterprise. It operates only in a controlled mode and is intended for users to work with information databases via the Internet (of course, it can also work over a local enterprise network). For the “thin client” there is a mode “ low speed connection", when working in it, the platform optimizes the interaction processes between the client application and the server for low-speed communication channels. The “thin client” requires significantly less system resources than the “thick client”, but is functionally limited - it works only with managed configuration forms, the Configurator mode is not available.

Web client. In this case, there is no need to install “1C: Enterprise 8” or any additional software on the user’s computer. Work with 1C: Enterprise 8 information bases is carried out through a regular Internet browser (MS Internet Explorer or Mozilla FireFox). The functional limitations of the Web client are the same as those of the “thin client”: it works only with managed forms, the Configurator mode is not supported. Almost complete (with the exception of a few minor limitations) identity is declared appearance and system behavior when working with a “thin” and Web client. Unfortunately, at the time of preparation of the article, the Web client technology had not yet been published by 1C, so the information provided about this technology is based only on the accompanying documentation of the Managed Application.

Subsystem-based command interface

In order not to get confused and clearly understand what methods of connecting to information bases and what interface models are supported different types client application "1C: Enterprise 8", the information is best presented in the form of a table (see Tables 1 and 2).

When working with the Managed Application, organizing online access to the 1C: Enterprise 8 information base mainly comes down to setting up a Web server. For each information base you will additionally need:

Create an infobase descriptor file (two lines of XML);

Configure on the Web server side (MS IIS or Apache) an application (virtual directory) corresponding to the information base.

These operations are performed once for each infobase with which remote work is expected. Of course, in order for remote users to be able to work with the information base in “thin client” or Web client mode, the configuration must be developed and (or) modified to suit the new interface model of the “Managed Application” and must contain managed forms of the objects with which they will work remote users.

Note that with the advent of Web client technology, 1C: Enterprise 8 becomes fully multi-platform. Now all the elements information system can run both Windows and Linux (see Table 3).

The only workplace that must have Windows OS is the information system administrator's workplace, where you need to run 1C: Enterprise 8 in Configurator mode.

Setting default command visibility

It should also be noted the changes in the client-server architecture of 1C: Enterprise 8 made in connection with the emergence of new types of client applications. In previous versions of the platform, the only form of interaction between the client and the server was a connection, that is, a rigid connection between the client application and one of the worker processes of the server cluster. This connection is established when the client connects to the infobase and is maintained until the client application is closed.

User interface customization

In the "Managed Application" when working with " thin client"or the Web client uses a more flexible scheme of client-server interaction: a user session. Each request from a client application to the server is separate and is processed by a cluster of servers regardless of previous requests. This scheme allows:

Increase the “survivability” of the system. If a worker process of a server cluster is no longer available for some reason, client applications switch to other, available worker processes (in previous versions, a “crash” of a worker process entailed the breaking of all connections and the “crash” of all client applications served by the process).

Increase system performance by dynamically distributing the load on work processes. In previous versions, the load was distributed only when the client first contacted the server. In the Managed Application, the cluster manager constantly monitors the workload of worker processes and distributes the load between them. If the worker process or worker server that was serving the client application suddenly becomes overloaded, the next time the client accesses the server, the client will be switched to a less loaded process or server.

Configuration Subsystems

In previous versions of 1C: Enterprise 8, configuration subsystems did not carry any functional load. Of course, it cannot be said that before the advent of the Managed Application, the subsystem mechanism was purely decorative - configuration developers and specialists involved in supporting information bases used it to solve a variety of technological problems. But the subsystems had absolutely no effect on the behavior of the configuration in user mode. Moreover, not a single subsystem could be defined in the configuration at all, and this would not affect its operation in any way.

In the Managed Application, the situation is completely different: the hierarchical structure of subsystems is the key configuration element on which the global command interface is based. The user interface is created according to the following principles:

Command interface sections are created on the basis of the root configuration subsystems (located at the first level of the hierarchy).

Based on the membership of certain configuration objects in the corresponding root subsystem and subsystems subordinate to it, a set of commands for the corresponding section is created.

For each command from the set, it is determined whether it is available to the current user in principle. The decision is made in two stages: first, those commands for which the user does not have access rights are removed from the set, and then commands that are disabled through functional options.

For each of the commands available to the user, the visibility mode is determined: display the command in the corresponding interface panel or hide the command. The platform checks the settings specified by the configuration developer and the infobase user. The configuration developer can set different visibility modes for one command for different roles, and the user, if desired, can override the visibility of each of the commands available to him for his workplace.

Thus, when switching to a “Managed Application”, configuration subsystems turn from a “service” object into a key one, and the task of competently designing the structure of subsystems and distributing configuration objects between them becomes paramount for the developer.

Functional options mechanism

Using the feature options mechanism, an implementer can dynamically include or exclude certain functionality and corresponding interface elements from a custom application without requiring any changes to the actual configuration. Functional options are based on application data of the information base and can be quickly switched directly during system operation.

Impact of functional options on the interface

The best way to explain how functional options work is to specific example. Let's assume we are creating a configuration to automate small retail businesses. When designing our configuration, we note a number of functionality, which are “end-to-end” to the configuration, with the need for these capabilities determined by the context of a specific implementation or even a specific process.

An enterprise can use various retail equipment (for example, barcode scanners) to automate accounting.

An enterprise may have several warehouses; accordingly, it may be necessary to maintain records by warehouse.

Accounting may be carried out differently for local and export products, for local and foreign suppliers.

Depending on the specific implementation, the same configuration objects should look and act differently, for example:

If barcode scanners are used, certain types of document forms must contain a command to control the scanner.

If accounting is maintained by warehouse, the relevant forms (commodity documents, reports) should display details and commands associated with the warehouse.

If an enterprise works with foreign suppliers, the relevant forms (settlement documents, reports) should display details and commands related to currency accounting (currency, exchange rate, “recalculate at the current rate,” etc.).

The mechanism of functional options allows the application developer to provide for adjusting the appearance and behavior of configuration objects to the requirements of a specific implementation and the specifics of the activity of a particular enterprise without incredibly tedious coding of functions that control the visibility and accessibility of interface elements. The developer declaratively defines a set of functions (objects and configuration commands) and sets the rules according to which the platform must enable or disable the specified set. The user receives an application interface that is not burdened with “unnecessary details” and does not waste time figuring out “in what cases is this field significant and when does it make sense to click on this button” - everything that is now in front of one’s eyes is significant.

It should be noted important point: the state of functional options and their parameters has no effect on either the composition of configuration objects or the composition of database tables and fields. Metadata objects and their details, managed through functional options, disappear only from the user interface, but not from the information base. Functional options are used not to reduce the capabilities of the application configuration, but to disable and hide from the user those functions that are redundant and (or) irrelevant in the current user context.

Managed Reports Managed Report Form

The reporting mechanism of the “Managed Application” has retained the “family features” of the reporting mechanism of the previous version of “1C: Enterprise 8”:

The report is built on the basis of a data composition diagram. In general, to create a new report in the configuration, it is enough to develop a layout scheme - the report form (including various service capabilities - transcripts, selection, conditional formatting, etc.) will be automatically generated by the platform.

In user mode, each user can, if desired, change some layout scheme settings, create and save their own personal “report options”.

Setting up a report variant

Managed reports (the so-called reports implemented using Managed Application technology) have a number of important differences from their predecessors.

The report is generated only on the server side; only the finished results are transferred to the client application. In previous versions of 1C: Enterprise 8, the report could be generated both on the server side and on the client side.

The mechanism for managing report settings has been significantly redesigned. The process is now hierarchical and consists of report variants, report variant settings, and custom report settings.

The report settings are saved in the database system table or (if the configuration developer provided for this) in a special information base object “Settings storage”. In previous versions of 1C: Enterprise 8, it was necessary to either save report settings as a file, or develop your own settings storage based on information registers.

Customizing a Report

Let's take a closer look at the mechanism for managing report settings. At first glance it may seem overly complicated, but in fact everything is very simple and convenient. Report settings are managed at several levels:

Configuration developer level. The configuration designer creates a data composition scheme and defines report options (a report option is a collection of data composition scheme settings). For example, for the “Sales Analysis” report, the options “By periods” (analysis of sales volume by periods) and “By groups” (analysis of sales volume by product groups) can be defined. The configuration designer also determines which settings the user can change when working with the report.

Implementation specialist level. Performs additional customization of the report to meet the requirements of a specific enterprise. An implementation specialist has access to the same operations as a configuration developer, but an important nuance should be noted: you can change existing report options and add new ones in the 1C: Enterprise 8 user mode without making any changes to the configuration.

Information base user. The user manages those report settings elements that the configuration developer and implementation specialist have given him access to.

Development of report options

Convenience new structure report settings compared to previous versions of 1C: Enterprise 8 is that:

Elements of user settings can be edited either directly on the report form (if the “ quick access"), or in a separate simple form. This form contains only the most necessary controls, is not overloaded with functionality and does not shock unprepared users (just compare the appearance of this form with the report option control form).

A set of report options and user settings can be edited in the client application by the system administrator or advanced user can modify the report on the fly, simplifying or complicating its configuration.

Due to the fact that all the settings made are stored in the information base, the process of exchanging settings between users can be simplified to the limit - for this, the configuration must be configured to store report settings in a special configuration object “Settings Storage”. The system administrator configures the necessary report options; the user only needs to open the report form, select an option, set the values ​​for “quick” user settings and click on the “Generate” button.

Multi-level report customization

If you try to formulate the advantages of managed reports over “regular” 1C: Enterprise 8 reports in three words, then these words will be: productivity, flexibility, convenience. Managed reports work faster - all report generation operations are performed on the server side. They provide a much more flexible configuration mechanism by dividing the settings into two levels. Finally, managed reports are simply easier to work with. But reports, or more precisely, the information presented in reports, are the final product of the information system, this is the result issued by the system to the consumer.

This concludes our review of the Managed Application innovation. Perhaps we will return to this topic after the first release. Of course, you can get a full understanding of the capabilities of the new generation of the platform only by holding it in your hands and carefully reading the documentation - partners of 1C and registered users of 1C: Enterprise 8 already have this opportunity.

News. From 15 to 15

Computers

ASUS (http://asus.com.ru) announced the release personal computer Eee Box. The product is assembled in an ultra-compact case; the Eee Box can be mounted on a VESA mount. The system features high-speed downloads and Internet connections (ASUS Express Gate), and wireless WiFi adapter 802.11n.

Hello.

In the last post I wrote about regular and managed applications, regular and controlled forms ah "1C:Enterprise", the article is here.
The future belongs to the managed application; already now, many typical configurations are built on the basis of a managed application, these include:
1. “1C: Trade Management 11”;
2. “1C: Management of a small company 8”;
3. “1C: Document Flow 8”;
4. “1C: Enterprise Accounting 3.0”;
5. “1C: Management manufacturing enterprise 2.0" (to be released in the near future);

These applications are based on managed forms and automatically open in the thin client.

Many external treatments and reports do not have managed forms and when opened in managed applications they will open, but will be empty, i.e. not working, they work in regular applications.

An example of opening processing is described in the post: ""

Most generic and other processing can only be run in a regular application.

Now consider the following question: How to launch a regular application if by default the application runs in the thin client?

The configurator parameter must be specified Managed application and regular application, and then according to the priority when choosing to launch the application.

The priority when choosing to launch an application is as follows:
1. The information base registration property is analyzed first.
2. The second one analyzes whether the user is forced to configure a regular or managed application. If the value is Auto, then the transition to the next level is carried out.
3. And lastly, the main configuration launch mode is analyzed.

In order to catch the moment the application starts and the moment it shuts down, it is used.

Let's look at each point in more detail.

Creating regular and managed forms becomes available if the parameter is specified in the configurator mode Service – General – Managed Application and Regular Application

Application launch priority

First when selecting a client to launch, the infobase registration property on this computer. To do this, in the infobase registration window, you need to click the Change button, go to the third tab of the infobase editing form and in the group Basic launch mode select the type of client to launch.

Second The application launch mode for a specific user is analyzed. It is set in the list of users. Administration – Users select the user and on the Other tab in the selection field Startup mode select Managed Application or Regular application.
For roles that are marked in the Available roles list, you must specify the right to run the thick client.

I am publishing the second chapter of my book “Development Fundamentals in 1C: Taxi”

Chapter 2. Regular and managed 1C application

In this chapter, we will look at what a regular and managed application is and how they differ from each other, but before that we will look at the concept of an “interface”.

What is an “interface” anyway? Essentially, this is a common boundary between two interacting systems (very often one system is a person). Let's take a car for example. Does it have an interface? Yes, sure. But what is the common boundary between a car and a person? Firstly, this is a workplace, i.e. directly the driver's seat and controls (steering wheel, accelerator pedal, brake pedal, etc.). Secondly, these are the principles of human interaction with a car, which are some kind of set of rules. For example, in order to speed up a car, you need to press the gas pedal, slow down - the brake pedal, to turn right you need to turn the steering wheel to the right, etc. Thanks to these two entities, a person can drive a car. Take away one thing and driving will become impossible.

in the world software everything is exactly the same. One system is a person - an operator, a user. And the second system is an application created to automate a certain type of human activity (we are considering application programming).

For example, we need to independently maintain warehouse records: carry out the arrival of goods at the warehouse, write off these goods and monitor balances. What will be the common boundary between the application, no matter how or where it is written, and the user? Firstly, these are information input organs - otherwise how will you convey to the program that 5 pieces of some product have arrived at the warehouse. In our case it is computer keyboard And computer mouse. Secondly, it is a system of interaction between a computer and a person. For example, this could be a command line interface: You will use the keyboard to enter various text strings (commands) and use them to perform the necessary actions (record the receipt of goods, consumption of goods, etc.). Such an interface looks something like this: see fig. 1.2.1.

Rice. 1.2.1 Command line example

This figure shows command line operating system Windows, with it you can do almost all the operations that you do in Explorer: copy files, delete files, create directories, etc.

This type of interface has long been archaic, and it was replaced by a graphical user interface (eng. graphical user interface GUI). In this interface, the interaction between the user and the application occurs through various graphic elements drawn on the display (buttons, icons, switches, etc.). In the graphical interface, the operator has random access through controls to any graphic elements. In our case, when we automate warehouse accounting, the interaction may look like this: the operator presses the “Receipt” button, the product selection form opens, where the operator selects the desired product from the list and enters its quantity. If you need to make an expense, the operator presses the “Consumption” button, and a selection form also opens, where the operator also selects the desired product and enters its quantity. When you need to check balances, the operator clicks on the “Remains” button, and the program displays the remaining goods in the warehouse. Thus, using this graphical interface, you can quite successfully keep track of goods in the warehouse.

Let's finish with the theoretical part and move directly to the topic of this chapter. Namely, to the types of application interfaces of the 1C program, which are all graphical user interfaces. The 1C: Enterprise 8 program has two global types of graphical application interfaces. These are regular application mode and managed forms application mode (or managed application).

Edition platforms 8.0 and 8.1. worked only under normal mode, higher versions of the platform (8.2, 8.3, etc.) can work in both regular application mode and managed application mode.

Normal Application Mode

Almost all modern configurations already operate in managed mode, but there are still organizations that use legacy configurations that operate in normal application mode. Therefore, it is necessary to know the principles of operation of a regular application. This is discussed in great detail in my book (chapters 3 and 4). Here we will touch only on the most general points.

The regular application mode uses the interface and forms that were used in the 8.0 and 8.1 platforms. Previously, this mode was not called anything, but now it is called “regular application mode”, and the forms that are used in this mode are called “regular forms”.

Let's take a quick look at what this mode looks like. Many will already be familiar with it, but some, especially those who have not seen work under platforms 8.0 and 8.1, will see it for the first time.

After loading the program, the user sees an interface with a menu at the top (see Fig. 1.2.2).

Fig 1.2.2 Interface view of a regular application

By clicking through menu items, the user can open various forms. These are mainly forms of lists of directories and documents (see Fig. 1.2.3), but there can also be reports, processing, charts of accounts, etc.

Fig.1.2.3. Document list form

From the list form, the user can open the form of a document or reference book (see Fig. 1.2.4).

Rice. 1.2.4. Document form

The developer can use automatically generated forms, or design them himself in .

The developer needs to design ordinary forms with the mouse: place the necessary elements on the form (button, field, table), move them to a convenient place and determine the size (see Fig. 1.2.5).

Figure 1.2.5. Designing conventional forms

Very often, when developing complex forms, it was necessary to take into account the interaction of form elements with each other. For this purpose, bindings were established. Sometimes they got confused and didn’t quite take the shape. beautiful view. We will not go into much detail about this mechanism and the consequences of its incorrect use, since in the case of controlled forms it has lost its relevance.

Finally, I note that, unlike a managed application, a regular application can only work under a “thick client”. By and large, this is the main, most fundamental difference between conventional forms and controlled ones. Because the managed application mode was designed specifically for working under a “thin client”.

Managed Application Mode

So what is the peculiarity and fundamental difference between the managed application mode and the regular one? The main difference is the use of a managed command interface and managed forms. Let's look at each of these entities separately. What is a managed command interface? In order to answer this question, it is necessary to delve again into the past.

Let's consider in the in simple form, how the configuration was developed in a regular application. First, we designed the business logic: documents, directories, reports, processing and their interaction with each other. Then we set up roles, for example, a user with the “Supplier” role had access to the “Goods Receipt” document, but not to the “Goods Output” document. Conversely, a user with the “Seller” role had access to the “Goods Output” document, but not to the “Goods Receipt” document. The next step was to develop interfaces for each type of user. Those who practiced development under a regular application remember that there was such a configuration object as “Interface”, in which it was possible to configure each menu like the menu in Figure 1.2.2. And in our case, the developer had to take the trouble to create two interfaces: one for the supplier, and the other for the seller. Because if he had developed one common interface in which you could open both the “Goods Receipt” document and the “Goods Output” document, then it would not be entirely correct if the supplier, when trying to open the list of “Goods Output” documents, received a message system that he does not have the right to do so. To avoid this, it was necessary to make two interfaces and specify for each user which interface he should work under.

In managed application mode, everything is much simpler. We will study the managed command interface in more detail in the next part. In this part we will analyze it in its most general outline. In the case of the taxi interface, the managed command interface looks like this:

Rice. 1.2.6. Managed command interface

When developing a managed application, the programmer will have to take a slightly different path. Before developing business logic, we need to define the subsystems that our objects will be included in (in a regular application they also exist, but they are more declarative in nature). For example, the document “Receipt of goods” will be included in the subsystem “Supply”, and the document “Consumption of goods” will be included in the subsystem “Sales”. At the same time, some objects can be located in several subsystems at the same time: the “Products” directory will be included in the “Sales” subsystem, and in the “Supply” subsystem, and in the “Marketing” subsystem. In this case, the developer does not need to create an “Interface” object; the system itself will automatically build the required type of interface based on the settings of user rights and functional options.

If some user has a role that does not have rights to view the subsystem, for example “Supply”, then when starting the 1C application he simply will not see this menu item. Also, he will not see a document in the menu list that he does not at least have the right to view.

In Figure 1.2.6 you saw the user interface with full rights, and, for example, the seller’s interface will look like this:

Rice. 1.2.7. Restricted User Interface

Another difference from the usual interface is that the user can independently determine the type of his interface using settings for navigation, actions, sections, etc. For example, from the interface in Figure 1.2.7 we can remove the “Warehouse” items from the functions of the current section (top menu) and "Product". You will get this look:

Rice. 1.2.8. User interface with reduced functions of the current section

We will look at user interface customization in more detail in the following chapters of this part, and we will study the relationship between roles and interface appearance in the next part of this course. For now, let’s note the main differences between the managed command interface and the regular one.

• The appearance of the managed command interface is configured automatically using platform mechanisms, depending on the settings of user rights and functional options.
• The user can independently customize the appearance of the interface as desired.

Now let's look at what managed forms are.

Learn programming in 1C with the help of my book “Programming in 1C in 11 steps”

1. No complicated technical terms.
2. Over 700 pages of practical material.
3. Each task is accompanied by a drawing (screenshot).
4. A collection of problems for homework.
5. The book is written in a clear and in simple language- for a beginner.
6. The book is sent to email V PDF format. Can be opened on any device!

If this lesson helped you solve any problem, you liked it or found it useful, then you can support my project by donating any amount:

You can pay manually:

Yandex.Money - 410012882996301
Web Money - R955262494655

Join my groups.

Attention! Now the course is also held in the evening from 18:30 to 21:30 in an immersion format.

The course is integral part comprehensive course "Effective work in the 1C:Enterprise 8 system".

Learning Objective: introduce students to the controlled operating mode of the 1C:Enterprise 8 technology platform, and show specialists approaches to building a system for using this version of the system.

The course covers a new model for building an application interface, a new implementation of client-server architecture, a forms mechanism. During the course, students will acquire practical skills in configuration, administration, programming in the studied software package. These skills will be acquired as you solve educational task. The essence of this task is to configure the provided configuration to enable operation in “thin client” mode.

The course is intended: for specialists with configuration experience application solutions on the 1C:Enterprise platform (versions 7.7, 8.0, 8.1, 8.2 - a regular application).

Mechanisms covered in the course:

• Principles of building a managed interface
• New modules, module execution context, interaction mechanism
• Interface properties of configuration objects
• Setting up the form (in configurator mode, in execution mode)
• Directives, client-server programming, managed form mechanism
• Functional options mechanism, functional form options
• List forms, dynamic lists
• Mechanism for forming printed forms
• Changes in the data composition mechanism (features of working in a managed application)
• Privileged/safe modes
• Temporary storage, new technology working with files, pictures
• Mechanism for interaction of forms, organization of selection
• Working with system settings, overriding the settings storage mechanism
• External sources
• Data sharing mechanism
• Automated Testing
• Mobile platform

The cost of a full-time day course includes:

• 2 days from 10:00 to 17:00
• teaching materials
• lunches, coffee breaks
• certificate of the company "1C"

The price of the WEB course includes:

• 5 weeks of course, 5 webinars with a teacher
• certificate of 1C Training Center No. 3 (subject to practical training)

The cost of the full-time immersion course includes:

• 5 days from 10:00 to 17:00 or 9 evenings from 18:30 to 21:30
• notes, headphones
• lunches, coffee breaks
• access to updated video materials for 2 years after completing the course
• certificate of 1C-Training center No. 3

Training formats

Full-time daytime

Who is this format for:For those who can undergo training while away from work and prefer classic full-time training.

Duration:16 academic hours

WEB training

What is this format:The proposed format combines many of the advantages of distance learning with a face-to-face component represented by video materials and online consultations.
The WEB course consists of videos, practical tasks and webinars with teachers. All course materials are available 24/7 via the Internet so you can study at a time that suits you. The course is divided into classes. During the lesson, materials on the current topic are studied, workshops are performed, and questions are asked to the teacher. At the end of each lesson, a webinar is held, during which the teacher addresses all questions received, typical errors, explains the correct solution. Recordings of webinars are available in the portal. In this way, several classes are held one after another. At the end there is a final independent work and final webinar.

Duration: 5 weeks

What is this format:

Duration:40 academic hours

What is this format:A full-time immersion course is a format that combines all the advantages of full-time training, distance learning and individual training. Classes are held in an equipped classroom, you independently study the course materials (step-by-step videos) and perform workshops. At the same time, there is a teacher in the audience who is ready at any time to answer questions and help with solving practical problems, as well as check the correctness of their implementation.
Advantages – individual consultations from the teacher on your questions, a pace of material that suits you personally.
All this provides a more in-depth study of the course material.
This course can be taken from your workplace with full effect presence of the teacher where the student is! If this opportunity interests you, give us a call!

Duration:40 academic hours

Course program

GOALS AND OBJECTIVES OF THE COURSE

INTRODUCTION

1. OPERATION OPTIONS

2. TECHNICAL STRUCTURE OF INTERACTION

• Client-server option:
• File option:
• Protocols used
• Server cluster structure
• Sessions
• Types of modules, general capabilities

3. COMMAND INTERFACE

• Subsystems
• Teams
• Pre-setting
• Interface improvements

4. INTERFACE PROPERTIES

• Custom object representation
• Standard details
• Control of filling in object details
• Setting the default value
• Using Submission

5. FUNCTIONAL OPTIONS

6. CONTROLLED FORM

• Configuring the dialog
• Defining Event Handlers
• Calculation of the document amount
• Checking completion, messages
• Fill Processing
• Using the toggle switch
• Privileged Mode Management
• Safe Mode
• New methodology for registering
• Event driven form model
• Form Functional Options
• View register movements

7. CREATE A PRINTABLE FORM

• Simple decryption

8. LIST FORMS

• List form of the document "Sale of goods"
• Form for selecting the directory "Nomenclature"
• Using the “When Receiving Data on the Server” handler
• Getting the data displayed by a dynamic list

9. REFUSAL OF MODAL CALLS.

10. TEMPORARY STORAGE

• Working with files (pictures)
• Organization of selection

11. MANAGED REPORTS

• Report "Remaining items"
• Report options
• Custom Settings
• Getting the decryption value

12. DATA HISTORY

13. UNIT MECHANISM

14. LIMITS OF THE RESULTS STORAGE INTERVAL

15. DEFINED TYPES

16. DESKTOP

17. STORING SETTINGS

• Saving report settings

18. GENERAL DETAILS

• Definition general details at objects
• Data sharing mechanism

19. CONFIGURATION EXTENSIONS

20. SCHEDULER

21. EXTERNAL DATA SOURCES

• Connecting to an Access database

22. AUTOMATED TESTING

23. MOBILE PLATFORM

• Introduction (extracts from "http://v8.1c.ru/overview/Term_000000818.htm")
• Database development
• Pre-setting
• Building a mobile application
• Application testing

Technical requirements:

• Internet access(you can check your communication channel by connecting to “test” access),
• availability of the 1C:Enterprise 8.3 platform to practice practical tasks of the course.

You can use “1C:Enterprise 8.3” Version for learning programming.