Proposal for course revisioning strategy

Drupal Commerce has a similar need. When you buy a product, it should be frozen in time, and not subject to future edits. I’m not sure if they solve this by refusing. Worth a look.

In general this proposal makes sense to me. There are.a couple downsides. Namely teachers Can’t easily fix typos in a course and have that affect students in progress. Same for scoring. Also we could see revision bloat similar to what happens on sites that use paragraphs module.

@moshe weitzman thanks for the feedback, much appreciated.

The thinking is that for something like a typo, teachers/admins can submit an edit and not create a new revision, in which case the change will be pushed live to current students.

Revisions shouldn't proliferate too badly since it will be a conscious choice to make a new one, and we can implement processes to safely delete old unused revisions.

I'll check out the Commerce approach, thanks for that tip!

The thinking is that for something like a typo, teachers/admins can submit an edit and not create a new revision, in which case the change will be pushed live to current students.

I think this is a bit too subtle to expect course authors to understand the implications of or get right all the time even if they do - if you're just doing a quick fix, the default behaviour would be to fix the typo and hit save. Once revisions default to on, that will result in a new revision, you have to take extra steps to avoid it.

However the issue summary doesn't explicitly mention that e.g. lessons would reference specific versions of activities (which is the only way older versions could be loaded), and I'm not sure it's necessary.

If e.g. a lesson status references a specific revision of a lesson, then the list of activities will differ by version, and it's that which would allow activities to be added or removed from lessons without affecting students in progress.

Similar if a course status references a specific revision of a course, the list of lessons will differ by version.

https://www.drupal.org/project/entity_reference_revisions →

There's another issue though that something like adding a lesson at the end of a course where no-one has reached it yet, you might want everyone to take that lesson

We could make a global setting so the site owner can choose if students take the course / lesson versions from the moment of starting or current, that'd also solve any possible BC issues.

I think we could do phase 1 without the exact details of what phase 2/3 look like - we definitely want answers, lesson status, and course status to reference revisions. Means switching the entity reference field over to https://www.drupal.org/project/entity_reference_revisions →

Can we start off by adding *_vid fields to CourseStatus, LessonStatus, and Answer entities and run an initial update hook, then transition to Entity Reference Revisions when we're ready to migrate the Course.lessons and Lesson.activities fields? Seems like that could make the updates less monolithic.

Drupal Commerce has a similar need...I’m not sure if they solve this by revisions.

Turns out Commerce copies the current product data into an order item. Same need but not really a transferable solution.

I think [the revision checkbox] is a bit too subtle to expect course authors to understand the implications of or get right all the time even if they do

The revision checkbox could have explicit instructions marked "IMPORTANT". Or we could alter the form to have two submit buttons, one for a minor live update, the other for a new version. Either way I agree it's hard to make it foolproof. Needs good documentation.

something like adding a lesson at the end of a course where no-one has reached it yet, you might want everyone to take that lesson

The "Freshest Unaccessed Content" feature would address this. It adds some complexity to the lock-in timing, but seems worthwhile for long courses.

We could make a global setting so the site owner can choose if students take the course / lesson versions from the moment of starting or current

If set to "current" then we'd lose consistency with evaluation & revisits, unless we associate revision lists with uid. The revision schema updates add a BC layer, so not sure if this would add more complication than it's worth.

Just a “vid” field will not be enough, for example lesson status references multiple activities, that’d be too messy. I also wouldn’t like to add an additional dependency but we can use some of the Entity Reference Revisions code as a reference - a new field type plugin should be enough in our case.
Update may be a bit tricky.

Actually.. maybe it’s not going to be so bad as we’ll just need to add a new column to an existing schema, reference field names will not change after all.

This will be bigger as we'll have to reference lesson revisions from course status as we currently reference activities from lesson status. The good thing is consistency though. That should be the first step of the work here. The first step alone will only introduce needless data storage though.

This will also affect caching a lot - nav block will depend on course status lessons and not course lessons. Course nav structure cache will have to be dropped.

For #12 I think we might want to make this configurable so that you only get a per-course-status navigation structure/activity display when the site owner explicitly wants that - I can equally see people being confused why they can't fix a typo in an activity name for existing users.

Also we already have logic to cache the navigation block differently depending on whether modules are finished, in progress, or not taken yet so it should be possible to preserve some or most of that.