Letting instructors create their own courses through LTI

[Alex-Jordan]

At a recent developer meeting, I described a project I am just starting to let instructors at a school initialize their own course without needing to go through a WW admin. To avoid certain problems, I would like to do this through LTI and the LMS. To outline:

1. The instructor has their new LMS course. They create an external learning tool using the WeBWorK server, and they define a custom LTI parameter. The presence (or value) of this parameter will be the trigger that tells WeBWorK to create a new course. (The presence of this custom parameter will lead WW to respond differently than a regular LTI connection.)
2. The instructor clicks to use this tool before the term starts. The LTI parameters have information in them, including a unique identifier for the LMS course. New code in LTIAdvanced.pm will trigger WW to create a new WW course, whose name is constructed from the LTI parameters, including the unique identifier. WW will email the instructor with the name of their new WW course.
3. Now the instructor can proceed to set things up in the LMS for their new WW course, using an LTI app in the regular way.

I realized that there needs to be a launch URL for this new LTI instance that will have the custom parameter. It has me wondering how to proceed. Some options that I would like your (anyone reading this) thoughts on:

1. The launch URL is the admin course. The instructor will have to have an account in the admin course for any of this to work. Their admin course account could have a permission level that prevents them from using the admin course in the usual way.
2. The launch URL is a special course created for this purpose. The instructor must have an account in that course for any of this to work. It could have a permission level that still prevents them from accidentally messing up that course.
3. The launch URL is a some page that is not an actual course. Going to this page in this manner, you just see a message indicating if course creation was successful.

I don't love any of these. Here are my issues with them:

1. After a user clicks the new tool, why should their screen now have them at the admin course? And do I really want more accounts to manage in the admin course?
2. Same as first issue above. Also, it feels like a hack.
3. There is no verification that the LMS instructor has an existing account already (with appropriate permissions) on the WW server.

Am I overthinking this? Is there a better way? Does one of these options seem like the least bad?

[drgrice1]

I think that sort of a mix of 1 and 3 is the way to go. The user needs to be in some course, and it seems that the admin course is the way to go. Yeah, you need to manage users there, but you will have to do it somewhere. However, instead of taking the user into that course main page, have a child page in the admin course that the user is directed to that indicates successful course creation, but that page would not have a site nav or anything that allows them to go anywhere else in the course.

I also think that a new permission level is merited for this. Probably at 15 (somewhere between professor and admin). Users at this level can create courses via this new LTI/LMS approach, but not in the usual way, and of course can't do any of the other things the admin user can do.

[dlglin]

Tagging @xcompass, since I have vague recollections that UBC had already implemented something like this.

If I were implementing this at my institution, I'd want the permissions to be handled by the LMS role. I don't want to have to maintain a whitelist of professors who can create WeBWorK courses. If they are a professor in their LMS course, then that would be good enough for me. I'd like to see both options available (whitelist or LMS role).

I also am not a fan of requiring a custom LTI parameter. If we have a dedicated course-creation URL, then it should be possible to create the course based on parameters that are already sent by the LMS. This could be configurable on the WW side, so the WW administrator decides which LTI parameters are used to create the course (either custom or existing).

[omar-hijab]

What's wrong with any instructor on campus typing a launch URL WWserverURL/new_course_id, and if this course doesn't exist, WW creates it etc? Why do we need a custom parameter or a dedicated course-creation URL?

If the course exists, and has a professor, WW shouldn't allow any connection from the LMS higher than the cutoff (ta usually), and if it doesn't exist, WW creates the course with that user as the professor, as soon as the user attempts to create an assignment in the LMS.

[Alex-Jordan]

I would not want to give every instructor the ability to create lots of WeBWorK courses. The potential for someone not knowing what they are doing and causing a headache either for themselves or for the admin is too high. So in what I am planning, a new WeBWorK course would have a name that is defined using the parameters of the LMS course. If you are an instructor in an LMS course, you get one automatically generated WeBWorK course, and that's it. (For a second WW course, say for separate quizzes, you could still contact the WW admin).

[omar-hijab]

Yes, sure, but isn't the list of LMS courses that are already linked to WW courses on the WW server stored somewhere on the WW server hence known? With a launch URL of WWserverURL (no course specified), the WW server can check whether the particular LMS course requesting access is on the list or not and proceed accordingly? As you say, just use the parameters of the LMS course, no custom parameter. This way each LMS course gets linked to at most one WW course?

[Alex-Jordan]

The outline that I have uses existing code in LTIAdvanced.pm. If a certain custom parameter is present and/or properly set, then the behavior in LTIAdvanced.pm changes a little. It sounds like you are describing a larger project to write new code.

I'm not the expert, but I think it's not as simple as "the list of LMS courses that are already linked to WW courses on the WW server stored somewhere on the WW server". If there is no grade passback, there is no need for the WW course to have any information about the LMS. So I could be wrong, but I don't know where you'd find that information. Not to mention, complications when multiple LMS courses use the same WW course (which is common). Of course if this data doesn't exist now, it could be added. But again, it sounds like a larger project.

So maybe using a custom parameter is just a way to leverage existing code.

[omar-hijab]

Fair enough, I was just thinking out loud. Another wish-list feature that struck me as more natural: A log-in page on the WWserver that sends a user to a listing of courses they are enrolled in, so the user need not log out/in when switching courses. Is this in the works anywhere?

[drdrew42]

Users only exist at the course level, so (strictly speaking) users are only ever 'enrolled' in a single course. The setup you're asking for is a feature in WeBWorK3 -- currently in very early development stage.

[omar-hijab]

Great, thanks for clarifying... awaiting ww3 eagerly!

…

On Thu, Jul 28, 2022, 11:50 AM K. Andrew Parker ***@***.***> wrote: Users only exist at the course level, so (strictly speaking) users are only ever 'enrolled' in a single course. The setup you're asking for is a feature in WeBWorK3 -- currently in very early development stage. — Reply to this email directly, view it on GitHub <#1601 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2F5U4GLRT4YDLHPAI2AJ5DVWKT3TANCNFSM5OTAT6RA> . You are receiving this because you commented.Message ID: ***@***.***>