Слетают роли расширения 1с

Обновлено: 06.07.2024

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.15.1489.

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

Упрощение поддержки небольших изменений в методах

При создании расширений бывают случаи, когда вам нужно полностью заменить какой-то метод основной конфигурации собственным методом. Для этого вы можете использовать аннотацию &Вместо. В таком случае, как бы ни изменялась типовая конфигурация, будет работать только ваш метод. Другими словами вы полностью берёте ответственность за работу расширяемого метода на себя.

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

Специально для таких небольших доработок мы сделали компромиссное решение – новую аннотацию &ИзменениеИКонтроль. Она позволяет вам добавить собственные изменения в метод, сохраняя, при этом, его исходный текст.

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

такой метод не применится и попадёт в список ошибок применения расширения,
Конфигуратор поймёт, что эта ошибка относится к особенностям работы аннотации &ИзменениеИКонтроль,
в колонке Действие Конфигуратор предложит вам Восстановить соответствие с методом конфигурации,
с помощью объединения по трём точкам платформа изменит в расширении исходный текст так, чтобы он соответствовал новому тексту модуля (для этого вы должны заранее настроить в Конфигураторе использование внешней программы для сравнения модулей).

В такой ситуации вы можете заимствовать этот метод в расширение, и использовать при этом аннотацию &ИзменениеИКонтроль.

Таким образом, заимствованный модуль будет содержать сразу два «варианта» текста:

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

Несмотря на всё удобство аннотации &ИзменениеИКонтроль, мы всё равно рекомендуем подходить к её использованию очень взвешенно. Основным сценарием для расширения типовых конфигураций являются аннотации &Перед и &После. Аннотацию &ИзменениеИКонтроль вы можете использовать тогда, когда &Перед и &После не позволяют достичь желаемого результата.

Облегчение поддержки расширений в случае переименования объектов конфигурации

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

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

Это понятное ограничение, но технически следовать ему не очень удобно. Такое переименование в расширении приходится выполнять вручную. К тому же не всегда бывает ясно, какое исходное имя было у переименованного объекта.

Чтобы облегчить вам эту работу, мы сделали следующие доработки:

Для свойств заимствованных объектов мы добавили новый тип действия – Предупреждать о расхождении при подключении расширения. Он отображается как обычный флажок. Кроме этого для заимствованных объектов мы добавили новое контролируемое свойство Объект расширяемой конфигурации. Оно недоступно для редактирования, заполняется автоматически при заимствовании и содержит внутренний идентификатор расширяемого объекта.

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

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

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

Переименовать, сохранив соответствие,
Выбрать соответствие,
Сохранить имя, изменив соответствие,
Установить значение из объекта конфигурации,
Очистить соответствие,
Отключить проверку,
Удалить объект.

Облегчение подключения «универсальных» расширений

«Универсальными» мы, условно, называем такие расширения, которые приносят в конфигурацию свою функциональность, и, как правило, не содержат заимствованных объектов. Например, это может быть расширение, добавляющее в конфигурацию какие-то обработки или отчёты.

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

Хорошо, если разработчик расширения предусмотрел собственную роль (роли), включающую объекты расширения. Тогда администратор может назначить эту роль нужным пользователям. Однако заранее неизвестно, как такая роль может называться, да и само создание такой роли для разработчика расширения является чисто «механической» задачей.

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

Чтобы упросить создание и подключение «универсальных» расширений, мы внесли в механизм некоторые доработки, которые позволяют работать по следующему сценарию:

На предприятии некоторым ответственным пользователям дается дополнительное право администрирования расширений конфигурации. Благодаря этому они могут самостоятельно (без участия администратора) подключать новые расширения.
Эти пользователи, например, скачивают из Интернета расширение, подключающее новую печатную форму.
С помощью стандартной функции Управление расширениями конфигурации они добавляют это расширение в информационную базу.

Доработки, которые мы сделали в механизме, заключаются в следующем.

Во-первых, теперь при создании расширения в нем автоматически создаётся роль, имя которой формируется по шаблону <ПрефиксРасширенияКонфигурации>_ОсновнаяРоль. Эта роль устанавливает права для новых собственных объектов.

