При проектировании современных корпоративных систем на платформе 1С:Предприятие разработчики часто сталкиваются с необходимостью адаптации интерфейса под различные типы устройств. Типичный сценарий: один и тот же сотрудник должен иметь полноценный доступ ко всем функциям системы при работе за компьютером в офисе (через ТонкийКлиент) и жестко ограниченный, упрощенный интерфейс при работе со смартфона или планшета (через МобильныйКлиент).
В этой статье мы подробно разберем, как правильно реализовать разделение интерфейсов, рабочих столов и прав доступа для разных клиентов под одной и той же учетной записью пользователя информационной базы. Мы проанализируем распространенные ошибки проектирования и рассмотрим надежные механизмы платформы, которые позволят решить эту задачу элегантно и безопасно.
В процессе обсуждения подобных задач на форумах часто звучит предложение использовать функциональные опции, привязанные к какому-либо справочнику параметров или регистру сведений. Идея кажется простой: при старте системы определять тип клиента и записывать значение (например, "Мобильный клиент") в базу данных для текущего пользователя.
Рассмотрим, почему это критическая архитектурная ошибка:
Один и тот же пользователь информационной базы может быть одновременно авторизован в системе с нескольких устройств. Например, у него открыта сессия на рабочем компьютере, и в этот же момент он запускает приложение на телефоне. Если система запишет признак "Мобильный клиент" в общий справочник или регистр для этого пользователя, то эта запись мгновенно повлияет на сеанс на персональном компьютере. В результате интерфейс на ПК «сломается», переключившись на мобильный вид, либо наоборот — мобильный клиент попытается отобразить тяжелые формы, предназначенные для монитора.
Правильное решение: использование механизма Параметров сеанса. Параметры сеанса уникальны для каждого конкретного подключения к базе данных. Даже если один пользователь запустит десять сеансов с разных устройств, у каждого сеанса будут свои независимые значения параметров, хранящиеся в оперативной памяти сервера приложений.
Давайте разберем по шагам, как связать тип клиента с интерфейсом системы с помощью параметров сеанса и функциональных опций (ФО).
Сначала создадим в конфигураторе новый параметр сеанса:
ИспользоватьМобильныйИнтерфейсБулевоДалее создадим Функциональную опцию (например, ОграничитьИнтерфейсДляМобильногоКлиента), у которой в качестве источника укажем наш параметр сеанса ИспользоватьМобильныйИнтерфейс. В состав этой функциональной опции мы включим все те объекты метаданных (подсистемы, документы, справочники, отчеты), которые не должны отображаться в интерфейсе мобильного клиента.
Теперь нам нужно инициализировать этот параметр при запуске системы. Перейдем в Модуль управляемого приложения и добавим обработчик события ПриНачалеРаботыСистемы:
Процедура ПриНачалеРаботыСистемы()
#Если МобильныйКлиент Тогда
// Устанавливаем параметр сеанса на сервере в Истина
УстановитьПараметрСеансаМобильногоКлиента(Истина);
// Принудительно обновляем интерфейс, чтобы применились функциональные опции
ОбновитьИнтерфейс();
#Иначе
// Для обычного тонкого или веб-клиента гарантируем стандартный доступ
УстановитьПараметрСеансаМобильногоКлиента(Ложь);
#КонецЕсли
КонецПроцедуры
Метод УстановитьПараметрСеансаМобильногоКлиента должен быть объявлен в общем модуле с установленными свойствами Сервер и Вызов сервера:
Процедура УстановитьПараметрСеансаМобильногоКлиента(Значение) Экспорт
ПараметрыСеанса.ИспользоватьМобильныйИнтерфейс = Значение;
КонецПроцедуры
Благодаря этому подходу, как только пользователь зайдет с мобильного устройства, платформа мгновенно скроет из меню все лишние подсистемы и документы, оставив интерфейс чистым и лаконичным.
Часто на форумах советуют создать одну универсальную форму рабочего стола и динамически управлять видимостью ее элементов (панелей, списков, графиков) в зависимости от типа клиента. Это решение рабочее, но оно сильно загромождает код формы и усложняет ее поддержку.
Платформа 1С:Предприятие предоставляет гораздо более элегантный механизм — объект НастройкиНачальнойСтраницы. С его помощью мы можем полностью подменить состав форм рабочего стола «на лету» при старте приложения.
Давайте проанализируем пример кода, который очищает стандартную начальную страницу для мобильного клиента и назначает туда одну специализированную форму (например, форму АРМ мобильного сотрудника):
#Если МобильныйКлиент Тогда
// Создаем объект настроек начальной страницы
Настройки = Новый НастройкиНачальнойСтраницы;
Состав = Новый СоставФормНачальнойСтраницы;
// Очищаем стандартное содержимое и добавляем только специальную форму
Состав.ЛеваяКолонка.Добавить("Обработка.РабочееМестоМобильногоКлиента.Форма.Форма");
Настройки.УстановитьСоставФорм(Состав);
// Сохраняем настройки в системное хранилище текущего сеанса
ХранилищеСистемныхНастроек.Сохранить("Общее/НастройкиНачальнойСтраницы", "", Настройки);
#КонецЕсли
При таком подходе вам не придется писать десятки условий на видимость элементов. На компьютере у пользователя откроется полноценный рабочий стол с аналитикой, а на мобильном телефоне — специализированная форма, разработанная специально под вертикальный экран смартфона.
Поскольку динамически включать или отключать роли (права доступа) во время активного сеанса пользователя в 1С невозможно, нам необходимо обеспечить программную защиту от несанкционированного доступа к данным с мобильного устройства.
Если пользователь каким-то образом попытается открыть форму скрытого документа (например, через навигационную ссылку), мы должны жестко пресечь эту попытку. Реализуем это на двух уровнях.
1. Ограничение на уровне форм документов и справочников:
В модулях форм объектов, доступ к которым с мобильных устройств запрещен, пропишем проверку в событии ПриСозданииНаСервере:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
#Если МобильныйКлиент Тогда
Отказ = Истина;
ВызватьИсключение "Данный документ недоступен для работы с мобильного устройства в целях безопасности.";
#КонецЕсли
КонецПроцедуры
2. Ограничение на уровне записи объектов базы данных:
Для гарантированной безопасности добавим аналогичную проверку в модуль самого объекта (например, документа) в событие ПередЗаписью. Это исключит возможность изменения данных через сторонние обработки или внешние источники, если сеанс запущен на мобильном клиенте:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
#Если МобильныйКлиент Тогда
Отказ = Истина;
ВызватьИсключение "Запись данных этого типа запрещена из мобильного клиента.";
#КонецЕсли
КонецПроцедуры
Если вам все же необходимо использовать одну и ту же форму и на десктопе, и на мобильном устройстве, но на телефоне требуется скрыть второстепенные реквизиты, воспользуйтесь стандартным механизмом адаптивной верстки платформы.
У каждого элемента формы (кнопок, полей ввода, колонок табличных частей) в конфигураторе есть свойство ВажностьПриОтображении. Оно может принимать значения:
Очень низкаяНизкаяОбычнаяВысокаяПри запуске формы на мобильном клиенте платформа автоматически анализирует доступную ширину экрана. Если места недостаточно, система начнет автоматически скрывать элементы с низкой важностью. Например, в табличной части документа на телефоне останутся только колонки с номенклатурой и суммой (свойство Высокая), а колонки со ставкой НДС, статьями затрат и единицами измерения (свойства Низкая или Очень низкая) будут автоматически скрыты без написания единой строки кода.
Для правильной реализации разделения интерфейсов под разные типы клиентов для одного пользователя необходимо следовать трем золотым правилам архитектуры 1С:
НастройкиНачальнойСтраницы, разделяя логику десктопного и мобильного рабочих мест.#Если МобильныйКлиент.