Данная статья — текстовый вариант свежего ролика по теме
ТолькоПросмотр, Доступность, Видимость. Даже самый маленький разработчик 1С сразу понимает, что это, скорее всего, свойства элементов формы. Свойства, которые часто управляются программно. И как же удобно, что можно установить значение свойства сразу на группу, тем самым распространив его на все подчиненные элементы. Это будет легче, чем в коде указывать множество установок свойств элементов, а результат такой же.
Или же нет? Однажды я засомневался в истинности этого утверждения.
— А как он это сделал?
— Говорит, что просто изменил поле.
— В конфигураторе вижу, что колонка недоступна.
— Я под своим пользователем менять не могу. А он может.
Довольно обычный диалог, свидетелем которого, думаю, становились многие. А может и участником. Ведь работа программиста состоит не только в написании кода, но и в исправлении ошибок, которые этот код породил.
И вполне обыденно, что программист Вася допустил ошибку. Присвоил свойство или не тому элементу, или не в тот момент, или потом где-то перезатёр это свойство. А всплывает такая ситуация только у пользователя, потому что он случайно наткнулся на волшебную комбинацию действий, после которых ошибка воспроизводится. Ничего не обычного — это разработка.
— Может у тебя где-то свойство перезатирается?
— Да его программно-то и не устанавливаю нигде. Оно на самой форме установлено.
И вот тут становится уже интереснее. Как оказалось, на форме действительно нигде не изменялось свойство поля. И поле было недоступно пользователю. Но не совсем.
Для имитирования этой ситуации, создадим простую обработку. В форму добавим реквизит "ТаблицаДанных". Пусть в этой таблице будет две доступные и две недоступные пользователю колонки. Так их и назовём.
Создадим элементы формы и разнесём доступные и недоступные колонки по двум группам.
Хорошо. А теперь, собственно, снимем доступность с папки "Недоступные колонки"
Открываем теперь эту обработку. Добавим новую строчку, заполним доступные колонки и проверим, что нельзя изменить недоступные.
На первый взгляд всё хорошо. Но может ли пользователь без каких-либо сложных действий обойти запрет? Оказывается, что может. Для этого воспользуемся волшебной кнопкой в командной панели формы. "Изменить форму".
А теперь вынесём недоступную колонку за пределы своей папки. Пусть она лежит отдельно.
Да, именно так. Теперь свойства папки не влияют на эту колонку. А это значит, что мы можем изменить её содержимое.
Да, именно так ведёт себя платформа. Пока элемент находится в группе, то к нему применяются правила этой самой группы. Проверим теперь свойство ТолькоПросмотр. Изменим группу в конфигураторе, сохранимся и переоткроем обработку.
Как удобно, что 1С сохраняет пользовательские настройки формы и наше "недоступное" поле сразу при открытии становится доступным =)
Теперь сделаем то же самое и с вторым нашим полем.
Верно - ТолькоПросмотр ведёт себя точно так же.
И это работает не только с установленными "вручную" свойствами, но и заданными программно. И не только с группами, но и со страницами и даже подменю.
Добавим кнопку на форму и поместим её в группу с отключенной доступностью.
Сохранимся и откроем обработку. Да, кнопка "серая".
Повторим тот же фокус - вынесём кнопку из группы:
Поздравляю - мы получили доступ к закрытому для нас функционалу!
Вы можете написать в комментариях, мол, "Криворукий разработчик сам виноват. Никто же так формы не делает". И тут ради интереса я залез в типовые конфигурации. Поэтому скажу — делают. Это нормальная практика, когда свойство устанавливают целой группе, а не элементам. И раньше я бы не подумал, что в этом есть что-то плохое.
Для примера возьмём демо-базу свеженького релиза УТ 11.4.11.104.
Откроем документ "Выданная доверенность" со статусом "Выдана".
Как мы видим, данные заблокированы. Нажмём же "Изменить форму" и вынесем поле "Действует до" отдельно
Ну вот - мы можем его редактировать. Изменим дату и проведём документ. Ура, мы сделали своё грязное дело.
И самое "приятное", что теперь в каждом документе поле будет доступно. Потому что платформа сохранила пользовательские настройки формы. И, если пользователь без злого умысла "перенёс" куда-то поле или кнопку (просто потому что ему так показалось удобнее), то он может и не догадываться, что это самое поле не должно быть доступно. Он просто открывает форму. Видит, что поле или кнопка доступны. И нажимает.
Возьмём ещё один похожий пример. На этот раз документ "Чек ККМ на возврат". Откроем документ, у которого заблокирован номер и дата. И вытянем их тем же методом из шапки:
Всё, теперь мы можем изменить номер и дату документа. Поздравляю!
На самом деле, поздравлять-то и не с чем. Скорее всего, мы своими экспериментами можем сломать какой-то функционал. Потому что разработчик не просто так делал кнопку или поле в данный момент недоступным. И колонки запрещал редактировать не потому что он "бяка". Он мог даже не знать об этой особенности. Прямо как разработчик Вася, с ситуации которого и началась эта статья. Он просто сгруппировал недоступные колонки в группу, а потом разом сделал их недоступными к изменению.
— И как теперь это будем поправлять?
— У меня есть пара вариантов
Да, если вы один из тех разработчиков, который хочет быть на все 146% уверенным, что ваш инструмент никто не сломает, то:
Устанавливайте запрет на сами элементы, а не только группы
Так вы точно будете знать, что поле будет в нужный момент недоступно.
Если же в группе много элементов, их состав периодически меняется, и не хочется писать кучу кода, то есть второй вариант.
Задайте свойство группы "РазрешитьИзменениеСостава": Нет
Тогда пользователь не сможет вытащить элемент из неё.
Вы можете подумать, что это произойдёт только с какими-то гипотетическими злыми пользователями, которые специально разыскивают дыры в программе, чтобы при их помощи создавать проблемы разработчикам. Но, как я уже говорил выше, это возможно по вине "случайности". Какой-то особо умелый пользователь перенёс колонку таблицы так, как ему показалось удобнее. Перенёс кнопку из подменю на основную командную панель, потому что ему лень искать её каждый раз. И так далее. А в результате — код разработчика сломан. Так что лучше уж обезопасить себя. Хотя бы в особо важных случаях.
И напоследок, покажу ещё один интересный пример в УТ. Ещё раз перейдём в форму списка "Доверенность выданная". И откроем документ с типом "На получение ДС". Как видно на скрине, у такого документа не отображается табличная часть "Товары".
Теперь откроем документ с другим типом. Табличная часть на отдельной странице.
Перейдём в "Изменить форму" и вынесём таблицу за пределы всех групп и страниц.
Хорошо, а теперь закроем форму и вернёмся к прошлому документу без табличной части. Теперь табличная часть видна и её можно редактировать:
Как вы могли догадаться, всё по той причине, что разработчики скрывают не табличную часть, а всю страницу целиком.
Таким образом пользователь может сломать ТолькоПросмотр, Доступность и Видимость элементов. А может и что-то ещё...
Понравилась статья?
Не будьте равнодушными! Поставьте лайк плюс, оставьте комментарий. Ещё много в 1С неизведанного!
В этом видео я наглядно показываю всё то, что говорится в статье: Наследование свойств элементов, или Как пользователь может сломать вашу форму
И переходите к другим публикациям:
