Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The D2LWS service's authentication mechanism puts the API caller in the position of being a privileged caller. The Valence Learning Framework APIs use a different auth model: the user ID/Key tokens that identify a user get employed by the back-end to restrict the functionality of calls. That is: the authenticated user should have access to the same functionality and data as the user would get through the web UI, and no more.</p> <p>In this particular case, the calls succeed: they send back all the elements in the result set that your calling user has privileges to see -- none of them.</p> <p>This is almost certainly an issue with the role privileges afforded to your calling user, and debugging the permissions around calls can be challenging. The Valence project's documentation provides a walkthrough topic on <a href="http://docs.valence.desire2learn.com/samples/permissionCheck.html" rel="nofollow">investigating role permissions</a> that might shed let on a possible approach here, especially with respect to the calls to gain access to user records (or properties that appear in user records).</p> <p>As the walkthrough discusses, there are various aspects to making the general call to <code>/d2l/api/lp/{version}/users/</code> that bring permissions into play:</p> <ul> <li><p>If you're trying to filter with a query parameter, does the calling user context have permissions to use the data on which you want to filter</p></li> <li><p>Does the calling user context have permission to see properties affected by User Information Privacy settings</p></li> <li><p>Does the calling user have permission to search for all the user roles they need to, in order find users in the result set</p></li> </ul> <p>The users call operates on the root organization unit, so the permissions the calling user requires must be set on the organization org unit type.</p> <p>By contrast, the Grades-related API calls operate not on the root organization unit, but typically on course offerings, sections, or groups. The permissions surrounding the calls there will get checked in the associated org unit types, so the calling user will need the right permissions against those types. Additionally, many of the calls related to course offerings (also sections and groups) require that the calling user be enrolled in the org unit in question (and in some cases, <em>explicitly</em> enrolled, not merely enrolled by cascading enrollment).</p> <p>If you're sure that your calling user context does give you access to these things (and allows you access to this data through the web UI), and you still see a mismatch like this when you're calling through the API, then you may have uncovered a defect of some kind and you should please ask your organization's support contact, or your account manager, to open a support ticket to report that through Desire2Learn's <a href="https://helpdesk.desire2learn.com/" rel="nofollow">support desk</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload