Allow per dashboard-element user privileges

[Hisma]

Description

Premise - in production environments, various people interact with HMIs, from engineers, to operators, simple maintainers, SCADA architects, etc.
These HMIs are normally in easy to access locations, specifically for their convenience. However, that creates a problem - anyone that can walk up to the HMI can interact with the HMI/dashboard, including potentially starting/stopping equipment, putting equipment and personnel at risk. To prevent this, most HMIs by default are in "read only" mode, so someone passing by can view the status of the process, but not manipulate it. If they want to actually interact with the dashboard, they must log in. Depending on the privileges of that user, they can do certain things.
Common user levels are Admin - full control Engineer - can fine tune equipment like change operating parameters & alarm setpoints but not completely nuke displays Operator - can start/stop equipment but not change setpoints that require authorization from engineering read-only - default user login

If we want NR Dashboard to really challenge traditional HMI/SCADA systems on the production floor, I see this as a feature that will need to eventually be implemented.

For now, having the ability to restrict at a page-level can achieve some degree of user privilege granularity, which is a step in the right direction.

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[Hisma]

Also, there's two typical properties associated with user-level - read/write access, and visibility. You may want an element completely hidden from certain users, ie a button that can start/stop a machine. Other elements you may allow certain people to read, not write, like a setpoint value. Visibility is more of a "nice to have" than a "need to have" feature, as it just makes displays more neat and tidy.

[joepavitt]

Richard and I spoke privately on Slack about this, but will drop my own notes from a development side too:

• We are going to support state messages e.g: msg.state.enabled = false or msg.visible.false which can be sent to an individual component
  • The thinking here is that we could have some kind of "on login" or "on mounted" node in Node-RED which fires an event anytime someone logs in, or loads the dashboard, that could then trigger the state messages accordingly, but would likely result in messy flows.
• We are also hoping to support page-by-page or, at least, dashboard-by-dashboard access control
  • The alternative here being you create an admin dashboard and a viewer dashboard, although this isn't ideal in that effort needs to be duplicated.
• We could introduce RBAC controls generally as a property on a component-by-component basis, default to "all", and then driven by some RBAC levels defined in Node-RED/Dashboard, which feels the cleanest way to do this.

[stytlus1234]

I'am developing an app and not having any option to set user privileges is a real problem, the "unified-red" project, did an exelent job on solving that problem from the start, creation of users and their privileges is built in on the dashboard. Even creating new users just for the dashboard at this time is a real problem, there's just not enough granularity for use on industrial environments.

[joepavitt]

Even creating new users just for the dashboard at this time is a real problem, there's just not enough granularity for use on industrial environments.

All of the problems you've detailed here are actually solved with FlowFuse. You can manage multiple instances of Node-RED, control different access levels for as many users as you like, including "Dashboard Only" access.