Bug in 'Get Memberships' for Instructor in unavailable courses?

I will start off first by stating that I am currently running the REST call against Learn Q2 2016 (Release 3000.1.3). If this has been addressed since that release, I couldn't find anything to say so.

The call I am making is for the course memberships API, the 'Get Membership' endpoint:

- /learn/api/public/v1/courses/{courseId}/users/{userId}

Responses to that call contain a field, 'availability' of type 'Availability_2' (per the documentation). The Availability_2 type itself has a field, 'available', for which its value may be set to 'Yes', 'No', or 'Disabled', depending on the user's availability in the course.

If a course is marked as unavailable to students, but a user with an 'Instructor' role (as established by the 'courseRoleId' in the API call) is able to access the course, I would expect the 'available' field to be set to 'Yes' for the instructor. The enrollment is available, yet the API result does not reflect this.

The argument could be made that since the course itself is unavailable, then automatically the enrollment availability should not be available either. I would argue that the REST API call should mimic the behavior of the system. If the Instructor is able to access the unavailable course through regular system navigation, the REST API call should specify the enrollment is available for that course for that user.

Thanks for checking on this. On further inspection, I wrote the wrong endpoint. It's for the 'Get Memberships' instead of 'Get Membership', so the endpoint:

- /learn/api/public/v1/users/{userId}/courses

Under the same conditions where the user is an instructor of a course (who can access the course through regular system navigation), but the course is unavailable to students. For me, the list of memberships returned does not include those for which courses are unavailable. So, yes, for the enrollments that do come back, the availability is set to 'Yes' as expected.

The Learn user associated with the REST application has full system admin permissions. But if this issue isn't happening for you under the same conditions, then it must be something that I'm doing wrong...I will investigate further.

So I figured this out. The user I was checking against was enrolled in just the right combination of courses that only 20 or so were initially returned (no offset or limit specified). And, the remainder of courses not returned, either by freak coincidence or some default sort priority, just happened to be the ones which were disabled to students. Because of course they were.

But thanks, Peter Love, for checking on this for me. I'm glad it turned out to be my own ignorance, and not an actual bug.