← На главную

Работа в команде над крупными проектами на платформе «1С:Предприятие» практически всегда строится с использованием встроенного инструмента — Хранилища конфигурации. Этот механизм обеспечивает совместную разработку, версионирование и контроль ссылочной целостности метаданных. Однако каждый разработчик рано или поздно сталкивается с раздражающей ситуацией: при попытке поместить в хранилище, казалось бы, простой измененный объект (или удалить ненужный реквизит) система неожиданно выкатывает огромный список незахваченных объектов, чаще всего состоящий из ролей. В худшем случае программист попадает в так называемый «замкнутый круг» (дедлок зависимостей), когда платформа не дает ни поместить изменения, ни захватить требуемые объекты.

В этой статье мы подробно проанализируем, почему возникает эта проблема, как устроен механизм контроля ссылочной целостности хранилища изнутри, и рассмотрим практические, проверенные временем способы обхода и предотвращения подобных конфликтных ситуаций.

Выясняем причину: почему хранилище требует захватить роли при удалении реквизитов?

Для того чтобы понять логику поведения платформы, углубимся в структуру хранения метаданных. Каждая роль в системе «1С:Предприятие» — это не просто абстрактное имя. Физически роль представляет собой сложную матрицу прав доступа, в которой явно прописаны разрешения (на чтение, изменение, просмотр, редактирование и т. д.) для абсолютно каждого объекта конфигурации, включая его подчиненные элементы: реквизиты, табличные части, формы, команды и макеты.

Рассмотрим стандартный сценарий:

1. У нас есть документ ЗаказПокупателя, у которого мы решили удалить устаревший реквизит СкидкаПоКупону.
2. В конфигурации существует несколько десятков ролей (например, Продавец, МенеджерПродаж, ПолныеПрава), в которых ранее были настроены права доступа к этому документу и, соответственно, к его реквизиту СкидкаПоКупону.
3. В локальной версии конфигурации разработчика при удалении реквизита платформа автоматически производит «чистку»: она удаляет упоминания этого реквизита из всех существующих ролей, чтобы не допустить появления «битых» или некорректных XML-описаний прав.
4. Таким образом, локально у разработчика изменился не только сам документ ЗаказПокупателя, но и физически перезаписались файлы описания всех затронутых ролей.
5. При попытке выполнить команду Поместить в хранилище для документа, система безопасности хранилища сверяет состояние метаданных. Она обнаруживает, что в локальной базе роли ссылаются на удаленный объект иначе, чем в самом хранилище. Чтобы предотвратить рассинхронизацию и появление невалидных прав в базе хранилища, транзакция блокируется. Система требует: «Сначала захватите и обновите измененные роли!».

Аналогичная ситуация происходит и при обычном изменении типов данных реквизитов, изменении состава планов видов характеристик или удалении любых других элементов, на которые прямо или косвенно завязаны права доступа.

Разбираем «замкнутый круг» зависимостей при добавлении новых объектов

Еще более неприятная ситуация возникает при создании новых объектов метаданных. Этот процесс часто приводит разработчиков в тупик из-за свойства ролей Устанавливать права для новых объектов.

Проанализируем этот дедлок по шагам:

1. Разработчик создает совершенно новый справочник БонусныеКарты.
2. В конфигурации есть административные роли (или роль ПолныеПрава), у которых включен признак Устанавливать права для новых объектов. Платформа 1С, следуя этому правилу, автоматически модифицирует эти роли в локальной конфигурации разработчика, добавляя в них полные права на новый справочник БонусныеКарты.
3. Разработчик пытается поместить новый справочник в хранилище. Система выдает ошибку: невозможно поместить объект, так как локально изменены роли, которые сейчас не захвачены в хранилище.
4. Разработчик соглашается и пытается выполнить захват этих ролей. Но хранилище отвечает отказом: «Для захвата ролей необходимо получить объект Справочник.БонусныеКарты». Получить его из хранилища невозможно, так как там его еще физически нет (он существует только локально у разработчика). Получается замкнутый круг блокировок.

Ниже мы подробно рассмотрим проверенные методы, как разорвать этот круг и навести порядок в процессе фиксации изменений.

Способ 1. Превентивный захват объектов (Золотое правило удаления)

Самый простой и надежный способ избежать проблем при удалении объектов или их реквизитов — это предварительное планирование своих действий. Если мы заранее знаем, что собираемся удалить реквизит или объект метаданных, мы должны действовать в строго определенном порядке:

