search

openwebwork / webwork2

Course management front end for WeBWorK
http://webwork.maa.org/wiki/Main_Page
Other
145 stars 165 forks source link

option to have courses hidden by default #2298

Closed Alex-Jordan closed 8 months ago

Alex-Jordan commented 9 months ago

This adds a new variable to site.conf, $hide_new_courses. With this PR, unarchiving a course and keeping its old name, you get a course with its hidden status unchanged. But for unarchiving a course with a new name or making a completely new course, this variable controls whether or not it will be born hidden. More specifically:

If it is false (the distribution default):

If it is true:

This will be useful for Runestone, where we always hide all courses (except the demonstration courses). Up to now, I have to manually hide each course after its creation.

This is also helpful for my regular PCC server. Our practice is to leave the prior term's courses open, but hidden. Then they get archived and closed two terms after the course ended. So later, if an instructor wants a new course that is a clone of the old course, we unarchive their old course with a new name (that includes the current term). But without this PR, the new course is born hidden when we don't want it that way.

drgrice1 commented 9 months ago

I don't agree with the change to behavior when $hide_new_courses is false, and a new course is unarchived with a new name. I frequently unarchive courses to a new name that were hidden, and want the unarchived course to still be hidden. (In fact, I don't want any courses visible on my server ever.)

Instead of creating a new course environment option, why not add a checkbox to the add course and unarchive course pages to control this?

Alex-Jordan commented 9 months ago

Wouldn't you want it set to true then, if you never want courses visible?

On Thu, Jan 11, 2024, 6:44 AM Glenn Rice @.***> wrote:

I don't agree with the change to behavior when $hide_new_courses is false, and a new course is unarchived with a new name. I frequently unarchive courses to a new name that were hidden, and want the unarchived course to still be hidden. (In fact, I don't want any courses visible on my server ever.)

Instead of creating a new course environment option, why not add a checkbox to the add course and unarchive course pages to control this?

— Reply to this email directly, view it on GitHub https://protect2.fireeye.com/v1/url?k=31323334-501cfaeb-3132feb7-454455535732-5bd00f0a150b7e68&q=1&e=1019f035-62af-4e58-8563-1136c9a74713&u=https%3A%2F%2Fgithub.com%2Fopenwebwork%2Fwebwork2%2Fpull%2F2298%23issuecomment-1887335531, or unsubscribe https://protect2.fireeye.com/v1/url?k=31323334-501cfaeb-3132feb7-454455535732-c8b21c350327271d&q=1&e=1019f035-62af-4e58-8563-1136c9a74713&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABEDOAD5B3ZNYQ6WL5ZGYODYN73GHAVCNFSM6AAAAABBWAHOESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXGMZTKNJTGE . You are receiving this because you authored the thread.Message ID: @.***>

drgrice1 commented 9 months ago

Yeah, I suppose that works.

drgrice1 commented 9 months ago

Although as you pointed out setting $hide_new_courses to true works for my purposes, in thinking about this more, I still think there should be an option that fully preserves the current behavior (and it probably should be the default).

There are cases where the current behavior makes sense. For example, suppose that at some institution some courses are hidden (perhaps because they are meant to be accessed via LTI authentication which is my reason for hiding courses), and others that are not (perhaps these don't use LTI authentication). If this institution does not use the scheme that you describe that you use at PCC, and when a course is unarchived with a new name it should have the same hidden/unhidden status that it had when archived, then the new options don't cover this case.

So how about instead of making the $hide_new_courses purely boolean, make it have three possible values (maybe 'off', 'smart', and 'always'?) where 'off' is the current behavior, 'smart' is what false does with this pull request, and 'always' is what true does with this pull request. Those may not be the best value names, but are offered to describe the idea.

Alternately, consider the checkbox approach maybe?

Alex-Jordan commented 9 months ago

I was thinking about the trinary option too this morning after the earlier messages. I'll go ahead and do that sometime soon. I think I am avoiding the checkboxes because I foresee myself having to check the box a lot. Runestone would have (almost) all courses hidden, and my PCC server would have new courses not be hidden. So one way or the other, I'd be checking that box over and over again.

Alex-Jordan commented 9 months ago

Now the variable is named $new_courses_hidden_status. It can be 'hidden', 'visible', or anything else (including unset) for the three behaviors. The comments in site.conf.dist hopefully explain it well.

BTW, with this and the custom admin course name PR (#2295), there are new types of things in the config files: config options that affect how the admin course behaves. I put these things in site.conf. Does that seem correct? As opposed to defaults.config with an option to override using localOverrides.conf?