Best practice for removing enrollment validity via API?

Hi everyone,

I had a bit of a fire to put out today! I had over 600 users who were suddenly locked out of several courses because their enrolment validity periods had all expired at the same time.

I’m still trying to figure out how the dates were originally applied since those courses are always available and don’t have any validity periods on them. At first I though maybe an admin or power user did a batch enrolment and set an expiration date, but I checked the audit trail it looks like each of those users had self-enrolled. What’s more is that the expiration dates were exactly the same across users, courses, and enrolment dates; like down to the second exact.

In theory it should’ve been a straight forward fix: just remove the validity period. But on 600+ users, doing it by hand wasn’t feasible. I ended up writing a script to automate it, but I ran into some gotchas:

1. When calling GET /learn/v1/enrollments/{courseID}/{userID}, it doesn’t return the validity period info. So I couldn’t even easily get which users were affected, and I couldn’t find another API in the explorer that returned what I needed.
    
2. When calling PUT /learn/v1/enrollments/{courseID}/{userID} to update the validity period, it wouldn’t accept null or empty strings for date_begin_validity or date_expire_validity. It requires actual date values.

What I ended up doing was running a Users – Course Enrollment Time report to get a map of expired user enrollments/courses, then dropped the .csv into a custom shell script that:

• Parsed the CSV

• Looked up user IDs by email

• Looked up course IDs by name

• Updated the validity period on affected users using full date strings

By sheer luck I figured out that if you set the date_begin_validity to 100 years in the past and date_expire_validity to 100 years in the future it actually just removes those dates entirely, effectively removing the enrolment validity period.

E.g.

{  
    "date_begin_validity": "1926-02-24",
    "date_expire_validity": "2126-02-24"
}

I ran the script and it seems to have solved the immediate issue, but it was definitely a workaround rather than a proper solution.
 

Has anyone else had to do something like this before? If so, do you know of any supported ways to handle bulk enrolment corrections like this?
 

I’d appreciate any insights!

Thanks!