Tag Structure, UDT setup, and Best Practices

[pturmel]

@rpavlicek

Scripting or json copy/paste only?

Yes.

@rpavlicek

Any way without doing those, but still being able to have top level parameters in the top level folder structure?

No.

@rpavlicek

potential disabled wasted tags

"Disabled" is a subcode of "Bad". You will make your life miserable if you do that widely.

If you feel you need variable numbers of items in tag folders, your UI is almost certainly going to need scripts to handle it. So having corresponding scripts to configure the mess is par for the course.

There's no magic wand, Ignition's reputation to the contrary.

[nminchin]

Topic digression warning...

What I feel is lacking is the ability to easily set write permissions on tags based on security zones. For example, if all device start commands need operator role, but then you add some of these devices into a particular area folder where only operators within a security zone can write to this tag, I haven't found an acceptable solution to achieve this simply.
You could:

• manually override the writePermissions on all relevant device tags within the area folder. Lots of work, especially if it's a large area. What if the base UDT definition changes its default write permission to require say the "OtherOperator" role instead? this isn't reflected
• leave the tags alone and instead apply the zone permissions at the page level. But this has a few drawbacks: It's impossible to apply this per tag and this will apply for all tags for the devices accessed from that page (e.g. device popups will have the control enable conditions passed to it which come from the page, and these include in it the security zone), and this decentralises the permissions configuration which can lead to errors in implementation.

Example:
2x grape crusher HMIs. These should only be able to be controlled by "operator" roles logged in from the 2x HMI clients which are positioned directly in front of the machinery.
The "maintenance" role should, however, have access to changing particular settings of devices, engineering setpoints, etc. from anywhere in case they get a call. This second maintenance requirement means that I essentially need to use the tag permissions to limit control, but this is a lot of effort to configure this on 4-5 tags for ~50 devices, plus all of the other process tags on top of that (maybe 60 tags)
Of course I can use scripting to do this but this is a bit to set up; it would be a lot simpler if we could set permissions on folder which would combine with the permissions on its sub-tags, similar to how OS file/folder security is done

[Hayden_Watson]

Maybe the wrong place to go, but I wish there was some security config in the tag groups. Would make something like this a lot easier to implement. I want my special motor jogging tags to only be accessible if you're next to that motor, etc.

[rpavlicek]

What about the ability to put parameters on folders in the main tag structure (not in UDTs) and having UDTs read from them? Maybe something to put in Ignition features and ideas?

*Edit to add that there seems to be a similar idea posted a few years ago. Didn't get much attention, however seems like it would be of big benefit.
add bindable parameters to tag folders | Voters | Inductive Automation

[zbinder]

It's not quite the same as parameters, but UDTs are capable of recognizing outside tags through relative paths. I've used this to give tags awareness of what folder they're in.

[pturmel]

@zbinder

UDTs are capable of recognizing outside tags

Only in expression tags. Binding expressions that configure a tag's properties only accept UDT parameters.

[j.israelsen]

@nminchin and @Hayden_Watson, I agree with the direction you are going with tag security.

Reference the following related feature request and forum post, maybe we can get some traction on a solution:

Tag Security Bindings | Ignition Features and Ideas | Inductive Automation

Tag Configuration - Security Setting By Script or Parameter

I have a UDT/Tag. I would like to set the security settings of the UDT/Tag through a script or a parameter. Is this possible? Clarification, I don't need to dynamically change the security setting (on the fly), just to be able to set it during configuration. An example implementation would be to secure a UDT/Tag based on whether it should be limited to "Supervisor" role or an "Operator" role. The only current solutions or ideas that I have thus far are as follows: Override UDT security setti…