Disable Changing Course Start and End Dates

[jheath]

We'd like our registrar exclusively to be able to able to control terms, as well as course start and end dates to prevent confusion for students and teachers alike. We currently have disabled the ability to change the term, but there is not permission setting to disable teachers from changing the start or end dates per role.

[jordan]

Thank you for submitting this feature idea! In order to attract the support of other Canvas users to support an idea we always encourage those who submit feature ideas to review and do their best to comply with these tips: How do I write a good feature idea submission?​

If you need to make any adjustments to your original feature idea, just visit your feature idea page at any time, and click the "Edit" button (right-column), make changes, and click "Publish"

In the meantime I will update your feature idea to go up for voting on November 4th!

[biray]

This idea has moved to the next stage and will be open for voting among the Canvas Community, from Wed. November 4, 2015 - Wed. February 3, 2016.

Check out this doc for additional details about how the voting process works!

[chriscas]

I'd love to see this as well!  We currently have javascript code to hide the boxes from faculty members on the settings page, but somehow a few of them still get dates put in (still trying to track down whether course dates are somehow coming from content imports or how it's happening).  This should definitely be tied to a permission, because I know some places would like to allow for flexibility, but some would not.  I wouldn't mind as much if the dates entered for start and end of a course had to fall within the specific term dates set globally (so make the course shorter), but we absolutely do not want our faculty members deciding on their own to start a course early, or extend it past the end of our official semester.

[jbrady2]

This could prove useful, especially after what was experienced at the start of this semester. While our institution generally does not have any issues that stem from faculty releasing their courses early, I had one faculty member contact me a little after one week into the semester and state that she was not seeing a needs grading indicator in the gradebook for a discussion post that she was using in an online course to determine if the students were engaging with the course materials prior to the withdrawal due to non-attendance date. She further stated that when she checked the discussion itself, the students in question had posted. We determined that it wasn't an issue with the students only replying to another student and not the original post. Rather it appeared that the students in question had all replied prior to the actual start of the semester based upon the institution's settings for the course.

[harker]

This is something I have wanted from the beginning.

I would rather have this be an Admin feature than an instructor. Integration with the SIS can be overwritten and some Registrars can get in a State policy violation if faculty continue to circumvent the standard.

There is a lot of philosophical reasons on both sides of this option. So by making this an on/off option for the Admins to decide based on institution policies would be grand.

[lane_worrall]

I agree with everyone here that this would be a great addition!  I'm not sure that I understand why we can lock down the ability for teachers to change the terms, but can't lock down the start/end date fields which appear to override the term dates when they are filled in.  Am I misunderstanding the functionality of the start/end date settings?

We were recently made aware that, in a majority of our courses, a start date (and seemingly random start time, 1:01pm etc.) has been "manually" entered.  In some cases, the start/end date conflict with the actual term--e.g. a "spring term" course has a start date of Sep 9, 2015 at 10:04am, and end date of Jan 16, 2015 at  7pm.  Just to clarify, our spring term actually begins February 2nd and ends June 22nd. 

chriscas​, I'm not sure if you've already tracked all this down, but I also explored the possibility of these fields being populated "unintentionally" when a teacher imported content from previous year.  I have tested the impact of importing content via the "copy a Canvas course" option with the following results:

• The start and end date fields for the course I'm importing into are blank, and I chose to import from a course that had dates in these fields
  • import content / copy a Canvas course / all content / (Adjust events and due dates - NOT selected)
    • this does not carry over the start/end dates from original course
  • import content / copy a Canvas course / all content / Adjust events and due dates / remove dates
    • this does not carry over the start/end dates from original course
  • import content / copy a Canvas course / all content / Adjust events and due dates - even if the teacher does not enter new dates into these fields, the "change date to / beginning date" field is automatically filled in
    • this appears to be the only option that does populate the start/end dates in destination course

Of the three options I tested, the teachers in our instance (brick and mortar K12 school) use either the first or second.  It is most likely that the third option would only occur unintentionally - i.e. if a teacher selected "adjust events and dues dates" and forgot to select "remove dates."  Although this "user error" might explain why the start/end date fields are populated in some courses, I have a hard time believing that it explains this irregularity in almost all of our courses...

