I always thought runScript was only used to call functions, really cool that you can do list comprehension one-liners in them, that’s very useful.
Keep in mind, I think @pturmel suggests only using runScript with functions that have short execution times.
1 Like
runScript has evolved from only being able to do one-liners to the current form that can pass arguments to functions. But only one or the other. If you wish to have inline code that also accepts arguments (without having to recompile the string), you would use my objectScript() function from my Simulation Aids module.
{ I created this expression function specifically to enable passing true objects into python from a binding. With other features that I think make sense. IA then added the argument passing to runScript, in a slightly different form, and credited my idea in the release notes. I pretty much always use objectScript where others use runScript. }
1 Like
What would be the correct method to change the username for the audit log? Our projects have an autologin to start. When we run our login script I can see in the audit log that it records a login action for that username, but then when we go to toggle a bit it still records it under the autologin username. We utilize the system.security.switchUser function to do this but it still doesn't update the System>Client>User>Username tag so I'm not sure if I'm missing a step on how to retain that username for the tag write functions. We might be able to get away with just seeing which users were logged in when some tag writes occurred, but it would be fantastic to directly tie that user to the tag write with the audit log.
I'm not having this issue. I have an auto-login as well, but all audit events are being logged under the user that performs the action. How are you performing the writes? When a user logs into mine, the System/Client/User/Username tag updates. (I know this because I show it on my header at all times).
Are you sure the user is actually getting logged in properly?
Ok, perhaps we're missing a portion of that function in our login template and looks like maybe have the hide error set on now that I'm reading it again. I will dig into this some more to see if that function actually is failing. I made a test label tied to display that tag and saw that it didn't update, but since the audit log recorded that user login I thought the function was still working.
You're also calling switchUser twice. You should only need one call and can check if switch is true or false to determine if it was successful. I also believe that when passing event, it will automatically close the window, so you don't need your closeParentWindow either.
Agreed, the redundant line was me testing a direct system call to see if it had any effect so line 54 will be taken back out. That's interesting on the event window close though didn't realize that's pretty slick!
The switchUser issue was that our projects are set to a default internal User Source so we can utilize a dummy autologin, but that means we aren't tied to AD for the system login. We manually call the AD user source in our script so we can set AD groups for each project so when I switched the project to one of our AD or Hybrid user sources I was able to get that switchUser function to work.
Making this change though meant our normal autologin can't be used anymore since we can only set that dummy login on an internal source so we'll have to create some dummy app ID that exists in our AD. For now I just used an app ID from one of our DB connections to test. One thing I'm still having issues with now though is the logout procedure. If I use system.security.logout then it completely takes you back to the main launch screen where no user is logged in. I can do a switchUser to go back to the autologin app ID, but then I'd have to leave the password in the script which is poor practice.
Any thoughts or recommendations on how to get that logout to return back to the default autologin user?
I put the password in my "logout" script to just switch back to the default user. Because this user/login isn't used for anything and in our system is read-only so they can't do anything besides change screens, it's not an issue.
I looked at the only other old project we have running the audit log and that's what they ended up doing for the logout as well so you're right should be fine since it has no real credentials. I appreciate the feedback!
That older project is somehow logging the username on its tag writes despite using that default user source and not having a switchUser function in the login so we might poke around in there to see if they've got some roundabout setup working, but we'll most likely move forward with a dummy app ID to keep things a bit more straightforward.
Most of my clients that use AD login use it with soft failover to an internal user source. Then all projects, and the gateway, and the Perspective IdP, all point at the AD user source.
The internal user source is where such dummy accounts go, along with contractors (like me) who don't get AD accounts.
1 Like
Oh that's a great point I forgot to look at failovers! Just set one to a soft failover and able to utilize our default internal autologin now. Thank you!
1 Like