Hi Paul,
Unfortunately, the answer is that role-for-enrollment information is typically treated as privileged information by clients, and the LMS configurations are set up this way -- typically "end user" type roles (like students, instructors, tutors, and so forth) are not given the permission to make the calls they need to inspect the role bound to an enrollment.
The call you want to use for your use case is the "
get all enrollments for a user" call, but on most client systems those general enrollment calls are reserved for administrative-role users. You really only have two options here:
* The LMS admins can extend the permissions for these calls to your target user role types -- I can well understand that they may not want to do this
* You can design a hosted service that uses a service user account with specific, elevated permissions, and controls the kinds of data sent back to your end-user-owned applications to help get the information you'd like to present and then massage it carefully; this is a potential workaround that could meet your use case, but is obviously potentially open to abuse, and again, your LMS admins may well object to this technique
I'd recommend that you request some enhancement around the enrollments APIs through your partner or account manager, or post it on D2L's Products Idea Exchange. Other clients have also asked for this enhancement, but this was an intentional design decision built into the API (so it's not a defect, it's "working as designed").
There are several potential solutions that could help meet your use-case and still preserve some of the privacy around assigned LMS roles that our clients have required, but none of them are on the immediate road-map to implement: requesting the enhancement through official business channels between your LMS admins and D2L (i.e. through an approved support contact, or an account or partner manager) can help increase the priority towards getting this done.