I would be very interested to hear if anyone else has experienced this and if so, please share possible explanation/solutions to prevent this from happening on a large-scale.

Thanks!

 @ckelson ​  @james_grogan ​

[Renee_Carney]

Thank You for taking the time and energy to submit and discuss your idea. Your feedback helps our product teams prioritize feature development so we can build a product you will love. Unfortunately, this idea has been archived because it did not meet the 100-vote threshold within the 3-month voting period. Learn more at: How does the voting process work for feature ideas?

Can archived ideas still become a feature?  Potentially. Archived ideas can be resubmitted by Community members. As people’s needs change, previously submitted ideas may gain additional traction. All feature ideas are evaluated as a whole and may influence product direction.

Panda-Cat: A mythical creature that we dreamed up to catch your attention, make you laugh, and encourage you to stay invested in Feature Ideas process of making Canvas better!

[millerjm]

We need some support for our case that the permissions available in Canvas are not sufficient for our needs.  Above is the update that Allison Weiss posted to many of our feature ideas.  She is asking for use cases for granularity and we really need to justify each and every one.  I made a document to track discussions and feature ideas related to permissions: 

Canvas Permissions and Granularity Feature Ideas

This is the sort of information that would assist in getting these changes made during this permissions audit.  This information would need to be added as comments to the individual feature ideas, and if it needs to be pasted to more than one, then please do that.  I know it's tiresome to post the same thing again and again, even though someone else has already done it, but they need to see that it's not just 5 people with these issues!  We haven't gotten much traction because we haven't had enough use cases posted but my document above seems to have gotten some attention.

• What has the current user permissions "bundling" and lack of granularity cost you in terms of support and functionality?
• What permissions have you HAD to grant to someone simply to allow them to be able to do their job, that you would have rather NOT given?
• What permissions have you had to DENY giving someone because it gave them access to something that you could not due to security, concern about causing trouble, etc.?
• What other qualms do you have about things?
• What things have cost you more in staff hours because of denying access to someone, means that your department had to research, do work, etc, on behalf of a user that would have been able to do their work if the permissions were granular?

Thank you!

Joni

I'm also tagging  @kona ​ and cms_hickss​  since they have been so involved in getting attention to these feature ideas. 

[cmarks1]

We would also want our Registrar's office controlling start and end dates.  Once faculty learn how to change the dates, they are starting courses before the term start without permission or knowledge of the Registrar's office.  This makes it difficult for many departments to monitor the courses and grades.  It is also difficult for the students since the noted date in the course schedule is not the same as the dates for the course.

[RobDitto]

A very similar idea will be open for voting starting in July 2016:

[ianjohnston]

Hey commenting on this late, but you mentioned that you had JS to hide the start and end date boxes from teachers. Would you be willing to share that code? We are running into issues with instructors changing start and end dates but don't have anyone well versed enough in JS to build something from scratch.

[chriscas]

Here's what we have (not developed by me, but I did have to modify the numbers once when Canvas was changed):

---

$(document).ready(function(){

  if($.inArray('teacher',ENV['current_user_roles']) == 1 && $.inArray('admin',ENV['current_user_roles']) == -1 ){

  // Hide the Start and End Date

  $(".coursesettings tbody tr:nth-child(7)").hide();

  $(".coursesettings tbody tr:nth-child(8)").hide();

  $(".coursesettings tbody tr:nth-child(14)").hide();

  }

});

---

Use at your own risk.  If you come up with a better way to do this too, let me know.  One thing I'll mention is that content imports can sometimes also populate the start_date or end_date (again, something I'd like Instructure to address), so with this code, teachers won't be able to see or ficx the problem, it'll have to be done by an admin.

[chriscas]

Ideally, I'd like to just have the buttons/fields "disabled" instead of hidden, but I haven't been able to figure out how to make them all disabled (specifically the datepickers, I can get the other fields done).  This would allow faculty to at least see if the fields have bad data and let an admin here know.  I posted a question about this in the Admin group, where I'm hoping a coding genius will be able to help, and then I can update everyone here.

