Наследование свойств, или Как пользователь может сломать вашу форму

Данная статья - текстовый вариант ролика:

ТолькоПросмотр, Доступность, Видимость. Даже самый маленький разработчик 1С сразу понимает, что это, скорее всего, свойства элементов формы. Свойства, которые часто управляются программно. И как же удобно, что можно установить значение свойства сразу на группу, тем самым распространив его на все подчиненные элементы. Это будет легче, чем в коде указывать множество установок свойств элементов, а результат такой же.

Или же нет? Однажды я засомневался в истинности этого утверждения.

— А как он это сделал?
— Говорит, что просто изменил поле.
— В конфигураторе вижу, что колонка недоступна.
— Я под своим пользователем менять не могу. А он может.

Довольно обычный диалог, свидетелем которого, думаю, становились многие. А может и участником. Ведь работа программиста состоит не только в написании кода, но и в исправлении ошибок, которые этот код породил.

И вполне обыденно, что программист Вася допустил ошибку. Присвоил свойство или не тому элементу, или не в тот момент, или потом где-то перезатёр это свойство. А всплывает такая ситуация только у пользователя, потому что он случайно наткнулся на волшебную комбинацию действий, после которых ошибка воспроизводится. Ничего не обычного — это разработка.

— Может у тебя где-то свойство перезатирается?
— Да его программно-то и не устанавливаю нигде. Оно на самой форме установлено.

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

Для имитирования этой ситуации, создадим простую обработку. В форму добавим реквизит “ТаблицаДанных”. Пусть в этой таблице будет две доступные и две недоступные пользователю колонки. Так их и назовём.

Создадим элементы формы и разнесём доступные и недоступные колонки по двум группам.

Хорошо. А теперь, собственно, снимем доступность с папки “Недоступные колонки”

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

На первый взгляд всё хорошо. Но может ли пользователь без каких-либо сложных действий обойти запрет? Оказывается, что может. Для этого воспользуемся волшебной кнопкой в командной панели формы. “Изменить форму”.

А теперь вынесём недоступную колонку за пределы своей папки. Пусть она лежит отдельно.

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

Да, именно так ведёт себя платформа. Пока элемент находится в группе, то к нему применяются правила этой самой группы. Проверим теперь свойство ТолькоПросмотр. Изменим группу в конфигураторе, сохранимся и переоткроем обработку.

Как удобно, что 1С сохраняет пользовательские настройки формы и наше “недоступное” поле сразу при открытии становится доступным =)

Теперь сделаем то же самое и с вторым нашим полем.

Верно - ТолькоПросмотр ведёт себя точно так же.

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

Добавим кнопку на форму и поместим её в группу с отключенной доступностью.

Сохранимся и откроем обработку. Да, кнопка “серая”.

Повторим тот же фокус - вынесём кнопку из группы:

Поздравляю - мы получили доступ к закрытому для нас функционалу!

Вы можете написать в комментариях, мол, “Криворукий разработчик сам виноват. Никто же так формы не делает”. И тут ради интереса я залез в типовые конфигурации. Поэтому скажу — делают. Это нормальная практика, когда свойство устанавливают целой группе, а не элементам. И раньше я бы не подумал, что в этом есть что-то плохое.

Для примера возьмём демо-базу свеженького релиза УТ 11.4.11.104.

Откроем документ “Выданная доверенность” со статусом “Выдана”.

Как мы видим, данные заблокированы. Нажмём же “Изменить форму” и вынесем поле “Действует до” отдельно

Ну вот - мы можем его редактировать. Изменим дату и проведём документ. Ура, мы сделали своё грязное дело.

И самое “приятное”, что теперь в каждом документе поле будет доступно. Потому что платформа сохранила пользовательские настройки формы. И, если пользователь без злого умысла “перенёс” куда-то поле или кнопку (просто потому что ему так показалось удобнее), то он может и не догадываться, что это самое поле не должно быть доступно. Он просто открывает форму. Видит, что поле или кнопка доступны. И нажимает.

Возьмём ещё один похожий пример. На этот раз документ “Чек ККМ на возврат”. Откроем документ, у которого заблокирован номер и дата. И вытянем их тем же методом из шапки:

Всё, теперь мы можем изменить номер и дату документа. Поздравляю!

На самом деле, поздравлять-то и не с чем. Скорее всего, мы своими экспериментами можем сломать какой-то функционал. Потому что разработчик не просто так делал кнопку или поле в данный момент недоступным. И колонки запрещал редактировать не потому что он “бяка”. Он мог даже не знать об этой особенности. Прямо как разработчик Вася, с ситуации которого и началась эта статья. Он просто сгруппировал недоступные колонки в группу, а потом разом сделал их недоступными к изменению.

— И как теперь это будем поправлять?
— У меня есть пара вариантов

Да, если вы один из тех разработчиков, который хочет быть на все 146% уверенным, что ваш инструмент никто не сломает, то:

Устанавливайте запрет на сами элементы, а не только группы

Так вы точно будете знать, что поле будет в нужный момент недоступно.

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

Задайте свойство группы “РазрешитьИзменениеСостава”: Нет

Тогда пользователь не сможет вытащить элемент из неё.

Вы можете подумать, что это произойдёт только с какими-то гипотетическими злыми пользователями, которые специально разыскивают дыры в программе, чтобы при их помощи создавать проблемы разработчикам. Но, как я уже говорил выше, это возможно по вине “случайности”. Какой-то особо умелый пользователь перенёс колонку таблицы так, как ему показалось удобнее. Перенёс кнопку из подменю на основную командную панель, потому что ему лень искать её каждый раз. И так далее. А в результате — код разработчика сломан. Так что лучше уж обезопасить себя. Хотя бы в особо важных случаях.

И напоследок, покажу ещё один интересный пример в УТ. Ещё раз перейдём в форму списка “Доверенность выданная”. И откроем документ с типом “На получение ДС”. Как видно на скрине, у такого документа не отображается табличная часть “Товары”.

Теперь откроем документ с другим типом. Табличная часть на отдельной странице.

Перейдём в “Изменить форму” и вынесём таблицу за пределы всех групп и страниц.

Хорошо, а теперь закроем форму и вернёмся к прошлому документу без табличной части. Теперь табличная часть видна и её можно редактировать:

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

Таким образом пользователь может сломать ТолькоПросмотр, Доступность и Видимость элементов. А может и что-то ещё…