1. До совершения каких-либо изменений в конфигураторе открываем дерево метаданных и находим ветку Роли.
2. Захватываем в хранилище те роли, в которых могут быть настроены права на удаляемый элемент (для надежности можно захватить все основные роли или использовать групповой захват).
3. Только после того, как роли успешно захвачены и помечены в дереве метаданных серым значком блокировки, производим удаление реквизита или объекта в локальной конфигурации.
4. Помещаем измененный объект и все захваченные роли в хранилище одним общим коммитом. При этом платформа корректно запишет все изменения прав в хранилище, и никаких конфликтов не возникнет.

Способ 2. Групповой захват ролей через окно просмотра Хранилища

Захватывать роли по одной через основное дерево конфигурации крайне неудобно, особенно если их в системе больше сотни. Проанализируем, как сделать это быстро с помощью встроенного инструмента групповой работы:

1. В главном меню конфигуратора переходим по пути: Конфигурация — Хранилище конфигурации — Хранилище....
2. Перед нами откроется специализированное диалоговое окно, отображающее полную структуру объектов хранилища.
3. Раскрываем узел Роли.
4. Используя стандартные возможности множественного выделения операционной системы (зажав клавишу Shift для выделения диапазона или Ctrl для выбора отдельных элементов), выделяем весь список необходимых ролей.
5. Нажимаем кнопку Захватить в хранилище в верхней панели или выбираем аналогичный пункт в контекстном меню правой кнопки мыши.

Этот способ экономит колоссальное количество времени и позволяет за один клик захватить всю структуру прав конфигурации.

Способ 3. Разрешение «замкнутого круга» через выгрузку в файл конфигурации (.cf)

Если разработчик уже попал в тупиковую ситуацию дедлока зависимостей, когда система не дает ни захватить роли, ни положить новый объект, не стоит паниковать и вручную переписывать код. Разберем по шагам классический алгоритм выхода из этой ситуации:

1. Сохраняем текущую локальную конфигурацию с вашими изменениями в файл. Для этого переходим в меню: Конфигурация — Сохранить конфигурацию в файл... и указываем путь на диске (например, temp_config.cf).
2. После успешного сохранения файла выполняем отмену захвата (команда Отменить захват) для всех объектов, из-за которых возник конфликт. При этом система предложит откатить локальные изменения к состоянию хранилища — соглашаемся. Наша локальная база вернется к исходному («чистому») виду.
3. Теперь, когда конфликты устранены, переходим в окно хранилища и захватываем одновременно и роли, и родительские объекты, в которые мы планируем вносить изменения (или просто захватываем нужные роли, если создаем новый корневой объект).
4. Выполняем операцию сравнения и объединения: переходим в меню Конфигурация — Сравнить, объединить с конфигурацией из файла... и выбираем ранее сохраненный файл temp_config.cf.
5. В открывшемся окне сравнения снимаем флажки со всех неизмененных объектов и оставляем только те элементы, которые мы непосредственно разрабатывали (наш новый справочник, измененный документ и т. д.). Нажимаем кнопку Выполнить.
6. Локальные роли автоматически обновятся правильными связями, но на этот раз они уже будут захвачены нами в хранилище.
7. Спокойно выполняем команду Поместить в хранилище для всех объектов одним пакетом.

Способ 4. Временное отключение автонастройки прав на новые объекты

Если на проекте ведется активная разработка, подразумевающая частое создание новых справочников, документов, регистров и других метаданных, постоянные конфликты с ролями могут сильно снижать общую продуктивность команды. В таком случае мы рекомендуем пересмотреть архитектурный подход к назначению прав:

1. Открываем свойства наиболее крупных и часто обновляемых ролей (в первую очередь это касается ролей администраторов и полных прав).
2. Находим свойство Устанавливать права для новых объектов и снимаем с него флажок.

После этого при создании нового объекта платформа не будет автоматически лезть в файлы этих ролей и прописывать туда новые права. Роли останутся неизмененными. Разработчик сможет без проблем поместить новый объект в хранилище. Назначение же прав на этот новый объект для пользователей будет производиться осознанно и централизованно, например, в рамках планового обновления прав перед релизом, когда один ответственный разработчик захватит все роли и настроит к ним доступ.

Резюме и лучшие практики работы с хранилищем

Для минимизации проблем при коллективной разработке в 1С рекомендуем внедрить в вашей команде следующие правила:

• Правило «Чистых ролей»: старайтесь минимизировать количество ролей, у которых взведен флаг автоматического назначения прав.
• Регулярный коммит: не копите изменения неделями. Чем меньше объем разового помещения в хранилище, тем проще локализовать и устранить проблемы зависимостей метаданных.
• Интеграция изменений: перед каждым помещением своих объектов обязательно делайте команду Получить изменения из хранилища, чтобы актуализировать локальную базу и сразу увидеть возможные коллизии с работой коллег.

Применение этих простых методологий и технических приемов избавит вас от рутины бесконечных отмен захватов и позволит сфокусироваться непосредственно на написании качественного кода и бизнес-логики.