-Chris

[James]

chriscas​,

I think using the next sibling selector, +, will help you with the date picker. You could probably also use the general sibling selector, ~, as well.

Try this to disable, but leave visible, the information. It's actually tied to the field so you don't have to worry about specific row numbers in a table.

$('#course_start_at').prop('disabled',true);
$('#course_start_at + button.ui-datepicker-trigger').prop('disabled',true);

if you would to hide the date picker instead of disabling it, then use

$('#course_start_at + button.ui-datepicker-trigger').hide();

Here's what it looks like if I disabled the start date and hide the course picker for it. I left the end date alone to show the contrast.

Each of those fields has an id associated with it. They are course_start_at, course_conclude_at, course_course_format. The last one has no date picker.  So, if you wanted to change all three, you could do this:

$('#course_start_at').prop('disabled',true);
$('#course_start_at + button.ui-datepicker-trigger').prop('disabled',true); 
$('#course_conclude_at').prop('disabled',true); 
$('#course_conclude_at + button.ui-datepicker-trigger').prop('disabled',true); 
$('#course_course_format').prop('disabled',true);

or use this to disable the dates and hide the datepickers

$('#course_start_at').prop('disabled',true); 
$('#course_start_at + button.ui-datepicker-trigger').hide(); 
$('#course_conclude_at').prop('disabled',true); 
$('#course_conclude_at + button.ui-datepicker-trigger').hide(); 
$('#course_course_format').prop('disabled',true);

Finally, if someone really wants to hide them completely, verses disabling them, here is some JavaScript/jQuery code that will do that without relying on the row number in the table. It uses the jQuery .closest() function, will will traverse up the DOM tree, so I find the field and then work backwards to find the parent table row.

$('#course_start_at').closest('tr').hide(); 
$('#course_conclude_at').closest('tr').hide(); 
$('#course_course_format').closest('tr').hide();

A more extendable approach would be to use an array of the fields you want to remove.

var hiddenFields = [ 'course_start_at', 'course_conclude_at', 'course_course_format' ]; 
for (var i = 0; i < hiddenFields.length; i++) 
{ 
  $('#' + hiddenFields[i]).closest('tr').hide(); 
}

That loop could be modified to disable the elements instead of hiding them. It won't cause irreparable harm (not the same as it's good programming) to attempt to disable an element that doesn't exist. If jQuery can't find, it, it just won't act on it.

This will disable all of the dates and date pickers as well as the course format.

var hiddenFields = [ 'course_start_at', 'course_conclude_at', 'course_course_format' ];
for (var i = 0; i < hiddenFields.length; i++) 
{
  $('#' + hiddenFields[i]).prop('disabled', true);
  $('#' + hiddenFields[i] + ' + button.ui-datepicker-trigger').prop('disabled', true); 
}

This will disable all of the dates and course format and hide the date pickers.

var hiddenFields = [ 'course_start_at', 'course_conclude_at', 'course_course_format' ];
for (var i = 0; i < hiddenFields.length; i++) 
{
  $('#' + hiddenFields[i]).prop('disabled', true);  
  $('#' + hiddenFields[i] + ' + button.ui-datepicker-trigger').hide(); 
}

Of course, all of that is still contained within whatever code you want to use to make sure you're on the right page and the right people have access to it.

I hope that helps. I know I provided lots of ways to accomplish things and that makes it look like a really long solution when it's just a bunch of short ones that someone should pick from, depending on their needs

[chriscas]

OK, with some assistance from  @James ​ (thanks so much for the suggestions you shared here and vie email!), I think I've got some slightly better script code to share here.  I've tested this on my test canvas instance, and it all seems to work.  This code also disables a few other things on the course settings page for non-admins, so I thought it may be useful to others to leave those in.  You can always comment out or delete lines you don't want.

If you find a flaw with this code, please let me know since it would probably affect my institution as well and I may have missed it.

---

