No work before term start

[ascholerChemeketa]

Testing copilot PR message. Let me know if you like them or not.

Note that client side filtering in checkLocalStorage functions will depend on PreTeXtBook/pretext#2804. Without that in place, nothing bad should happen, but student work done before term start will get loaded from local storage.

---

This pull request introduces a new mechanism for handling the validity of locally stored answers and user progress in interactive components by incorporating the course's term_start_date. It ensures that any saved answers from before the course start date are ignored or removed, preventing students from reusing answers from previous terms.

Additionally, it updates the micro-parsons dependency and improves error handling when parsing stored data.

Key changes include:

Local Storage Validation and Data Reset

• All interactive components (e.g., ClickableArea, DragNDrop, FITB, LP, MatchingProblem, MultipleChoice, Parsons, ShortAnswer, Timed, WebWork, HParsons) now check if locally stored answers are from before the current course's term_start_date and remove them if so, ensuring only relevant answers are restored. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

• Timestamps are now stored with answer data in local storage for relevant components, allowing this validation to occur. [1] [2] [3]

Error Handling Improvements

• Improved error messages and handling when parsing corrupted or invalid local storage data across interactive components, making debugging and user experience better. [1] [2] [3] [4] [5] [6] [7] [8]

Propagation of term_start_date to Frontend

• The term_start_date is now included in the context sent from the backend (books.py) and injected into the eBookConfig JavaScript object in the frontend templates, making it available to all interactive components. [1] [2] [3]

Dependency Update

• Updated the micro-parsons interactive dependency from version 0.1.7 to 0.2.0 in both package.json and package-lock.json, ensuring the latest features and bug fixes are integrated. [1] [2] [3] [4]

Grading Logic Consistency

• Updated grading queries in rs_grading.py to only consider answers and useinfo events submitted after the course's term_start_date, aligning backend grading with the new frontend logic. [1] [2]

[ascholerChemeketa]

Force pushed with reformat to 2 files

[bnmnetp]

I like the copilot summary.

I'm not sure what happened with micro-parsons 0.2.0 I know I have built releases of runestone that used 0.2. So that is a good catch.

I'm thinking that it might be worthwhile to do a small change to either the course home page for instructors or the instructor dashboard where we could flag in big bold red letters if someone's term_start_date is more than a year old.

[ascholerChemeketa]

What's the thinking on flagging old term_start_dates? It doesn't seem like it would impact this much... only danger here is if someone has a recent term start date but expects to pick up older work.

How would you even end up with an old term_start_date other than using the same course for term after term?

[bnmnetp]

Yes, despite my protestations there are people that use the same course year after year.

[bnmnetp]

Not saying it has to be part of this PR, just wanted to get it out there when it popped into my head as a potential issue.

[ascholerChemeketa]

Added course start date to course home page for all users. Instructors get warning for stale courses.