It would be really useful to be able to obtain the user name of some one running an app in the Gallery. This could be used for instance in row level security for people running an app that produces a report and that data is considered sensitive
@wildflower How do I put this data into my workflow? I want to create a workflow that has user data, and I want to be able to leverage that against the login that is used in gallery. That way I can control what the user sees when they run the workflow.
@AudieCruz I found what Alteryx has implemented via their Server Usage Report lacking but this post on the community helped me build and integrate an audit workflow that queries MongoDB into workflows that require an audit: Get App User name at Run Time. There's a lot of back and forth and the 2nd page or so has example workflows. You can pull the app and user info out of MongoDB, tie it in with a gallery workflow and write out to a db for audit purposes. Have fun!
The status of this is "Implemented" but there is no link to a documentation.
This post is mentioned in a comment (Get App User name at Run Time) The status of this idea should not be "Implemented" since the method described in the post really is only a workaround.
Reasons: 1. It cannot run in a macro and has to be copy pasted into every workflow where it should be used.( Use __cloud:UserId in a Macro) This is not nice.
2. I would have to give the MongoDB password to every user who wants to access this (NO) and open the MongoDB port in my firewall for someone on designer testing it (NO) or create a job to save the content of the user table into a different database (redundant) where everyone who needs to be permissioned and can see all users having a gallery account (NO).
The only thing really needed is the username. There should be a function that can be used in the formula tool for this like username().
Seems to be some misconceptions and confusing on this idea (not to mention being in the wrong place), so I wanted to clear up some of the confusion if possible.
First, this idea has had a long life and due to that a lot of the features that may have been impacted from this idea in 2015 may no longer be applicable or present. An example of this is the Server Usage App, which has evolved considerably as well as our auditing functionality which has been updated as recent as 2020.2, like this more robust auditing idea which was accepted and implemented recently. It's also important to consider that as our product team understood this idea back when it was implemented in 2018, this primarily pertained to auditing and less so to the usage of that data in macros in real time as is being suggested in more recent comments.
While we're open to all feedback for our products, including the inclusion of usernames as more accessible variable, this would need to be researched in greater depth as it was not considered when working through the original ask. As such it may be better suited as a new idea that can traction as it's own feature request.
We appreciate the feedback however, and understand that there are many use cases for many functionalities, and we strive to meet as many of these use cases as possible for our product.
@KylieF Seems like a lot of the comments here and the initial request were very much focused on real time access to the user that launched the workflow. Are you aware of an idea that focuses on the real time access to user id/name/email?
We've opened a new "Idea" In hopes of getting traction. Its hard to tell if this is a duplicate and if we should uptick someone else's.
@MPohlers , @autolycus , @AudieCruz have any of you found a workaround? We haven't and are still in need of some way to know the actual user (from a macro that can't be tampered with by the artisan... we're trying to implement some lower level security checks).. If you haven't found a solution and still need one please uptick the above idea or send us one that is further along.