Как в Системе взаимодействия 1С создать обсуждение «только для чтения»

← На главную

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

Постановка задачи и анализ стандартных возможностей

Основная проблема заключается в том, что по умолчанию любой участник группового обсуждения может отправлять сообщения, менять тему чата или добавлять/удалять других участников. Чтобы превратить обсуждение в полноценный «канал», нам необходимо решить три задачи:

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

Проанализируем ситуацию: платформа предоставляет программный интерфейс для управления обсуждениями через объект МенеджерСистемыВзаимодействия. Начиная с версии платформы 8.3.16, появились расширенные возможности по управлению типами обсуждений, включая выделенные каналы, но для полной блокировки действий пользователя потребуется программное вмешательство.

Решение 1: Использование обработчиков событий для блокировки сообщений

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

Разберем по шагам, как это реализовать. Мы можем использовать подписку на события или код в модуле, который будет анализировать контекст создаваемого сообщения. Если сообщение пытается отправить обычный пользователь в «новостной» чат, мы должны прервать операцию.

Пример логики проверки в обработчике:


Процедура ПриЗаписиСообщенияСистемыВзаимодействия(Источник, Отказ) Экспорт
    // Проверяем, является ли обсуждение информационным каналом
    Если Источник.Обсуждение.Ключ = "ОбщийНовостнойКанал" Тогда
        ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
        // Разрешаем писать только пользователям с ролью Администратор или специальному Боту
        Если НЕ РольДоступна("АдминистраторКанала") И Источник.Автор <> ИдентификаторБота Тогда
            Отказ = Истина;
            ВызватьИсключение "В данном канале запрещено оставлять сообщения. Он предназначен только для чтения.";
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

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

Решение 2: Программное управление свойствами обсуждения и «Бот-модератор»

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

Рассмотрим подробнее схему с использованием технической учетной записи (бота):

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

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


Процедура ПривестиКаналыКСтандарту() Экспорт
    КлючКанала = "Global_News_Channel";
    Обсуждение = СистемаВзаимодействия.ПолучитьОбсуждение(КлючКанала);
    
    Если Обсуждение <> Неопределено Тогда
        Если Обсуждение.Заголовок <> "НОВОСТИ КОМПАНИИ" Тогда
            Обсуждение.Заголовок = "НОВОСТИ КОМПАНИИ";
            Обсуждение.Записать();
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

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

Решение 3: Индивидуальные обсуждения для каждого пользователя

Рассмотрим альтернативный вариант, упомянутый в обсуждении: создание отдельного обсуждения для каждого сотрудника. С точки зрения архитектуры это выглядит как «чат с поддержкой», где пишет только одна сторона.

Преимущества:

Пользователь не видит сообщений других пользователей.
Полная изоляция данных.

Недостатки:

Высокая нагрузка на систему при массовой рассылке (нужно создать тысячи сообщений вместо одного).
Сложность администрирования.

Тем не менее, если количество пользователей невелико (до 100-200 человек), этот метод вполне жизнеспособен. В этом случае мы создаем обсуждение между Ботом и КонкретнымПользователем. Поле ввода у пользователя останется, но бот может просто игнорировать входящие сообщения или отвечать автоматической заглушкой.

Решение 4: Кастомизация интерфейса (скрытие поля ввода)

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

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