Thank you very much, Josh!
Now it is a bit clearer to me why we haven't seen anything in the SIP2
settings within the staff client as these would probably be the ones
used by SIP2 Mediator rather than by the SIP2 server mentioned in the
official documentation
<https://docs.evergreen-ils.org/docs/latest/admin/sip_server.html#_installing_the_sip_server> (which
we followed when trying to make it all work; it is great that new
sections about SIP2 Mediator and about filters have now been added
<https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fb4959fec943baf9ef1057354b0e5e17634139ec>
:-)!).
We will try to test it and then report back.
Linda
On 11/19/25 15:47, Josh Stompro wrote:
I think the original sip2 server uses the evergreen code under
Open-ILS/src/perlmods/lib/OpenILS/SIP/
In this spot there is logic that approximates the hold_pickup_date if
the item is still in transit.
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/SIP/Item.pm#L391
So you could test with an item in transit to fill a hold and an item
on the hold shelf and see if the output is any different.
Ah, ok so /OpenILS/Application/SIP2 is part of the newer Sip2 server -
Sip2Mediator - https://github.com/berick/SIP2Mediator
https://bugs.launchpad.net/evergreen/+bug/1901930
So you could also give that a try and see if the problem still exists
there? I haven't run that one yet so I don't know what would be involved.
Here is the perl module where the hold_pickup_date is pulled for the
newer Sip2 Server.
https://gitlab.com/LARL/evergreen-larl/-/blob/main/Open-ILS/src/perlmods/lib/OpenILS/Application/SIP2/Item.pm#L106
It doesn't look like the new Sip2 server tries to approximate the hold
pickup date for items in transit like the original code does.
Josh
On Wed, Nov 19, 2025 at 12:54 AM Linda Jansová
<[email protected]> wrote:
Thank you very much, Josh!
Linda
On 11/18/25 22:49, Josh Stompro wrote:
Hello Linda,
I think the intention was for the hold pickup date to be in SIP
format going by.
https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l194
188
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l188>
Returns the location of C<$patron_id> in the hold queue for the
189
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l189>
item, with '1' indicating the next person to receive the item. A
190
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l190>
return status of '0' indicates that C<$patron_id> does not have a
191
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l191>
hold on the item.
192
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l192>
193
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l193>
=item C<$date = $item-E<gt>recall_date>
194
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l194>
=item C<$date = $item-E<gt>hold_pickup_date>
195
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l195>
196
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l196>
These functions all return the corresponding date as a standard
197
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l197>
SIP-format timestamp:
198
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l198>
199
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l199>
YYYYMMDDZZZZHHMMSS
200
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l200>
201
<https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=HEAD#l201>
Where the C<'Z'> characters indicate spaces.
The response gets built here
https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=Sip/MsgType.pm;hb=HEAD#l1212
I'm not really seeing anything that would make me think the date
is getting changed. So the date might be getting truncated
before it gets to the SIPserver code. I'll look some more when I
have a chance.
Josh
On Sat, Nov 1, 2025 at 4:49 AM Linda Jansová via
Evergreen-general <[email protected]> wrote:
Hi,
We are in the process of setting up a pickup locker which we
hope will work together with Evergreen (currently 3.13.1),
using the SIP server.
Currently, if we ask for item information (request 17 in the
SIP protocol parlance), we get the 18 response but it
contains the CM field value (which represents hold pickup
date) in the YYYYMMDD format which seems to be incorrect (not
accurate enough or, in other words, too short).
A sample request (sent after successfully logging in via
telnet and so there is a manually added date at the beginning
of the string):
1720251101 084453AOjabokkn|AB424480023074|
Response to this request which we have received (with the CM
field highlighted in bold):
1808020120251101 092707AB424480023074|AJTropika diskursu :
kulturně kritické
eseje|CK001|AQJAB-KN|APJAB-KN|BHCZK|BV0.00|BGJAB-KN|CF1|*CM20251107*|CTJAB-KN|CSFL-1.4/W|
So CM’s value is 20251107, not the long date we would wish to
receive.
The guidelines entitled "How to Set Up a SIP2 Server for
Self-Check Systems" (used for Aleph but containing also the
generic SIP information; available from
https://files.mtstatic.com/site_11811/57183/3?Expires=1761987196&Signature=BUhN1BmluFzxM4NH~0LnIQRvkqtOS8p5Z1drTKv6X66zWrkazeGiJ4Hhx8h8evPbXRn-bPDQZqBqYMrJXhla-epAH4o02MMYdbk2r0N0s7-dpywSLws-XfUBKihwCARK0vf3~C9UX7~-AMgAUmZsWNZl6tcaVoi3JvbCuVhy43M_&Key-Pair-Id=APKAJ5Y6AV4GI7A555NA
<https://files.mtstatic.com/site_11811/57183/3?Expires=1761987196&Signature=BUhN1BmluFzxM4NH~0LnIQRvkqtOS8p5Z1drTKv6X66zWrkazeGiJ4Hhx8h8evPbXRn-bPDQZqBqYMrJXhla-epAH4o02MMYdbk2r0N0s7-dpywSLws-XfUBKihwCARK0vf3~C9UX7~-AMgAUmZsWNZl6tcaVoi3JvbCuVhy43M_&Key-Pair-Id=APKAJ5Y6AV4GI7A555NA>)
give the following specification for the CM date format:
"18-char, fixed-length field: YYYYMMDDZZZZHHMMSS."
In the Evergreen SIP config file
(https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=SIPconfig.xml.example.evergreen;hb=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
we have enabled (uncommented) the following option:
<option name="use_sip_date_format" value="true"/>
Given its description ("By default, most dates use the SIP
date format. Some, like circulation due dates, use the
ISO8601 date format instead. If this setting is set to true,
all dates will use the SIP date format."), it looks pretty
much like something that might help the date format to appear
in the correct format.
However, after enabling the option and restarting Evergreen,
the date is still delivered in the YYYYMMDD format.
Evergreen documentation
(https://docs.evergreen-ils.org/docs/latest/admin/sip_server_communication.html#sip_17-18_item_information)
mentions the CM field but the sample responses do not contain
this field and its value (obviously, this piece of
information is not always applicable, so its absence in the
examples is understandable).
The Item.pod file
(https://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=ILS/Item.pod;hb=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
mentions:
"=item C<$date = $item-E<gt>recall_date>
=item C<$date = $item-E<gt>hold_pickup_date>
These functions all return the corresponding date as a standard
SIP-format timestamp:
YYYYMMDDZZZZHHMMSS
Where the C<'Z'> characters indicate spaces."
This file was last changed in 2016, so even if we are on
3.13.1 and not on the latest version, it is already there.
We have noticed some recent changes to the SIP server (e.g.,
relating to filters:
https://git.evergreen-ils.org/?p=SIPServer.git;a=commitdiff;h=335ba9848c620c7c5e35fd05ebb9fcaf188b316f)
but we are not sure if they might be (in one way or another)
relevant in our case (?).
The Launchpad bugs (found using the simplest sip query:
https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=sip&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=DEFERRED&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=sip&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=DEFERRED&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=>)
do not seem to mention the date issue.
We have also tried to have a look elsewhere (e.g., at
https://pines.georgialibraries.org/docs/doku.php?id=circ:holds:book_lockers)
but as the GAPINES documentation focuses on procedures which
are to be performed by librarians rather than on setting up
the SIP server, it does not provide any clues to the CM date
format issue.
Any ideas where else to look (which particular setting to
change etc.) to make the date appear in the right (i.e.,
long) format in the SIP server response?
Thank you very much for providing any hints!
Best,
Linda
on behalf of the Czech Evergreen team :-)
_______________________________________________
Evergreen-general mailing list --
[email protected]
To unsubscribe send an email to
[email protected]
_______________________________________________
Evergreen-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
