# Политика хранилища по слоям конфигурации 1С Каждая конфигурация имеет собственную политику: основная конфигурация — слой `base`, каждое расширение — слой `extension:`. Подключение основной конфигурации к хранилищу не означает подключения расширения и наоборот. Адаптер работает с метаданными 1С только через SQL. Он не считает SQL-таблицы доказательством нативного захвата объекта в хранилище. Заявки на захват и явные ручные подтверждения — это служебные данные адаптера, а не данные 1С. Они хранятся в `/data/onec-repository-locks.json` в named volume Docker `adapter-1c-data` и переживают пересоздание контейнера. Это хранилище не используется для вывода о нативном захвате и не требует записи в какую-либо базу 1С. ## Настройка В `development_layers` для каждого фактически используемого слоя задаётся `repository.connection_state`: ```json { "base": { "repository": {"mode": "manual", "connection_state": "configured"}, "support": {"mode": "unknown"} }, "extension:86d12be8-086c-11f0-925c-0050568c1b38": { "repository": {"mode": "none", "connection_state": "not_configured"}, "support": {"mode": "unknown"} } } ``` Допустимые состояния: | Состояние | Политика записи | | --- | --- | | `not_configured` | Слой не подключён к хранилищу; захват не требуется. Ограничения поддержки сохраняются. | | `configured` | Подключение известно. В SQL-only режиме нужен запрос и явное подтверждение захвата. | | `unavailable` | Подключение предполагается, но проверить его нельзя; нужен запрос и явное подтверждение захвата. | | `unknown` | Не делать предположений: запись в слой блокируется до настройки. | Для ручного подтверждения всегда передаётся точный объект и явный флаг `user_confirmed_locked`. Имя пользователя хранилища берётся из `repository_user` настройки данного слоя. Поэтому при заполненной настройке его не нужно повторять в каждой заявке или подтверждении. Если клиент всё же передаёт `confirmed_repository_user`, оно должно совпадать с настроенным именем. Если имя не настроено, подтверждение попросит его явно. ## Сохранение факта подключения агентом Агент может сохранить подтверждённый факт в служебной конфигурации адаптера через `repository.layer.connection.set`. Метод не меняет SQL-базу 1С и требует явного флага подтверждения. Основная конфигурация подключена к хранилищу: ```json { "method": "repository.layer.connection.set", "payload": { "base_id": "neft", "layer_id": "base", "connection_state": "configured", "repository_user": "ivanov", "confirm_repository_connection_change": true } } ``` Расширение точно не подключено: ```json { "method": "repository.layer.connection.set", "payload": { "base_id": "neft", "extension_guid": "86d12be8-086c-11f0-925c-0050568c1b38", "connection_state": "not_configured", "confirm_repository_connection_change": true } } ``` При `not_configured` адаптер устанавливает режим слоя `none`. При `configured` или `unavailable` новый слой по умолчанию получает ручную политику захвата. Рекомендуется сразу передать постоянный `repository_user`: он сохраняется только в конфигурации адаптера для этого слоя и используется во всех последующих ручных подтверждениях. ## Ручное подтверждение захвата После `repository.lock.request` клиент должен использовать возвращённый `next_call` без самостоятельного подбора имён полей. Поля из `next_call.params` передаются как RPC `payload`; его эквивалент: ```json { "method": "repository.lock.confirm", "payload": { "base_id": "neft", "request_id": "rreq-…", "user_confirmed_locked": true } } ``` `objects`, `operation` и `layer_id` не передаются повторно: подтверждение берёт их из неизменяемой сохранённой заявки. Если имя пользователя сохранено для слоя, оно тоже не передаётся. Успешный ответ содержит `lock_session_id`; его необходимо передать в preflight и операцию записи. Ответ `repository.lock.confirm` содержит готовый `write_context`. Его можно передать целиком либо верхнеуровневым полем `write_context`, либо алиасом `repository_lock`; адаптер нормализует поля до проверки захвата: ```json { "base_id": "neft", "target": {"module_id": "Config:.0"}, "repository_lock": {"lock_session_id": "rlock-…", "repository_object": "Document.Имя.Form.ИмяФормы", "layer_id": "base"} } ``` Если одновременно переданы вложенное и верхнеуровневое значение, они должны совпадать; иначе возвращается `repository_lock_context_conflict`. ## Проверка `repository.layers.audit` обнаруживает основную конфигурацию и расширения из live SQL и выдаёт для каждого слоя состояние хранилища, общий режим поддержки и безопасное следующее действие: ```json { "method": "repository.layers.audit", "payload": {"base_id": "neft"} } ``` Ключевые действия в ответе: - `repository_lock_not_required` — слой явно не подключён к хранилищу; - `request_and_confirm_repository_capture` — перед записью требуется подтверждение захвата; - `configure_repository_connection_state` — слой нельзя менять, пока не установлен один из статусов подключения. Проверка поддержки выполняется отдельно от хранилища. Для конкретного объекта используйте `metadata.write.preflight`: разрешение объекта определяет его `origin`, и адаптер применяет политику найденного слоя, а не клиентский выбор слоя. ## Захват формы владельца Для формы документа, справочника, обработки или отчёта область захвата задаётся точно, без сворачивания к владельцу: ```json { "method": "repository.lock.request", "payload": { "base_id": "neft", "objects": ["Document.тл_Планировщик.Form.ФормаДокументаНовая"], "operation": "modify" } } ``` До создания заявки `repository.lock.plan` и сама заявка разрешают форму через live SQL, получают GUID формы и сохраняют точную каноническую область. После ручного подтверждения эта сессия не даёт права на соседние формы или модуль владельца. Также принимается `Form.`. Для него адаптер проверяет связь формы с владельцем по live SQL; при отсутствии готовой производной записи владельца выполняется ограниченный SQL-скан форм поддерживаемых типов владельцев. Если владелец не найден, планирование и заявка завершаются `not_found`, а не возвращают ложный `ready`.