Add new endpoint to admins API to retrieve accounts where admin has specifed role/s

(1)

Problem:

Given a users user_id or sis_user_id I want to retrieve a list of all the sub-accounts they have admin access to, with a given set of roles. Passing at least one role would be required (at least in this implementation).

Example request/response:

GET /api/v1/admins/<user_id>/accounts?role_ids[]=347&role_ids[]=347
GET /api/v1/admins/sis_user_id:<sis_user_id>/accounts?role_ids[]=347&role_ids[]=347

Returns a list of Accounts

Why does this matter?


The workaround to getting this info out of the Canvas system is a costly operation. Here is how I would have to do it and as far as I know it's the only way:

  1. Load up all subaccounts under the root account
  2. For each subaccount load up all the admins
  3. Then iterating through each admin, find the matches for my sis_user_id and role_ids

This sequence takes a very long time for an instance with as much data as ours.

Sales pitch
 
This would be a very valuable API call to add to Canvas as I imagine there are a lot of auditing processes that want to make these types of queries. Oh, and let's save some CPU cycles (that's always a good thing).
7 Comments
Stef_retired
Instructure Alumni
Instructure Alumni

 @kl3020 ‌, we notice that your idea https://community.canvaslms.com/ideas/14595-add-recursive-parameter-to-roles-api is currently open for voting. Would you please add clarifying details to the idea description that will help prospective voters distinguish between the two?

James
Community Champion

What about using GET /api/v1/accounts to get a list of all the accounts that the user has admin access to? It doesn't give the list of roles, but it gives a list of accounts. You didn't list how you were determining the role in your current work-around, so I'm not quite sure how that factors in, but it seems like getting a list of accounts the person is an admin for would be quicker than loading all of the sub-account admins and scanning them.

There's also GET /api/v1/course_accounts that gives courses that people have admin rights in.

This is under the Accounts API, not the admins API.

kl3020
Community Member

Sure, glad to clarify. This feature proposal is about being able to load a full list of all roles from the root account. It proposes doing that by adding a recursive parameter to this endpoint.

Whereas this feature proposal is about getting a list of sub-accounts that a particular admin user has access to.

kl3020
Community Member

There is an assumption baked into this which is that I'm making requests to the API as super admin. Perhaps GET /api/v1/accounts would show the list of accounts a user has access to if I were that user. I also made a mistake in my OP at Step #3 (corrected now). The other thing is that this is not just about which accounts the person has access to but the accounts they have access to with a particular role.

Stef_retired
Instructure Alumni
Instructure Alumni

Thanks,  @kl3020 , for making that significant distinction. We've opened the idea for voting.

prj_site_commun
Community Participant

If you're using the API with a root admin, or any user that has permission to act as other users, then you can use API masquerading:

https://canvas.beta.instructure.com/doc/api/file.masquerading.html 

This will let you see the account list for another user, using the /api/v1/accounts endpoint.  It doesn't show which role the user has in each account, though--that would still require another API call for each subaccount.  So maybe /api/v1/users/<id>/admins could show those, just like how both users and courses have /enrollments endpoints.

ProductPanda
Instructure
Instructure
Status changed to: Archived
Comments from Instructure

As part of the new Ideas & Themes process, all ideas in Idea Conversations were reviewed by the Product Team. Any Idea that was associated with an identified theme was moved to the new Idea & Themes space. Any Idea that was not part of the move is being marked as Archived. This will preserve the history of the conversations while also letting Community members know that Instructure will not explore the request at this time.