Complete name-first 1C adapter saved-state support

This commit is contained in:
2026-07-26 16:39:53 +03:00
parent b8c62fa8fa
commit aed134d817
44 changed files with 15436 additions and 697 deletions
+179
View File
@@ -0,0 +1,179 @@
# Политика хранилища по слоям конфигурации 1С
Каждая конфигурация имеет собственную политику: основная конфигурация — слой
`base`, каждое расширение — слой `extension:<GUID>`. Подключение основной
конфигурации к хранилищу не означает подключения расширения и наоборот.
Адаптер работает с метаданными 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:<form-guid>.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.<GUID>`. Для него адаптер проверяет связь формы с
владельцем по live SQL; при отсутствии готовой производной записи владельца
выполняется ограниченный SQL-скан форм поддерживаемых типов владельцев. Если
владелец не найден, планирование и заявка завершаются `not_found`, а не
возвращают ложный `ready`.