During a developer/release team meeting we enumerated the following 3 issues related to LTI account permission levels:
- User created without permission (apparently due to dropped DB connections).
- LMS role to WW mapping does not exist (including when the LMS role sent via LTI is blank or missing).
- LMS role is too high and account creation is not prevented.
#1150 was intended to address issue 1, but really addressed issue 2. It was decided that issue 2 should be handled by a configurable fallback level, and maybe an on/off switch for whether accounts will be created in those cases. Thus 1150 was closed without being merged, and some additional work is needed on the general approach there to provide the features desired.
Issue 1 - should probably be fixed during authentication attempts triggered by LTI when no permission exists. Since student permission would be assigned by viewing the class list, whatever permission is granted should be the same in both places. Since both are meant to handle "broken" student records, which should be rare, @Alex-Jordan felt that a default of student should be OK, but it would still be nice if this was configurable.
Issue 3 - The initial development decision was not to take a security risk of allowing high-permission accounts to be created automatically. Unfortunately, this leads to unpleasant error messages and requires manual account creation. There is not yet a consensus about what account permission level should be granted to such users.
- Granting student permissions will lead to excess score records.
- One idea was to grant low permission access but to prevent assigning open sets.
During a developer/release team meeting we enumerated the following 3 issues related to LTI account permission levels:
#1150 was intended to address issue 1, but really addressed issue 2. It was decided that issue 2 should be handled by a configurable fallback level, and maybe an on/off switch for whether accounts will be created in those cases. Thus 1150 was closed without being merged, and some additional work is needed on the general approach there to provide the features desired.
Issue 1 - should probably be fixed during authentication attempts triggered by LTI when no permission exists. Since student permission would be assigned by viewing the class list, whatever permission is granted should be the same in both places. Since both are meant to handle "broken" student records, which should be rare, @Alex-Jordan felt that a default of student should be OK, but it would still be nice if this was configurable.
Issue 3 - The initial development decision was not to take a security risk of allowing high-permission accounts to be created automatically. Unfortunately, this leads to unpleasant error messages and requires manual account creation. There is not yet a consensus about what account permission level should be granted to such users.