I’ve actually only recently started using Security Levels and associated tag
writePermissions, as I’m only just now in a version of Ignition where we can read the CanWrite prop of a tag to check if the current user has privilege to disable components (previously, I didn’t like that you couldn’t show the user with an icon and disabled button state that they didn’t have access to functionality, and you had to rely on them clicking the button to bring up the “no privilege” error popup).
However, unless I’m missing something, I’m finding it’s a lot of work when you have tags based on UDTs that you want to lock down to more complex security levels that don’t just link to individual roles.
For example, a pump UDT might have tags
CloseCMD, and generically, you only want an
Operator role to have write access.
However, when you add an instance of this into the ‘WWTP’ area of a site, you only want, for example, either certain HMIs (i.e. IP addresses) or certain usernames to have access to the pumps in this folder. In this instance, you have to manually go into each and every instance and override the security permissions for each relevant tag. Imagine you have 100 UDTs with 5 tags with write permissions, that’s a lot of tags to go through. It then also means that these UDT tag write permissions config are now unlinked from the UDT definition; any changes to the definition are now lost in the instance.
What I’ve seen in other SCADA platforms and also in OS’ is cascading security permissions, where you can define permissions at each level, and the resulting permission is a combination of all levels.
This would mean that you could add the area-based write permission to the
WWTP folder, and that would then combine with the pump UDt instance’s Operator requirement.
Sounds complicated to implement…