Have a mechanism for handling LMS course merges, particularly when combined with course and user loads
This issue seems to affect every site that uses an LMS, but it becomes particularly problematic when users are also allowed direct access to the Ares web and when course and user loads are being used. This example was written out for Kent State to explain the problem they're facing when courses are merged in Canvas.
John is an instructor and is teaching Course 101. This course has two sections, A and B. Jack and Jill are students. Jack is enrolled in section A. Jill is enrolled in section B. This information is provided to Canvas through a data feed. That same data is used to generate a feed that is sent to the Ares server. Canvas and Ares both recognize that A and B are unique "course entities". When Jack logs into Canvas and navigates to course 101, he sees data that has been uniquely associated with section A. When Jill does the the same, she sees data that's been set up for section B and does not see what Jack sees, because section A and section B are distinct, even if they maintain the connection of having an identical "parent" course. This distinction between A and B is passed through to Ares, allowing instructors to have completely separate reserve lists for section A and section B.
The data feed that has been sent to Ares also illustrates this separation between section A and section B. Section A has been given its own course in Ares, called CourseA, and section B has its own course, CourseB. There is no data link within Ares that suggests a relationship between CourseA and CourseB.
The file sent to the Ares web server that contains data about courses, Courses.txt, has two separate entries for these sections.
CourseUsers.txt has separate entries for the instructor for both courses. If we verbalize the data is would be something like:
John has instructor-level permissions for CourseA. John has instructor-level permissions for CourseB. Jack has student-level permissions for CourseA. Jill has student-level permissions for CourseB.
Providing this information directly to Ares allows students and instructors to access Ares outside of Canvas (amongst other things). This means that Jack can directly log into your Ares web pages and he will have access to CourseA. Jill can log in and see CourseB. John the instructor logs in and sees CourseA and CourseB.
Then John decides section A and section B are similar enough in Canvas that he shouldn't need maintain them separately. Instead, he wants all of the students to just see one big happy Course 101. John enters into section A and selects a merge. Section B is archived. Jack will continue to see section A when he logs in and selects Course 101. Jill will now ALSO see section A when she clicks on Course 101 in Canvas.
While all of this is happening, Ares continues to receive the original data feed that says that Jack is in CourseA, Jill is in CourseB, and John is the instructor for two separate courses. Here's what happens to our three friends.
Instructor John clicks on the only Ares link now available to him from Canvas, which was within section A (because section B is no more) and is taken to CourseA in Ares. Potential issues for John: The reserve items that Jack had associated with CourseA in Ares might not be the same as what was in CourseB. He asks, "Where are my items?" If John navigates to the main menu in Ares (or logs into the Ares web pages directly), he will see that CourseB (section B in Canvas) still exists. He asks, "Why are there still two sections when I merged these?" All reserve usage stats for CourseB continue to stay with CourseB. The stats in CourseA misrepresent usage. Jack clicks on the Ares link in Canvas and continues to see the Ares course he has always seen - CourseA. If Jack logs in directly to the Ares web, he still sees everything's the same. Jack is happy.
Scenario 1 for Jill - which is not great, but not that big of a deal:
Jill clicks on the Ares link in Canvas and now is added as a new student in CourseA by the LTI config. She no longer sees any of her personal tags for items in the course. All items appear as "New" and unread. She asks "Where are my personal tags? Why does it show I didn't see these? If she clicks on a Hot List entry for an item that's a child of CourseB, she will be taken directly into the "deprecated" CourseB, which will likely add to the confusion. If Jill navigates to the main menu in Ares (or logs into the Ares web pages directly), she will see two very similar courses. She asks, "Why are there two different versions of the same course?"
Scenario 2 for Jill - this is the ultimate problem with all of this:
Jill doesn't like to use Canvas and prefers to navigate to Ares using the web pages. She logs in and continues to see CourseB. Jill believes she is happy. HOWEVER - Instructor John has been making changes and adding new items and mandatory readings to CourseA, believing the merge has handled all of this and all of the students are seeing the same thing. She asks, "Why can't I find these assignments and readings?"
Library staff try to help clean up this problem.
Staff manually enroll students from CourseB in CourseA and manually add any missing items that were in CourseB and not in CourseA. Jill now sees both courses when she logs in directly to the Ares web. Jill asks "Why do I see two courses?" Staff manually delete CourseB. This unfortunately wipes usage data, but Jill logs in and only sees the one course - but it's not the course she expects to see and her personal tags and missing. Her hotlist items that she had saved for CourseB are gone. The overnight load is set to autocreate courses. It automatically recreates CourseB and enrolls Jill. Jill logs in to the Ares web pages and now sees two courses and the one that's familiar to her contains zero items. Jill is confused. She is told that life will be easier if she uses Canvas. She does not want to use Canvas and has been told she does not have to use it. She is not pleased.