| Time |
Nick |
Message |
| 04:43 |
|
phasefx__ joined #evergreen |
| 04:43 |
|
gmcharlt_ joined #evergreen |
| 04:45 |
|
csharp_ joined #evergreen |
| 04:59 |
|
dcook joined #evergreen |
| 04:59 |
|
jeff__ joined #evergreen |
| 07:33 |
|
collum joined #evergreen |
| 07:42 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
csharp joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:05 |
csharp |
@who has to work today? |
| 08:05 |
pinesol_green |
has to work today. |
| 08:05 |
csharp |
pinesol_green: tru dat |
| 08:05 |
pinesol_green |
csharp: No, you're a puzzleheaded kraken! |
| 08:05 |
pinesol_green |
Factoid 'tru dat' not found |
| 08:05 |
csharp |
pinesol_green: your mama |
| 08:05 |
pinesol_green |
Factoid 'your mama' not found |
| 08:05 |
pinesol_green |
csharp: http://cat.evergreen-ils.org.meowbify.com/ |
| 08:47 |
|
rlefaive joined #evergreen |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:21 |
|
maryj joined #evergreen |
| 09:21 |
|
sarabee joined #evergreen |
| 09:21 |
* Dyrcona |
just loves "smart" quotes, especially in MARC! |
| 09:22 |
csharp |
@whocares smart quotes |
| 09:22 |
pinesol_green |
csharp: I can't find anyone who loves or hates smart quotes. |
| 09:22 |
csharp |
marc-- |
| 09:24 |
csharp |
in the Item reports source, "Monograph Parts" appears as a field with the Data Type "link", but doesn't appear in the source tree... why would that be? fm_IDL.xml looks correct (as far as I understand its relationship to reports display) |
| 09:25 |
csharp |
same is true of "Holds" |
| 09:28 |
Dyrcona |
csharp: Does autogen affect reports? (I really don't know.) |
| 09:28 |
csharp |
Dyrcona: I don't think so - I think reports pulls everything from its own copy of fm_IDL.xml |
| 09:29 |
Dyrcona |
csharp: Now that you mention it....I recall seeing that. |
| 09:29 |
dbs |
Field name != Source name occasionally, I think. |
| 09:30 |
csharp |
dbs: yeah, I considered that possiblility too, but it's just not there (even under another name) :-/ |
| 09:31 |
bshum |
csharp: https://bugs.launchpad.net/evergreen/+bug/1228392 |
| 09:31 |
pinesol_green |
Launchpad bug 1228392 in Evergreen "Item does not link to Monograph Parts in Evergreen Reports Module " [Wishlist,Triaged] |
| 09:31 |
bshum |
Maybe that? |
| 09:31 |
csharp |
bshum: aha - well, for the record, I did try a launchpad search via Google :-( |
| 09:32 |
csharp |
that's definitely what I'm seeing |
| 09:32 |
bshum |
I just vaguely remembered reading a bug like it, so I did a launchpad search for "monograph parts" |
| 09:33 |
* csharp |
changes Importance from Wishlist to Medium, since it appears to be a bug, not a feature request |
| 09:33 |
dbs |
Weird, I see "Monograph Parts" under Sources -> All Available Sources, but maybe I'm looking at the wrong thing |
| 09:33 |
dbs |
(also, 2.7-ish here) |
| 09:33 |
csharp |
dbs: yeah, it's there, but when you go to Item, it appears as a field, but not a selectable link in the source tree |
| 09:34 |
dbs |
Oh, I see |
| 09:34 |
dbs |
I think I saw something similar with acq |
| 09:34 |
csharp |
so there is a workaround for needing the data, but it will probably require nullability selection (which is pretty much a non-starter for PINES end users) |
| 09:43 |
tsbere |
we don't let our end users make templates in the first place. <_< |
| 09:48 |
Dyrcona |
Heh. I don't even let myself make templates. :) |
| 09:49 |
csharp |
tsbere: yeah, that genie's out of the bottle in PINES, unfortunately :-/ |
| 09:49 |
* csharp |
tries to remember what oils_persist:virtual="true" means |
| 09:50 |
berick |
csharp: no DB table/column |
| 09:50 |
jeff |
"this isn't backed by a table" |
| 09:50 |
Dyrcona |
Yep. |
| 09:50 |
csharp |
huh - well, that's not the case here, but it's marked as such |
| 09:52 |
|
gmcharlt joined #evergreen |
| 10:02 |
Dyrcona |
csharp: what object? |
| 10:05 |
miker |
csharp: to clarify what berick said, virtual="true" means "not backed by a db column /on this table/" |
| 10:05 |
berick |
yes, that, good point |
| 10:06 |
miker |
well, berick/jeff |
| 10:10 |
berick |
do we have a way to prevent an IDL class from appearing in the reporter? |
| 10:12 |
miker |
berick: well... sorta. the open-ils.reporter source should be required, but IIRC we let open-ils.cstore stand in its stead ... so, "almost" |
| 10:14 |
miker |
s/source/controller/, sorry |
| 10:14 |
berick |
so as it stands, if it's accessible by cstore, it's reportable? |
| 10:14 |
miker |
berick: we can, however, suppress specific fields with a suppress_controller attr on a <field> |
| 10:15 |
berick |
oh right |
| 10:15 |
berick |
that's def. useful |
| 10:15 |
miker |
yeah, we suppress au.passwd |
| 10:16 |
miker |
but, looking at the code, I'm remembering a dream :) ... we don't filter on controller at all, it seems |
| 10:16 |
miker |
but we could |
| 10:16 |
* miker |
makes a note to look at that for webstaff |
| 10:17 |
* berick |
nods |
| 10:17 |
berick |
thanks |
| 10:22 |
csharp |
miker: oh - makes sense |
| 10:24 |
csharp |
miker: and thanks for the comment at https://bugs.launchpad.net/evergreen/+bug/1228392/comments/2 - that explains it for me |
| 10:24 |
pinesol_green |
Launchpad bug 1228392 in Evergreen "Item does not link to Monograph Parts in Evergreen Reports Module " [Medium,Triaged] |
| 10:27 |
miker |
np |
| 10:28 |
|
mrpeters joined #evergreen |
| 10:51 |
|
Christineb joined #evergreen |
| 11:19 |
jeff |
Hrm. Anyone know offhand what semi-common process can cause a hold to change shelf_time and shelf_expire time? |
| 11:19 |
jeff |
I wonder if simply re-scanning an already on-shelf hold does that. |
| 11:19 |
* jeff |
tests |
| 11:21 |
berick |
pretty sure it would take more than that |
| 11:21 |
berick |
it would have to be un-shelved in some way |
| 11:22 |
berick |
i think. like, pickup_lib changed, checked in, changed back, checked in later. |
| 11:23 |
jeff |
Current example happened at a branch other than the one I'm at. Drat. |
| 11:25 |
* jeff |
tests |
| 11:29 |
jeff |
Yeah, it's not a simple "scan it again". |
| 11:29 |
jeff |
At least, not with default checkin modifiers, etc. |
| 11:42 |
jeff |
Okay, in this specific example it was "patron didn't want the hold anymore, staff were unfamiliar with how to cancel a hold" |
| 11:43 |
jeff |
So they did a few things, presumably one of which involved reset/retargeting the hold. |
| 11:43 |
jeff |
Then they just left it in its captured on-holdshelf state and chucked it in the bin for transit to the owning library. |
| 11:43 |
jeff |
So we went over how to cancel a hold. |
| 11:47 |
tsbere |
jeff: I can think of two things. One being manual "find another target" triggering, the other being "the copy that *was* on the shelf was checked out to someone else, and now that is a new copy" |
| 11:47 |
* tsbere |
is amazed he hasn't had to dig out records of the latter in the past few months, actually... |
| 11:51 |
jeff |
amusing when the target of a ready for pickup hold changes. |
| 11:52 |
jeff |
(bib merges) |
| 11:58 |
tsbere |
jeff: Not to mention title hold transfers. <_< |
| 12:01 |
|
rlefaive joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:17 |
|
phasefx_ joined #evergreen |
| 12:27 |
Bmagic |
where does one post SIP code changes? Is there a working repo just like EG? Who adds public keys? |
| 12:29 |
jeff |
There is a working repo, and a launchpad instance. |
| 12:29 |
jeff |
http://git.evergreen-ils.org/?p=working/SIPServer.git;a=summary |
| 12:30 |
Bmagic |
oh |
| 12:30 |
jeff |
https://bugs.launchpad.net/sipserver |
| 12:30 |
jeff |
keys via the usual means -- i'd test to see if yours are already in place. |
| 12:31 |
Bmagic |
weird, I see that I somehow have a commit there already |
| 12:31 |
jeff |
I suspect that any keys submitted added after the creation of that repo are already in place, but I'm not certain. |
| 12:31 |
Bmagic |
lol, I guess I forgot |
| 12:32 |
tsbere |
Working repos don't have lists of keys. If your key exists on the server it works for working repos. |
| 12:32 |
Bmagic |
groovy |
| 12:33 |
jeff |
logical and efficient! |
| 12:44 |
tsbere |
In addition to my comment on https://bugs.launchpad.net/evergreen/+bug/1528301 I imagine it would require changes in SIPServer as well as in Evergreen. :/ |
| 12:44 |
pinesol_green |
Launchpad bug 1528301 in Evergreen "WISHLIST Add SIP Support for BF field on type 10 checkin responses" [Undecided,New] |
| 12:45 |
Bmagic |
tsbere: I have it working, yeah, it was one line addition in SIPServer and one line in Evergreen |
| 12:45 |
Bmagic |
Bibliotheca wont change their code to ask the server for more information about the patron via 63 - they expect to get the information in the 10 response |
| 12:46 |
tsbere |
Based on what spec? |
| 12:46 |
Bmagic |
CircIT will check an item in, and if it fills a hold, their software asks the server again for the 63 information |
| 12:46 |
Bmagic |
I don't know about the spec |
| 12:47 |
Bmagic |
we have a library moving away from CircIT to Bibliotheca - and there is an issue here with the checkin fill hold notify phone number |
| 12:48 |
Bmagic |
I suppose I don't need to share the code back, but I thought it would be nice for others |
| 12:49 |
tsbere |
Bmagic: Given that the SIP2 spec doesn't say that field is given for that response (at least not that I can find) you should at a minimum explain why you want this on Launchpad |
| 12:50 |
* Dyrcona |
wonders why the self check is concerned about holds and notifying patrons. I don't see that as being its job/business. |
| 12:50 |
tsbere |
Bmagic: Beyond that, I then want to know why their system needs the phone number, what they do about other enabled notification options, etc because just looking at the phone number seems limiting. |
| 12:51 |
Bmagic |
tsbere: I agree |
| 12:51 |
Bmagic |
It's for the printed slip |
| 12:51 |
Bmagic |
selfcheck |
| 12:52 |
Dyrcona |
Um, no. That just seems wrong. Putting a patron in charge of handling another patron's holds. |
| 12:52 |
* tsbere |
wonders why you would want that info on a *checkin* if this is a *selfcheck* as the latter usually implies check *out* |
| 12:52 |
Bmagic |
one of our libraries has trained the patrons to return items by them selves. They know which bin to put each item into depending on the computer screen's response |
| 12:53 |
Bmagic |
and the accompaning hold slip is printed automatically |
| 12:54 |
Bmagic |
I'm not totally sure how they are doing this. I don't know that the slip is public, but for whatever reason, they need this. Maybe it is so bizzare, that it's not worth publishing |
| 12:57 |
jeff |
I favor the "share what you have, with as much info as you can about WHY you have it" :-) |
| 13:06 |
|
artunit joined #evergreen |
| 13:22 |
csharp |
@blame reports tickets in a holiday week |
| 13:22 |
pinesol_green |
csharp: Forget it, Jake. It's just reports tickets in a holiday week. |
| 13:22 |
csharp |
don't they know I'm trying to relax here? |
| 13:30 |
Dyrcona |
csharp: Don't you know it's Chinatown? ;) |
| 13:50 |
|
artunit joined #evergreen |
| 14:13 |
|
mllewellyn joined #evergreen |
| 14:17 |
|
artunit joined #evergreen |
| 15:08 |
|
jlitrell joined #evergreen |
| 15:11 |
csharp |
I'm looking at implementing the newest SIPServer, including multiplex... I'm noticing some configuration parameters in our current XML config file that don't appear to be in current SIPServer code |
| 15:12 |
tsbere |
csharp: I know a few relating to, I believe, script based circ would have been removed... |
| 15:13 |
csharp |
for instance under <server-params> I see <max_servers>500</max_servers> and <check_for_dead>10</check_for_dead> (example params are min_servers='1' and min_spare_servers='0') - not sure what effects those changes will have |
| 15:13 |
csharp |
tsbere: yeah, I just blew away the <implementation> sections relating to script-based circ |
| 15:14 |
csharp |
max_servers is pretty obvious to me, but check_for_dead? grep shows nothing for that |
| 15:15 |
Dyrcona |
csharp: I've never seen a check_for_dead setting, so if it was ever legit, it must be very old. |
| 15:15 |
csharp |
yeah, I'm pretty sure this is the same config from like 2008 or something like that |
| 15:15 |
tsbere |
csharp: Those may be parameters that get passed into PreFork? Or rather, the Net::Server parent. |
| 15:16 |
csharp |
we've been dragging it along without really any analysis, because, hey, It works!™ |
| 15:16 |
tsbere |
csharp: The loop basically says "take the key, assign it the value, pass it through" if I am reading this correctly... |
| 15:16 |
jeff |
lqcheck_for_dead |
| 15:16 |
jeff |
Seconds to wait before checking to see if a child died without letting the parent know. |
| 15:17 |
jeff |
http://search.cpan.org/dist/Net-Server/lib/Net/Server/PreForkSimple.pm |
| 15:17 |
jeff |
and disregard that lq. probably JuiceSSH as i was throwing my phone in my pocket. |
| 15:17 |
csharp |
heh |
| 15:17 |
csharp |
jeff: thanks! |
| 15:18 |
jeff |
check_for_dead defaults to 30s, according to this. |
| 15:18 |
jeff |
tsbere++ not me -- he got it first |
| 15:20 |
Dyrcona |
@blame spam for all the world's problems |
| 15:20 |
pinesol_green |
Dyrcona: spam broke Evergreen. for all the world's problems |
| 16:31 |
Dyrcona |
ASCII stupid question; get a stupid ANSI. :) |
| 16:34 |
|
RyanLGPL joined #evergreen |
| 17:16 |
|
mrpeters left #evergreen |
| 18:23 |
|
rlefaive joined #evergreen |
| 20:39 |
|
Christineb joined #evergreen |
| 20:54 |
|
finnx joined #evergreen |
| 21:34 |
|
artunit joined #evergreen |
| 22:00 |
|
finnx left #evergreen |
