tools_ui_1c: a subsystem of universal tools for 1C:Enterprise managed forms

One subsystem replaces a folder of standalone processing files

The project is a subsystem of universal tools for 1C:Enterprise, built for managed forms. What it collects is a long list of processing tools that in a typical 1C environment live as separate external processing files, downloaded one at a time from various sources and installed into a configuration by hand.

The list in the documentation covers data work, metadata work, development work and administration. There is a group processing tool for catalogs and documents, a constants editor that works in table mode, a database storage structure viewer that shows table names and their relations to metadata objects, a marked-objects deletion tool, a query console, a scheduled and background jobs console, a change registration tool for exchanges, a find-and-remove-duplicates tool, a code console, a references finder, an object attribute editor, a report console, a dynamic list browser, an HTTP request console, XML export and import with filters, a metadata navigator, a file manager, a regular expression constructor, a web services console, a data comparison console, a 1C licensing information tool, a data loader from a spreadsheet, a JSON editor and an HTML editor.

The distribution is a single file, the `UI.cfe` artifact attached to the latest release, and the project homepage is at `toolc.ru`. The licence is GNU General Public License v3.0, and the documentation is explicit about what that means in practice: the code is open, it can be copied and distributed, and it also has to be published with its source.

The supported platforms start at 8.3.12. The supported clients are the thick client managed application, the thin client, and the web client, which is marked as partially supported. The supported operating systems are Windows x86 and x64 and Linux x64 and x86, with macOS expected to work but untested.

The design assumes no modality and no synchronous calls

One design decision in the documentation is worth isolating, because it explains the shape of several of the tools.

The module is developed on the assumption that modality is disabled and that synchronous calls are not used, and the expectation is that it should work in all modern configurations and some older ones. Modality in 1C terms means that a piece of code cannot proceed while a modal dialog is open, and the Russian 1C ecosystem has a long history of tools that work only in the thick client because they open modal windows.

Writing the subsystem against that assumption is what makes the thin client a supported target rather than an aspiration, and it is also why some of the individual tools still have rough edges: the file manager, for example, is described as containing synchronous calls at the moment, which is a leftover from the processing it was forked from.

The fork history explains most of the inconsistencies in the list, and it is a mixed picture. The query console is a fork of RequestConsole9000 and is under GPL3. The jobs console is a fork of JobsConsole2019 with the author's permission. The web services console is a fork of WSReader2 and is under GPL3. The deletion of marked objects is a copy of the standard processing from the BSP library adapted to work outside BSP. The report console is a reworked composition console from the ITS disk. The register changes for exchange tool and the search and delete duplicates tool are forks of standard and ITS disk processing, and the duplicates tool has extra parameters for how the replacement runs.

The practical consequence is that a team inherits a bundle with a mixture of licences and a mixture of upstream quality, and the individual credits in the documentation are the place to check which is which.

Consoles for code, queries, HTTP and web services

The developer-facing half of the bundle is a set of consoles, and they are the tools most 1C developers would recognise first.

The code console is the one with the most unusual property: it allows code to be executed from the enterprise without creating external processing files. It has syntax highlighting and a minimal context hint. For a developer who is used to writing a throwaway external processing to run a snippet, that is a real change in the loop, and it is also the tool with the most obvious risk, since it runs arbitrary code with the rights of the session that opened it.

The query console is for developing and running queries without writing additional processing, and it is the fork of RequestConsole9000. The HTTP request console makes HTTP requests from inside 1C, which is the fastest way to check an endpoint that a configuration calls. The web services console reads and executes the web services of the 1C:Enterprise 8.3 platform and is described as an analogue of soapUI, showing the result as XML or as a tree; it is a fork of WSReader2.

The data comparison console is the most broadly useful of the set for anyone doing migration work. It compares data from different sources, and the list of sources covers 1C 8 databases, 1C 7.7 databases, SQL databases, files in CSV, TXT, DBF, XLS, DOC and XML format, JSON strings, and a manually filled spreadsheet document. Being able to diff a 1C 7.7 export against a live 1C 8 database in one tool is the kind of capability that otherwise gets built twice.

The file manager handles files between the client and the server, with transfer, viewing and deletion, and the metadata navigator replaces the standard All functions menu, with additional administrative functions planned for it.

Editors for JSON, HTML and regular expressions

Three of the tools are editors, and each one has a platform caveat that a reader should know before planning around it.

The JSON editor lets JSON strings be edited in a convenient form. It has JSON syntax highlighting, tree-style editing and some automatic substitutions, and it is implemented on the basis of the jsoneditor library. The documentation states that in Windows it works starting from platform version 8.3.14, which is two releases above the 8.3.12 floor the project otherwise supports, so on an older platform this particular tool is not available.

