Introduction
This post basically serves a dual-purpose in that it's both a question about the topic as well as an explanation for anyone else that may encounter it. It was a weird one for me to find, but it ended up having a relatively easy workaround.
Question
Anyways, yeah, "ghost enrollments." Ever seen them? Know what causes them? Is there a better way to fix them? Is there a way to prevent them? No idea what I'm talking about? Okay, I'll explain.
Situation
So, there seem to be two methods of pulling instructor enrollments for a course via the API:
/api/v1/courses/:course_id/enrollments
/api/v1/courses/:course_id?include[]=teachers
Some months ago, I released a script that relies upon the second API call to identify the teachers of courses without having to make an additional call. Today, I found out that these lists do not always match up.
Making these calls on some of our "Master" shells, I got the following results (Note: I redacted all potentially identifiable information):
/api/v1/courses/4720/enrollments
[]
/api/v1/courses/4720?include[]=teachers
{
"id": 4720,
"name": "REDACTED",
"account_id": 23,
"uuid": "REDACTED",
"start_at": "2014-08-04T04:00:00Z",
"grading_standard_id": 0,
"is_public": false,
"course_code": "REDACTED",
"default_view": "syllabus",
"root_account_id": 1,
"enrollment_term_id": 1,
"end_at": "2015-08-05T03:59:00Z",
"public_syllabus": false,
"public_syllabus_to_auth": false,
"storage_quota_mb": 500,
"is_public_to_auth_users": false,
"hide_final_grades": false,
"apply_assignment_group_weights": true,
"teachers": [
{
"id": 182,
"display_name": "REDACTED",
"avatar_image_url": "REDACTED",
"html_url": "REDACTED"
}
],
"calendar": {
"ics": "REDACTED"
},
"time_zone": "America/New_York",
"sis_course_id": "REDACTED",
"sis_import_id": null,
"integration_id": null,
"enrollments": [],
"workflow_state": "unpublished",
"restrict_enrollments_to_course_dates": false
}
As you can see, the first call, which mirrors the People page of the course, has nothing listed. The second call, which is what my script uses, has a user listed.
For a standard user, this is VERY confusing (at least it better be, because I was stumped at first). If we can't access their entry on the People page, how can we remove their enrollment?
Workaround
Well, as it turns out there's a fairly simple solution. For administrators, they can access the users account details and Delete the enrollment. For non-administrators with the rights to manage enrollments for the course, they can manually access the users course profile by appending "/users/:user_id" to the end of the course URL.
So, in the above case, these are the options:
Administrators-only: https://REDACTED/users/182
Non-Administrators: https://REDACTED/courses/4720/users/182
Update 2018-02-13 09:30 GMT-5
Well, now I feel blind. Thanks, Instructure! Seriously, though, thank you! Instructure T2 support responded to my ticket yesterday shortly after I had left for the day with exactly the information I needed to realize what was happening. A short chat with some of the users identified as having these "ghost enrollments" and I was able to confirm that it was so close to my ear that I'd be deaf if it could've been translated into sound.
So, turns out the issue was with how the enrollments coming up as "ghost enrollments" had been removed from the shell (prior to the execution of the script). Those identified as ghosts had previously been removed via rejection or deactivation. Since the default list generated when calling the enrollments API only includes "active" and "invited", these were ignored when the publication script ran.
The solution we're implementing is to update the publication script to include the following data object:
This data object results in a complete list on non-deleted enrollments (you can't delete what's already deleted). The rest of the script operates without change (for each result delete).
Original 2018-02-12 11:11 GMT-5
Well, we ran our update of master shells last week, so I checked for these this morning, and there's a whole new set. So, I've sent it to Instructure, since I can now confirm it wasn't a 1-time glitch.
I'll post their responses as I am able.