Нашелся ответ, если элемент не связан с основным реквизитом формы или у реквизита, с которым он связан не установлена СохраняемыеДанные, то он не блокируется. Спасибо.

Источник

Гибкое управление свойствами доступности элементов управления в обычных формах 1С: Предприятия 8.х

Наверное, одной из самых непростых и скучных задач при проектировании обычной формы в «1С: Предприятии» является управление доступностью элементов в зависимости от того или иного набора данных. Мне встречалось очень много решений: от процедуры вроде УстановитьВидимостьДоступность() с включением в нее всех правил для элементов управления, до совершенно хаотично разбросанных по всему коду обращений к указанным свойствам.

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

Все началось с того, что поиск решения для этой задачи натолкнул меня на статью из «Методик разработки» под названием «Организация управления доступом в форме». Ключевым моментом в статье является то, что управление доступом сосредотачивается в одной лишь процедуре УстановитьДоступ(). И если необходимо изменить состояния элементов управления, вызывается только эта процедура. Сама процедура не занимается определением доступа, а работает с данными из списков, которые формируются следующими функциями:

То есть сами условия доступности устанавливаются в этих функциях, а уже процедура УстановитьДоступ() присваивает соответствующим свойствам элементов управления эти заранее установленные значения.

Я разделил код на три составляющих. Первая — это методы, которые как раз выполняют изменения значений свойств доступности элементов формы. Вынес их в общий модуль. Назовем его условно УправлениеДоступом. Ниже расположен код, который размещается в нем. Я постарался максимально прокомментировать малопонятные участки кода.

Например, у нас есть табличное поле Товары, в котором присутствует колонка СкидкаПоДисконтнойКарте. Колонка видна только тогда, когда дисконтная карта проставлена в документ, т.е. реквизит ДисконтнаяКарта является заполненным. Соответственно, условие списока управления видимостью для колонки СкидкаПоДисконтнойКарте будет следующим:

Вторая часть когда — это функции, которые отвечают за формирование списков доступности. Они располагаются непосредственно в форме и являются экспортируемыми. Я немного отошел от стандарта 1С и заменил метод ПолучитьСписокДоступаКУправлениюВидимостью() на ПолучитьСписокУправлениеРедактированиемТекста(). Просто мне кажется, что так удобнее и логичнее. Ниже приведен шаблон кода с этими функциями:

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

Чтобы было все нагляднее и понятнее, давайте рассмотрим следующий пример. Допустим, что у нас есть форма. На ней расположен флажок НаличнаяПродажа (булево), флажок ПробиватьФискальныйЧек (булево), поле ввода ДисконтнаяКарта (ссылка на справочник ДисконтныеКарты), поле ввода Комментарий (строка) и табличное поле Товары. Все связаны с одноименными реквизитами. У табличного поля есть колонка с именем СкидкаПоДисконтнойКарте (число). Кроме этого, есть командная панель ОсновныеДействияФормы, на которой размещена кнопка ПробитьЧек. Определим некоторые условия:

Теперь достаточно вызвать процедуру формы УстановитьДоступ(), и мы получим то состояние элементов, которые задали.

Хочется выделить следующий момент. В списки можно можно добавлять пути к элементам формы. Например, для вышеприведенного примера с таблицей Товары имя элемента определяем как «Товары.Колонки.СкидкаПоДисконтнойКарте». Или путь к кнопке ПробитьЧек. Можно использовать множественные вложения, вроде «ИмяКоманднойПанели.Кнопки.ИмяПодменю.Кнопки.ИмяКнопки».

Предлагаемый вариант не конечный. Можно внести множество мелких дополнений, вроде указаний, какие списки обрабатывать, а какие нет. Но это уже зависит от точечных потребностей разработчика.

Источник

Настройка ролей и прав доступа

Область применения: управляемое приложение, обычное приложение.

Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.

1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.

Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.

1.2. Роль ПолныеПрава (англ. FullAccess ) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator ) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.

1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы ) не должна давать право на интерактивное удаление ссылочных объектов.

1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.

1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.

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

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

1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».

1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.

2. Правила создания ролей к элементарным функциям

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

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

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

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

2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.

2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.

3. Ссылочные объекты и регистры

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

Роли должны содержать следующие права (когда они имеются у объекта метаданных):

Источник