Web client check-out "specific due date" should also include times

+1 to having the ability to set a specific time is required for academic libraries.

In the implementation of this functionality, it might make more sense to separate out the date and time, rather than jamming it all into a single field, similar to what the XUL client currently does (see attached screenshot).

Public libraries use hourly circs as well, sometimes in fairly creative
ways, so it would be useful to public as well.

On Thu, Mar 3, 2016 at 11:27 AM, Dan Scott <email address hidden> wrote:

> +1 to having the ability to set a specific time is required for academic
> libraries.
>
> In the implementation of this functionality, it might make more sense to
> separate out the date and time, rather than jamming it all into a single
> field, similar to what the XUL client currently does (see attached
> screenshot).
>
> ** Attachment added: "Screenshot of XUL specific date / time picker"
>
> https://bugs.launchpad.net/evergreen/+bug/1552778/+attachment/4587574/+files/specific_due_date.png
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1552778
>
> Title:
> Web client check-in effective date should have a configurable format
>
> Status in Evergreen:
> New
>
> Bug description:
> As an academic library that circulates certain materials for a few
> hours at a time, we would like to be able to backdate checkin to a
> certain time. However, the web client only allows an effective date
> in the form "yyyy-MM-dd" (we would prefer "yyyy-MM-dd HH:mm" for our
> local context). When I change the library setting "GUI: Format dates
> with this pattern" to "yyyy-MM-dd HH:mm", the checkin still only
> recognizes dates in the format "yyyy-MM-dd" as being valid times for
> backdating purposes.
>
> Note: I don't believe that the ability to backdate to a specific time
> exists in the XUL client either.
> Note: I tested this on the webby version of the web client
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1552778/+subscriptions
>

+1 to separating out the date and time on this interface *and* the checkout interface on the Web client. I just looked at checkout and it also only accepts due dates, not due datetimes.

Upon further exploration, if you pull up a patron who has items checked out, you can edit the due date. That screen includes a time picker as well as a date picker. So it seems like that time picker (as well as any needed logic) could be integrated into the standard checkout and checkin screens.

And exploring some more. :-)

Renewing items (either through "Circulation > Renew" or the patron record) also should have a time picker.

Adding a note that, although the Edit Due Date function in the patron record has a time picker, it does not successfully store the time. The due time remains as 12 a.m.

I added the tag webstaffblocker, because we often wish to extend a due time on one of our hourly checkouts by a few hours. This is possible in XUL, but not in the Web staff client.

Note: there is now proposed support in the date/time widget for context-dependent time adjustment, where if (for example) a circ duration is hourly it can be made to show the time, but not otherwise. This is new with the Emergency Closing Handler code on bug 1766716.

A note that comment #6 is now its own bug: https://bugs.launchpad.net/evergreen/+bug/1789442

Patches to add a timepicker to the specific due date input on the webstaff checkout page are available in the branch user/gmcharlt/lp1552778_webstaff_hourly_loans:

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

Some things to note:

[1] This branch also includes a patch for bug 1789442.
[2] This branch is surprisingly invasive, as it includes a fix for clean[se]_ISO8601 to copies it over from OpenSRF to Evergreen. Consequently, while I have added rel_3_0 and rel_3_1 targets, I recommend that it /not/ be backported until there's been some production use of 3.2.x.

Since setting a specific time for checkins is not present in XUL, it's more of a wishlist item that I've split off to new bug 1793817.

I did some light testing on this branch following the test plans in Galen's commit messages. Checking out items with hourly and daily circ rules, both with and without using the specific due date picker, worked as expected. However, I encountered some issues.

1. When running make check, I did encounter failures with 14-OpenILS-Utils.t.

t/14-OpenILS-Utils.t .......................... 7/43 Cannot determine local time zone
# Looks like your test exited with 2 just after 41.
t/14-OpenILS-Utils.t .......................... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/43 subtests

Test Summary Report
-------------------
t/14-OpenILS-Utils.t (Wstat: 512 Tests: 41 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan. You planned 43 tests but ran 41.
Files=25, Tests=3236, 22 wallclock secs ( 0.68 usr 0.07 sys + 18.92 cusr 2.96 csys = 22.63 CPU)
Result: FAIL
Failed 1/25 test programs. 0/3236 subtests failed.

2. Working on a laptop with a resolution of 1366x768, the Submit button is falling below the barcode entry box. See the screencast at http://www.screencast.com/t/rSBAqnRE2bwN. It appears as if the specific due date options have shifted a bit to the left. Since the time picker appears below the due date picker, I think these could shift back to the right to make more run for the barcode entry box.

3. When I scan items to checkout, the details no longer immediately populate the grid row in the check out tab. However, if I move to another tab, like Items Out, and then return to the Check out tab, the details appear.

Thanks Galen!

> 2. Working on a laptop with a resolution of 1366x768, the Submit button
> is falling below the barcode entry box. See the screencast at
> http://www.screencast.com/t/rSBAqnRE2bwN. It appears as if the specific
> due date options have shifted a bit to the left. Since the time picker
> appears below the due date picker, I think these could shift back to the
> right to make more run for the barcode entry box.

The shift to the right was intentional, as adding the timepicker had
(to my eyes) the effect of making the specific time controls look
disconnected from the barcode entry widget. I'll experiment some more
with the layout.

I've pushed follow-up patches to the branch to address #1 and #2. I'm seeing #3 as well, but in master, so I will open a separate bug report for that.

Thanks Galen! The test now passes for me and the layout on the check out tab is improved. I was also able to confirm that #3 is indeed an issue in master without this code.

I've signed off on the changes and merged them to master for inclusion in 3.2. I'll leave the 3.1 target open in case we want to backport it once it's gotten some production use. Since 3.0 is nearing its end of life, should we set that target to Won't Fix?

This has had enough road testing in 3.2 now, so backporting to 3.1.

Has this been tested on 3.1? I tried backporting it locally and it looks like Galen's branch alone is insufficient -- the time picker doesn't show up. I wonder if it depends on the fix for bug 1766716, which makes some changes to the date/time picker; that fix is only in 3.2+.

I confirm that it doesn't work for me in a 3.1.13 system. Including commit b46d4eaac2a6b023c2cde2a1642ef61cb8206548, or at least the parts of it related to the timepicker may be sufficient to complete the backport.

Backporting that specific commit didn't make the time picker work on my 3.1.7 test system, but I think we're on the right track. I hope to take a closer look next week.

Working branch user/jeffdavis/lp1552778_time_picker_rel_3_1 contains a fix that seems to work in our 3.1.7 environment when applied on top of Galen's branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=b558e2c4

I haven't had a chance to test this on a clean 3.1 install yet.