selfcheck receipt can break on processing hours of operation

Bug #793627 reported by Jason Etheridge on 2011-06-06
This bug affects 7 people
Affects Status Importance Assigned to Milestone

Bug Description

In trunk and 2.0.2, in the selfcheck interface: http://hostname/eg/circ/selfcheck/main, when you click logout, a receipt is generated via an action/trigger template, along the lines of request open-ils.circ open-ils.circ.fire_circ_trigger_events "7d64510d521dac6f0dbb6b5da5f9033d" "1" null "format.selfcheck.checkout" "print-on-demand" [1] [{"renewal_failure":null}]

The template is "Self-Checkout Receipt" (action_trigger.event_definition with id = 10)

The error is an uncaught exception, No receipt data returned from server. The actual result is an atev object with a state of error. This happens consistently for me in my trunk environment, but sporadically with one library's production 2.0.2 environment.

A pertinent error in the logs is [2011-06-06 11:54:14] open-ils.trigger [ERR] Error processing Trigger template: date error - bad time/date string: expects 'h:m:s d:m:y' got: ' 1/1/1000'

This is coming from the Library Hours div in the template. If we remove that div, no errors.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Low
Robert J Jackson (rjackson) wrote :

Library reporting this same error in 2.1.1. The problem only occurs if more than 1 item checked out prior to selecting the Logout option to print the receipt. For only 1 item out the receipt (and hours) print.

Ben Shum (bshum) wrote :

Confirmed that the div for hours of operation is the culprit in our selfcheck receipts too. Going to ponder this one some more...

Changed in evergreen:
importance: Low → Medium
milestone: none → 2.4.0-alpha
Ben Shum (bshum) on 2013-03-03
Changed in evergreen:
milestone: 2.4.0-alpha1 → 2.4.0-beta
Ben Shum (bshum) on 2013-03-17
Changed in evergreen:
milestone: 2.4.0-beta → 2.4.0-rc
Ben Shum (bshum) on 2013-04-27
Changed in evergreen:
milestone: 2.4.0-rc → none
Dan Scott (denials) wrote :

From IRC, Bill Erickson noted that the problem likely stems from hours of operation not being set for a given library.

One could do something crazy to populate the hours of operation by default, like:

INSERT INTO actor.hours_of_operation (id, dow_0_open, dow_0_close, dow_1_open, dow_1_close, dow_2_open, dow_2_close, dow_3_open, dow_3_close, dow_4_open, dow_4_close, dow_5_open, dow_5_close, dow_6_open, dow_6_close) SELECT id, '05:00'::time, '20:00'::time, '05:00'::time, '20:00'::time,'05:00'::time, '20:00'::time,'05:00'::time, '20:00'::time,'05:00'::time, '20:00'::time,'05:00'::time, '20:00'::time,'05:00'::time, '20:00'::time FROM actor.org_unit;

On the other hand, it would probably be much smarter to just enhance the template to check for a valid set of hours of operation - and if not there, just skip that chunk of the template gracefully, rather than the... ungraceful... alternative.

Bob Wicksall (bwicksall) wrote :

We are getting the same error on 2.2.1.

It is caused by missing hours of operation but not how you would expect. On my live and test system I can checkout odd numbers of items and the receipt will print. If I checkout an even number of items the system hangs trying to print the receipt.

I added the following to the template to debug:

[% USE Dumper(Indent=0, Pad="<br>") %]
[% Dumper.dump(target) %]

When I checkout an odd number of items I get the the full list of hours:


When I checkout an even number of items I get the following for the hours:


Just a single time is returned and no bless([ ]) wrapping it.

Robert J Jackson (rjackson) wrote :

We were lucky at Evergreen Indiana Consortium as all sites currently using selfcheck agreed on removal of the hours of operation from the template. If you create a consortium level template without the hours of operation then the receipts will be OK.

Ben Shum (bshum) on 2013-08-22
no longer affects: evergreen/2.2
Kathy Lussier (klussier) on 2014-09-02
tags: added: selfcheck
Jennifer Pringle (jpringle-u) wrote :

This continues to be a problem in 2.9.

no longer affects: evergreen/2.4
no longer affects: evergreen/2.3
no longer affects: evergreen/2.9
Jason Stephenson (jstephenson) wrote :

I can confirm this on 2.10.7, and I assume it is an issue still in 2.11, so adding targets to reflect that.

I suspect that I may be tasked with fixing this sooner or later, but I will not assign the bug to me until I am asked to fix it.

Changed in evergreen:
milestone: none →
Changed in evergreen:
milestone: → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers