LTI settings in Course Config

[Alex-Jordan]

I'm going to add a tab to Course Config for LTI settings. (If it is a concern to have yet another tab there, I can make it something for which you must opt in.)

There are some settings that are definitely appropriate for granting the professor quick access. Especially $external_auth and $LTIGradeMode.

There are other settings that a professor who doesn't know what they are doing should not be encouraged to fiddle with.

My list is below. How do others feel?

Should be in Course Configuration LTI tab

$LMS_name
$LMS_url
$external_auth
$LTIGradeMode

Should not be in Course Configuration LTI tab

These all strike me as (a) risking unauthorized strain on the server, or (b) risking unstable student WW accounts, or (c) something technical that is for the server admin only.

$preferred_source_of_username
$fallback_source_of_username
$strip_address_from_email
$preferred_source_of_student_id
$LTIBasicToThisSiteURL
$LTIGradeOnSubmit
$LTIMassUpdateInterval
$lti_check_prior

Unclear to me

$debug_lti_parameters
$debug_lti_grade_passback
$authen{user_module}
$LTIBasicConsumerSecret
$NonceLifeTime
$LMSManageUserData
%LMSrolesToWeBWorKroles
$LTIAccountCreationCutoff

As you consider this, keep in mind WW servers that serve multiple institutions with multiple LMSs.

[dlglin]

I like the idea of instructors being able to configure LTI from within their course, and I had the same thought of adding this to the config page. I guess I have some questions about philosophy, which mainly boil down to "how much rope do we give instructors"? Almost any modification to LTI settings can get an instructor into varying degrees of trouble. Some of this can be mitigated by having some checks done by the UI. Here are some thoughts:

Even allowing the instructor to change $external_auth is dangerous. I can see situations where the instructor logs in directly, but students use LTI. Enabling $external_auth could lead to them locking them out of their course.

$LMS_name and $LMS_url seem safe enough, since IIRC they only affect messages displayed to users. I think the worst thing that happens with $LTIGradeMode is that they screw up their LMS grade book, and possibly that students get errors if they try to access an assignment directly and not through the LMS.

In general two scenarios come to mind:

1. LTI has already been configured with default settings for the server, and the instructor wants to enable it for their course.
2. There is no LTI configuration for the server, but the instructor wants to enable it for their course.

As an aside, we may be able to merge these two scenarios by adding some of the LTI parameters to defaults.config, if we can agree on reasonable defaults.

In scenario 1 a smaller subset of config items would need to be available to the instructor.

For $authen{user_module} and %LMSrolesToWeBWorKroles, if these were made available we'd have to be careful about how the interface works. For $authen{user_module}, the list of available authentication modules isn't stored anywhere. For %LMSrolesToWeBWorKroles, the list of WeBWorK roles is available, but the list of LMS roles is not standard, and the names used for LTI links aren't always made available to instructors in the LMS.

Since everything set by the configuration page is stored in simple.conf, the worst case scenario is that the instructor makes a mess of their course (locks themselves/students out, allows LTI access beyond what they intended, etc.), and possibly their LMS grade book. The only thing I can think of that would have consequences beyond the course is $LTIMassUpdateInterval, since this could affect server performance (though I'm not sure that this setting is even accessed at the course level).

[Alex-Jordan]

Even allowing the instructor to change $external_auth is dangerous. I can see situations where the instructor logs in directly, but students use LTI. Enabling $external_auth could lead to them locking them out of their course.

If students can access through LTI, can it not be safely assumed that the instructor can as well? The instructor may have been in the habit of logging in directly, but they would normally have access to the same LTI links as students. Or is that wrong? Either way, the doc for that entry could stress "including the instructor" as a warning.

[dlglin]

A more likely scenario is locking out a course coordinator or WeBWorK administrator, who may not be registered in the LMS course, but would still need access to WW.

[Alex-Jordan]

Note that I opened #1505 with one version of how this could work. In that, the new tab has to be activated by uncommenting code from authen_LTI.conf.

[Alex-Jordan]

I wonder if when $external_auth=1, if we should still allow users to enter their user ID and password into the form fields. But if they validate, they are not actually let in. They just get a message "You must log in through the LMS". Except it could allow users of a certain level like professor to pass on in. It would be similar to the permission for "is allowed to log in to the course".

[Alex-Jordan]

"LTI settings in Course Config" has been implemented. Closing this discussion.