Механизм «История данных», появившийся в платформе «1С:Предприятие» начиная с версии 8.3.11, стал отличной альтернативой старому «Версионированию объектов» из БСП (Библиотеки стандартных подсистем). Он работает на уровне самой платформы, функционирует значительно быстрее и эффективнее. Однако при его внедрении у разработчиков часто возникает закономерный вопрос: как правильно разграничить права доступа пользователей для работы с этой самой историей данных?
В этой статье мы подробно разберем, за что отвечает каждое из 9 специфических прав доступа, как они взаимодействуют между собой, что такое «отсутствующие данные» в контексте версионирования и как управлять историей программно.
Когда мы включаем историю данных для справочника или документа, платформа начинает автоматически записывать все изменения полей объекта при его записи. Но история изменений — это тоже конфиденциальная информация. Не каждый пользователь должен иметь возможность видеть, какие реквизиты менялись, и уж тем более не каждый должен иметь право откатывать изменения к старым версиям или программно затирать историю. Именно для этого в роли (объекты метаданных «Роли») для каждого версионируемого объекта предусмотрен целый набор специализированных прав.
Давайте подробно проанализируем каждое право из этого списка.
1. Чтение истории данных (ReadDataHistory)
Это право предоставляет возможность программного чтения записей истории (версий) для существующих и доступных пользователю объектов базы данных. Сама по себе эта галочка в роли не дает пользователю красивую кнопочку в интерфейсе. Она лишь разрешает обращаться к истории объекта через встроенный язык 1С (например, считывать версии в коде обработок).
2. Чтение истории данных отсутствующих данных (ReadDataHistoryOfMissingData)
Выясним причину существования этого права и что скрывается под загадочным термином «отсутствующие данные». В системе 1С под отсутствующими данными понимаются:
Если пользователю необходимо программно анализировать историю удаленных объектов или документов, скрытых правами RLS, ему обязательно должно быть назначено это право.
3. Изменение истории данных (UpdateDataHistory)
Одно из самых непонятных прав на первый взгляд. Зачем изменять историю, если она должна быть неизменяемой? На самом деле, это право носит исключительно программный характер. Оно позволяет разработчику через встроенный язык принудительно создавать новые версии (например, записывать в историю техническую информацию, которой нет в самом объекте) или удалять устаревшие версии истории по конкретному объекту для экономии места в базе данных.
4. Изменение истории данных отсутствующих данных (UpdateMissingDataHistory)
Аналогично предыдущему пункту, это право позволяет программно изменять или очищать историю версий для физически удаленных документов и справочников, а также для объектов, закрытых механизмом RLS для текущего пользователя.
5. Изменение настроек истории данных (UpdateDataHistorySettings)
Это право позволяет управлять настройками версионирования непосредственно в режиме «1С:Предприятие» без открытия конфигуратора. Пользователь с этим правом может определять, какие именно реквизиты объекта нужно версионировать, а какие можно игнорировать при записи версий.
6. Изменение комментария версии истории данных (UpdateDataHistoryVersionComment)
Предоставляет программную возможность (через код на встроенном языке) изменить или перезаписать текстовый комментарий к уже сохраненной версии истории изменений.
7. Редактирование комментария истории данных (EditDataHistoryVersionComment)
В отличие от предыдущего пункта, это право является интерактивным. Оно позволяет пользователю зайти в стандартную форму истории изменений в интерфейсе «1С:Предприятие», нажать кнопку «Редактировать комментарий» и вручную написать, почему именно были внесены те или иные изменения в документ или элемент справочника.
8. Просмотр истории данных (ViewDataHistory)
Это ключевое право для обычных пользователей. Оно разрешает интерактивный просмотр истории изменений. Если это право активно, в форме объекта (или списка объектов) появится стандартная команда «История изменений». Если право снять — кнопка перехода к истории просто исчезнет с экрана.
Важная особенность: право «Просмотр истории данных» логически завязано на право «Чтение истории данных». Нельзя просматривать интерфейсную форму, не имея права читать сами данные истории.
9. Переход на версию истории данных (SwitchToDataHistoryVersion)
Это интерактивное право на восстановление объекта до состояния выбранной версии (так называемый «откат изменений»). В стандартной форме истории изменений у пользователя становится доступна кнопка «Перейти на версию».
Важная особенность: чтобы пользователь действительно мог откатить изменения, у него обязательно должно быть право на «Изменение» самого восстанавливаемого объекта конфигурации (справочника, документа и т.д.). Ведь при переходе на старую версию платформа фактически считывает старые значения и записывает текущий объект поверх новыми (старыми) данными.
Рассмотрим подробнее, как эти права сочетаются друг с другом на практике. Давайте составим логическую схему:
ReadDataHistory (Чтение истории) и ViewDataHistory (Просмотр истории).EditDataHistoryVersionComment (Редактирование комментария).SwitchToDataHistoryVersion (Переход на версию). При этом помним, что у него должны быть полные права на изменение самого документа.Вся работа с механизмом истории данных на встроенном языке осуществляется через глобальный контекст ИсторияДанных. Давайте посмотрим на простой пример того, как мы можем программно перебрать все версии определенного документа:
// Пример программного чтения версий объекта
СсылкаНаДокумент = Документы.РеализацияТоваровУслуг.НайтиПоНомеру("00000001");
Если ИсторияДанных.ПолучитьИспользование(Метаданные.Документы.РеализацияТоваровУслуг) Тогда
ВыборкаВерсий = ИсторияДанных.ВыбратьВерсии(СсылкаНаДокумент);
Пока ВыборкаВерсий.Следующая() Цикл
Сообщить("Версия № " + ВыборкаВерсий.НомерВерсии
+ " от " + ВыборкаВерсий.ДатаВерсии
+ ". Автор изменений: " + ВыборкаВерсий.Пользователь);
КонецЦикла;
КонецЕсли;
Начиная с версии платформы 8.3.13, разработчики получили еще больше инструментов для тонкой настройки переходов по версиям. Проанализируем эти нововведения подробнее:
Во-первых, в модулях объектов (справочников, документов, планов счетов и т.д.) появился новый предопределенный обработчик события: ОбработкаФормированияПоВерсииИсторииДанных(). Это событие вызывается в тот момент, когда пользователь инициирует команду «Перейти на версию».
Для чего это нужно? Допустим, у вас в документе есть служебные реквизиты, которые не версионируются (например, статус синхронизации с внешней системой или уникальный идентификатор транзакции банка). При обычном откате версии эти реквизиты могли бы очиститься или принять неверные значения. С помощью этого обработчика мы можем перехватить процесс восстановления и дозаполнить нужные поля программно:
Процедура ОбработкаФормированияПоВерсииИсторииДанных(Направление, Версия, СтандартнаяОбработка)
// Если восстановление идет "из истории в объект"
Если Направление = НаправлениеФормированияПоВерсииИсторииДанных.ИзИсторииДанныхВОбъект Тогда
// Наш кастомный алгоритм заполнения неверсионируемых реквизитов
ЭтотОбъект.ТехническийСтатус = "Восстановлено из истории";
КонецЕсли;
КонецПроцедуры
Во-вторых, появился параметр управляемой формы НомерВерсииПереходаНаВерсиюИсторииДанных, который можно использовать для тонкой кастомизации интерфейса при открытии формы объекта, восстановленного из истории.
Изучив эти права доступа и механизмы взаимодействия, вы сможете гибко и безопасно внедрять современную историю данных в любые конфигурации «1С:Предприятие»!