LTI Tool Provider: Empty service url

LTI Tool Provider: Empty service url

by Gemma Lesterhuis -
Number of replies: 10
Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hello,

I bumped into an issue I have not had before. And wondering if someone recalls a simalar issue. 

Moodle 3.9.x  LTI Tool Provider
CAPP12 LTI Tool Consumer

Case:
Student enters course, in the enrol_lti_user column serviceurl, the url is placed.
Student receive a grade, grade is send through the services , LTI tool consumer confirms that grade is visable. 

Student re-enters course to improve grade, grade is not being send. 
Cron log shows error: skipping - empty serviceurl for the user xxx in the tool xx for the course xxx

We check the database, and confirm that the service url has "dissapeared". 

We enter the service url manually in the database and grade is being send again. 

We discussed the issue with the technical staff of CAPP LMS and they responded:
beside the normal way to start a new attempt, students have - when set - the possibility to see a result that been send before. Conform LTI we send an earlier used lis_result_source_id without the service url. We don't send the service url because we don't expect a result back. 

I have no idea how they do it, but could it be that because they don't send the service url again this is being cleaned in the Moodle database? 

I have checked between 2 Moodle LMS systems. I removed the service url in the database, and re-entered the course as a student and noticed the service url is being placed again in the database. 

Hope someone reconginizes what happens here, and might have an idea if it is a bug in Moodle that causes the service url to dissapear when they do this (what they claim to be a standard) or that they do have to send the service url anyways. 

Gem


Average of ratings: -
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Gemma,

Thanks for the very detailed description. That certainly helps in tracking stuff like this down. I'm not sure I quite follow their response, though.

beside the normal way to start a new attempt, students have - when set - the possibility to see a result that been send before. Conform LTI we send an earlier used lis_result_source_id without the service url. We don't send the service url because we don't expect a result back.

Assuming you do, could you perhaps clarify what they're trying to say there? It sounds like they're talking about a mechanism to allow grade history to be shown in the Consumer, which can result in a launch with an old lis_result_sourcedid being sent, without an accompanying lis_outcome_service_url. Is that about right?

In any case:

I have no idea how they do it, but could it be that because they don't send the service url again this is being cleaned in the Moodle database?

This seems to align itself with what the tool provider code does. It grabs the service URL and, if different to the currently stored value, it sets the new value.
https://github.com/moodle/moodle/blob/master/enrol/lti/classes/tool_provider.php#L344-L346
I guess this is to handle cases where the service URL changes from one valid URL to another, rather than cases where it's being omitted.

