Настройки SenDev: iBlock History

Страница «Настройки» управляет тем, какие объекты попадают в историю, когда создаются версии, сколько они хранятся, как обрабатываются файлы и что пользователь видит в административной карточке.

Перед первым созданием базиса рекомендуется полностью пройти все вкладки. Изменения применяются после нажатия «Сохранить».

[Скриншот 1: страница настроек с вкладками «Общие», «Правила», «Хранение», «Устаревшие файлы», «Исключения», «Интерфейс», «Аудит»]

Вкладка «Общие»

Включить версионирование элементов

Разрешает автоматическое сохранение истории обычных элементов инфоблоков. Если выключить параметр, новые версии ELEMENT не будут создаваться обработчиками модуля.

Включить версионирование разделов

Отвечает за разделы инфоблоков. Полезно, если редакторы меняют названия, описания, изображения или структуру разделов.

Включить версионирование ТП (offers)

Отдельно управляет торговыми предложениями каталога. При обычном редактировании модуль определяет, является ли элемент SKU, и записывает такую историю с типом OFFER.

Если на сайте нет торговых предложений, параметр можно выключить.

Вкладка «Правила»

Создавать версию при добавлении

После создания нового элемента или раздела сохраняется его первое состояние. Обычно параметр стоит оставлять включённым.

Создавать версию при сохранении/изменении

Основное правило повседневной работы. После изменения объекта создаётся новая версия.

Создавать версию при удалении

Перед удалением модуль сохраняет последнее состояние. Такая версия нужна для восстановления удалённого объекта.

Только значимые изменения

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

Режим полезен для снижения объёма истории. Его стоит отключать, если ваша задача — фиксировать каждое сохранение, даже когда видимые данные не изменились.

Не создавать версии при импорте/API

Особенность версии 0.9.802: флажок присутствует в интерфейсе и сохраняется в настройках, но стандартные обработчики элементов и разделов не проверяют его при создании версий. Поэтому не рассчитывайте на него как на гарантированное отключение истории во время внешнего импорта. Если импорт меняет элементы стандартными событиями 1С-Битрикс, версии могут создаваться.

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

[Скриншот 2: вкладка «Правила» со всеми флажками создания версий]

Вкладка «Хранение»

Хранить версии за последние (дней)

Глобальный срок хранения. Значение 0 означает отсутствие ограничения по возрасту. Очистка выполняется служебным агентом примерно раз в сутки, поэтому старые версии не исчезают сразу после сохранения нового значения.

Хранить последние N версий на объект

Ограничивает количество сохранённых версий каждой сущности. Значение 0 — без ограничения. Если одновременно заданы и дни, и количество, служебная очистка применяет обе политики.

Режим хранения файлов

Всегда копировать;
Только при удалении;
Только ссылки (без копий).

Особенность версии 0.9.802: значение этого списка сохраняется и отображается в диагностике, однако текущий стандартный механизм сохранения файлов версий не переключает алгоритм по этой настройке — при создании снимка он пытается сохранить копии файлов. Поэтому варианты «Только при удалении» и «Только ссылки» нельзя считать полностью реализованными режимами в этой версии.

Архивировать заменяемые файлы

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

Хранить устаревшие файлы (дней)

Срок хранения obsolete. Значение 0 — без автоматического ограничения. По умолчанию 30 дней.

Вкладка «Устаревшие файлы»

Здесь выбираются расширения, для которых выполняется архивирование заменяемых файлов. Доступны изображения JPG/JPEG/PNG/GIF/WebP/BMP и документы PDF/DOC/DOCX/XLS/XLSX/PPT/PPTX/TXT.

Если расширение снято, заменяемые файлы этого типа не будут попадать в obsolete. Это не запрещает обычное сохранение файла внутри версии.

Вкладка «Исключения»

Показывает активные инфоблоки сайта. Отмеченные инфоблоки полностью исключаются из автоматического версионирования.

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

Вкладка «Интерфейс»

Кол-во версий на странице

Задаёт размер страницы общего журнала. То же значение используется как ориентир для вкладки «История», но сама вкладка ограничивает вывод диапазоном от 5 до 20 последних версий.

Показывать вкладку «История» в карточке

Добавляет вкладку к стандартной форме редактирования элемента/раздела. Если выключить параметр, история остаётся доступна через общий журнал, но дополнительная вкладка не показывается.

[Скриншот 3: вкладка «История» в карточке после включения параметра интерфейса]

Вкладка «Аудит»

Писать в журнал событий

При создании и восстановлении версий модуль пишет служебные события в стандартный журнал событий 1С-Битрикс. Оставляйте включённым, если важен дополнительный аудит действий.

Включить отладочное логирование

Включает более подробные диагностические записи. Используйте временно при разборе ошибки. На постоянной основе отладочный режим может создавать лишние служебные данные.

Какие настройки не вынесены в текущую форму

В коде модуля есть дополнительные служебные параметры для интеграций и расширенных сценариев. Поскольку в версии 0.9.802 они не представлены в стандартной странице настроек, в пользовательской документации они не рассматриваются как штатные возможности интерфейса.

После изменения настроек

Нажмите «Сохранить».
Откройте диагностику и проверьте сводку параметров.
Внесите тестовое изменение в объект.
Проверьте, появилась ли версия.
Если менялись правила файлов, выполните тест на объекте с изображением или документом.

Как одновременно работают keep_days и keep_last

Ограничения не выбирают «более мягкое» из двух. Ежедневная очистка сначала удаляет версии старше заданного срока, затем применяет ограничение количества последних версий. Поэтому сочетание 90 дней и 20 версий означает: история будет ограничена и возрастом, и числом записей.

Ограничения хранения и базис

Глобальная служебная очистка ориентируется на возраст и номер версии. Перед использованием жёстких лимитов на проекте, где базис должен храниться постоянно, проверьте поведение на тестовом объекте и используйте экспорт для особо важных контрольных точек. Операция «стереть версии кроме базисной» — отдельный механизм и явно сохраняет определённую базисную запись.

Значимые изменения: практические ограничения

Сравнение выполняется с последней сохранённой версией после события обновления. На обычной редакторской работе этого достаточно. При очень частых параллельных обновлениях одного объекта или сложных интеграциях возможны ситуации, когда последняя сохранённая версия не идеально соответствует состоянию непосредственно перед конкретным запросом. Для критичного аудита каждого технического сохранения режим «Только значимые» лучше отключить.

Какие служебные поля не считаются значимыми

Модуль исключает из обычного сравнения поля, связанные со временем изменения, автором изменения и счётчиками просмотра. Это сделано, чтобы простое обновление служебной информации не создавало новую пользовательскую версию.

Настройка исключений как средство контроля нагрузки

На проектах с обменом 1С, фидами, импортом цен или другими роботами исключения часто важнее общего срока хранения. Если технический инфоблок обновляется тысячи раз в сутки, его лучше исключить полностью, чем сохранять огромную историю и затем регулярно очищать её.

Изменение параметров во время работы

Выключение типа сущности или правила влияет только на будущие события. Уже созданные версии не удаляются. Для очистки существующей истории используйте журнал, политики хранения или отдельные операции для сущности.

Что проверять после включения offers

Откройте конкретное торговое предложение, измените поле или свойство и убедитесь, что в истории тип указан как OFFER. Это лучше сделать до массовой работы с каталогом.