// Disable the term Start date, End date, and visibility checkboxes. Also hide the delete and conclude buttons from non-admins in course settings

$(document).ready(function(){

    // Checks the page to make sure it is course settings

    if (/^\/courses\/[0-9]+\/settings$/.test(window.location.pathname)) {

        // Checks that current user role is not an admin to hide term start end date and visibility options. Admins can access all settings.

        if($.inArray('admin',ENV.current_user_roles) == -1){

            // Disables start date

            $('#course_start_at').prop('disabled',true);

            $('#course_start_at').removeClass('date_entry hasDatepicker');

            $('#course_start_at + button.ui-datepicker-trigger').hide();

            // Disables end date and fixes display flaw introduced by lack of datepicker

            $('#course_conclude_at').prop('disabled',true);

            $('#course_conclude_at').removeClass('date_entry hasDatepicker');

            $('#course_conclude_at + button.ui-datepicker-trigger').hide();

            $('[name=\'course[restrict_enrollments_to_course_dates]\'').before('<div class="datetime_suggest"></div>');

            // Disables the restrict enrollments to dates checkbox

            $('#course_restrict_enrollments_to_course_dates').prop('disabled',true);   

            // Disables the Make the syllabus for this course publicly visible checkbox

            $('#course_public_syllabus').prop('disabled',true);   

            // Disables the Make this course publicly visible (student data will remain private) checkbox

            $('#course_is_public').prop('disabled',true);   

            // Disables the Make this course visible to authenticated users checkbox

            $('#course_is_public_to_auth_users').prop('disabled',true);   

            // Disables the Include this course in the public course index checkbox

            $('#course_indexed').prop('disabled',true);   

            // Hides course delete button

            $('a.btn.button-sidebar-wide.delete_course_link').hide();

            // Hides course conclude button

            $('a[href*=\'confirm_action?event=conclude\']').hide();

        }

    }

});

[ianjohnston]

This looks really good however one issue that I am running into is our teachers do have an admin role in our sandbox sub-account (this is so they can create their own courses in the sub-account to play around with). Thus the test of " if($.inArray('admin',ENV.current_user_roles) == -1)" always flags true for them. Would it be possible to have a test to see if the person is a teacher? I tried "if($.inArray('Teacher',ENV.current_user_roles) == 1)" but it is not working. As an alternative would it be possible to say if they are not an admin OR if they are the faculty type of admin then do the stuff?

[chriscas]

Hi Ian,

I think this should do the trick for detecting a teacher role:

if($.inArray('teacher',ENV.current_user_roles) != -1)

