added registration to sendState and getState calls

[julesb]

Without the registration value being recorded in our state objects, our system was returning state from previous attempts. This change fixes that issue.

[brian-learningpool]

Hi @julesb, thanks for the PR. Can I ask which LRS you're using?

[julesb]

Not an LRS, but we are using xapiapps. We are launching the content using the xapiapps builtin player (xapilauncher). We are relying on content to interact with xapiapps' Tin can API endpoints such as /tcapi/endpoint/statements and /tcapi/endpoint/state to track state.

[brian-learningpool]

Hi @julesb, I think we may actually require a new configuration setting to store/retrieve state by registration, since in Adapt we typically want to use the same state across attempts/registrations. Accepting this PR as is might fix it for your use case but it will break it for everyone else.

Are you ok to make the necessary changes?

Alternatively, can you contact xapiapps and query why they require the registration parameter? According to the spec it's optional: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Communication.md#23-state-resource

[brian-learningpool]

Hi @julesb, any thoughts?

[julesb]

Hi @brian-learningpool I agree that a adding configuration setting for this would be the right thing to do. Unfortunately I can't commit to working on this at this time. That said, If we continue using Adapt at xapiapps, then those who make the resourcing decisions here may well agree to put some resources on it.

BTW xapiapps uses the registration parameter to differentiate between different executions of a given module by a given person. This happens with recurring training, as we'll as the less common case that xapiapps support where multiple instances of the same content may be underway concurrently.

[liveaspankaj]

We should not confused between attempts and registration. Though it can be a topic of debate because there is no standard involved, two are very different things, at least based on how most of the content work currently.

Attempts are mostly number of times a learner comes back to same content during same enrolment.

So, for example, taking a course on Sexual Harassment is a requirement for Mr A. He is enrolled into the course. He comes and takes 50% of the course today, and then comes back tomorrow, he restarts from where he left and completes the rest. This is possible because you are storing and reading the bookmark data from State API.

Now, next year, he has to retake the Sexual Harassment course, he is re-enrolled into the same course. He comes to the content, and what will happen now? In current Adapt scenario, I have not tested but most likely he will start from the end.

A commonly used method is to use registration as enrolment, so first year you get one registration, all state data is assigned to that registration. So, all attempts for that registration allow you to resume from where you left.

Next year the registration value changes, and you start afresh, but when you attempt again against same registration you are able to resume from where you left.

Those who want the state to persist always, can either not use any registration at all, or use one fixed registration value.

Use of registration depends on the authoring tool, however, a common practice is to use it with State API as well as Statement API. So that the enrolment use case can work.

[brian-learningpool]

Hi @julesb, just to update you on this, your change is earmarked for v0.8, which should be released before the end of August.

[julesb]

Hi @brian-learningpool - that's great news! Thanks for the update.

[brian-learningpool]

This is now merged in https://github.com/adaptlearning/adapt-contrib-xapi/pull/76.