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

← На главную

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

Вариант 1: Программная проверка в обработчике ПриОткрытии

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

Разберем реализацию на примере: пусть у нас есть Обработка1 (для «Васи») и Обработка2 (для всех остальных). В модуле формы Обработка1 мы можем прописать логику, которая будет проверять пользователя и, при необходимости, принудительно открывать Обработка2, закрывая текущую.

Посмотрим на пример кода:


// В модуле формы Обработка1
&НаКлиенте
Процедура ПриОткрытии(Отказ)
    Если ИмяПользователя() <> "Вася" Тогда
        // Если зашел не тот пользователь, перенаправляем на другую форму
        ОткрытьФорму("Обработка.Обработка2.Форма.Форма");
        
        // Отказываемся от открытия текущей формы
        Отказ = Истина;
    КонецЕсли;
КонецПроцедуры

Этот метод прост, но имеет нюанс: пользователь видит на долю секунды первую форму, прежде чем сработает Отказ = Истина. Также важно помнить, что если пользователь имеет право изменять рабочий стол, он может попытаться добавить обе обработки вручную.

Вариант 2: Использование параметров сеанса

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

Выполним следующие шаги:

Создадим параметр сеанса, например, ЭтоТестировщик типа Булево.
В модуле управляемого приложения при старте системы заполним этот параметр на основе проверки текущего пользователя или его принадлежности к группе.
В коде наших обработок будем обращаться к этому параметру: ПараметрыСеанса.ЭтоТестировщик.

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

Вариант 3: Использование общей формы-обертки

Разберем еще один, более профессиональный вариант — создание формы-обертки. Вместо того чтобы предоставлять пользователю доступ к двум разным объектам, мы создаем одну общую команду, которая открывает некий «диспетчер».

Логика работы такой формы будет следующей:


&НаКлиенте
Процедура ПриОткрытии(Отказ)
    Отказ = Истина; // Саму форму не показываем
    
    Если ПараметрыСеанса.ЭтоТестировщик Тогда
        ОткрытьФорму("Обработка.Обработка1.Форма");
    Иначе
        ОткрытьФорму("Обработка.Обработка2.Форма");
    КонецЕсли;
КонецПроцедуры

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

Важные рекомендации при реализации

При тестировании новых версий обработок через описанные механизмы, обратите внимание на следующие моменты:

Кеширование: Убедитесь, что ПриСозданииНаСервере в обеих обработках учитывает различия в данных. Если новая версия обработки использует иную структуру данных, кешированные параметры старой версии могут вызвать ошибки исполнения.
Настройки рабочего стола: Помните, что в платформе 1С:Предприятие 8.3 пользователи могут самостоятельно менять интерфейс. Если ваша цель — жестко ограничить доступ, программных проверок в ПриОткрытии может быть недостаточно, так как пользователь может открыть обработку через пункт меню «Файл - Открыть».
Расширения: Если вы не хотите менять основной код конфигурации, используйте расширения для переопределения команд открытия. Это позволит сохранить целостность основной поставки и сделать внедрение тестирования практически незаметным для системы.

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