when a user runs a PSOS script, if the records modified/created by the script are tracking the modification/creation USERNAME ( not the accountname ) the user name will read the same way you see the script appear in the DB connections. <scriptName> - <accountName> <someNumber>
It seems <scriptName> is the name of the script that was called via PSOS regardless of any subscript it may have called where the actual edits are taking place.
You also get <scheduleName> if the script is triggered by a schedule and not PSOS. I wonder what it shows when that stuff is happening via dAPI. Anyone knows?
I guess it can be useful under some circumstances. Not sure which ones yet...
The tricky part with the User Name is that it's editable by the user of the device. So that makes it both useful and also suspect.
One nice usage centers around users with multiple devices. If I was logged into the custom app on both my work machine, and my personal laptop, I could pick up that data. It's obviously more of an informational thing, and probably not something you want to use for something vital, like security, but that's one use-case.
As for the scenario you describe, knowing the starting point of what fired the connection to open, can be extremely useful when diagnosing how data changed, or other issues with the server itself. It's rare that I've needed that data, but on occasion, seeing correlation between the logs helps pinpoint what caused a failure.
I once worked on a solution where there were cases where a PSOS-invoked script could exit out of the OnFirstWindowOpen triggered script as early as possible. And -- there were also cases where the PSOS-invoked script needed to have the OFWO script run its course. That was one instance where I leveraged the behavior that you've called out in order to determine the target PSOS script at the start of the OFWO script. I don't think I've ever had to deal with that in more than just that one solution.
As @jormond has mentioned, it is nothing that I would base security off of, but it did help out in the scenario I described above. Additionally, it struck me as not a perfect technique, as if the result of Get( UserName ) were to contain more than one hyphen char, then there is some ambiguity going on there - not necessarily insurmountable, but I did always regard it as inconvenient.
All that said, I keep an open eye/ear out for other ways this could be of use.
we got a bigger installation where the IT sets up virtual PC's for every user. After setting up, the user-name defaults to something like 'default user', what also shows on the client-list/statistics (FMS18)
If username is that default, users were asked to set up the username correctly on their vPC
On our VM RDP streaming accounts it defaults to ‘Windows User’ after activation. As we set all preferences, hosts and favourites up, very few users ever go into preferences.
It can be useful to identify a user accessing a database from someone else’s account (or PC if on a traditional setup), which they do frequently - Get (UserAccount) compared with Get (GetAccountName)
As the admin console in Databases --> All Databases only displays the UserName, I annoy my users with a dialog and opening of the Preferences if UserName and AccountName do not match, asking them to change the UserName. On FM12/13 I managed to set the UserName to the windows login name by editing the installer msi, but that stopped working, so the user has it to do once:
......
If [ Get ( UserName ) <> Get ( AccountName ) ]
Show Custom Dialog [ "Benutzername" ; "Bitte ändere im nächsten Dialog-Fenster deinen Benutzernamen von '" & Get (UserName ) & "' auf '" & Get ( AccountName ) & "'¶Danke!" ]
Open Preferences
End If
.....
Get ( AccountName ) gets the account the user logged in with ( what you enter in the login dialog ).
Get ( UserName ) gets the value that is in the preferences. Either the default user name that comes from the machine's login, or the "Other" User name that is entered, if selected.
It can be useful to identify a user accessing a database from someone else’s account (or PC if on a traditional setup), which they do frequently
Andy was saying.
I don’t understand how get username would return Cecile if I go to your work station and access the database from your account.
Either the copy of FileMaker installed on your machine would return Josh if system was selected or it would return admin if other was selected.
I highly doubt anyone going to help a colleague, for instance, would take the time, to change that value before accessing any records or doing anything in the db.
Consider this example:
Get ( AccountName ) = "Josh"
Get ( UserName ) = "Cecile"
That says that "Josh" may have logged in on "Cecile's" machine, since that User Name isn't going to change, if Cecile is still logged into the machine.
Ok so my local copy will return what is in my username default (either my account name or the value I put in other) for get username but will return the real user (account logged into the copy) for get account.
The essential condition for it to achieve its purpose is that system owner has logged out of the db from his machine and doesn’t remember his password to auto login in his preferences.
Correct. Best practice is that you not leave the file open and the computer unlocked. That is especially important when logged in as an Admin account or account with Manage Security privileges.
We use Microsoft Intune MDM to set the device name of all iOS and Windows devices such that the user can’t edit them. Then with Get(UserName), we capture that on all logins, and some script logging, and it’s proven very helpful for troubleshooting and isolating from which device a problem may be originating.
It's in the new XML 2.0 that Claris is still building out. So it's probably going to be around for a while. I find it really useful because I can log in with an account that's not my name, but still have the "User Name" pick up my name. Makes it awesome for FMComparison to see changes between files, and know who made the last change.
