Move code that connects to ILS back end out of
sip_protocol_loop() and into handle_login().  This way, if
there's a problem loading or initializing the ILS implementation,
the client will be told that login failed, rather than
"successfully" logging in and then having the server die later.

Test logging in with invalid username and invalid password

Log both raw input and raw output messages.

Zero-pad the checksum that we transmit.

Cope with trailing whitespace on the titles returned from the
ILS, since that seems to be a problem for PINES

Properly transmit the patron's fee amount and currency.  Make a
note of the missing limit fields until the OPAC supports them.

Tighten up test for value of the BX field in the ACS status message

Added missing value for whether the server supports the SC/ACS
resend messages.

Transmit screen message and print line in Patron Information
Response messages.

Go back to using unpack to generate the checksums, except that
I'm using the 'U'TF encoding instead of the 'C'har encoding.
This seems to work, at least in my test environment.

Add test case for checking titles that have a diacritical in the title.

Add entry to "catalogue" that has a diacritical in the title, for
testing the checksum algorithm.

Replace idiomatic perl checksum code, which seems to fail on
strings with diacriticals in them, with an explicit sum of the
ordinal values of the characters in the string, which seems to cope.

Make two shut down messages different, to simplify debugging

Use correct boolean format for 'OK' field of Checkin Response
message.

Don't rely on clients sending the exactly protocol strings '1.00'
and '2.00'.  Anything that starts with a '1.' is a "revision 1"
protocol string and anything that begins with a '2.' is a
"revision 2" protocol string.  That way, when a clients reports
that they support protocol revision '2.0S', we will properly
react and send revision 2.00 messages.

Allow clients to violate the protocol specification by not
sending and SC Status message first after they log in.  This
should work fine for SIP Login clients, but clients that use
telnet to log in MUST send an SC Status message, or they'll be
trapped using SIP rev 1.00.

Add support for protocol extension 'Patron Internet Profile' with
protocol field code 'PI'

Adjust tests run for OpenILS.

Accept either 'other' or 'available' for circulation status.

Parameterize the "Renew All" tests, even though they don't run on
Evergreen right now.

Added target to run just the Evergreen-compatible tests

Basic instructions for running tests

Basic installation README

Initial system integration with Evergreen code.

It's not "FID_CHARDED_ITEMS_LMT", it's "FID_CHARGED_ITEMS_LMT"

Rewrite so that each message is a single test, which might fail
in one of several different ways, rather than counting all of the
various checks performed on each message as a separate test.
This reduces the number of "tests" counted from over 1000 to less
than 100, but the same number of things is being tested.

Add code to check out two items and confirm that both are renewed.

add code to check item out, rather than depend on the fact that
another test case checked it out for us.

clean up by cancelling the second user's hold.

Add code to check item in when done testing.

fix handling of hold_queue, add second item to DB to test
renew_all

fix handling of Item::hold_queue

Add tests for Invalid patron password and invalid patron id

FID_PATRON_PWD is a valid field in a "Renew All" message.  Also
fix handling of failure status returned from ILS::renew_all.

Check patron password in ILS::renew_all

Add test for attempting to renew item that has outstanding
holds.

Fix definition of Item::available to eliminate warning message

Change definition of Patron::available to test to see if the item
is available for a patron, rather than just available in
general.

Add tests for invalid patron and invalid item

Test for a blocked patron attempting to check out a book

Fix ILS::checkout to handle more error conditions properly (but I
still can't cope with Bob attempting to check out a book that
Alice already has out.

Test renewing an item that's identified by title rather than by
item id.

Add code to renew items that are specified by title, rather than
by item id.  This is very odd, but the spec seems to allow it.

Define an empty array of fields to be checked in the responses
for those messages that don't require any field checking.  This
eliminates "TODO" failures from the test harness.

Test that when a second hold is placed on an item, the queue
position is properly reported.

Add second patron to stub ILS, to test multiple holds on an
item.

Generalize configuration of Net::Server::PreFork to allow for
arbitrary configuration parameters.

Clean up after the test is completed by checking the item back
in.

Minor cleanup: be consistent in use of "LOG_" in syslog levels.

Initial tests for Item Information message

Extend reporting of circulation status

Initial test for Renew All

text fields in the response messages may be empty

Add support for the configuration parameters

    <min_servers value="N" />
    <max_servers value="N" />

which parallel the paramters for Net::Server::PreFork.

write_msg() is used by both the server and the test suite.  In
the test suite, we don't want to call syslog, so only call syslog
if we're writing the message to stdout (which only happens in the
server).

Fix check renewal permissions check

Initial set of tests for Renew

Fix minor bugs in error condition for Renew Response

Initial test suite for Checkin

Confirm the actual title of the item being held

Only attempt to add the Patron ID to the Checkin Response message
if the ILS actually provides a valid $patron structure

Add a bunch more tests

minor fixups for hold management

Hold messages can have a patron password in them

Initial test case

Add more tests

I'm beginning to wonder how many times it'll take me to get the
password check right.  But this time I actually ran it through
the test harness before checking it in.

add missing value to debug message

Get the test right for checking the patron password in
handle_patron_enable()

Initial set of tests

Fix bugs in Patron Enable: A valid patron with an invalid
password should generate a true patron status message, but
shouldn't enable the patron.

Fix language handling in Block Patron: return the patron's
language, rather than sending 'unknown'.

Initial set of tests for Checkout Response

Eliminate warning message for uninitialized variable use

Fix spelling mistake

Fix handling of the "renewal ok" status field in the ILS

Finish first pass at ILS::Patron documentation

Initial, incomplete, documentation for ILS::Patron

Missed an unused function in the last code cleanup

Code cleanups

Initial pass at documentation for ILS::Item

Delete unused access method

Add code to build HTML documentation from the podfiles.

Finish first pass at documentation for ILS module

Minor code cleanups

Adjust tests to agree with the code.  Since the server reports
that a patron is valid, but the password was wrong, we need to
make sure that that's what the tests expect.

Sequence numbers are a single digit, so when it hits 10, wrap
around to 0.

Adjust the test data so that it works with the test cases.

If the patron is valid, but the patron password is provided, and
wrong, still report that the patron's good.  This seems to be
what clients are expecting, and since we can "trust" them, we
will give them full disclosure.

'0' is a valid sequence number (it comes after '9'), so we have
to see if the sequence number is set, not just if it's true.

minor cleanups

Add a bunch of tests, and stock field checks

Make sure to set BL: Patron Valid when the patron is, in fact,
valid (uncovered by the tests)

Fix formatting, export FID_PATRON_BIRTHDATE FID_PATRON_CLASS

Add support for FID_PATRON_BIRTHDATE (PB) and FID_PATRON_CLASS
(PC) to Patron Information Response, for Envisionware terminals.

Add stub methods sip_birthdate and ptype, to support Envisionware
terminals (and probably others).

Change port for raw socket connection from 5300 (chosen at random
by your's truly) to 6001, as per Envisionware email.

Very basic tests.  This will be a big test case.  I suspect that
the test harness will have to be enhanced in a variety of ways,
including some way of indicating fields that SHOULD NOT appear,
as well as just fields that are required.

Generalize handling of tagged fields, so we can reuse field
specifications between test scenarios.

Fix Patron Information message handling to parallel the situation
in the handling of Patron Status messages: if the password's not
provided by the terminal, then we don't worry about checking the
password, but if the terminal gives us the password, then it has
to match before we say anything about the patron.

Replace call to nonexistent method 'hold_items_count' with
correct code.