Also, based on additional feedback from  @James ​, I modified the code again slightly to hopefully resolve almost all but the rarest timing difficulties (I know he's suggested using MutationObservers as an alternative, but I was definitely having trouble figuring that out on my own over the weekend).  The revised code (for a couple sections only) is:

// Disables start date

$('#course_start_at').prop('disabled',true);

$('#course_start_at').removeClass('date_entry hasDatepicker');

$('#course_start_at + button.ui-datepicker-trigger').hide();

// Disables end date and fixes display flaw introduced by lack of datepicker

$('#course_conclude_at').prop('disabled',true);

$('#course_conclude_at').removeClass('date_entry hasDatepicker');

$('#course_conclude_at + button.ui-datepicker-trigger').hide();

$('[name=\'course[restrict_enrollments_to_course_dates]\'').before('<div class="datetime_suggest"></div>');

James did also suggest some ways to do this that wouldn't take up as many lines, but i left things more broken out so people could add or remove things they don't want in their own code, and to make it easier to read/modify for others in the future.

[ianjohnston]

Thanks for the help. Got it up and running for our set up.

[whitaker_tammar]

This is what was uploaded for us and admins are not able to change the term dates now (everything is greyed out). Any help would be appreciated:

*/

$(document).ready(function(){

  // Checks that current user role is is a teacher, Admins can see the buttons

  if($.inArray("admin", ENV.current_user_roles) == -1) {

  $("input#course_is_public").parent().hide(); // Hide "Make this course publicly visible (student data will remain private)"

  $("input#course_is_public_to_auth_users").parent().hide(); // Hide "Make this course visible to authenticated users"

  $("input#course_public_syllabus").parent().hide(); // Hide "Make the syllabus for this course publicly visible"

  $("input#course_indexed").parent().hide(); // Hide "Include this course in the public course index"

  }

});

$(function() {

  if (window.location.pathname == "/courses/" + ENV.COURSE_ID + "/settings") {

  if($.inArray('teacher',ENV.current_user_roles) != -1) {

  // Disables start date

  $('#course_start_at').prop('disabled',true);

  $('#course_start_at').removeClass('date_entry hasDatepicker');

  $('#course_start_at + button.ui-datepicker-trigger').hide();

  // Disables end date and fixes display flaw introduced by lack of datepicker

  $('#course_conclude_at').prop('disabled',true);

  $('#course_conclude_at').removeClass('date_entry hasDatepicker');

  $('#course_conclude_at + button.ui-datepicker-trigger').hide();

  $('[name=\'course[restrict_enrollments_to_course_dates]\'').before('<div class="datetime_suggest"></div>');

  }

  }

});

[chriscas]

Do your admins also have roles as teachers in those courses?

The "if($.inArray('teacher',ENV.current_user_roles) != -1)" statement in your code will look for users with a teacher role (whether or not they are also an admin) and disable the fields for them.

The statement I use instead for our institution is "if($.inArray('admin',ENV.current_user_roles) == -1)" which checks if the user is an admin, and disables the fields if they are not found to be an admin.

[whitaker_tammar]

Thank you for getting back to me! Yes, our admins also have teacher roles. I tried

Previously:

if($.inArray('admin’, ENV.current_user_roles) == -1)

Currently:

if($.inArray('admin',ENV.current_user_roles) == -1)

And everything is still greyed out for us. I am not sure what is causing this. I tried to use the script offered here: GitHub - lyonsinbeta/canvas-disable-course-dates but it only works for FF and not Google Chrome. Sigh... We really are having a lot of issues with faculty changing the start/end dates on accident and students unable to take their finals or complete work. I wish there was an easier way to lock this down on the admin side.

I think the workaround will be creating an admin account that is not enrolled as a teacher. Thanks for your help! Please let me know if anything else comes to mind.

[chriscas]

One thing to try might be clearing your browser cache after you make changes to the script.  We have had admins also have teacher roles in the past and had no issues with the dual roles.  Maybe there's something else unique about your setup causing the issue, but I can't imagine what.  Do you have other code in your .js file too, or did you paste the exact contents of it before?

[whitaker_tammar]

Yes, we also have additional code I believe for branding and to hide a few other things. I am sure it is conflicting. At least I found a doable workaround for now. I am so happy to have the community as a resource!

[chriscas]

If you want, you could email me (chriscas@umich.edu) your whole .js file and I can try it on our test instance and see what happens.  Maybe I'll be able to spot the problem.  You definitely shouldn't have to have separate accounts for this to work right.  My guess is that there's just a typo or something simple like that causing the issue).

[whitaker_tammar]

Thanks! I will send an e-mail now. I am definitely not an expert in js.

[swatts]

Does this keep the box checked? I am finding that when a course is imported from Commons, the box unchecks.

[chriscas]

Hi  @swatts ‌,

Unfortunately, this code will just prevent modifications from being done on the course settings page.  When importing from other courses or commons, there are certain scenarios that still modify the course dates.  I don't think it's very feasible to address those scenarios with Javascript, but I'm certainly hoping Instructure will consider adding a permission to control who is allowed to modify the course dates, as that seems like the ultimate solution to these issues.

I do have a separate script (vbscript housed in an Excel file with some other things I need on a semi-regular basis) that I manually run a few times per semester.  This script iterates over all courses in a chosen term , checking that the dates match term term settings, and fixing them if they don't.

-Chris

[swatts]

Thanks!

Our school operates by course start and end dates, not by terms. It would be nice if that box was part of admin settings and not course settings.

-Susan