Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-69327

Learn about remote configuration challenges by creating a simple, remote setup proof of concept using LTI 1.1: Service considerations

    XMLWordPrintable

    Details

    • Story Points:
      1
    • Sprint:
      4.0 holding pattern 3

      Description

      This issue deals with the service considerations problem only. Only those points marked in red.
      We want to discover as must as we can about what's involved in programmatically setting up an activity, in a course, as an LTI provider, so that a consuming site may use this.

      The way this normally works when Moodle is acting as a provider (assuming human setup) is as follows:

      1. Admin enables LTI enrolment method
      2. Teacher creates an activity
      3. Teacher creates an LTI enrol enrolment instance, selecting the activity (there are several options when doing this, via the enrolment instance form)

      Programmatically creating this raises an array of questions, but we'd like to attempt to do this in order to learn more about what might/might not be problematic.

      At the end of this task, we should be able to make a web request to create an instance of an activity and make that activity available via LTI enrolment, as a provider. We want to document all limitations, assumptions, etc that we face along the way. This will be critical in identifying viability of LTI for such a task.

      These are just some of the things we'll want to experiment with and document the answers to. There will surely be other facts learned along the way too, which should also be documented clearly.

      1. How can we create an activity without knowing which fields are required by the activity (i.e. what fields would be mandatory if manually creating the instance)?
      2. Is there the possibility of creating the instance with defaults for these required fields? If so, how?
      3. Are we going to be able to support configuration of any of the enrolment method specific settings? These are things which normally be set up on the enrolment method, by the teacher setting up the method. Can we use sensible defaults here? If so, what does that mean for clients consuming the provided activity?
      4. What does the client absolutely need to consume the provided tool? Secret, key, etc?
      5. How are we going to pass the required information back to the client, assuming creation of the provided activity was successful?
      6. What access/permissions problems can we foresee? E.g. if a teacher in "Consumer Site" wants to create a provider activity in "Provider Site", how are they authenticating? Will they have an account in the provider site? Do they need any new capabilities to remotely create activities as providers like this?

        Attachments

          Activity

            People

            Assignee:
            jaked Jake Dallimore
            Reporter:
            jaked Jake Dallimore
            Participants:
            Component watchers:
            Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias, Sujith Haridasan
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: