I am attempting to create an alarm (diagnostic level, FWIW) that triggers every time a new user is logged into the system. This seems like it would be an easy task, but there are far more roadblocks than I would have anticipated.
There’s a System/Client/User/Username tag, which would be perfect, except the System tags can’t be configured to alarm.
I tried pointing this to a client tag, but the same is true for those.
Obviously I can’t point this to a regular (gateway-wide) tag as it’s different across multiple clients.
I tried making an event script on my client tag (mentioned above) that wrote a “True” to a gateway-wide tag in my regular tag provider, which was then alarmed, but this script didn’t work (didn’t execute at all, as far as I can see).
I’m running out of ideas for how to get the user information into an alarm. Is this possible? Are the Ignition spirits mad at me for trying?
Not sure I follow. I was referring to a single gateway tag with the alarm mode set to any change. The OP wanted notification of a new user that was logged into the system. A single tag changes each time a login on a client executes would accomplish this. The alarm value could be a timestamp if the OP wants every login. Or the username, if they want only unique logins. They weren’t entirely clear in the original post.
Sure, but I'd guess that’s a rare occurrence. If 100% integrity is necessary, best to use the audit trail as originally suggested. But considering the OP was trying to set an alarm on the user tag, I would surmise that the off chance two clients logged on within a few seconds of each other was a permissible miss. Would need more info from the OP as to the desired accuracy.
To add a bit of context, I’ll only have three clients operational at a time, and one is a backup that won’t be used unless the other two are compromised, so the issue of overlapping logins is definitely a permissible rarity.
I have tried what @robertm is suggesting, writing to a tag each time the login event is triggered with the username value. The script doesn’t appear to trigger at all, so no data is ever written to the alarmed tag (which must be a Gateway-scoped tag, for clarity).
It does seem like the built-in auditing will be the best option for this. (I’m still relatively new to Ignition, so I wasn’t aware of the user logs in audits before; thank you!)
Seeing that Ignition intentionally divorces events on the client and gateway scope (which does make sense), this feels like the only “clean” way to do it (writing to the database will probably work fine too, just a bit clunkier)
