SIP support workstation option at login

[Bill Erickson]

It should be possible to specify a workstation for SIP logins. This is especially useful for running reports on payments by workstation and having it properly report on SIP Fee Payments.

I propose an additional attribute in the oils_sip.xml configuration file, like so:

<login id="username" password="password" institution="someplace" workstation="BR1-sip-123"/>

This allows for a different workstation per login.

[Jason Stephenson (jstephenson)]

I am not a fan of the proposed solution, but given that we have to work with 3rd party vendors, I can't think of anything better.

I actually came here to shoot your proposal down, but after starting a response, I actually can't think of any other way to do it given our constraints.

[Jason Stephenson (jstephenson)]

The reason that I'm not a fan is it would lead to a proliferation of sip2 accounts in the database and in oils_sip.xml. For instance, if library X has 5 selfchecks, that means 5 sip2 accounts.

As long as the attribute field is ignored if not present, i.e. doesn't throw an error, I'm OK with it.

[Jason Boyer (jboyer)]

I think most vendors allow you to set the "location code" field on the login message (field CP on message 93), if this value is set to a workstation name, it could be cached with the authtoken for the session. It's almost even in line with the intended purpose of the field.

[Jason Boyer (jboyer)]

I forgot to mention in that comment, this would allow you to get by without having multiple sip logins, all workstation information would be entered in the sip client, not oils_sip.xml

[Bill Erickson (berick)]

Good point, Jason. I could imagine supporting both. The config option is useful for clients that cannot pass a "location code" value (or pass a bogus value) for whatever reason and it's easy enough to ignore if you don't need it.

Note: some messages already look for a "location code" value (checkin comes to mind), which contains an org unit shortname, so we'll need to ignore that value and use the org unit value from the workstation instead when a workstation is specified.

[Jeff Godin (jgodin)]

Some various notes on SIP2 location-related fields from earlier conversations/research can be found here: https://docs.google.com/document/d/1MuGva1c4Wd_-oog9yI5lz9ySB80nu8-2BmVP9bIgEyk/edit

[Jason Boyer (jboyer)]

I've added support to SIPServer to send the Location (CP) field when signing in (LP 1579144) and here's a patch to make use of this in Evergreen: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1259196_sip_workstation

To test you'll need a SIP client that allows you to specify the Location (CP) field on login. (This is distinct from the Institution ID and is unique to the Login (93) message) You'll also want to log at INFO or lower to verify the results.

Testing:
Pre-patch:
Sign in with the CP field empty.
Perform one or more circulations.
No workstation will be set when looking at the logs or the circulations.
Set the CP field to the name of an existing workstation and repeat the above steps. The results will be the same.

Post-patch:
Sign in with the CP field empty.
Perform one or more circulations.
No workstation will be set when looking at the logs or the circulations.
Set the CP field to the name of an existing workstation and repeat the above steps. In the logs the workstation will be shown when the client logged in, and the workstation id will be present in the action.circulation rows.

NOTE: Currently, if you supply an invalid workstation name the connection will just fail. This is the same thing that happens if the account is allowed to go inactive. If using a workstation isn't desired, configure your selfcheck to leave the Location field blank or not send it at all.

[Mike Rylander (mrylander)]

I like Bill's idea of supporting both client and server location codes. Please see bug 1579144 for details, where I've added support for a <location_code> element to hold the workstation name for Evergreen.

Regardless of my addition going it, I plan to pull this into master for 2.11.

[Mike Rylander (mrylander)]

This is now in master. Thanks, Jason!