If you have a look at the Basic Outcomes 1.0 documentation (https://www.imsglobal.org/specs/ltiomv1p0/specification), specifically section 2 there, you'll see this part:

A typical implementation pattern is for the Outcomes Service Provider to only accept outcomes for launches with a role of "Learner". If this were the case, the TC would only provide lis_result_sourcedid values on launches with a "Learner" role. If the TC is configured to accept outcomes on a particular launch, the TC is required to include lis_outcome_service_url regardless of the role in the launch and regardless of whether or not a lis_result_sourcedid is included in the launch.

Whilst not exactly the same situation, that, to me, suggests that omitting the service URL isn't something that's permitted when we expect results in any of the launches. Regardless of whether a result is expected on a particular launch, if we expect it at some point, for some role, it seems that the service URL must be sent on every launch.

Hope that helps,
Jake

Average of ratings: -
In reply to Jake Dallimore

Re: LTI Tool Provider: Empty service url

by Gemma Lesterhuis -
Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Jake,

Assuming you do, could you perhaps clarify what they're trying to say there? It sounds like they're talking about a mechanism to allow grade history to be shown in the Consumer, which can result in a launch with an old lis_result_sourcedid being sent, without an accompanying lis_outcome_service_url. Is that about right?

I have translate their full reply for you. But as I understand it, you are right they are talking about a mechanisme to allow grade history to be shown in the consumer, which can result in a launch with an old lis_result_sourced_id being send. 

Their reply fully translated:"The supplier indicates that the service url is sometimes lost. The only explanation I have for this is that in addition to the 'normal' start-up of an attempt, there is also the possibility to view previously acquired results if this is checked (as a check mark at the device) in our LMS. The form in which previously achieved results in accordance with LTI standard can be viewed is by sending previously used lis_result_sourced_id to the supplier of the content, but WITHOUT a service url. After all, no result is expected in return from this review of a previous attempt. On the part of the supplier, the attempt can then be looked up and the results (possibly provided with feedback) can be shown to the user.

It seems to me that what you descibe on the Basic Outcome 1.0 documentatie, section 2 -is exactly what they are reffering to. I will double check with them if this is the case. 

But do I understand you correctly that Moodle's current code, cannot handle this behavior that the LMS consumer is asking of Moodle as a provider? And if so, does that mean looking at the Basic Outcome 1.0 documentation that this behavior in Moodle should be adapted, or in other words: should a tracker be made for this, and if so is this an improvement or considered as a bug? 

I am also wondering if this effects the changes in Moodle 4.0 looking at the new 1.3 LTI provider set up? 

(Sorry too many questions)

Average of ratings: -
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Gemma,

I'm wondering whether that type of use case is actually supported by the BO 1.0 standard. I will add the disclaimer that I'm more versed in the 1.3 standards than the legacy ones though. I'd be interested to see the specific part of the spec that deals with launching into past results using different lis_result_sourcedid values.

You're right when you say Moodle's BO code cannot handle this . It will update the service URL on every launch. If it's being omitted on the most recent launch, then Moodle removes that data from the table. Another way to think about it is that Moodle is designed to support changing service URLs (which is a valid, albeit rare use case according to the spec) but wasn't designed to handle the use case being discussed here.

In any case, Moodle is moving away from 1.1/2.0 and related services since these are deprecated. We're unlikely to accept any changes to this code because of this, so I wouldn't recommend creating a tracker issue. Presumably, the platform also supports 1.3 and Advantage.

Currently, the LTI Advantage code in enrol_lti (a dev branch) won't delete the Line items endpoint, even it it's omitted from a given launch. If the tool (formerly provider, aka Moodle) doesn't have permission to post/update the score (i.e. cannot get an access token for the required scope), that operation just won't happen. LTI Advantage also has a spec called Submission Review, which may handle situations like "Student launches to review their existing work" - which seems to be what's being discussed here. That spec is not final, however, and there is no support for it yet in Moodle in either the Platform (consumer) or Tool (provider) code.

Cheers,
Jake
Average of ratings: -
In reply to Jake Dallimore

Re: LTI Tool Provider: Empty service url

by Gemma Lesterhuis -
Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Jake,

Sorry for the delay. They confirm that the BO 1.0 section you refered to describes what they are doing, but since they implemented it awhile ago they are not sure if this is the only section that referens to the working.

They do test through https://saltire.lti.app/tool (or https://ltiapps.net/test/tp.php ) to ensure that they work according to the standard. 
And confirmed through these test that a module can be started without the lis_outcome_service_url .
In any case, Moodle is moving away from 1.1/2.0 and related services since these are deprecated. We're unlikely to accept any changes to this code because of this, so I wouldn't recommend creating a tracker issue.
Does this mean that Moodle 4.0 will only support 1.3 / LTI Advantage? Because I can imagine that there a multiple suppliers that have not moved away from the deprecated standard. And would be good to inform them on time. If Moodle still support 1.1/2.0 in Moodle 4.0, I can imagine that creating a tracker (and providing a patch) would be still usefull (?)
Currently, the LTI Advantage code in enrol_lti (a dev branch) won't delete the Line items endpoint, even it it's omitted from a given launch.

Do I understand you correctly that the current discussed scenario won't be happening from Moodle 4.0 forward? 

Gemma

Average of ratings: -
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Gemma Lesterhuis -
Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
@Jake - Following up on the yes/no tracker . It seems to be a setting in this specific LMS (CAPP) that can be turn on / off per LTI tool url. So a patch won't be necessary.

But I do wondering if in M4.x LTI 1.1 / 1.2 will still be available even though it will deprecate this year. Because I fear that - similar to by example SCORM - that this "old" standard even though deprecated will take some time to be replaced by 1.3 in other LMS systems.
Average of ratings: -
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Arnout Vree -

Hi Jake,

If LTI 1.1 and 1.2 are no longer supported, this will have a major impact on a number of our customers. 

I hope you can clarify this soon.

Best regards,
Arnout (Avetica, Premium Moodle Partner)


Average of ratings: -
In reply to Arnout Vree

Re: LTI Tool Provider: Empty service url

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Arnout,

1.1 and 2.0 will certainly be present in 4.0 - both in the consumer code (mod/lti) and in the provider code (enrol/lti). In the case of the latter (the provider code), we simply highlight, via the UI, that the method of publication is deprecated. There are no plans to remove this yet.

Cheers,
Jake
Average of ratings: Useful (1)
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Gemma,

That's good news. With cases like this, in which the proposed code change may end up being non-trivial and may change the way Moodle stores data about the launch, I'd be reluctant to push forward with too much vigor, given we can't certify again with said changes in place.

As mentioned above, yes, Moodle 4.0 will still have all the legacy LTI features you've used before / are currently using.
Average of ratings: Useful (1)
In reply to Gemma Lesterhuis

Re: LTI Tool Provider: Empty service url

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Gemma,

A few things to address here:

I'm not sure those test tools are 100% IMS compliant. While we've used these in the past ourselves too, they may not accurately test things like the edge cases we're talking about here. In any case, they aren't something to rely on as a single source of truth.

Moodle 4.0 only adds resource publishing over LTI 1.3 (enrol/lti). It doesn't remove any of the publishing capabilities for 1.1/2.0, nor does it change any of the Moodle consumer code (mod/lti). We just make it clear, via the UI, that the 1.1/2.0 method of publishing is deprecated but it's still possible to do this. Because, like you say, many consumers will not be able to support 1.3 (despite it being the only recommended standard right now), there are no plans to remove publication or consumption of resources over these legacy standards. I expect we'll be stuck with these for some time yet. What you see now in 3.11 will continue to work the same way in 4.0.

We can no longer certify legacy LTI with IMS - this is the important point driving the need to be very careful about what changes we do accept. Normally, we'd certify our LMS releases (as a consumer of 1.1/2.0/1.3 LTI resources) during the release period. We can no longer certify for 1.1 or 2.0 at all with IMS, meaning the current codebase (which is certified) is the last time we can be sure that the code passes the certification suite and works as intended. As such, we'll be very careful about what code changes we'll land for legacy version like 1.1/2.0 in future. Major changes will likely be rejected, but minor changes may be ok - on a case by case review.

Regarding my comment about the 4.0 changes and the endpoint: Yes, the issue being discussed here won't be a problem for consumption of resources published over LTI 1.3 in Moodle 4.0. You will of course need to wait for 4.0 and then republish the resource over 1.3 (and have a 1.3 capable consumer platform).

Cheers,
Jake
Average of ratings: Useful (1)