Locking down a course

If the course isn’t in a catalog, it should only be visible to users who are enrolled in it (and SuperAdmins or potentially Power Users).  That seems like the easiest path, enroll those who need to see it but otherwise leave it unlisted.

Morning Nate,

If you can author a SCORM course as an option? It really is not too challenging to meet the requirement. Here is a breakdown of how to do it (most of it brought to you by an AI Overview):

Key steps:

    Add a password input field:
    Insert a text entry field on your first slide where the user will type their password.

Create a "check password" trigger:

    Trigger condition: When the user clicks a "submit" button or leaves the text field (on the "on exit" event).

    Trigger action: Compare the text entered in the field to your predetermined password.

Conditional branching:

    If the password is correct:
        Allow the learner to proceed to the next slide in the course.

    If the password is incorrect:

    Display an error message asking the user to try again.

Potentially lock the user out after several failed attempts. Now you may want to ponder how secure this is. But I would say - dont worry just that much about it….if you national security level types of approaches - then I will tell you this is not a great match. But for the 95% of your security needs - this can work wonders.

Adding to this comment.  I agree, as long as it is not in any catalogs or is only in a catalog visible to whoever you want to view it, it will be locked down from the front-end learner perspective. 

But another thing to note, if you have Power Users that have categories listed in their resources and you don’t want Power Users enrolling people in this course, then you will want to make sure that specific course is not in a category that is a resource to Power Users.  Our university went through a lot of trouble archiving courses by removing them from catalogs only to have Power Users accessing the course on the backend and enrolling people. 

Categories = what gives Power Users the ability to access via “course management”

Catalogs = what gives learners the ability to view content

I just had a weird and probably dumb idea: I suppose you could create a user additional field called “Catalog password” or... whatever. Make it not required, and visible to the users in their profiles. You’d also need to not hide the personal info tab on profiles under “Advanced Settings”.

And then have a group for users whose “Catalog password” field equals the correct password. That group could then be used for granting access to a catalog with the resources inside. Or for triggering an enrollment rule… Whatever.

Further in the spirit of dumb ideas, you can even use CSS to make the profile field look like a password field:

/* Naturally, check which one it is, it probably won't be ui-input-text-6 on YOUR platform */
input#ui-input-text-6 {
    -webkit-text-security: disc;
}

But like… Enrollment links are about as secure as a password anyway. Because what’s to stop people sharing the password, just as they could share the enrollment link with its hash? I’d say your colleague is probably better off managing a manual group and controlling access that way.

Thanks ​@dklinger this is a good idea. It might have even wider uses than just this project...

Thanks ​@Ian. I am always in the market for dumb ideas, they have always (well, often) worked for me. I think that they’re the backbone of effective problem solving for Instructional Designers, to be honest.

Good point, ​@sarahbarber99, thanks for highlighting this...which brings up a different point, I really wish there was an easy way of determining which PUs have access to the different catalogs & categories, rather than checking the permissions on each individual PU.