Эта роль сразу же добавляется в свойство Основные роли расширения (возможность модифицировать основные роли мы добавили в версии 8.3.14).

Таким образом, мы избавляем вас от необходимости «механически» создавать роли, дающие полный доступ к объектам расширения. Кроме этого такая, автоматически созданная роль, имеет понятное для всех имя, формируемое по фиксированному шаблону.

Во-вторых, расширению конфигурации мы добавили новое свойство ИспользоватьОсновныеРолиДляВсехПользователей, которое стандартно установлено в значение Истина. Это значит, что по умолчанию при добавлении такого расширения все пользователи конфигурации будут обладать правами из основных ролей добавляемого расширения.

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

С её помощью пользователь, которому «доверено» администрирование расширений, может отобрать роли расширения у тех пользователей, которым оно не нужно. При этом автоматически будет сброшено свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей.

При необходимости и «ответственный» пользователь, и разработчик могут отдельно изменять значение этого свойства расширения. Пользователю оно доступно в списке расширений в стандартной функции Управление расширениями конфигурации, а разработчику оно доступно в списке расширений в Конфигураторе.

Таким образом, если вы не хотите использовать новое стандартное поведение (чтобы при добавлении вашего расширения все пользователи сразу же получали доступ к его функциям), устанавливайте свойство расширения ИспользоватьОсновныеРолиДляВсехПользователей в значение Ложь. Тогда роли расширения, как и раньше, администратор должен будет добавить пользователям в явном виде.

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

По поводу использования основных ролей расширения хочется дать некоторые рекомендации.

Во-первых, среди основных ролей расширения могут быть только собственные роли, и эти роли не могут давать права на заимствованные объекты.

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

И, наконец, если в расширении нужен разный ролевой доступ к разным его частям, то в основную роль расширения добавляйте ту роль, которая понадобится большинству пользователей. А роль, которая даёт права на остальную функциональность, администратор добавит пользователям самостоятельно. Например, ваше расширение позволяет формировать и отправлять отчёты. Формировать могут все, а отправлять – только некоторые пользователи. Тогда роль, позволяющую формировать отчеты, вам нужно включить в основные роли расширения.

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

Столкнулся с небольшой проблемкой при создании "своих" ролей в конфигураторе и добавлении их пользователям. Гуглил много, ответа толкового не нашёл, поэтому пришлось разбираться самому и как результат, решил поделиться опытом. Возможно кому-то пригодится.

Итак, проблема заключалась в следующем:

В какой-либо конфигурации на управляемых формах создаём свою роль (или несколько ролей, как в примере) (см. рис.1), обновляем конфигурацию. В режиме предприятия создаём профиль групп доступа с нашей новой ролью (см. рис.2), добавляем пользователю этот профиль (см. рис.3) и. ничего не происходит, как-будто у этого пользователя не добавлена наша роль. Заходим в конфигуратор, администрирование, пользователи, заходим в пользователя, смотрим "доступные роли" и видим, что у нашего пользователя не выбрана наша роль (см. рис.4).

Почему так происходит? Всё очень просто, разработчики сделали так, что если пользователь "администратор", то есть у него полные права, то собственно говоря, зачем же ему ещё какие-то роли? Ведь у него же и так полные права!

В целом вполне логично и кстати если пользователь не администратор, то всё работает корректно (см. рис.5 и рис.6). Сложности возникают только в том случае, если мы хотим добавить нашу роль/роли пользователю с полными правами. Можно конечно просто в конфигураторе выбрать у пользователя нашу роль/роли, но всё будет работать ровно до тех пор, пока кто-нибудь не решит перезаписать в режиме предприятия права доступа у этого пользователя, после этого "галочка" у добавленной роли "слетит".

Что же делать и где это происходит?

Идём в общие модули - "УправлениеДоступомСлужебный", находим процедуру "ОбновитьРолиПользователей". В ней есть следующий код:

