cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cesbrandt
Community Champion

Ghost Enrollments

Jump to solution

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‍‍‍‍
1 Solution

Accepted Solutions

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:

{
      'state': [
            'active',
            'invited',
            'creation_pending',
            'rejected',
            'completed',
            'inactive'
      ]
}‍‍‍‍‍‍‍‍‍‍

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.

View solution in original post

4 Replies
stuart_ryan
Community Coach
Community Coach

That is a great rundown cesbrandt! Thank you for putting it together!

I will convert this over to a discussion as it doesn't have an answer you are seeking, more you had a question and managed to answer it yourself (which is awesome).


Kudos for coming back to share it with everyone, it is so great that people share their experiences as it helps everyone down the track!

Cheers,
Stuart

Well, it is a question in regards to I want to know what has caused it, but I suspect I'll need to take it to Instructure support to get the answer. Since I found a workaround, I figured I shouldn't be super concerned and see if anyone else has better information on it before bothering support. ^^'

Fair point and my bad there, I have converted it back for you!

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:

{
      'state': [
            'active',
            'invited',
            'creation_pending',
            'rejected',
            'completed',
            'inactive'
      ]
}‍‍‍‍‍‍‍‍‍‍

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.

View solution in original post