Change behavior when changing dates in a datepicker group to be more intuitive. #2583
Conversation
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
8391a24 to
13afbcf
Compare
|
Overall this is what I was asking for in #2581, though I may have not been clear enough there. I just wanted user input to always be honored and the other dates updated based on that. In testing, this doesn't seem to be fully working for me, as the open date is never being adjusted under any of my tests when it should. My tests are to set all the dates (open, reduced, close, answer) to be the same. Then when I set the answer, closed, or reduced date to be an earlier date, the open date isn't updated (all the other dates are updated appropriately though). |
|
The open date updates when I test it. 😜 |
|
You did see that I added another commit after you made the comment? |
|
Yea, I saw the fix, I tried to figure out why the open date was being ignored, but missed the loop index needed changed. |
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
d6c0d02 to
267a826
Compare
|
I seeing the following behavior with the date picker and setting the dates for individual user(s). Go override the dates for a single user, set all the dates to the same date in the future (I'm using a full year). Then delete the 'close' date. When this happens the reduced scoring and open date are reset, but they aren't rest to a valid date corresponding to the set close date. Here is a screen shot.
To me the dates should have reverted to |
|
Note, setting all the dates to some date over a year in the past, and deleting the open date, does reset the reduced, close, and answer date to equal the open date of the set, so I wasn't able to reproduce any issue with updating the dates in the other direction. |
|
Are you testing with this pull request? I just tested with this pull request and used the exact dates shown in your screen shot, and I don't see that. When I delete the close date, the open and reduced scoring dates are then set to |
|
Yes, I'm testing with this PR. Wonder what other settings in my set could be causing the problems. |
|
Oh, I think I figured it out. I have previously overridden the close/answer date for this set/user to be |
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
c003744 to
28557d8
Compare
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
28557d8 to
dd069f7
Compare
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
dd069f7 to
9a725b0
Compare
|
@somiaj: I pushed a change that should address the issue that you saw. Basically, instead of falling back to the user's previous override when a date is deleted, it falls back to the course's date. |
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
2 times, most recently
from
aabf37a to
43d34a7
Compare
…intuitive. Previously when any of the dates were changed, the open, reduced scoring, close, and answer dates were ensured to be in the correct order by always changing the input later in the last to a later date if needed. This instead acts on the input that was modified. That input value is not changed from what the user just changed it to. Any earlier inputs in the list are set to the new date in the changed input if they are later than that date, and any later inputs in the list are set to the new date in the changed input if they are earlier than that date. This is to address issue openwebwork#2581.
Previously the open date was never acted on, and so the for loop started at one which skipped the open date. Now it needs to be acted on.
When using the "Today" or "Now" buttons, the "changed" class is not being added to the input. When the handlers for those buttons are called, the "change" event needs to be triggered so that this happens.
drgrice1
force-pushed
the
datepicker-group-update-tweak
branch
from
43d34a7 to
fc659e1
Compare
|
Tested and I get the desired behavior. I'm not entirely following the finer point that was discovered if there is a previous date override. I will approve this and invite @somiaj to merge it if that issue is also resolved. |
|
Great, this works well in this case now. Thanks for looking into that last minor issue. |
Previously when any of the dates were changed, the open, reduced scoring, close, and answer dates were ensured to be in the correct order by always changing the input later in the last to a later date if needed.
This instead acts on the input that was modified. That input value is not changed from what the user just changed it to. Any earlier inputs in the list are set to the new date in the changed input if they are later than that date, and any later inputs in the list are set to the new date in the changed input if they are earlier than that date.
This is to address issue #2581.