Retentive client tag

Hi all,

Is it possible to make client tags retentive?

Details: I have an auto logout script that uses a client tag to determine after how many minutes to automatically log out. I’d like to use a client tag, because I’d like this value to be settable for each client - e.g. a client in a secure area that requires semi-frequent interaction could be set to 30 minutes to avoid having to continually keep logging in, while a client out in a more public area logs out after 3 minutes to limit unintended access. Creating a client tag for this means that each time a new client is added, it will get its own copy of the tag - but when I close and re-open the client, the tag value reverts back to whatever it was set to in the designer.

Is there a way to make client tags retentive, or to otherwise achieve what I’m trying to achieve here?

A few possibilities:

  • Have each client create their own memory tag through scripting (include their name to make it unique)
  • Or make their own entry in a memory dataset tag.
  • Have a script on each client save the client tag value to a local file on change and then load from file on client startup.
1 Like

I like the first two options. The third makes things OS and client configuration dependent, which is probably not ideal.

I’ll have a play with the first option and see if I can get it to do what I want

Or store client-specific information in a database table, using any desired client ID characteristics you like. Avoids the problems with simultaneous writes to dataset tags, and proliferation of individual memory tags.

4 Likes

Even neater again. I like it!

Another possible option would be to use a client startup script to set its timeout based on the MAC address tag [System]Client/Network/MACAddress. You could set a low default value if it’s not in the list just in case the client hardware is ever changed out.

1 Like

Another good idea. I’m allowing a suitably credentialed user to change the time from a settings screen, so new hardware “resetting” the idle time isn’t a massive deal.

I ended up going with the database idea and have got it working. The client startup script was already getting the hostname to determine which windows to display. So now it also queries a client_properties database table for an entry with its own hostname. If found, it grabs the autoLogoutTime column value and writes to the client tag. If not found, it adds a row to the database with its own hostname. The database table is set up to have a default value of 5 in the autoLogoutTime column, so that’ll be what it’s created as by default.

Then on the client tag I run a tag change event script to update the database with the new value, where hostname = the clients hostname. Works a charm.

The only question I have is that I initially got hit with an error about not having the required roles. I did some googling and found that I had to turn off role restrictions for Legacy Database Access in my project properties to get it to work. Reducing security is always a red flag for me, and the use of the word “legacy” is another red flag. Is there a slightly different way I should be doing this to avoid using “legacy” features, or reducing security?

I definitely like the database idea better.

If you convert any query you’re running to a Named Query, you should be able to disable the Legacy Database Access permission.
https://docs.inductiveautomation.com/display/DOC79/Project+Properties#ProjectProperties-ClientPermissions
https://docs.inductiveautomation.com/display/DOC79/Named+Queries

2 Likes

Perfect, thanks. Had a hell of a time with the named queries until I learned that you can’t just type :parameterName into the query, you actually have to drag and drop the parameter. But I now have three named queries: GetAutoLogoutTime, AddNewClient, and UpdateAutoLogoutTime. The startup script will run the first, and if nothing is returned, run the second. The third is run from a tag change event on the client tag itself. Works a treat!