Status: Development in progress
Affects Version/s: 4.0
Fix Version/s: Must fix for 4.0
Component/s: LTI provider
Sprint:Navigation push 8, Navigation push 9
This one is part bug and part planned improvement to solve said bug. It's a must fix 4.0 issue as instructors will almost certainly run into this problem without a process in place to handle it.
The bug occurs only for users allowed to perform both types of launches: deep linking (content selection) and resource link launches (launching a shared module in the tool). I.e. Admins and instructors are affected.
When the instructor makes a deep link launch, they must be authenticated with the tool site. This is so that we can find content which they have the capability to see (shared in courses where they both have access and can share content themselves). The instructor will thus log in to their preexisting account on the tool site. Let's call this one the 'real' account. So, the user logs in and can browser a selection of resources to use. All fine so far.
Once the user selects a resource (or several) and sets up some resource links (these are the mod_lti instances in a Moodle platform), they probably want to launch said resource to see what the view looks like, etc. THIS is where the problem arises. Because of the way the enrol_lti code works now, they will be logged in as a user account which belongs to the auth_lti auth method, and which IS NOT their 'real' account. Let's call this one the 'lti' account. So, we have 'real' and 'lti' accounts in the tool site.
Now, let's assume the user goes back to add some more content and performs another deep linking launch. This time, since they're already authenticated as the 'lti' user, they'll be allowed to view the content listing, but it will be empty because that 'lti' user doesn't have the necessary caps to see the published content. The instructor will have no idea what's happened and will create a bug report or a forum post.
What we want is for the same account to be used when launching as an instructor, whether that be a deep linking launch or a resource link launch. Some instructors will have an existing tool account and will want to link that. Other instructors may only be given access to certain published resources, such as if they're emailed the launch URL and uuid of the resource. These users will want to have an account auto-provisioned for them as they will not necessarily have an existing account on the tool.
The solution to this problem is to provide an account binding (or "Linked login" to use existing Moodle terminology) which would essentially link the platform user (identified by their LTI launch credentials) with the respective user in the tool site. The way this would be achieved is via a one-time prompt for instructors when launching for the first time. They will be asked what they'd like to do and can select from two options:
- Create a new account - have the Moodle tool site automatically provision an LTI account for me
- Use an existing account - the user can log in with their preferred account.
Regardless of which option the user chooses, it will result in the creation of an LTI Linked Login on the tool site, allowing us to find this user in future during any launch as part of authenticating them.
This change must not impact student/learner launches. Student accounts in the tool will remain auto-provisioned for the time being.
This change must also take into account migrated tools (those tools being launched with a valid LTI migration claim). We need to carefully document how instructor launches will behave in such cases as:
a) when migration claim is sent and a preexisting user was found
b) when migration claim was sent and there was no preexisting user found (i.e. the teacher is a new user to the tool)