IOL and UserID

Is there a reason you're trying to use IOL versus standard user fields and form rules? Is there something specific about the User ID you need? You could user a formula-user and User() formula in combination with form rules to store the value to accomplish what it sounds like you're trying to do. 

Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base

I have an app in which I've added @mycompany.com as a user - granting all registered users of my firm basic access to the app, which includes access to a profile table. Users can create a profile for themselves and in so doing identify the role the user should have in the app. 

Once the form is populated sufficiently, a formula URL field button will appear in the form. The button will use the API_AddUsertoRole call. 

I need to reference the userID in the API_AddUserToRole call. I don't know how else to get that userID short of IOL, etc.

Thoughts?

To expand on my prior comment - the goal is that I don't want myself or my team to be a bottleneck of user management. There may be a lot of users coming/going into the app over time - I want them to be able to dictate their own user experience based on their profile table inputs.

So if I'm understanding: 
1) User creates profile, selects role
2) User clicks button to add themselves to that particular role

From your original description - I'm going to go out on a limb and make an educated guess that you're going to have an issue that unless you granted everyone 'sharing' access to this app or others - they won't be able to add themselves to a new role regardless. Basically their permissions likely won't be high enough to actually apply themselves to a role - because they need 'Basic + Sharing' which opens up the 'Users' tab

That said - another approach might be to re-think how to chain the actions together. Basically - instead of the button adding them in the role - you can use the button to make your API_GetUserinfo call - and then store the user ID in the record as a field - basically the way you want to with IOL - but this way it's user initiated. When that field is written - you could have a webhook fire - and the webhook could do the provisioning of the actual user as a background action that isn't reliant on the particular user trying to provision themselves. 

Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base

Thanks, very much for that. I'm quite happy to do it the way you suggested, but I keep struggling at the point of extracting the userid from the API_GetUserInfo call. I don't know how to parse the userID values from the other values returned in the call. Any tips? Thanks!!

If you're setting it up to run from a button - you can throw some jQuery in a formula-url and make your api call - parse the response - and throw that in your field. Since your question is specific to how to get the user ID - here is an example of how you might do it in QB (using a formula-url) --

var text url = "https://yourrealm.quickbase.com/db/main?a=API_GetUserInfo&email=youremail";
"javascript: { 
$.get('" & $url & "', function(response, success) {
var userId = response.getElementsByTagName('user')[0].getAttribute('id');
console.log(userId);
})}"

The $.get makes the API call - then as I typed it above should parse it out and log it to your console. From there - you can make another API_EditRecord call with another $.get request and store the true value of the userid in a field somewhere or take whatever action you need from there.


Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base

Hi Patrick. Since IOL is not an officially supported technique, it would be safest to try and solve things via native methodologies to ensure your application is supportable and stable long term. What you could do is create a dbpage and have a formula-URL button call that page and pass in the necessary variables for your code to execute the queries. Keeping this contained in the javascript pages without pushing JavaScript into the buttons is cleanest.

I would also encourage you to specifically post on UserVoice about having us expose the userID in a formula since that would completely negate the need for any JavaScript.

Thanks, Harrison. I'm happy to explore any solution. Are you able to point me to any materials or other posts on this forum which elaborate on the approach you've described? Thanks!

The quickest way to get the userid but its not the full one, the .letters after it look like they can change but not sure if they only change per app? but in console you can type _fid_#.value where # is your user id field in the console and get it. so if you have some javascript running on page to run the add user to role you can grab it there but that value is the user id with the negative format so its not ideal.

If I'm not mistaken (I could certainly be), couldn't the code Chayce so graciously provided be embedded in a formula url button - such that at the press of a button, the code retrieves the userID and places it in a field value. That field value in turn could be referenced in a webhook, which executes the API_AddUserToRoll call. Is that right? 

If so, I just can't figure out the code to append to Chayce's - the code that would take the retrieved userID and enter it into a field value. 

I'm really sorry for the training wheels with this - I'm somewhat new to this kind of QB development, but I'm quite eager to learn.

Thoughts?