I'd like to access a JS object of all app users in a similar fashion to current_user. I understand this can be achieved in a roundabout way on-prem, but native support within Retool-hosted or self-hosted apps would be amazing!
My app is currently Retool-hosted and my use case requires a mechanism where end users can be allocated to various work items in-app using a selection dropdown (which would be populated by app_users.fullName, for example). Of course the alternative is to keep a separate table of app users in one's own DB to map to selection dropdowns, but that's a somewhat inelegant solution.
TL;DR please could we have a current_user like object for all app users!
Hello Ryan! Just want to clarify. So in the editor window, you'd like to be able to reference any user that is currently enabled for your cloud-hosted instance of Retool in the same way that we can reference currentUser right now? Is that right?
Hey @Gabriel_Ferrier! No updates at the moment, there aren't specific plans for this feature right now but if that changes and the feature is included can let you know here! Do you have a specific use case this would enable?
I can't speak for @Ibrahim_Mohammed but my use case would involve the ability to assign app users to specific work items contained with my apps. I want to be able to map a select component to all my app users, and be able to select a user from that component. Then I can save that user's ID (or some other unique identifier) within the work item's row in a "assigned_user" column in my Retool database. Then when my app loads a SELECT query on page load, that select component has a default value of that previously selected user. I hope that's clear!
This would cause security nightmares, and is not something Retool should ever do. Imagine if every user in your favorite app could access every other user of that app, all via javascript. Yikes!
If user data was only available server-side, meaning that there's zero chance a user on the frontend could get other user's information unless that data was explicitly passed to them on purpose by a retool developer, then that could be ok. But still opens dangerous pathways for security problems.
I'm not sure I follow. My organisation's apps will be shared with 10-20 colleagues. I simply want to be able to access my Retool organisation's user list so work items can be allocated to team members in-app. You know, like how I can tag a colleague in a Google doc, or assign a team member to a Jira issue. This can already be accomplished in on-prem Retool instances.
A trivial JS query would only retrieve such a list of users as and when required. JS is already sandboxed and the vast majority of apps aren't public. Comparing an organisation's internal web app to manage organisation workflows to a "favourite app" like something downloaded from the iOS App Store is a total strawman.
It depends on how you're using Retool; some companies use current_user.id or current_user.sid in security-related things, like generating API credentials. At those companies, imagine there are 20 users and one of them is a superadmin with very high-level privileges. Would you want the 19 other users to have access to any security-related data (id, sid, etc) of the superadmin user? No definitely not.
A list of all other users' first and last names? Sure, that's likely safe for most companies. But it might not be for all! Don't assume all companies using retool are small, have one level of access, are all in one location, all work with the same clients, etc.
For your company, allowing any user to get a list of other users might not pose any risk whatsoever; for others, it might pose a very, very bad security risk and in fact might even break GDP and other laws.
Monitoring user activity in Retool is SUPER hard for a cloud user.
I just want a dashboard that shows which users logged in when and what they did - to achieve this, I have to use the DataDog API to extract about usage on our API (connected to Retool).
Hello! Just want to give a quick update here as well. For Enterprise users Retool recently made the SCIM user API available on Cloud for user management. At the moment, bringing the same API to self-serve users isn't part of the road map but as the API expands certain features may be made more widely available. I'll try and post here again if that is the case!
