Invalid Summary Type crashes SIPServer

[Thomas Berezansky]

When a Patron Information Request is made via SIP2 there is a 10-position "Summary Type" field. A 'Y' in a position indicates what kind of summary information is returned in the response.

The standards only describe, and thus we only implement, 6 slots, the last 4 likely being for future expansion.

Currently if you stick a 'Y' in one of the last 4 slots SIPServer errors out when it tries to run code that doesn't exist and/or iterate over an arrayref that isn't defined later. At least one vendor I know of has been requesting slot 7 (in previous revisions, "fee items" with no field to return them in defined) and wondering why they are timing out (when SIPServer has crashed). They claim that other systems respond to the request.

The branch below adds a new check to MsgType.pm to ensure that we have a definition for the summary type requested *and* the patron module returned something other than "undef" on the "can" check for that type. If either is false it pretends that no detailed summary information was requested.

http://git.evergreen-ils.org/?p=working/SIPServer.git;a=shortlog;h=refs/heads/user/tsbere/ignore_invalid_summary_request

[Galen Charlton (gmc)]

I've confirmed both that the bug exists and that the patch fixes it, so I've pushed the patch to master.