За идею спасибо Владимиру.
Но его обработку переработал порядка на 90%, как по функционалу, так и по логике.
Итак, это расширение, которое надо добавить в программу, и надо отключить все безопасные режимы, чтобы мог работать перехваченный метод общего модуля.
По умолчанию, за минусом исключений, о чем подробнее ниже, рядовым пользователям дается право одновременной работы в одном сеансе. Для работы в двух сеансах (более я не предусматривал) надо дать такое право в дополнительном реквизите, его надо создать вручную к справочнику "Пользователи".
Наименование (заголовок), описание и т.д. задайте сами, какое хотите.
Тип значений - булево.
Имя (для разработчиков) - строго "_РазрешеноЗапускать2сеанса" (ну или вы сами измените, если будете дорабатывать "под себя").
Здесь это право даётся пользователю
Функционал обработки, проверки. Примечание, функционал делался под "наши нужды", кому надо иначе - код открыт.
Шаг 1. Это файловая база? Да - проверки закончили и новый сеанс можно, иначе продолжаем (мы работаем в клиент-серверном варианте).
Шаг 2. Роли пользователя стартующего сеанса. Если есть «Полные права» или «Администратор» тогда сеанс разрешён, иначе идём дальше (полным правам нет лимитов).
Шаг 3. Считаем, сколько уже запущено сеансов в этой базе этим пользователем. При этом в проверяемых сеансах «Полное имя» пользователя не должно быть пустым, а имя приложения должно быть «1CV8C» или «1CV8» (толстый или тонкий клиент). Другие соединения типа "фоновый процесс", COM, designer ... не считаем.
Если ещё не запущен ни один сеанс, тогда стартуем, иначе дальше.
Шаг 4. Проверяем, можно ли пользователю иметь 2 сеанса.
Если можно и ранее запущен всего один сеанс, тогда разрешаем новый сеанс, иначе дальше.
Шаг 5. Если число сеансов, с учетом запускаемого, превышает допустимое, тогда выводим пользователю такое предупреждение с правом выбора:
(примечание - под краской скрыты имя сервера и имя базы)
Шаг 6. Если пользователь выбирает "да", сразу закрывается этот только что начинавшийся сеанс.
Если выбирает "нет", тогда новый сеанс остаётся, а "лишние" ранее начатые удаляются.
(примечание - под краской скрыто имя пользователя)
Подсказка внедряющему.
В обработке учтены пустые логин и пароль "администратора кластера серверов".
Вы можете написать свою логику получения логина и пароля в этом методе.
В том числе применив получение данных в каком-нибудь недоступном обычному пользователю месте базы, и с разными вариантами в зависимости от имени сервера базы (рабочий сервер и сервер разработчиков, и т.п.).
Например, справочник или регистр сведений, доступ к которому имеют только "полные права".
Эффект. Мониторинг сеансов (консолью администратора кластера серверов) в течение недели до внедрения показывал, что в корпоративной базе было от 50 до 100 повторных и более сеансов, общее число под 400 и выше.
Сейчас пиково 330, ноль двойных. То есть в среднем 70 лицензий мы не тратим напрасно, и они достаются пользователям других баз 1С.
Проверено на следующих конфигурациях и релизах:
- Зарплата и управление персоналом, редакция 3.1, релизы 3.1.28.64
