Hello Dojo!
I have a QAction that generates a string report using user information retrieved via protocol.UserCookie by calling the Notify types NT_GET_USER and NT_GET_USER_INFO. However, when this QAction is triggered by NT_RUN_ACTION, the retrieved user information becomes incorrect, and I end up with details from a different user. Logging the values during this process shows they are all empty, yet the final report contains incorrect user information. According to the documentation for protocol.UserCookie, when its value is null, the script runs using the user associated with the Communication object. Could you clarify how am I ending up with another user information in my report and also advise me how how I can reliably retrieve the correct data in this scenario?
Here's the logs as mentioned: (Expected user is Mariana Navarro. -- Red outline is triggered by NT_RUN_ACTION and Blue outline is triggered from button parameter) 
This is what the code for the logs looks like:
Hi Mariana,
Unfortunately, within DataMiner there are several uses of UserCookie and I believe the documentation you found is for the property of the DmsAutomationScriptRunOptions object that is used when calling an automation script from within a QAction via our NuGets, while the one you are using to do the NotifyDataMiner calls is documented here Property UserCookie | DataMiner Docs (sadly the documentation does not contain details).
This one is populated by DataMiner itself when it can determine who started a QAction like when a user pressed a button.
This functionality has a limitation where it needs user interaction and is not capable of determining the user when a QAction is called from the NT_RUN_ACTION.
Which causes the user cookie to be empty and the resulting username from the NT_GET_USER call will also be an empty string.
When you use an empty string to query the user details with the NT_GET_USER_INFO notify call you are calling this method to retrieve all users instead of just the one that matches a certain username.
This is why your userInfo[1] object will print the details of another user and if you iterate over all entries of the userInfo object you should see the users from the system.
The only suggestion I can think to assist you, in this case, is to attempt to rework the logic so that whichever part of the code calls the NT_RUN_ACTION is avoided and calls directly this bit of code and manually passes the user info into it.
It always needs to start with an interaction, being the pressing of a button or something else because all QAction code is executed in the same process in the server regardless of who is connected.
If you can determine the user by other means or on a previous step of your logic you could look into propagating that information but at its root, it needs to start from a user interaction.
Thank you João! That is very helpful information. Just a quick follow-up—based on your suggestion, I assume there's no way to retrieve the logged-in user instead of identifying the one who clicked the button/triggered the QAction?