We recently discovered an issue in a course that was using an ORA2 type of problem in Ironwood and for which we are now encountering problems in our Juniper production systems.
Even if we can download the ORA2 grade reports, the grades are no longer being calculated as part of the global notation of students. For example, we had an exercice who was worth 40% of the grade, but now people who had 100% or 90% now only have 60% or 50%. It affects anyone who had been registered (past or present) in that course.
TBD - Need to provide a description of changes in ORA-2 since April 2019 as it impacts the community.
As I don’t remember ever seeing that description of changes in ORA-2, I wonder if it has impacted our courses in our instance. Who would be able to give me that description of changes? It is kind of urgent right now…
Was there something to do with ORA-2 apart from the standard Django Migration when upgrading from Ironwood to Juniper? Has someone encountered a similar problem? And how did you fix it in order for students to get their correct grades back? Please take note this is happening in an ongoing course that was opened way back in Ironwood. We need to fix this.
Something I forgot to add. It has also impacted previous archived courses who are using the same ORA2 XBlock. It’s as if the grades had been recalculated for all these courses. All these courses were clones or new instances of the same original course with minimal differences.
We can still see the grades in the ORA-Report dowloaded from the instructor tab in the course, but we cannot view them even if we try to access a student through the “Manage Individual Learners” at the bottom of the exercice. All we get is “A response was not found for this learner.”. Strangely enough, the “View Assignment Statistics” look ok.
It turns out we had two different SECRET_KEY entries in lms.env.json and lms.auth.json. And depending which one I use, I don’t have the issue or I have it,
Mystery solved. Thanks @Felipe for suggesting it might be a SECRET_KEY issue this morning in the BTR WG meeting.
Now, I have to figure out how to fix it in case the SECRET_KEY is used in other cases than authentication and submissions for ORA2.
