users API missing items

Justin.McRae12 · November 2022

I'm looking specifically at the GET and POST on /d2l/api/lp/(version)/users/ Is there a reason that it doesn't return the Role? When you post I have to include the RoleID. But when I retrieve all users it doesn't include the RoleId making me have to hit each user individually to retrieve their roles. It would be nice if the preferred names were also obtainable from /users/. When you are dealing with legal vs preferred names. Again, to retrieve every users/role and preferred names you have to hit 201 API's for 100 users. Instead of just 1 API.

Paul.Janzen98 · November 2022

Thanks for reaching out Justin.

1) Users. I don't know why we don't include the Organization Role in the Get Users call. At this time we just don't. I can add it to my product backlog, but I can't commit to us making this change.

You can get this information (Users + their Org Role) through the Users Data Set (https://documentation.brightspace.com/EN/insights/data_hub/admin/bds_users.htm?tocpath=Administrators%7CBrightspace%20Core%20Analytics%7CAbout%20Brightspace%20Data%20Sets%7C_____29#Brightspace_Data_Set:_Users). If you have access to our Data Sets then this could be a better approach for you.

2) Preferred Names - the answer here is... one call will do it! That is, only if the Preferred Name fields for the user have already been set. If a User has a Preferred Firstname and/or Lastname value set, then those values will be displayed when performing a Get Users call.

Justin.McRae12 · November 2022

@Paul Janzen Thanks for the information.

Just for context this is the background: I work on a centralized Identity management system which manages users in about 120 different applications right now, Brightspace will be 1 of them. We generally pull in the full set of top level user data daily to see if someone created/edited the users within the applications, enabling/disabling them based on their roles at the company.

For 1) Unfortunately, I can't make use of the datahub as the system I'm using can only use 1 method to communicate per application. Since it uses JSON threw API's to create/enable/disable users it has to use the same method to read data also. It unfortunately doesn't have the ability to download the zip, extract it then work with the csvs.

For 2) This is good information, I didn't know that it showed the preferred name then the legal name if the preferred name was null. I might be able to work with this. However, this could cause people to have incorrect Legal names in the system if I just relied on the /users/ and not the /names/. I can trigger that the first/last names and preferred names need to be synchronized between the identity management system and Brightspace and send both when I do an update. But, there wouldn't be a trigger on my side to synchronize the legal names if Brightspace had the wrong information. Being a school that rotates thousands of users a year legal name changes are not uncommon, unfortunately, and people will generally change their preferred name months or years before they change their legal names.

Essentially, I was looking for something along the lines of /users/enhanced/ if you had access to their legal vs preferred name privilege

User.UserDataEnhanced

{

"OrgId": <number:D2LID>,

"UserId": <number:D2LID>,

"LegalFirstName": <string>,

"MiddleName": <string>|null,

"LegalLastName": <string>,

"PreferredFirstName": <string>|null,

"PreferredLastName": <string>|null,

"RoleId": <number>,

"UserName": <string>,

"ExternalEmail": <string>|null,

"OrgDefinedId": <string>|null,

"UniqueIdentifier": <string>,

"Activation": { <composite:User.UserActivationData> },

"LastAccessedDate": <string:UTCDateTime>|null,

}

users API missing items

Answers

Categories