JimHarrison
4 years agoQrew Champion
Using API_GetUserInfo and API_GetUserRole
We have a feature where we make requesting Apps available to Quickbase Users and we call it "App Access". The User selects the App they need from a drop down list of Apps to request access. When the User completes this task we get a notification telling us who the user is and what App or Apps they are requesting access to. The information in the request helps determine which Role the User should get. Also we can route access through App Owners if there is concerns for PII. The whole thing works pretty good until we start denying users, or users leave and then return, or their Role changes. We also have a rule that if you don't open Quickbase within a specified period of time, your account gets denied. So it's pretty complicated, lot's of variables.
Over time the initial App Access information becomes stale. When users look at the data in the table, their response is "It says I have access what happened?" which starts off a flurry of emails and phone calls and questions and ends with the solid determination from everyone we need a way to keep this information up to date without going in to the Admin Console and copying the user table exporting etl importing etc etc etc. this problem is totally a use case for Automation.
We started looking for a solution to keep the data fresh. Of course User state is not available to Apps and hence Users, so we need a way to do that. First we send a POST API_GetUserInfo for each userid. The response doesn't tell us much. It would be nice to know if the username is on the denied list or not and the date of last access. In the end it seems like the API_GetUserInfo doesn't have any value. So we send POST API_GetUserRole with the userid gotten from a user type field in the App. If the response has nothing in the <role> </role> section we "assume" the user account is denied, that's it. Clunky right?
What really bugs me is:
There is a Last Access Date in the Admin Console but it is not exposed in the API.
There is no data on if a userid is enabled or denied, which are features of the Admin Console.
Each time I work on this problem I keep asking myself "How hard would it be?"
So I added a UserVoice.
Vote for this UserVoice if this has value.
Quickbase Product Feedback - Quickbase Product Feedback
------------------------------
Jim Harrison
transparency = knowledge + understanding : The Scrum Dudes
------------------------------
Over time the initial App Access information becomes stale. When users look at the data in the table, their response is "It says I have access what happened?" which starts off a flurry of emails and phone calls and questions and ends with the solid determination from everyone we need a way to keep this information up to date without going in to the Admin Console and copying the user table exporting etl importing etc etc etc. this problem is totally a use case for Automation.
We started looking for a solution to keep the data fresh. Of course User state is not available to Apps and hence Users, so we need a way to do that. First we send a POST API_GetUserInfo for each userid. The response doesn't tell us much. It would be nice to know if the username is on the denied list or not and the date of last access. In the end it seems like the API_GetUserInfo doesn't have any value. So we send POST API_GetUserRole with the userid gotten from a user type field in the App. If the response has nothing in the <role> </role> section we "assume" the user account is denied, that's it. Clunky right?
What really bugs me is:
There is a Last Access Date in the Admin Console but it is not exposed in the API.
There is no data on if a userid is enabled or denied, which are features of the Admin Console.
Each time I work on this problem I keep asking myself "How hard would it be?"
So I added a UserVoice.
Vote for this UserVoice if this has value.
Quickbase Product Feedback - Quickbase Product Feedback
Uservoice | remove preview | ||||||
|
------------------------------
Jim Harrison
transparency = knowledge + understanding : The Scrum Dudes
------------------------------