The HTML editor is for quickly debugging how an HTML page will look in 1C. It is a screen split into four parts, with three editors on the left for the HTML body, CSS and JavaScript, and a result field on the right, with context hints and autocompletion.

The regular expression constructor builds complex, structured expressions from a parameterised description, lets you test them, and produces 1C program code as the result. At the moment it works only in Windows, and it is a fork of a processing from infostart.ru with the author's permission.

So the picture across the three editors is consistent, and it is a useful signal about the project in general: the functionality is broad, and the platform coverage of individual tools is uneven, with the oldest configuration in a team being the one that decides which of these tools are available. The regular expression builder, the JSON editor and the file manager are the three to check first.

Build scripts, a 1C EDT project and a Sonar quality gate

The repository is organised as a 1C:Enterprise Development Tools project rather than as a normal application, and the tooling around it is visible in the root.

There is a `.project` file, which is the project descriptor used by 1C:Enterprise Development Tools, and a `.bsl-language-server.json` configuration for the BSL language server that provides the language support the editor needs. The `src/` directory holds the configuration sources, `packagedef` describes the build, and the build itself is driven by three scripts: `build.sh` for Linux, `build.bat` for Windows, and `build_actions.bat` for the CI path. There is a `sonar-project.properties` file, and the README carries a Quality Gate Status badge pointing at a SonarQube instance for the project, so the code quality gate is a visible part of the workflow rather than an aspiration.

The rest of the repository is a normal modern open source layout. There is a `CONTRIBUTING.MD`, an `AGENTS.md` for coding agents, a `docs/` directory and a `website/` directory, `.github/` for the workflows, `.vscode/` for editor settings, and `.gitattributes` and `.gitignore`. The topics also list 1c-edt and hacktoberfest, which explains the presence of the contribution and agent files.

The release naming is unusual and worth knowing before you look for a download. The recent releases are v26.6.1 from 2026-06-01 and v26.5.1 from 2026-05-25, and there is also a v0.0.0 release whose description says it is a version in development, a build from the current commit on the develop branch, dated 2025-02-22. The default branch is `develop`, so the published version numbers and the branch are two different lines of work, and the v0.0.0 entry is the development snapshot rather than a stable build.

Where this bundle is the wrong tool

The constraints are real and they are specific, so a short list is enough.

It is a 1C:Enterprise tool. Outside that platform there is nothing here to use, and the interoperability tools, such as the data comparison console and the HTTP console, are still bound to the 1C runtime and its configuration model. A team that only needs to diff two SQL databases or call an HTTP endpoint has better options that do not require a 1C licence.

Web client support is partial, and the regular expression constructor is documented as Windows-only, and the JSON editor needs 8.3.14 in Windows while the platform floor for the rest is 8.3.12. A deployment that is thin client only, or that has to run on 8.3.12, will find holes.

The licence is a constraint too, and not a light one. The subsystem is GPL version 3, and the documentation asks that redistributed copies keep their source open. An organisation with a policy against GPL components in its configuration environment will have to check that before installing it, and the fork situation makes that check per tool rather than per project.

The alternative approach is the one most 1C teams already live with, and it is worth stating plainly: keep the standalone external processing files, one per tool, downloaded from their original authors, and maintain a script that distributes them. The difference in approach is that this bundle gives a single update path, a single install and a consistent set of interfaces, while the standalone files give a smaller licence surface and independent updates, and can be replaced one at a time when an upstream improves. A second alternative, closer to the platform itself, is to rely on the standard 1C processing tools and the ITS and BSP disk utilities that several of these are forks of in the first place.

Editorial conclusion

tools_ui_1c fits a 1C:Enterprise developer or administrator on Windows or Linux who keeps separate standalone processing files for query consoles, code execution and data comparison, and who wants them in one subsystem with one update path. It is the wrong choice outside the 1C platform, for a team that needs a supported commercial product rather than a GPL community bundle, or for a web-only deployment, because web client support is partial and the regular expression builder and the JSON editor are documented as Windows-only in parts. Before adopting it, check the platform floor of 8.3.12 against your configuration, read the licence of each fork that is included, since the query console and the web services console carry their own GPL terms and others carry only the original author's permission, and confirm that the build scripts in the root, `build.sh`, `build.bat` and `build_actions.bat`, produce a configuration that matches your client type.

Frequently asked questions

Official sources

1. cpr1c/tools_ui_1c on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases