Fill in empty dates with valid dates for date picker groups.

[drgrice1]

This builds on #2348, and was requested by @Alex-Jordan in that pull request (see #2348 (review)).

This makes it so that if a date is not filled in, then it will be filled by javascript with a date as needed to ensure it satisfies the usual date requirements on open, reduced scoring, close, and answer dates.

The class value is taken into account for this when editing a set for users.

This applies on both the problem set detail page and the user detail page. This javascript is also used on the sets manager page when editing set dates where this change does not apply, but it is designed to still work without conflict there.

[drgrice1]

Note that once #2348 is merged you will see that there is not much to this pull request. Or just look at the last commit.

[pstaabp]

We have those variables $pg{assignOpenPriorToDue} and $pg{answersOpenAfterDueDate} that are updatable in the Course Configuration. I know those are variables in pg, but can we pass them to the javascript to do the filling of the due and answer dates and maybe set the reduced scoring to the due date?

[drgrice1]

It does not make sense to use those variables in the JavaScript. Those are used to set the dates initially when an assignment is created. This for a global set, the changes made here are overriding those things, and the JavaScript should not presume otherwise. When editing a set for users, the values from the global set are used, and those variables also should not override that.

[pstaabp]

Works well.

[Alex-Jordan]

I'm getting some strange behavior with this. I'm using Firefox, in case that matters.

• In Instructor Tools, I select a student and click to "Edit assignments and dates for one user"
• There is a set with coursewide Open/Close/Answer: 6/19/23, 11:59 PM, 6/26/24, 11:59 PM, 6/26/24, 11:59 PM
• I click inside the override field for the close date, and type "4/1/25".

I'm not sure what I should expect at this point (not having entered a time) but when I click outside of the input, it changes to "4/6/24, 12:00 AM".

[drgrice1]

The same thing happens with develop and WeBWorK 2.18. So that is not this pull request. That is because the date doesn't parse in the required format.

[drgrice1]

This now changes the way that the fallback behavior works to address what @Alex-Jordan observed.

Currently if a date is entered into a datepicker input that does not parse with the format of the current locale (for example if a date is typed without a time), then a fallback is filled in. That fallback is the last displayed valid value if there was one. If there was an intial value in the input, then that fallback will initially be the input's initial value. It is then updated anytime a new valid value is entered. However, if there was no initial value for the input, the fallback ends up being set to the last visible date in what is shown when the calender popup opens. That is sommewhat unexpected behavior.

So this changes the way that the fallback works. If there is an initial value for the input (as will be the case when editing a set for the whole class), then that is still used for the initial fallback. However, if there is no initial value (as will be the case when editing the set for users), then the class value is used. In any case, the fallback will be updated to be the last valid value that is entered after that.

There is a last case in which the input does not have an initial value and there also is no class value. In that case the fallback is the current date and time. This usually won't be used on the set detail page, but applies to the import date shift input on the set list.

[Alex-Jordan]

Thanks for that refinement. Works for me. Since @pstaabp only tested the other aspect of this PR I'll let him test again before merging (or let someone else test).

[pstaabp]

Tested again. This still looks good to me. Will merge.