1с расширение откатить изменения
В информационной базе 1С:Предприятия 8 конфигурация, редактируемая разработчиком, сохраняется без выполнения реструктуризации. Ее сохранение не оказывает влияние на работающих пользователей. Для работы пользователей в режиме "1С:Предприятие" используется конфигурация базы данных, также хранящаяся в информационной базе. Чтобы привести конфигурацию базы данных в соответствие с редактируемой конфигурацией, нужно выполнить обновление конфигурации базы данных (меню " Конфигурация – Обновить конфигурацию базы данных "). При этом выполняются дополнительные проверки конфигурации, реструктуризация базы данных (если изменилась структура данных) и замена конфигурации базы данных на редактируемую конфигурацию.
В меню " Конфигурация – Конфигурация базы данных " можно выполнить сравнение редактируемой конфигурации с конфигурацией базы данных и при необходимости вернуться к конфигурации базы данных.
Использование команды " Конфигурация – Обновить конфигурацию базы данных " (клавиша F7) позволяет сохранять редактируемую конфигурацию сразу с обновлением конфигурации базы данных.
Использование команды " Отладка – Начать отладку" (клавиша F5) позволяет начинать отладку с сохранением редактируемой конфигурации и обновлением конфигурации базы данных.
Для сохранения редактируемой конфигурации без обновления конфигурации базы данных следует использовать команду " Сохранить конфигурацию " или " Сохранить " (клавиша Ctrl+S).
Как включить возможность редактирование объектов в 1С? Как именно происходит изменение конфигурации в 1С? Рассказываем подробнее и представляем вашему вниманию пошаговую инструкцию для большей наглядности!
Включение возможности редактирования объектов
Действительно, для типовых конфигураций 1С возможность редактирования объектов отключена.
Для того, чтобы включить данную возможность необходимо сделать несколько действий.
Запускаем 1С в режиме конфигуратор.
Выбираем пункт «Поддержка» вменю «Конфигурация». Подпункт «Настройки поддержки».
Если нужно отредактировать конкретный объект конфигурации, то нет необходимости менять правило для всей конфигурации. Найдите в списке интересующий объект, кликните по нему правой кнопкой мыши и выберите «Установить правило поддержки»
В открывшемся окне выбираем «Объект поставщика редактируется с сохранением поддержки». В случае если необходимо отредактировать подчинённые объекты, устанавливаем галочку для опции «Установить для подчинённых объектов»
Если необходимо включить возможность редактирования для всех объектов конфигурации, то в правом верхнем углу открывшегося окна нажимаем кнопку «Включить возможность изменения»
В появившемся диалоговом окне отвечаем «Да»
Все объекты конфигурации делятся на два вида: «Объекты с правилом «Изменения разрешены» и «Объекты с правилом «Изменения не рекомендуются». Для каждого вида необходимо выбрать настройку.
По умолчанию значения установлены «Объект поставщика не редактируется». Рекомендуется установить «Объект поставщика редактируется с сохранением поддержки» для объектов с правилом «Изменения разрешены» и «Объект поставщика не редактируется» для объектов с правилом «Изменения не рекомендуются».
Необходимо обновить конфигурацию базы данных. Это можно сделать с помощью кнопки на панели или нажав F7
Для редактирования конкретного объекта конфигурации нужно в «Настройка поддержки» установить значение «Редактируется с сохранением поддержки. Если необходимо запретить редактирование конкретного объекта конфигурации, то установите свойство «Не редактируется».
Возвращение конфигурации на поддержку
В первую очередь перед проведением каких-либо операций необходимо сделать резервную копию вашей базы.
В качестве демонстрации вернём поддержку базе из примера выше.
1С одновременно сохраняет три конфигурации:
- Типовая конфигурация, ещё её называют конфигурацией от поставщика
- Конфигурация нашей информационной базы
- Основная конфигурация
При запуске обновления конфигурации выполняется следующая последовательность действий:
- Обновление типовой конфигурации
- Типовая конфигурация заменяет конфигурацию вашей базы, но только в случае «Объекты поставщика не редактируются»
- Запуск «Режима сравнения и объединения», в случае если ваша база «Объекты поставщика редактируется с сохранением поддержки»
- Обновление конфигурации нашей информационной базы
В первую очередь необходимо узнать номер текущего релиза нашей конфигурации. Запускаем 1С, в меню «Справка» выбираем пункт «О программе».
На рисунке выделена строка, содержащая номер релиза
Запускам 1С в режиме конфигуратор. Выбираем пункт «Поддержка» вменю «Конфигурация». Подпункт «Настройки поддержки».
Смотрим номер текущего релиза конфигурации поставщика.
В нашем примере релизы совпадают. Нажимаем кнопку «Сохранить в файл».
Выбираем пункт «Загрузить конфигурацию из файлов» вменю «Конфигурация».
Будет произведено замещение нашей текущей конфигурации, конфигурацией содержащейся в файле.
Производим обновление конфигурации
Восстановлена «Полная поддержка».
Как можно оптимизировать работу с 1С?
В работе с 1С постоянно возникает множество вопросов — от решения проблем до обновления или потребности в доработке программы. Не у каждой компании есть соответствующие специалисты, способные помочь в перечисленных ситуациях, а если и есть, то не всегда бывает целесообразно отвлекать их на мелкие задачи.
Чтобы обновления происходили без проблем, а на все вопросы вы могли получать ответы, приглашаем обращаться за сопровождением 1С к профессионалам, в компанию «ПРОГРАММЫ 93».
Почему нас выбирают?
ООО «ПРОГРАММЫ 93» — это компания с большим штатом сотрудников, в который входят не только специалисты 1С, но и бухгалтеры, юристы и другие эксперты смежных областей.
В результате вы получаете услуги от опытных компетентных специалистов, не зависите от одного человека и не отвлекаете штатных специалистов от стратегических задач.
Мы можем предложить вам:
- доработку программы под ваши нужды;
- поддержку продуктов 1С;
- интеграцию программы с сайтом;
- внедрение других продуктов 1С;
- сопровождение бухгалтерского и налогового учета.
Позвоните по номеру телефона, указанному на сайте или заполните форму обратной связи, чтобы мы могли ответить на все возникающие вопросы и рассказать о том, как начать сотрудничество!
Для этого нужно внести изменения в Общий модуль ОбщегоНазначенияБП
Нужно внести изменение в функцию ПредлагатьОбновитьВерсиюПрограммы модуля Общий модуль ОбщегоНазначенияБП
Пример исправленного кода модуля:
Если ОбщегоНазначенияПовтИсп.РазделениеВключено() Тогда
И ТекущаяДатаСеанса() > ДобавитьМесяц(ДатаТекущейВерсии, 2);
НадоПредлагать = Ложь; // Отключение уведомления "Рекомендуется обновить версию конфигурации"
В оригинальный код добавлена строка:
НадоПредлагать = Ложь; // Отключение уведомления "Рекомендуется обновить версию конфигурации"
Наиболее правильным вариантом будет создать расширение для объекта Общий модуль.ОбщегоНазначенияБП и создать в нём собственный вариант функции ПредлагатьОбновитьВерсиюПрограммы
Вот готовый код для модуля расширения:
// Отключение уведомления "Рекомендуется обновить версию конфигурации"
Если ОбщегоНазначенияПовтИсп.РазделениеВключено() Тогда
И ТекущаяДатаСеанса() > ДобавитьМесяц(ДатаТекущейВерсии, 2);
НадоПредлагать = Ложь; // Отключение уведомления "Рекомендуется обновить версию конфигурации"
После подключения расширения нужно отключить для него Безопасный режим и Защита от опасных действий
Каждый хочет держать под контролем свою жизнь, знать ответы на все вопросы. Так же дела обстоят в части информационных систем. Но здесь все значительно сложнее, так как ваша жизнь зависит от 3-10 человек. А в информационной системе зачастую работают 200 и 1000 сотрудников. И именно в таком потоке информации жизненно важно знать, что изменилось по сути и кто конкретно осуществил эти изменения.
Эту задачу давно ставили разработчикам 1C и вот, мы обрадованы появлением более или менее работающего механизма. Однако хранение версий в самой базе быстро приводит к ее росту. Устранению этого недостатка посвящена эта статья.
"
Версионирование 1С.
Механизм версионирования объектов используется для аудита изменений объектов информационной базы в разрезе времени и позволяет ответить на вопросы КТО, КОГДА и ЧТО изменил. В качестве версионируемых объектов могут выступать справочники и документы. Настройка механизма выполняется в форме настройки программы и доступна пользователю с ролью «Полные права». Настройка состоит из активизации механизма и настройки режима сбора версий документов и справочников.
Однако нет худа без добра. Со временем количество измененных записей по объему сопоставимо с основными данными, а потом попросту уходит в «отрыв» и превышает все разумные пределы. Что начинает существенно сказываться на объеме быстродействия системы.
Для устранения этого недостатка логично изымать эти данные и хранить их отдельно. Это тем более логично, когда информационных систем, которые необходимо подвергать аудиту, более чем одна.
Для решения этой задачи наша команда разработала программный продукт обладающий следующим функционалом:
1.Сбор данных об измененных объектах в фоновом режиме согласно расписанию. В рабочей базе остается только последнее изменение, количество «последних» регулируется. Так можно устранить «распухание» базы и одновременно можно в случае чего за секунду вернуть испорченный документ.
2.Формирование отчетов в части аудита (кто, что, когда изменил). Очень нравится «Безопасникам».
3.Все что когда либо менялось в системах.И все версии измененных объектов в одном месте в отдельной базе.Система собирает как версии так и журналы регистрации из указанных систем.
4. Но когда надо провести аудит изменений имеем полную картину.
В общем полезная система получилась. С одной стороны устраняет неопределенность изменений, а с другой дисциплинирует пользователей так как нет возможности свалить вину на «последнего».
Для сценарного и модульного тестирования, процесса разработки, создания видеоинструкций, сопровождения, первичной настройки конфигураций. В общем, для любых процессов, в которых используются эталонные или стартовые данные, к которым хотелось бы возвращаться (в случае возникших проблем, например) быстрее и проще, нежели с помощью резервной копии
Практически все описано в анонсе публикации, но еще чуть-чуть.
Вы разработчик. Пишите код, запускаете отладку, накликиваете за пользователя какие-то данные. Или даже за нескольких пользователей - в нескольких сессиях параллельно, если бизнес-процесс сложный. Или запускаете "накликанный" на эталонных данных сценарный тест. Ловите ошибку, идете в конфигуратор исправлять, чтобы повторить все заново.
Если к следующему циклу "накликивания" надо вернуть исходное состояние данных, то можно написать (лень!) и запускать обработку, которая восстановит данные, или восстанавливать каждый раз в базу резервную копию (каждый раз сохранять наработку в cf, восстанавливать копию, перезапускать конфигуратор, восстанавливать наработки. в общем - отпадает. а если тут еще и хранилище. уууу. ).
Или прицепляем данное расширение, настраиваем фиксацию и автоматическое восстановление данных и после каждого цикла просто перезапускаем отладку. Данные восстанавливаются самостоятельно.
Или вы - инженер сопровождения. У вас тестовая база с "исходными" данными и вы пытаетесь повторить ошибку, возникающую у пользователя. После короткого времени ошибка не повторена, а контекст данных "испорчен".
Переключаетесь в список истории изменения данных, нажимаете одну кнопку, ждете несколько секунд. Вуаля, контекст данных восстановлен, ищите ошибку заново.
С разработкой видеоинструкций отдельная боль. Собственно, идея оттуда и пришла. Коллега, который занимался созданием видеоинструкций, реализовывал свою версию подобной разработки. Но она не покрывала восстановление данных всех объектов ИБ.
При разработке сценарных тестов тоже должно пригодится!
Ограничения
Слукавил немного. Эта разработка тоже не покрывает восстановление данных ВСЕХ объектов ИБ. Не восстанавливается первоначальное состояние регистрации объектов в узлах планов обмена и хранилищ настроек.
Все же остальное фиксируется в истории и восстанавливается вполне успешно - объекты ссылочных типов, движения регистров любых типов, константы.
Понятно что разработка построена на событиях. Поэтому главное ограничение - версия платформы. Подписки на события в расширениях появились в 8.3.17. Поэтому использовать данную разработку на более старых версиях платформы не получится. А вот режим совместимости конфигурации (не забудьте синхронизировать режим расширения с ним) может быть достаточно "старым" - от 8.3.12.
Также при добавлении расширения в конфигурацию желательно снять флаги безопасного режима и защиты от опасных действий.
Механика
Из объектов, несущих данные, в расширении есть справочник для фиксации истории изменений и настроечный регистр сведений.
В справочнике фиксируются объекты в состоянии "до изменения". Прирост времени выполнения при включенной фиксации данных по моим замерам составляет до 10%. Для работы в тестовой базы для процессов сопровождения/разработки /настройки считаю показатель вполне приемлемым.
При восстановлении данных восстанавливаются только самые первые версии измененных объектов. То есть если документ (или регистр по определенному отбору) меняли десять раз, то в истории изменения зафиксируются все, но восстановится он только один раз - по самой первой фиксации. Это значительно сокращает время восстановления.
При восстановлении объекты имеют ОбменДанными.Загрузка = Истина. Объекты восстанавливаются в порядке, обратном порядку записи истории, хотя при восстановлении "среза первых" это необязательный атрибут. Документы при этом не проводятся, поскольку наборы записей регистров фиксируются и восстанавливаются отдельно.
Восстановление происходит в транзакции. После успешного восстановления история изменений очищается.
Можно восстановиться до определенной записи в истории, если сможете правильно определить эту самую нужную вам запись. Тогда история зачистится только до этой строки.
А еще можно поставить закладки в историю в нужные вам моменты (спасибо коллеге, подсказавшему идею в комментариях) и восстанавливаться до них.
Настройка
Она элементарна.
Можно включить тотальную фиксацию изменений (первая на скриншоте). Тогда фиксироваться будет все, в том числе изменения данных в фоновых заданиях. Именно такой вариант я и рекомендую.
При этом варианте можно дополнительно настроить автоматическую очистку данных при старте или заверешении работы системы.
Можно включить фиксацию изменений для отдельного пользователя (он "сам" должен это сделать) и для текущей сессии.
Такие варианты могут использоваться с дополнительными оговорками, поскольку не гарантируется целостность восстанавливаемых данных из-за того, что в истории не фиксируются действия других пользователей.
Но, возможно, кому-то это будет полезно.
При записи истории изменений может достаточно быстро расти размер базы. Но я не рекомендую использовать запись истории без периодического восстановления данных или очистки истории (справочник легко чистится непосредственным удалением элементов) на продолжительном отрезке времени.
В любом случае, это расширение не предназначено для работы в "боевой" базе. Это инструмент исключительно для IT-специалистов и использования исключительно в тестовых базах!
Заключение
Разработка тестировалась на платформе 8.3.18.1289 на базах ЗУП (3.1.16.134) и ERP (2.4.12.64 и 2.5.6.98).
Разработкой активно пользуются коллеги, занимающиеся видеоинструкциями и сценарными тестами.
Жду обратной связи, всем спасибо за внимание!
Версия 1.0.0.2 (от 21.06.2021)
Изменения в версии:
Версия 1.0.0.3 (от 22.07.2021)
Изменения в версии:
Специальные предложения
- заменил слово, которое не могу написать (из заголовка), на Ролбэк - т.к. движок Инфостарта его заменял на * (смотрю - сейчас и в заголовке стала "*")
Думал, тут что-то хитрое придумано, но
Хотя, всё-равно, это хорошая штука для тестовых баз.
И для демо-серверов
Можно включить фиксацию изменений для отдельного пользователя (он "сам" должен это сделать) и для текущей сессии.
Такие варианты могут использоваться с дополнительными оговорками, поскольку не гарантируется целостность восстанавливаемых данных из-за того, что в истории не фиксируются действия других пользователей.
По хорошему, тут как раз можно было бы и заморочиться. Обычно это нужно как раз в рабочей базе и как раз по одному пользователю-тестировщику (+ все остальные). Тогда можно было:
1. Зафиксировать версию объекта до изменения тестировщиком
2. Для остальных пользователей при чтении объекта читать зафиксированную версию (это самое сложное)
3. Фиксировать отдельно версию после изменений других пользователей.
Или даже проще
1. Фиксировать отдельно версию тестировщика (оставляя оригинальные данные - вернее сразу восстанавливая их)
2. При чтении данных тестировщиком - читать зафиксированную отдельно версию
Организовать чтение зафиксированную версии из отдельного источника, пожалуй, самое сложное - причём именно поймать момент чтения и подменить одни данные на другие.
Можно восстановиться до определённой записи в истории, если сможете правильно определить эту самую нужную вам запись. Тогда история зачистится только до этой строки.
На эту тему рекомендую сделать простую доработку - явно назначаемые временнЫе маркеры (с комментариями) - которыми можно было бы фиксировать (интерактивно или програмно) временные отсечки - и потом просто восстанавливаться на состояние перед этим маркером.
А вот это можете пояснить?
Поэтому главное ограничение - версия платформы. Подписки на события в расширениях появились в 8.3.17. Поэтому использовать расширения на более старых версиях платформы не получится. А вот режим совместимости может быть достаточно "старым"
И вот это тоже, хотелось бы пояснить подробнее
(1) Спасибо за развернутый комментарий и хорошие вопросы. Талантом писателя, в том числе и технического, к сожалению, не наделен)
Самый простой способ "откатить" изменение данных - выполнять изменения в транзакции, которую потом не фиксировать. Здесь как раз нет никаких транзакций (кроме платформенных и прописанных в коде конфигурации, разумеется) именно при изменениях данных. А восстанавливаются они действительно в транзакции, дабы сохранить целостность данных и истории изменения в случае возникновения ошибки при восстановлении.
Накликивать данные можно часами, восстановление в транзакции будет занимать десятки секунд или минуты.
Ну, это чисто мое мнение. использовать-то можно. на свой страх и риск. Но я бы не стал :-)
Про фиксацию данных и их подмену для разных пользователей. Тема интересна чисто с технической точки зрения. Но тут вопрос скорее к овчинке и выделке.
В тех эко-системах серверов и ПО, где работаю я, восстановление довольно свежего "боевого" бэкапа в тестовую базу занимает совсем непродолжительное время и такие доработки и сопутствующие риски неактуальности данных в боевой базе - вещи нецелесообразные.
Но код открыт полностью - все в Ваших руках)
Про "временные маркеры" и комментарии к ним. Очень хорошая идея, постараюсь реализовать в ближайшее время. Спасибо!
А вот это можете пояснить?
Поэтому главное ограничение - версия платформы. Подписки на события в расширениях появились в 8.3.17. Поэтому использовать расширения на более старых версиях платформы не получится. А вот режим совместимости может быть достаточно "старым"
Тут очепятка, сори (если я правильно Вас понял). Сейчас отредактирую: "Поэтому использовать расширения" заменю на "Поэтому использовать данную разработку"
И вот это тоже, хотелось бы пояснить подробнее
Объекты восстанавливаются в порядке, обратном порядку записи
Тут как раз все просто: справочник истории с числовым кодом и с автонумерацией. В процессе восстановления данных определяется набор восстанавливаемых элементов и восстанавливаются они по отсортированному по этому коду в обратном порядке списку.
(2)Вопросы был про вот эту фразу - видимо я что-то не знаю о режимах совместимости и о требованиях к ним в расширениях
Тут как раз все просто: справочник истории с числовым кодом и с автонумерацией. В процессе восстановления данных определяется набор восстанавливаемых элементов и восстанавливаются они по отсортированному по этому коду в обратном порядке списку.
Нее. я не понимаю. Допустим восстановление идёт на некую строку (как Вы пишите) - по факту - на некоторый момент времени - тут сразу на ум приходит периодический регистр сведений - но у Вас справочник - тогда нужен просто срез последних данных (ключа данных - и это тот ещё вопрос - т.к. для ссылочных типов всё просто - это их ссылка, а для регистров (особенно неподчинённых и не периодических) всё куда сложнее); да и как Вы храните версию - целиком - или только изменённую часть - если только изменённую - то боле-менее понятно что Вы делаете) - получили срез - и просто перезаписали объекты из версии среза - если они хранятся целиком - никакого обхода по версиям не нужно делать.
А, вот, если Вы храните данные по изменённым полям (например у документа изменили дату - то сохраняете в своё хранилище - по ключу ссылке - имя реквизита "Дата" и его прошлое значение), то на срезе не будет плоской таблицы текущих версий - нужно сделать обход в глубину (в прошлое) и восстановить каждый изменённый реквизит каждого объекта - причём один раз (только последний) - а это уже куда сложнее и дольше.
А с регистрами - так вообще можно только полные версии хранить - всего набора. или нужно целиком хранить ключ - измерения - и далее имя изменившегося ресурса/реквизита и значения - но обычно ключи тут как раз очень длинные - и проще весь набор хранить (в идеалае запаковав по методу колоночных баз данных).
Я это всё говорю не просто так - так как имею опыт разработки системы версионирования данных на 1С - а Ваше решение по сути таковым и является
Поначалу я настройку сделал на константах. При тестировании очередной базой, к которой я "прилепил" расширение, была ERP 2.4. У нее режим совместимости был 8.3.14 и он не пропускал констант в расширении. Они появились в появились в 8.3.16. Я переделал настройки на регистр сведений в итоге.
Это и явилось причиной появления данной фразы в публикации.
Вы сейчас в комментариях вытягиваете все, что я недосказал в публикации)). По сути, просите пересказать все внутренности разработки. Ну что ж, код открыт, секрета никакого, извольте, коли не хотите скачивать, тратить мани и время на изучение чужого кода. Искренний технический интерес хороших специалистов мною очень уважаем и льстит мне не меньше лайков :-)
Действительно, "обратный" порядок восстановления данных не играет никакой роли. Сделал так "на всякий случай". Даже прогрессбар работает в форме восстановления от 100% к нулю :-) Ведь о т к а т же :-) (и правда ИС "запикивает" это слово!)
Главное - локализовать "первичные" версии объектов и наборов данных, которые и будем восстанавливать.
И тут действительно есть идентификатор данных, его поле видно на одном из скринов. И в случае со ссылочным типом данных там действительно "сидит" уникальный идентификатор из ссылки.
А вот в случае регистров (на скрине как раз наборы записей различных регистров, в историю запакованные) там находится. назовем это неким "хэшем" отбора регистра, созданным на основе сериализованного в JSON массива, содержащего все элементы отбора.
Таким образом имя метаданных (разумеется полное, вида "РегистрСведений.СостоянияСотрудников") и данный "хэш" дадут нам уникальный ключ данных.
Сами же данные хранятся в виде JSON-представления объекта (всего набора записей, например), будь то ссылочный тип, или набор данных регистра, или значение константы. Я его даже не упаковываю в хранилище со сжатием, пытаясь таким образом не повлиять на скорость выполнения основных операций.
Именно поэтому я говорю, что длительное накопление истории приведет к увеличению размера базы.
(4)Ничего не вытягиваю, просто пытался на скорую руку понять как глубоко Вы копали. Оказалось не глубоко, и это всё как раз обусловлено теми сценариями, которые Вы предлагаете к использованию (и тем как использовали на практике). Они вполне себе имею право на жизнь. для данной разработки.
То что версия объекта записывается целиком как раз может сильно влиять и на производительность записи и на производительность восстановления (но да - так проще, хотя и не компактно) когда они очень большие (а это не редкость, скажем, для документов в оптовой и и в розничной торговле, или при бюджетировании и много где ещё), а модифицируют в них обычно как раз "помелчи". Но для тестовых баз и так сойдёт.
Хеши отбора регистра - вещь правильная - но ни один алгоритм хеширования не гарантирует уникальности хеша. Поэтому все хеш-коллекции используют хеш-только как первый индекс, сравнивая потом полные ключи. Но для тестовых баз, наверное, и так сойдёт.
Обратный порядок - замедляет восстановления - Вам нужен только срез до выбранного момента
Обратный отсчёт индикатора - идея плохая - она намекает об отмене процесса (который до этого шёл в прямом направлении) - а у Вас идёт процесс отмены изменений - это вполне себе нормальный процесс - лучше измените на прямое направление - не смущайте народ - вот не применится транзакция этого процесса (а это легко может произойти, скажем, из-за блокировок) - вот тогда можете визуализировать декриментирование индикатора прогресса.
Сжимать JSON можно отдельно - в фоновом задании - это не будет шибко тормозить основную работу - вообще в фоне можно много оптимизации сделать
Восстанавливать тоже можно в фоне. рисуя красивый прогресс и его обратку на клиенте без блокировки сессии - если транзакция не будет принята - пока будет идти фоновая отмена этой транзакции (хотя момент завершения отмены в СУБД не поймать)
Это всё равно не понимаю. Так какой режим совместимости конфигурации нужен, чтобы поставить на неё данное расширение?
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.15.1489.
Мы выполнили ряд доработок, которые упрощают поддержку и подключение расширений в простых и частых сценариях использования.
Упрощение поддержки небольших изменений в методах
При создании расширений бывают случаи, когда вам нужно полностью заменить какой-то метод основной конфигурации собственным методом. Для этого вы можете использовать аннотацию &Вместо. В таком случае, как бы ни изменялась типовая конфигурация, будет работать только ваш метод. Другими словами вы полностью берёте ответственность за работу расширяемого метода на себя.
Но часто возникают ситуации, когда вы не хотите полностью менять поведение метода конфигурации, а хотите лишь немного подкорректировать его. Так, чтобы основное «содержание» метода менялось бы вместе с изменениями конфигурации, и в то же время в нём сохранялись ваши небольшие изменения.
Специально для таких небольших доработок мы сделали компромиссное решение – новую аннотацию &ИзменениеИКонтроль. Она позволяет вам добавить собственные изменения в метод, сохраняя, при этом, его исходный текст.
В результате, если в Конфигураторе при проверке применимости обнаружится, что исходный текст метода (в расширении) не совпадает с новым текстом метода в конфигурации, будут выполнены следующие действия:
- такой метод не применится и попадёт в список ошибок применения расширения,
- Конфигуратор поймёт, что эта ошибка относится к особенностям работы аннотации &ИзменениеИКонтроль,
- в колонке Действие Конфигуратор предложит вам Восстановить соответствие с методом конфигурации,
- с помощью объединения по трём точкам платформа изменит в расширении исходный текст так, чтобы он соответствовал новому тексту модуля (для этого вы должны заранее настроить в Конфигураторе использование внешней программы для сравнения модулей).
В такой ситуации вы можете заимствовать этот метод в расширение, и использовать при этом аннотацию &ИзменениеИКонтроль.
Таким образом, заимствованный модуль будет содержать сразу два «варианта» текста:
Как и в случае использования аннотации &Вместо, метод с аннотацией &ИзменениеИКонтроль полностью заменяет собой расширяемый метод конфигурации. С одним расширяемым методом конфигурации может быть связан только один метод, имеющий аннотацию &ИзменениеИКонтроль. Если есть другие методы с этой аннотацией, расширяющие исходный метод, они будут признаны ошибочными и будут показаны в списке ошибок применения расширения.
Несмотря на всё удобство аннотации &ИзменениеИКонтроль, мы всё равно рекомендуем подходить к её использованию очень взвешенно. Основным сценарием для расширения типовых конфигураций являются аннотации &Перед и &После. Аннотацию &ИзменениеИКонтроль вы можете использовать тогда, когда &Перед и &После не позволяют достичь желаемого результата.
Облегчение поддержки расширений в случае переименования объектов конфигурации
Если в расширении есть заимствованные из конфигурации объекты, то каждый раз, при проверке применимости, платформа контролирует, что в конфигурации всё ещё есть объекты, соответствующие заимствованным. При этом сопоставление объектов происходит по именам.
Если в конфигурации, после создания расширения, переименовали какой-либо из расширяемых объектов, расширение применено не будет. Чтобы оно снова начало применяться, необходимо соответствующий заимствованный объект аналогичным образом переименовать в расширении.
Это понятное ограничение, но технически следовать ему не очень удобно. Такое переименование в расширении приходится выполнять вручную. К тому же не всегда бывает ясно, какое исходное имя было у переименованного объекта.
Чтобы облегчить вам эту работу, мы сделали следующие доработки:
- Для свойств заимствованных объектов мы добавили новый тип действия – Предупреждать о расхождении при подключении расширения. Он отображается как обычный флажок. Кроме этого для заимствованных объектов мы добавили новое контролируемое свойство Объект расширяемой конфигурации. Оно недоступно для редактирования, заполняется автоматически при заимствовании и содержит внутренний идентификатор расширяемого объекта.
- Для самого расширения мы добавили новое свойство Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам. По умолчанию оно имеет значение Истина.
В результате, если вы не меняли стандартное значение нового свойства расширения, то в Конфигураторе, при переименовании объекта расширяемой конфигурации, во всех открытых расширениях будут соответствующим образом переименованы заимствованные объекты расширения.
Если же конфигурация и расширение разрабатываются отдельно, то в Конфигураторе, при добавлении расширения, в списке ошибок проверки применимости у вас появятся новые действия, основанные на том, что в расширении теперь сохраняются идентификаторы расширяемых объектов:
- Переименовать, сохранив соответствие,
- Выбрать соответствие,
- Сохранить имя, изменив соответствие,
- Установить значение из объекта конфигурации,
- Очистить соответствие,
- Отключить проверку,
- Удалить объект.
Облегчение подключения «универсальных» расширений
«Универсальными» мы, условно, называем такие расширения, которые приносят в конфигурацию свою функциональность, и, как правило, не содержат заимствованных объектов. Например, это может быть расширение, добавляющее в конфигурацию какие-то обработки или отчёты.
Пользователи конфигурации, у которых есть роли, автоматически дающие права на новые объекты, смогут воспользоваться этими обработками и отчётами. Но дать права на них другим пользователям бывает сложно.
Хорошо, если разработчик расширения предусмотрел собственную роль (роли), включающую объекты расширения. Тогда администратор может назначить эту роль нужным пользователям. Однако заранее неизвестно, как такая роль может называться, да и само создание такой роли для разработчика расширения является чисто «механической» задачей.
Если же в расширении нет собственных ролей, то воспользоваться им смогут только те пользователи конфигурации, у которых есть роли, автоматически дающие права на новые объекты. Другим пользователям администратор не сможет предоставить доступ, не модифицировав расширение.
Чтобы упросить создание и подключение «универсальных» расширений, мы внесли в механизм некоторые доработки, которые позволяют работать по следующему сценарию:
- На предприятии некоторым ответственным пользователям дается дополнительное право администрирования расширений конфигурации. Благодаря этому они могут самостоятельно (без участия администратора) подключать новые расширения.
- Эти пользователи, например, скачивают из Интернета расширение, подключающее новую печатную форму.
- С помощью стандартной функции Управление расширениями конфигурации они добавляют это расширение в информационную базу.
Доработки, которые мы сделали в механизме, заключаются в следующем.
Во-первых, теперь при создании расширения в нем автоматически создаётся роль, имя которой формируется по шаблону _ОсновнаяРоль. Эта роль устанавливает права для новых собственных объектов.
Эта роль сразу же добавляется в свойство Основные роли расширения (возможность модифицировать основные роли мы добавили в версии 8.3.14).
Таким образом, мы избавляем вас от необходимости «механически» создавать роли, дающие полный доступ к объектам расширения. Кроме этого такая, автоматически созданная роль, имеет понятное для всех имя, формируемое по фиксированному шаблону.
Во-вторых, расширению конфигурации мы добавили новое свойство ИспользоватьОсновныеРолиДляВсехПользователей, которое стандартно установлено в значение Истина. Это значит, что по умолчанию при добавлении такого расширения все пользователи конфигурации будут обладать правами из основных ролей добавляемого расширения.
В третьих, в стандартную функцию Управление расширениями конфигурации мы добавили возможность управления основными ролями.
С её помощью пользователь, которому «доверено» администрирование расширений, может отобрать роли расширения у тех пользователей, которым оно не нужно. При этом автоматически будет сброшено свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей.
При необходимости и «ответственный» пользователь, и разработчик могут отдельно изменять значение этого свойства расширения. Пользователю оно доступно в списке расширений в стандартной функции Управление расширениями конфигурации, а разработчику оно доступно в списке расширений в Конфигураторе.
Таким образом, если вы не хотите использовать новое стандартное поведение (чтобы при добавлении вашего расширения все пользователи сразу же получали доступ к его функциям), устанавливайте свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей в значение Ложь. Тогда роли расширения, как и раньше, администратор должен будет добавить пользователям в явном виде.
Также мы изменили отображение ролей расширения в Конфигураторе. Теперь они отображаются под своими именами, и у вас есть возможность управлять ими.
По поводу использования основных ролей расширения хочется дать некоторые рекомендации.
Во-первых, среди основных ролей расширения могут быть только собственные роли, и эти роли не могут давать права на заимствованные объекты.
Во-вторых, если ваше расширение небольшое и не предполагает разного ролевого доступа к разным его частям, то вы просто создаёте расширение, и не задумываетесь о ролях. Основная роль, создаваемая автоматически, даст доступ ко всей функциональности вашего расширения.
И, наконец, если в расширении нужен разный ролевой доступ к разным его частям, то в основную роль расширения добавляйте ту роль, которая понадобится большинству пользователей. А роль, которая даёт права на остальную функциональность, администратор добавит пользователям самостоятельно. Например, ваше расширение позволяет формировать и отправлять отчёты. Формировать могут все, а отправлять – только некоторые пользователи. Тогда роль, позволяющую формировать отчеты, вам нужно включить в основные роли расширения.
Мы надеемся, что новые возможности упростят вам создание и использование расширений конфигурации.
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.14.1565.
Мы сделали несколько изменений, которые упрощают адаптацию расширений к изменениям конфигурации, а также добавили новые объекты, которые вы можете создавать в расширениях.
Добавление собственных параметров сеанса и значений перечислений
Раньше вы могли изменять роли типовой конфигурации, заимствуя их в расширение: устанавливать и снимать права на заимствованные объекты конфигурации и на собственные объекты расширения. Однако если заимствованные роли использовали ограничения доступа к данным на уровне записей и полей базы данных, то для полноценной работы этих ограничений вам не хватало возможности создавать собственные параметры сеанса в расширении.
Теперь мы добавили такую возможность. Собственные параметры сеанса становятся доступны при первом вызове события УстановкаПараметровСеанса(), и вы можете использовать их в ограничениях доступа.
Кроме этого мы реализовали и другую возможность – добавление собственных значений в заимствованные перечисления. Значения перечислений имеют уникальный внутренний идентификатор, они хранятся в таблице базы данных, доступны из встроенного языка и используются в полях форм в качестве значений. Поэтому существуют некоторые особенности, связанные с деактивацией расширений, которые «приносят» собственные значения перечислений.
Например, вы заимствовали перечисление и добавили в него собственное значение Отменен.
Если в момент применения расширения проблем не возникло, то будет выполнена реструктуризация базы данных и все собственные значения перечислений будут записаны в неё. В результате вы можете использовать значение Отменен в форме заказа, чтобы указать состояние заказа.
Если после этого вы деактивируете расширение, то собственные значения останутся в базе данных, но не будут показаны в пользовательском режиме. Вместо этого будет выведена надпись .
Также эти значения не будут доступны вам из встроенного языка:
При последующем подключении расширения собственные значения расширения будут восстановлены.
Комментарии к объектам в расширении
Для того чтобы вам было удобнее работать при длительной разработке расширения или при коллективной его разработке, мы добавили возможность комментирования заимствованных и собственных объектов.
Добавленное нами свойство Комментарий никак не используется платформой в процессе применения расширения ни для контроля, ни для изменения одноимённого свойства расширяемого объекта. Оно предназначено исключительно для вас, для того, чтобы вы могли сохранять какие-то заметки к изменяемым и добавляемым объектам.
Ослабление контроля обработчиков событий при применении расширения
Раньше при расширении модулей количество параметров обработчика события в расширении и в расширяемом модуле должно было быть одинаковым. Платформа контролировала это соответствие и не применяла расширение метода, если количество параметров отличалось.
Однако реальность такова, что в результате развития платформы количество параметров в обработчиках событий может увеличиваться. Это не влияет на работу существующих в конфигурации обработчиков, написанных в младших версиях платформы. Нет необходимости «дописывать» в объявление процедуры новые параметры. Однако при заимствовании таких обработчиков в расширении формируется шаблон процедуры уже с новым, правильным количеством параметров.
Раньше это приводило к тому, что расширение не применялось, так как количество параметров не совпадало. Теперь мы отменили этот контроль, и при применении расширения количество параметров и описателей Знач в обработчиках событий не контролируется.
Упрощение работы с расширениями формы
Ещё одна доработка, которую мы сделали, тоже направлена на то, чтобы уменьшить зависимость расширений от изменений конфигурации, которые вы не собирались контролировать. Эта доработка касается механизма расширений форм, который мы перепроектировали.
Изначально, создавая этот механизм, мы хотели добиться того, чтобы форма в расширении (после заимствования) выглядела бы максимально похожей на свой окончательный вид. Для этого вместе с формой автоматически заимствовалось большое количество объектов, которые требуются для её отображения (реквизиты, параметры, команды и связанные с ними объекты).
С одной стороны это было хорошо, так как вы всегда (даже в отсутствие расширяемой конфигурации) можете посмотреть на форму в том виде, в котором она задумывалась. С другой стороны подавляющее большинство заимствованных при этом объектов лично вам не нужно для контроля или доработки. А любое их изменение в расширяемой конфигурации сразу же приводит к тому, что ваше расширение перестаёт подключаться, и его нужно адаптировать.
Теперь мы пересмотрели свой изначальный подход, и при заимствовании формы заимствуется только собственно форма и её элементы. Вся остальная информация, необходимая для работы с формой и для её предпросмотра (реквизиты, команды, параметры и пр.) берётся из расширяемой конфигурации и только отображается в расширении (серым цветом).
Если после заимствования в расширяемой форме появятся новые элементы, вы узнаете об этом в расширении. В верхней части редактора формы будет показан баннер, который предложит вам обновить форму.
Если вы захотите изменять реквизиты, параметры и команды, их нужно в явном виде заимствовать в расширение. Для этого в редакторе формы есть контекстная команда, а заимствованные элементы отображаются чёрным цветом.
Работа с формами, заимствованными ранее, никак не изменяется. Они работают так, как будто все возможные реквизиты, команды и параметры были заимствованы вручную.
Мы надеемся, что эти изменения сделают ваши расширения более стабильными, уменьшат их зависимость от расширяемой конфигурации и упростят адаптацию расширений в тех случаях, когда возникает их «нестыковка» с новой версией расширяемой конфигурации.
Читайте также: