Bug 9138 - SIP2 failing to mark reserves waiting, and sending blank emails
Summary: SIP2 failing to mark reserves waiting, and sending blank emails
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-25 22:19 UTC by Chris Cormack
Modified: 2014-05-26 21:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 9138 : SIP2 passing incorrect itemnumber to ModReserveAffect (2.04 KB, patch)
2012-11-25 22:23 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2012-11-25 22:19:49 UTC
The itemnumber was not being passed correctly to Koha, resulting in blank emails being sent to people. Also reserves were not being marked waiting.
Comment 1 Chris Cormack 2012-11-25 22:23:56 UTC
Created attachment 13662 [details] [review]
Bug 9138 : SIP2 passing incorrect itemnumber to ModReserveAffect
Comment 2 Colin Campbell 2012-11-27 15:10:43 UTC
As a note I was having a problem with blank emails for holds on return in SIP devices. Problem was that db handles stored by C4::Letters had gone stale. The crude caching in letters is a bit suspect as it doesnt check handles are still valid (unlike C4::Context) and the db could cache more effectively. But its worth being aware of when looking at this
Comment 3 Chris Cormack 2012-11-27 19:57:44 UTC
Thanks Colin, I'll check that out also.
Comment 4 Chris Cormack 2012-12-11 02:15:34 UTC
Yep that is definitely a problem, ill send a follow up to fix that.
Comment 5 Chris Cormack 2012-12-11 02:37:13 UTC
The problem code is in C4::Letters around line 555

We do this
# check cache first
(defined $handles{$table}) and return $handles{$table};

We just return an $sth for the table, not knowing if it is still even connected to the database, so you end up with a bunch of this


DBD::mysql::st execute failed: MySQL server has gone away at 
               /usr/share/koha/lib//C4/Letters.pm line 523.

DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at 
               /usr/share/koha/lib//C4/Letters.pm line 526.

And blank emails being sent, because the parsing isn't done
Comment 6 Chris Cormack 2013-06-26 03:44:29 UTC
Did you mean to mark this resolved fixed? If so, what fixed and where?