Получение информации о пользователе в задаче родительского объекта MasterSca

[AlexeyKitaev]

Есть потребность в передаче информации о текущем пользователе в объектах выполняемых в задаче основного узла или в задаче родительского объекта, получение параметров текущего пользователя с помощью функционального блока GET_CURRENT_USERNAME выполняемом в задаче экрана.

На данным момент реализация выполнена следующим образом: исполнение происходит на двух серверах работающих в резерве, подключение к ним происходит от 3-х АРМ компьютеров, где и производятся все работы, соответственно одновременно активны 3 сессии. В MasterScada создан объект выполняемый в задаче экрана, в него вложен функциональный блок GET_CURRENT_USERNAME, с него тянутся значения Username, ClientAddress передаваемые в параметры находящиеся в том же объекте, откуда уже идёт передача информации в другие объекты системы, выполняемые в задачах родительского объекта или в задаче основного узла. Однако при одновременном подключении нескольких сессий передача информации о текущем пользователе начинает сбоить - метаться от одного пользователя к другому или выводит значения о последнем залогинившемся пользователе.
Все рабочие объекты являются библиотечными экземплярами и при назначении их выполнение в задачу экрана при компиляции выходят ошибки.
Как пример задачи в которой требуется знание о текущем подключенном пользователе - это изменение видимости элемента на окне объекта, что-то должно быть видимо только администратору или инженерам, но не операторам и гостям.

Также имеется задача в вызове скрипта AstraLinux на АРМ компьютере, с которого было произведено нажатие кнопки, как пример открытие через wine AbakReporter для печати отчёта, на данный момент применяется функционального блока SysProcessCreateAsync, однако данный функциональный блок открывает программы на сервере (RT), а не на АРМ компьютере (т.е. открывать скрипт там где крутится клиент визуализации DT). Есть ли возможные решения этой задачи?

[Ready]

Как пример задачи в которой требуется знание о текущем подключенном пользователе - это изменение видимости элемента на окне объекта, что-то должно быть видимо только администратору или инженерам, но не операторам и гостям.

Это решается ч/з права доступа для роли/пользователя. Возможен доступ к отдельным элементам, в справке "Настройка прав доступа элементов". Также можно назначить отдельный экран для роли/пользователя.

Также имеется задача в вызове скрипта AstraLinux на АРМ компьютере, с которого было произведено нажатие кнопки, как пример открытие через wine AbakReporter для печати отчёта, на данный момент применяется функционального блока SysProcessCreateAsync, однако данный функциональный блок открывает программы на сервере (RT), а не на АРМ компьютере (т.е. открывать скрипт там где крутится клиент визуализации DT). Есть ли возможные решения этой задачи?

1. Веб-сервер на АРМ, например, на python или node.js
2. Через "file:///usr/local/script.sh". Для Firefox: в настройках указать "все файлы *.sh открывать с помощью /bin/bash". Для Chrome: через расширение. (не уверен в этом пункте)

[AlexeyKitaev]

Это решается ч/з права доступа для роли/пользователя. Возможен доступ к отдельным элементам, в справке "Настройка прав доступа элементов". Также можно назначить отдельный экран для роли/пользователя

ч/з права доступа есть возможность задать только управление элементом, в нашем случае нужно управлять отображением (видимостью) элементов или же передавать значения в программу находящуюся в объекте исполняемом в задаче родительского объекта или в задаче узла (в том числе в экземплярах библиотечных объектов)

[Ready]

ч/з права доступа есть возможность задать только управление элементом, в нашем случае нужно управлять отображением (видимостью) элементов или же передавать значения в программу находящуюся в объекте исполняемом в задаче родительского объекта или в задаче узла (в том числе в экземплярах библиотечных объектов)

Сделал проект, может поможет: Проект 1.zip

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

Для примера добавлены:
пользователи: Admin, User1, User2, Guest1, Guest2
роли: Администратор, Оператор, Диспетчер, Гость

Возможные пути решения вопроса видимости элементов:

1. Способ ч/з разграничение по окнам.
Для пользователя 'Guest2' назначено стартовое окно 'Окно для гостей', для остальных по умолчанию 'Главное окно'.
У экземпляров библиотечного объекта 'Test2' 'Окно 1' -> 'Главное окно', 'Окно 2' -> 'Окно для гостей'

2. Способ ч/з текущего пользователя.
Программы, исполняемые в задаче экрана:
Объекты > Main > CurrentUser > CurrentUser_FBD_1
Объекты > Main > Программа_ST_2
Библиотека > Локальная > TestProgram > Программа_ST

CurrentUser_FBD_1 предоставляет имя текущего пользователя для Программа_ST_2 и Программа_ST для его проверки.
Результат работы - вкл/откл видимости кнопок. Видимость кнопки библиотечного объекта Test настроена ч/з параметр окна, а в дереве объектов с выходным параметром ButtonVisibility (Программа_ST).

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

[AlexeyKitaev]

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

[Ready]

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

Еще способ. С помощью пользовательского элемента и динамизации.

Проект 2.zip
Пользовательский элемент (Script).pdf

Суть в пробросе пользователя ч/з контролы:
Res/control_set_current_user.js - для CurrentUser (он глобально устанавливает пользователя через 'window.currentUser')
Res/control_get_current_user.js - для Test (берет пользователя из 'window.currentUser'. В принципе любой другой может)

Доступ к свойствам элементов ч/з динамизацию. В экземплярах работает.

Ознакомьтесь с пользовательским элементом и веб-компонентами. Контролы в MS4D построены на веб-компонентах.

[AlexeyKitaev]

Пообщался с тех. поддержкой, и получил решение задачи, все окна выполняются в задаче экрана, независимо от того, в каком объекте они находятся, и следовательно, если привязать username напрямую к параметру окна, то его значение будет отрабатываться только для одного пользователя.
Поставил ФБ get_current_username в объект исполняемый в задаче экрана и привязал значение username к параметру библиотечного окна (НАПРЯМУЮ) и всё заработало.

[Larrrik]

получил решение задачи

Спасибо. На самом деле весьма ценная информация, которую обычно не расписывают в справочной системе.