Retrieving user info within extension


Is there any possibilty to get current log in user within extension using outsystems API rather than passing username to extension in parameter?

Hi Adam,

Not that I'm aware of. But in general, you shouldn't need it. What is your specific use case?
I am trying to implement audit trail functionality. For some reason I need to do it outside outsystems so I am implementing this as a extension in .net code. Extension has one input parameter that is entity record. I easly read all needed information in .net code from the record but I also need information about user that changed the record. Possible solutions are:
1. Add column to each entity witch change user and REMEMBER to always fill this column in outsystems (I can't use current user id in default value of the attribute)
2. Add second parameter with current user and alway fill this parameter
3. More generic approach - leave filling user information to generic .net code in extension. Basically in this solution I am looking for method GetCurrentUser in Outsystems API that retrieves information about user who executed extension(action).
Hi Adam,

I had to do some serious digging into the Platform internals, but here's a way to retrieve the User Id and User Name:

int UserId = AppInfo.GetAppInfo().OsContext.Session.UserId;
string UserName = AppInfo.GetAppInfo().OsContext.Session.UserName;

you need to call the action from outsystems itself.
so create a wrapper-action, and fill in the username/id.
no need to use c# for that.


I don't know what you mean. The OP asked for a way to retrieve, inside an extension, the currently logged in user. I provided a way to do that. I'm not sure what you mean by "call the action from outsystems itself" and "create a wrapper-action"?
What Killian showed you, while it may be correct, is not a public and supported API and can break at any time.

I really recommend passing the Session.UserId and Session.Username as parameters to functions where you need this information. This way it will never break.

Despite you guys all the time claiming all this stuff can break any time, we found that ordinary, supported stuff is more likely to break with version upgrades than this "unsupported" APIs ;).

how does he want to call the extension? by calling an action from the extension, right?
so, when you create an action in a common espace that calls that specific extension-action, you have wrapped it. in there you can give the username/id on the easy way.

Then you  can "enforce"(*) other espaces to only call the action from that espace.

(*)One thing remains with this, that extension-actions (and entities for that matter) are universally public.
which sucks monkeyballs.but with "find usages" in servicecenter you can at least monitor the right way.


I see what you mean, and I even agree this would be an even better solution :).
Killian, public APIs are under constant use and are revised or have stuff corrected every once in a while, while internal APIs are indeed usually left alone. This doesn't mean that they're not subject to change. If we internally change something in such an API, since it's not public, we'll simply break it and not consider it a breaking change, so you'll have no notice.

Public APIs however are not subject to change inside a major revision.

If your application breaks because you're using a public API that's behaving badly, you'll get a fix. If your program breaks because you're using an unsupported API ... well... tough luck.
Thank you guys. That was very helpful. I think I will go with wrapping the extension but it is good to know there is possibility to get this information from API also.

I agree, but that's sometimes the risk one needs to take :).
Why take it when there's a simple and supported solution?

I wasn't talking about this specific usecase, I already said above I agree with S&W that a wrapper action is better. However, we also use unsupported functions to write to the General Log, and to retrieve the value of site properties. Especially the former would be difficult (if not impossible) without them. For the site-properties a wrapper could also be used (but it's still less convenient, imho).