"НовыеРоли" это Таблица значений, в которой выбраны все роли пользователя, которые мы ему назначили в режиме предприятия (включая "наши" роли). Как видно далее по коду, эта таблица очищается, в неё добавляются "ОбязательныеРолиАдминистратора" (Администратор системы, Полные права) и если выбрано, "ДополнительныеРолиАдминистратора" (Интерактивное открытие внешних отчетов и обработок).

Как мне показалось, самый простой и очевидный вариант, это добавить "наши" роли в таблицу "НовыеРоли". Для этого нам надо как-то отделить эти роли от всех остальных, поэтому у всех добавленных нами в конфигураторе ролей, делаем префикс "Доп_". Те "наши" роли, которые мы выбрали для пользователя, собираем в массив "ВыбранныеДополнительныеРоли" и далее из этого массива добавляем роли в таблицу значений "НовыеРоли". Ниже представлен код:

В заключение добавлю, процедура "ОбновитьРолиПользователей" абсолютна одинакова у многих конфигураций (благодаря "унификации" 1С), смотрел в УНФ 1.6, Бухгалтерия предприятия 3.0, Управление торговлей 11.4 (все конфигурации в нескольких версиях), поэтому сделал расширение, которое по идее должно работать на многих конфигурациях на управляемых формах. Можете скачать и добавить его себе, но предварительно не забудьте, что все добавленные роли должны иметь префикс "Доп_". Расширение написано на версии платформы: 8.3.12.1685. В расширение добавлен один общий модуль "УправлениеДоступомСлужебный", в котором только одна процедура "ОбновитьРолиПользователей" (&Вместо) с добавленным, по описанию выше, кодом. При добавлении расширения, не забываем снять галочки "безопасный режим" и "защита от опасных действий".

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

Добавление собственных ролей

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

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

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

Роли, созданные в расширениях, вы можете добавить пользователю только программно. Например, таким образом:

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

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

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

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

Расширение ролей конфигурации

Устанавливать права для новых собственных объектов;
Устанавливать права для собственных реквизитов и табличных частей по умолчанию.

Ограничения собственных и заимствованных ролей

Проверка возможности применения

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

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

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

Теперь новые средства диагностики позволят вам проверить применимость расширений ещё до их реального запуска вместе с конфигурацией.

При запуске клиентского приложения

В Конфигураторе

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

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

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

Во встроенном языке

Второе место, в котором вам доступна такая диагностика, это встроенный язык. В МенеджерРасширенийКонфигурации мы добавили новый метод ПроверитьВозможностьПримененияВсех(). А в объект РасширениеКонфигурации - метод ПроверитьВозможностьПрименения(). С помощью этих методов вы можете проверить применимость всех (или одного) расширений информационной базы в текущей области данных по порядку загрузки с учётом уже участвовавших в проверке расширений.

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

В стандартной обработке «Управление расширениями конфигурации»

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

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

Описан готовый механизм решения следующей проблемы:

При добавлении ролей в расширение конфигурации 1С 8.3 нет возможности в режиме предприятия корректно назначить их пользователю с полными правами (Администратору). Т.к. отрабатывает стандартный код общего модуля 1С УправлениеДоступомСлужебный процедуры ОбновитьРолиПользователей, который сбрасывает все роли, переназначая основную (ПолныеПрава) и дополнительную (ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок).

А теперь разберем пример на «простом языке».

Была задача создать новые роли в расширении. Режим совместимости конфигурации ниже 8.3.13 (т.е. нет возможности применения «Основные роли» в том числе). При назначении ролей полноправным пользователям выявлена проблема: роли из расширения конфигурации 1С 8.3 недоступны (по вышеуказанной причине).

2. Решение проблемы с ошибкой при расширении конфигурации

Решение можно реализовать как в текущем, так и в отдельном расширении:

1. Добавить в расширение общий модуль УправлениеДоступомСлужебный:

2. Заменить процедуру ОбновитьРолиПользователей

Копировать код 1С:Предприятия из основной конфигурации. Между строк вставить код:

(!) Тут укажите имя своего расширения, которое содержит ваши роли:

3. Подключите (или обновите) расширение.
4. Назначьте эти роли в режиме 1С:Предприятия (Роли – в Профиле, Профиль – в Группе доступа, Группу доступа – полноправному пользователю).

Читайте также: