use a custom course key type according to architecture review

[cewing]

During review of the open pull request by the EdX Architecture Council, it was suggested that rather than treating ccx overrides as one-off special versions of courseware items, it would be better to be able to reference them using a customized course id type. Apparently the infrastructure exists to create custom course ids, such that we could identify the overrides for a ccx by an id that included not only the course-provider-run identifiers used by a course, but also include a ccx identifier as a path segment. This would improve the ability of ccx data to be incorporated in analytics and course data dumps and so on.

Investigate the feasibility, mechanisms, and impact of this change and then implement it if the MIT team chooses to follow this path.

[cewing]

@pdpinch can I get you folks to weigh in on this? It was my principle takeaway from the architecture meeting and I'd like to know the MIT teams take on this.

[pdpinch]

We'd like to leave this as is for now, as it's not a blocker for MVP.

It might be useful to know the scope of the work required, but we won't be prioritizing it over the other high priority issues here.

[pdpinch]

I believe the following notes from @bdero capture the discussion well:

The solution that Cale Pennington and Dave Ormsbee proposed was that we separate the identity of CCX instances from their respective MOOCs altogether by identifying CCXs using a CCX-specific opaque key that extends CourseKey. This would make the separation of MOOC and CCX enrollments completely transparent to the platform, unifying the enrollment process. The courses would have entirely separate user pools from MOOCs, but still reference the same content, since the course user persistence is all determined by course key.

The way this would work is by having each CCX identified by its own unique "CCXCourseKey" (for lack of a better name), that consists of the parent CourseKey (e.g. course-v1:MITx+802x+Fall_2015) with an extra component denoting the CCX (e.g. course-v1:MITx+802x+Fall_2015+5).

The good thing about this is, the implementation doesn't seem far away from what we have right now. The field overrides and CCX role delegation would remain exactly as they are now. With the addition of the new CourseKey type, the separate enrollment process could be entirely removed, and the (problematic) MOOC/CCX switching menu persisted by session would also be discarded, as the LMS will just see them and treat them as different course instances.

[pdpinch]

I've gotten some follow-up details from the edX Engineering team on implementing this. I'm going to paste it all here, but I think each of these bullets calls for a separate issue and (probably) a separate PR:

#77 No longer use session-based global state as the way to identify when someone is in a CCX course.
#78 Use the standard enrollment table
#79 Move CCX-related field overrides to happen at the modulestore layer, so that content-related services like search and course structures can query with the new CCX course keys.
#80 Changes to a CCX course should emit a course_published event, just like regular courses. (edX is willing to help with this one as we didn't discuss this specifically. It is a low effort ask and has lots of downstream value)

[pdpinch]

Ferdi & I spoke with Dave Ormsbee today about PRs and ordering. He suggests the following:

• 1st PR: Move CCX-related field overrides to happen at the modulestore layer...  #79
• 2nd PR: Don't use session-based global state to identify when someone is in a CCX course #77 & Use the standard enrollment table instead of a custom CCX table #78
• 3rd PR: Changes to a CCX course should emit a course_published event, #80

[pdpinch]

https://github.com/edx/edx-platform/pull/8395 currently in review

[cewing]

edx#8395 has been merged and this is now in place.