SCORM - Aceptar nuevo dato score tras recibir un lesson_status completed ANTES de recibir un LMSFinish()

[juan-cortizas-ponte]

Este problema creo que se trató en el pasado, no se si exactamente en los mismo términos pero si creo que muy similar, está relacionado con recibir un valor de score tras haber recibido previamente un estado “completed” para lección. Lo habro como sugerencia porque entiendo que en principio no es un bug sino una forma de interpretar el RTE de SCORM

Esto viene del comportamiento que nos estamos encontrando con paquetes SCORM 1.2 creados con Rise 360 (Articulate), en principio, según se avanza se va registrando correctamente el progreso, pero llega un momento en que el paquete SCORM realiza la siguiente secuencia:

LMSSetValue('cmi.core.score.raw','94')
LMSSetValue('cmi.core.score.max','100')
LMSSetValue('cmi.core.score.min','0')
LMSSetValue('cmi.core.lesson_status','incomplete')
LMSSetValue('cmi.core.lesson_status','completed')
LMSSetValue('cmi.core.score.raw','100')
LMSSetValue('cmi.core.score.max','100')
LMSSetValue('cmi.core.score.min','0')
LMSSetValue('cmi.core.lesson_status','incomplete')
LMSSetValue('cmi.core.lesson_status','completed')

En todos los casos Chamilo devuelve un true y posteriormente se realiza el LMSFinish()

En este escenario Chamilo recibe del SCORM primero un valor de score 94 y un lesson_status con valor completed. Esto provoca que, aunque posteriormente recibe un score 100, no se actualiza por que Chamilo no admite la actualización de score si ya se ha recibido un lesson_status = completed

Nuevamente comento que me consta que en el pasado ya se discutió si se debía aceptar actualizaciones de valores tras recibir un lesson_status = completed, sin embargo, tras comprobar que otros LMS (SCORM Cloud, TalentLMS), con este mismo SCORM, recibiendo la misma secuencia SI actualizan el valor de score, consulte directamente con Rustici (SCORM Cloud) este comportamiento obteniendo la siguiente respuesta:

Really it is up to your LMS how you would like to handle it. I do not believe that there is anything in the SCORM specification that indicates that you have to accept scores after the course sets itself completed, but from a learner standpoint, I feel like you probably should. It feels like you are opening yourselves up to support tickets from folks confused that they received a 100, but the LMS is only reflecting a 94. Since not all courses will send scores in the same way, it may be good to just accept the data the course sends until it is committed and the course calls LMSFinish.

Entiendo que desde el punto de vista de Rustici, debido a las diferentes formas que un curso puede enviar el score al LMS se debería aceptar el dato que hasta que se realiza un LMSFinish, aunque se hubiese recibido antes un lesson_status = completed. Viendo que este es el comportamiento de una herramienta de uso masivo como Rise y como una empresa especialista en SCORM como Rustici simplemente lo acepta, ¿Chamilo debería abrirse a tener el mismo comportamiento?

Testeado en tres sites diferentes de Chamilo 1.11.16 con el mismo comportamiento y testeado en SCORM Cloud (https://app.cloud.scorm.com/) y TalentLMS (https://talentlms.com) donde acepta nuevos valores de score tras recibir un completed.

Captura completa de consola de navegador: https://pastebin.com/HxANwG25

[ywarnier]

@juan-cortizas-ponte I cannot find any reason in the SCORM 1.2 RTE not to accept setting the score after receiving the status=completed and before receiving LMSFinish(), so I am open to a PR for this.

[ywarnier]

In the code for feda, there is also a change in updateLpProgress() suggesting to only apply a progress change if the progress is greater than the previously registered progress. I don't think it's related to the issue described here, but I find that change reasonable (I have difficulties imagining a case where progress goes backwards, except if sent erroneously by the SCORM and the SCORM is auto-correcting itself, but this updateLpProgress() is only called by learnpathItem::write_to_db(), so not directly from the SCORM, so I'm adding that too. This could avoid one "write" operation in the DB which should have a positive impact on load on high-use systems.

[ywarnier]

Commit e19e39d has been erroneously linked to #4594. It should be linked to this issue here.

[ywarnier]

Regarding the changes to LearnpathItem::save(), taking your comments above into account and reviewing the code, I agree to let the SCO still change other properties until LMSFinish() has been received, but this excludes lesson_status when prevent_reinit is still set to 1, because if we allow the status to change back from completed to incomplete or not_attempted, we are effectively allowing the SCO to be reinitialized (which goes against the prevent_reinit setting set to 1.

My change thus takes this particular case into account, but for the rest, all properties will now be changeable, even if the status was completed or failed.

[ywarnier]

He probado un SCORM normal y no veo problema en el registro de sus datos ahora (post-cambios) así que considero que por lo menos no hay regresión.
Tendráis que revisar estos cambios y reportar si va mejor así o si se necesita algo más. Por eso dejo la tarea abierta, pero está en 1.11.20.

[contidos]

Yannick, Juan ha probado tu modificación pero sigue fallando para el caso de progress as score. Vamos a revisar la modificación que hizo Juan e intentar integrarla dentro de tu solución.