renew and edit due date features do not calculate correctly in web staff client

[Sally Fortin]

The renew and edit due date features do not calculate correctly in web staff client. The date is incorrect by one day. For example,select November 5, 2014 as the new date and it records it as November 4, 2014. The same problem occurs when you check out an item with a specific due date or you edit the due date of a checked out item. See screencast at https://drive.google.com/file/d/0B74gDMUDwDXqSzdhM05aLVdfTjg/view?usp=sharing

[Victoria Lewis (vlewis-q)]

Add code to correctly calculate renew and edit due dates.
Correct for date picker time zone offset.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/vlewis/lp1437109-calculate_renew_edit_due_date

[Mike Rylander (mrylander)]

While there are obviously issues with the code as-is (date vs due_date in args), this will likely be impacted by bug 1485374, which adds timezone awareness to the client and server. I think we should reassess this once the patches on that bug and the OpenSRF one linked from it are evaluated.

[Terran McCanna (tmccanna)]

Update: As of 12/23/2015, I'm no longer able to edit due dates - the pop-up window opens and I can edit, but I cannot save. The window stays open and does not update the circulation.

[Kathy Lussier (klussier)]

I can confirm the behavior Terran reported on the Items Out tab of the patron record.

The 2.10 deadline is nearing, and a fix for this bug is necessary before libraries can start using the web client in production.

Mike, I haven't seen any movement on bug 1485374. Do you know if anyone is actively testing that bug and if it is likely to be included in 2.10? If yes, do you know if it will be done in enough time for Victoria or another developer to do the work required for this bug?

If it doesn't look like the time zone awareness bug going in for this release, can you provide some feedback to Victoria on what she needs to do to clean the patch up?

[Mike Rylander (mrylander)]

Kathy,

The movement on bug 1485374 has been behind the scenes, but as Galen mentioned in IRC, it's been rolling along. Which server(s) have shown the inability to edit a due date? Just webby?

Thanks!

[Kathy Lussier (klussier)]

Hi Mike,

Thanks for checking in! I see this behavior on webby and on Dyrcona's dev server.

On both servers, if I enter a specific date for a checkout (e.g. 06/01/2016), the due date will fall on the day before (5/31/2016). The same thing happens if I use the Renew Items interface or if, from the Items Out tab, I renew the item with a specific due date.

On both servers, if I simply edit the due date from the Items out tab, I am unable to submit the date. The popup stays on the screen an doesn't allow me to save.

[Michele Morgan (mmorgan)]

Just a comment while work is progressing on this: The edit due date function needs to work with hourly circulation intervals as well as daily intervals.

[Jason Stephenson (jstephenson)]

I can confirm what Kathy reports in Comment #6. I've tried in both Firefox and Chromium.

I might give fixing that behavior a go as an extension of Victoria's branch in comment #1.

[Jason Stephenson (jstephenson)]

Victoria’s branch no longer applies cleanly to master. It modifies code in Open-ILS/web/js/ui/default/staff/services/ui.js that was apparently removed. These are the modifications that adjust the date with the timezone offset. When I cherry-pick the changes and delete the conflicting code, the due date saves in edit due date, but it is still 1 day behind.

I also tried this branch with the changes in the branches on the LP bugs referenced in the comments above. The results were the same. It appears that this branch needs a rebase and some changes.

I'm looking into this in the context of working on bug 1552778, so might try my hand at coming up with a solution.

[Terran McCanna (tmccanna)]

Is there work currently being done on this?

I'm testing in the 2.11 web client right now and I can't edit due dates at all (I can select a new date, but clicking OK does nothing).

[Kathy Lussier (klussier)]

Noting that this bug also affects backdated check ins. Also adding another data point. When I checked in item out or renewed an item with a specific due date this afternoon, the system stored the date correctly. When I performed the same tasks this evening, I saw the one-day difference. I'm guessing this discrepancy is related to time zone issues.

The issue where you cannot save the due date when editing an existing checkout from a patron's account is also still a problem. Not sure if that should be a separate bug.

[Kathy Lussier (klussier)]

I'm going to file a separate bug with the 'Edit Due Date' form not working correctly since it's a separate issue from the way dates are being calculated. That problem is now reported in bug 1657466.

[Kathy Lussier (klussier)]

Bug 1485374, the time zone branch, appears to have resolved this issue. The edit due date form still does not store the entered time correctly, but this is the subject of bug 1552778. I'm going to mark this bug as a duplicate of 1485374.