Рассматриваемый кейс: обновление связки 1С:ERP 2.5.12.95 + «УправлениеЛизингом» 2.5.10.63 на релизы 2.5.21.118 и 2.5.17.151 соответственно. Отраслевое решение было модифицировано: разработчики заказчика доработали его под свои потребности, в том числе добавили собственные объекты метаданных, а также вносили туда исправления типовых ошибок лизинга.
Алгоритм обновления ролей 1С в стандартной ситуации
Рассмотрим пример обновления роли ПолныеПрава в отраслевом решении. Эта роль уже присутствовала в поставляемом расширении как заимствованная, но также в ней были доработки заказчика. В стандартных ситуациях, когда расширение не является поставляемым, заимствованные роли мы обновляем по следующему алгоритму:
- копируем список прав обновляемой роли из расширения до обновления в инструмент для сравнения текстов (для вывода прав в виде списка необходимо открыть права роли и нажать «Действия» — «Вывести список»). В этом списке выводятся все объекты, присутствующие в расширении;
- удаляем роль из расширения, добавляем ее заново (обнуляем все права);
- снова копируем список прав из вновь добавленной роли;
- сравниваем списки, полученные в 1 и 3 пунктах, таким способом выявляем доработки, затем переносим их в обновленное расширение, в котором также сначала удаляем роль, затем добавляем ее снова, это необходимо для того, чтобы подтянулись новые типовые изменения из основной конфигурации.
Разумеется, первые три пункта выполняются в конфигураторе базы до обновления в копии расширения, чтобы не затронуть «рабочую» конфигурацию 1С. Но для обновления доработанной роли в поставляемом расширении указанный метод не подошел: роль нельзя просто удалить и добавить заново, так мы потеряем типовые изменения отраслевого решения.
Способ выявления «чистых» доработок без влияния сторонних метаданных
Изначально мы думали просто сравнить списки прав из старого типового расширения и модифицированного расширения, но в таком случае мы получали избыточное количество различий из-за объектов метаданных, добавленных заказчиком, в которых сложно вычленить реальные доработки роли. Поэтому мы поставили перед собой задачу найти способ для выявления «чистых» доработок без влияния сторонних метаданных и нашли, для этого мы:
- скопировали список прав роли ПолныеПрава из расширения до обновления;
- сравнили-объединили доработанную роль с ролью из старого типового расширения с использованием штатного механизма платформы;
- снова скопировали список прав из полученной после объединения роли;
- сравнили полученные списки между собой;
- перенесли доработки, выявленные на предыдущем шаге, в обновленное расширение.
Данным способом мы получили реальные доработки без «мусорных» изменений, которые осложняют сравнение. Для наглядности прикрепляем скриншоты из используемого нами инструмента для сравнения текстов, на которых видно сколько различий выводилось, когда мы просто сравнивали старое типовое расширение с доработанным расширением заказчика:
И сколько оказалось среди этих различий реальных доработок, которые мы выявили методом, указанным выше:
Вероятность пропустить доработки при использовании данной методики обновления становится минимальной. Но человеческий фактор все равно никто не отменял, поэтому на проектах сложных обновлений мы используем инструмент сценарного тестирования собственной разработки, благодаря которому вероятность возникновения ошибок доступа на этапе промышленной эксплуатации снижается до минимума, так как практически все несоответствия в ролях выявляются и исправляются на этапе тестирования до передачи обновленной конфигурации заказчику.
А на каком этапе вы ловите ошибки ролей: при тестировании или уже после звонка разгневанного пользователя?
Вступайте в нашу телеграмм-группу Инфостарт