Vital Source Technologies
funded the addition of LTI 2 support to Moodle 2.8. It is now
proposing to do the same to add support for the new Outcomes Management 2 (rich outcomes) services (see http://www.imsglobal.org/lti/ for details) which overcome the limitations of resource links having only a single gradebook column.
A project page describing the work to be undertaken is being set up at https://docs.moodle.org/dev/LTI_Outcomes2_Services.
In designing an implementation of the LineItem services, I need to find a way of creating records in the grade_items table. It appears that, without making other changes to the core code, I cannot create them with an itemtype of "mod", an itemmodule of "lti" and an iteminstance of null or "0". If I do the gradebook interface tries to locate the associated LTI instance, which does not exist. Since the columns exist independently of any specific resource link, they cannot be associated with an actual instance.
My current proposal, for which I would appreciate feedback as I am probably not aware of the wider implications of doing this, is as follows:
"Since the columns exist independently of any specific resource link" - why?
Even if you cannot naturally associate each LineItem, can't you find some arbitrary make the association, so that it fits the Moodle API? (Sorry, I have not read the Outcomes service spec, and I am not going to. If you can give, or link to, a one-page summary, then I might be able to help more. I guess the key thing to understand is the data model.)
The one example of this in standard Moodle activity with multiple grade items is mod_workshop, where each workshop activity contributes two grade items. See https://github.com/moodle/moodle/blob/032a4fe51ccf41cbd3c310d52ca5b7777ffb5123/mod/workshop/lib.php#L1076
OK, I have now read your wiki page. That is a good summary. (Sorry, I should have done that before.)
I note that the spec is still a draft. Perhaps this aspect of it deserves more discussion. Perhaps each LineItem should have to belong to one particular LTI activity in the course?
If they don't re-consider that part of the spec, then i would suggest that the grade_items you create should not be linked to mod_lti at all. I can think of two ways you might handle it:
1) Create a special activity mod_ltioutcomeservice which cannot be added manually, but on any course where the outcome service is used, an instance of that module gets automatically added to the course (hidden from students) and manages all the grade items.
2) Alternatively, implement this services as a local plugin instead of a mod, and use standard custom grade-items, such as a user would create using the gradebook UI. (Or, extend the gradebook UI so the local plugins can own grade-items in a course.)
Thanks for your helpfui responses, Tim. I left responding for a while in case anyone else wanted to contribute to the discussion, but I had not meant to leave it quite this long.
My feeling about your second suggestions is that it seems to be contrary to the way in which LTI services have defined as sub-plugins which can be automatically discovered and offered to tool providers. Your first suggestion has the disadvantage of requiring an additional install which, to me, is not ideal. It would be nice for a service to be self-contained within a single sub-plugin.
I have, however, heeded your advice about not abusing the content of the grade_items table. My current proposal is to create the lineitems as manual items. This involves a couple of database changes:
1. The lti_submissions table has two new fields: courseid and gradeitemid which allow a submission to be associated with a grade item since this is no longer possible via the LTI instance ID. The course ID is useful when a grade item has been deleted.
2. A new table named ltiservice_outcomes2 is created with the following fields:
This table allows grade items created by the service to be associated with a tooi proxy and as a place to record any activity IDs defined by the tool provider. At present I have not added any referential inegrity constraints so records will remain in this table after a tool proxy or grade item has been deleted. Would a maintenance script to tidy up this table be sensible?
Does this sound like an acceptable solution or should I be revisiting one of the other suggestions?
That sounds plausible, though as you say, it would be nice to get some input from other people.
I don't know what the coding style rules say about digits in database table names. You may need to call it mod_lti_outcomes_two. (Table names must start with the plugin name.)
Thanks Tim. I cannot find any definitive documentation on the naming of plugins/subplugsin, apart from being lower case. However, I have also not found any other examples which include digits in their name and I did find mod_turnitintooltwo which suggests that I should rename my subplugin to ltiservice_outcomestwo (named because it is an implementation of the Outcomes Management 2 specification). In which case this would also mean a similar change to the database table name.