Is it possible to identify the current (= logged in) user in an App? And if yes, how can this be done?
In Classic ONE DATA you can use the system variable “sys_user” to do so. But in the Apps documentation I did not found this system variable. The only available system variable seems to be “apps.appSessionId”.
Use Case:
I have a table where each user can add data to. In one column the current user is stored as the user who added the data. This is done by using the system variable “sys_user” in the corresponding Workflow.
But in the App, every user shall see only “his” data. So I have to filter the table by current user.
Note: As I need the full data for some calculations using AA is not an option.
no currently in Apps there is no such variable to access the logged in user.
I had a similar challenge and Analysis Authorization (AA) was my solution.
In the workflow you have to store the result in two tables and keep them in sync.
I used also two different storage types, one for postgres and one parquet.
Therefore I use the “big” table with parquet for the complete analysis without AA as it does the “heavy lifting” and the table with AA via Postgres as I know my filter criterias and can optimize with indizies on it as i only want to retrieve small filtered amount of data. This also takes into consideration a scaling of the app.
So overall storing in 2 tables redundant for two different purposes not only worked for me but also brought some flexibility and advantages.
Maybe this helps, so you can also go with 2 tables approach.
Nevertheless it is on my Product Manager for Apps agenda to somehow consider such a feature extension in the future, which might or might not be a sustainable solution as you always should consider the scaling of your App in production.
… another “client-only” solution to this (if the scaling is not relevant) is to create a small custom component that assigns the username (that is known to the client) to an user-defined APPS-variable. Then the variable can be used to filter the data.
We did something similar for the bearer token which is also sometimes (but not always) exposed. If making the user available is something useful such a cc could be written in ~30 minutes (with docu!)
If you really really need it now and without a custom component, I can think of a workaround via a dataset with apps.appSessionId mapped to sys_user via a workflow. The workflow must be triggered via an action to add one single row and then the dataset needs to be queried for the session id to retrieve the user info. Still, this seems a bit overkill and should only be a temporary solution. Also it might be vulnerable to concurrent updates (isolation groups are in order here). I’m also not entirely sure if there’s a way to execute an action “in the background” or if a user would have to manually trigger it.
As far as I know AA is not applied to the owner of the Data Table, right? If so, the App would have different behaviour for me while all the other user would see the correct behaviour.
So, to go with AA I would need a second user to create the Data Tables. But without Admin permissions I can not set up an according group or create another user.
Yes correct, that is what I had to do.
I used my user as develper user and a test user of the project endevour to see it from a end-user view to check the state.
For the user maybe just ask your domain admin or project lead of your endevoour if she/he is so kind to provide you everything.
