| Time |
Nick |
Message |
| 05:25 |
|
remingtron__ joined #evergreen |
| 05:26 |
|
dbwells_ joined #evergreen |
| 05:28 |
|
rlefaive joined #evergreen |
| 07:20 |
|
rlefaive joined #evergreen |
| 07:51 |
|
mrpeters joined #evergreen |
| 07:54 |
|
ericar joined #evergreen |
| 08:15 |
jeff |
eeevil: thanks (re ahcm). it's sometimes difficult to extract original intent. |
| 08:22 |
|
Dyrcona joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 09:10 |
|
jwoodard joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:35 |
jeff |
hrm. just realized/remembered that there's no real chance to drop in or bounce between preconference sessions this year. |
| 09:37 |
jeff |
though i guess you could pay the full $220+65+65+65 if that was that important to you. |
| 09:39 |
Dyrcona |
I keep forgetting/putting off submitting a presentation proposal! |
| 09:41 |
jeff |
yeah. |
| 09:41 |
jeff |
that too. |
| 09:54 |
jboyer-isl |
I didn't read the costs correctly, I didn't realize each pre-conf was a separate thing. I initially took it to be "pre-conf only is just $65!" as opposed to 1-day or full. I guess I'll stick to the hackfest. (Not complaining, mind.) |
| 09:59 |
jeff |
yeah, it's unlikely that anyone actually will spend the full $415 for registration fees, and requiring advance registration will help the organizers plan appropriate spaces. |
| 10:07 |
|
Christineb joined #evergreen |
| 10:14 |
|
maryj joined #evergreen |
| 10:19 |
Dyrcona |
Sometimes, I think my code is the product of madnes, then I look at other people's code.... |
| 10:19 |
Dyrcona |
if statements that make the "flagon with the dragon" routine look like amateur hour at the comedy club. |
| 10:28 |
|
rlefaive joined #evergreen |
| 10:41 |
|
mllewellyn joined #evergreen |
| 10:53 |
|
graced joined #evergreen |
| 10:56 |
Dyrcona |
Ooh... helper functions for helper functions, so I get the same functionality for random objects without changing the older function's interface and the code that uses it. |
| 11:00 |
|
collum joined #evergreen |
| 11:05 |
Dyrcona |
Code is kind of like barnacles....It tends to accrete more than it disappears. |
| 11:33 |
|
sandbergja joined #evergreen |
| 11:40 |
jeff |
is there a way to match field X against field Y in a vandelay match profile? |
| 11:41 |
|
graced joined #evergreen |
| 11:42 |
jeff |
for example, if you're using bre.id for 001 and you want to match an incoming 001 against 901$a |
| 11:43 |
kmlussier |
jeff: No, I don't think you can do that. |
| 11:52 |
|
rlefaive joined #evergreen |
| 11:58 |
jeff |
kmlussier: thanks. probably for the better, at least in this case. |
| 11:59 |
jeff |
i of course have a very nice match with this vendor on 037$a and 037$b, but of course their older records don't have the 037$a... |
| 12:12 |
Bmagic |
One of our libraries is reporting something interesting with bills. If a staff/patron overpays a bill by 5 cents, the leftover money is ignored - like not recorded. Is that right? |
| 12:13 |
jeff |
Bmagic: it should show as change due in the staff client, unless the option to treat change as patron credit is selected in the client for that payment. |
| 12:14 |
Bmagic |
jeff: thanks - that's what I thought. I haven't seen it first hand, but I thought I would ask |
| 12:14 |
jeff |
Bmagic: if the option to treat the change as patron credit is selected, then the amount should be added to the current value of actor.usr.credit_forward, but would not be otherwise recorded anywhere else. |
| 12:14 |
Bmagic |
right |
| 12:14 |
jeff |
the "amount tendered" is never recorded in the database. just the individual per-transaction payment amounts that the amount tendered is broken down into. |
| 12:15 |
jeff |
likewise, the change given or credit applied is not recorded (except in that it is added to the patron's credit_forward value). |
| 12:18 |
|
graced joined #evergreen |
| 12:29 |
|
jihpringle joined #evergreen |
| 12:31 |
|
bmills joined #evergreen |
| 12:36 |
|
Christineb joined #evergreen |
| 13:22 |
|
maryj joined #evergreen |
| 13:28 |
|
maryj_ joined #evergreen |
| 13:36 |
|
graced joined #evergreen |
| 13:39 |
jeff |
ingest.metarecord_mapping.preserve_on_delete is (presently) false: 57075 deleted bibs with entries in mrfr. |
| 13:39 |
jboyer-isl |
Because I'm thinking about it, does anyone have a favorite VPN/Firewall appliance that hasn't recently had a complete game-over backdoor exposed in the last 3 months? I'm looking to upgrade. |
| 13:40 |
jeff |
good: zero non-deleted bibs without at least one entry in mrfr. |
| 13:40 |
jboyer-isl |
jeff: Would you ever have operated in that mode? I don't know if entries are removed when it's changed. |
| 13:40 |
|
StomproJ joined #evergreen |
| 13:40 |
jeff |
jboyer-isl: i wouldn't expect changing the value of the flag to have an immediate effect, no. |
| 13:42 |
|
vlewis joined #evergreen |
| 13:42 |
jeff |
jboyer-isl: i don't recall operating with it set to true, but that doesn't mean much. |
| 13:43 |
jboyer-isl |
I suppose a better question is "how old is the setting?" Because before it existed it always operated one way or the other. |
| 13:55 |
|
vlewis_ joined #evergreen |
| 13:55 |
|
vlewis__ joined #evergreen |
| 14:01 |
|
rlefaive joined #evergreen |
| 14:02 |
|
vlewis joined #evergreen |
| 14:02 |
|
vlewis___ joined #evergreen |
| 14:09 |
jeff |
jboyer-isl: original commit of that setting was 2013 (released as part of 2.4, i think). flag defaults to false, which is the same as the previous behavior before the flag existed. |
| 14:10 |
Bmagic |
anyone have renewals working over SIP? |
| 14:10 |
jeff |
jboyer-isl: i.e., if you wanted to keep deleted records in mrfr, you needed to turn the flag on and reingest. |
| 14:12 |
|
maryj joined #evergreen |
| 14:13 |
Bmagic |
my 29 request results in a 30 response "Renewals not allowed." |
| 14:15 |
Bmagic |
Renewing the item via OPAC is no problem |
| 14:15 |
jboyer-isl |
jeff: So, edge cases! Hurray. |
| 14:16 |
jeff |
Bmagic: sounds like your sip institution/policy element may not have renewal="true" |
| 14:17 |
Bmagic |
it does, I checked on that <item name='renew' value='true'/> |
| 14:18 |
jeff |
that looks unfamiliar. |
| 14:18 |
jeff |
unless you were paraphrasing |
| 14:18 |
Bmagic |
<item name='renew all' value='false'/> from <supports> xml block |
| 14:18 |
jeff |
oh, no. different. |
| 14:19 |
Bmagic |
<policy renewal="true" |
| 14:19 |
|
maryj_ joined #evergreen |
| 14:19 |
jeff |
okay, that's the one i was talking about. :-) |
| 14:19 |
Bmagic |
yeah, both of those are set to true |
| 14:19 |
jeff |
acsconfig/institutions/institution/policy |
| 14:19 |
Bmagic |
The <supports> block in my config does have renewall set to false |
| 14:19 |
* jeff |
nods |
| 14:20 |
Bmagic |
but it's a 29 request in the logs |
| 14:22 |
Bmagic |
so I assume its touching the renew code. I see a line in OpenILS::SIP.sub renew { if(!$trans->patron->renew_ok) { |
| 14:22 |
Bmagic |
where it might be failing |
| 14:25 |
jeff |
does the patron have a standing penalty like max items out? |
| 14:26 |
Bmagic |
he does have some penalties, let me see if they block renew |
| 14:26 |
jeff |
doesn't matter. |
| 14:26 |
Bmagic |
oh? |
| 14:26 |
jeff |
if they block anything, it'll block sip renewal. |
| 14:26 |
Bmagic |
ah! |
| 14:26 |
Bmagic |
why's that? |
| 14:26 |
jeff |
standing penalties 1, 2, or where block_list is not null. |
| 14:27 |
jeff |
see OpenILS::SIP::Patron::flesh_user_penalties |
| 14:27 |
Bmagic |
he has 2 |
| 14:27 |
jeff |
it's also why patrons with max items out get charge_ok set to N and can't use a 3M selfcheck |
| 14:27 |
Bmagic |
I see, so it's by design |
| 14:28 |
Bmagic |
presumably, if the patron didnt have any penalties, they would be able to renew |
| 14:28 |
jeff |
i'd test to confirm that's what you're running into. |
| 14:28 |
Bmagic |
I will remove the penalty and try to renew, just a minute |
| 14:28 |
jeff |
and i wouldn't say "by design" |
| 14:29 |
jeff |
it's just that penalties have become more nuanced and granular, and there's room for improvement in the SIP code now. |
| 14:30 |
jeff |
though the specific example i gave of "max items out blocks use of some SIP terminals" is a little tricky. |
| 14:30 |
Bmagic |
ok - that worked |
| 14:30 |
Bmagic |
so, it's the penalty that is preventing the renew.... thanks jeff |
| 14:30 |
jeff |
'welcome! |
| 14:30 |
Bmagic |
jeff++ |
| 14:31 |
Bmagic |
moar karma for you! |
| 14:34 |
jeff |
what penalties did the patron have, and what was their block list? |
| 14:35 |
Bmagic |
jeff: is there a bug report for this? |
| 14:36 |
Bmagic |
he had #2 "PATRON_EXCEEDS_OVERDUE_COUNT" |
| 14:38 |
kmlussier |
Ah, nice. Can't renew because he has overdues. But can't address the overdues because he can't renew. |
| 14:38 |
jeff |
exactly :-) |
| 14:38 |
Bmagic |
yeah - exactly - however, the OPAC will let the renew work. This library has self check kiosks |
| 14:39 |
Bmagic |
no bug on this? |
| 14:39 |
jeff |
opening. |
| 14:39 |
Bmagic |
oh, you are going to report it? |
| 14:40 |
Bmagic |
patrons are "blocked" via SIP if they have penalty 1,2 or any other penalty that assigns any block ? |
| 14:47 |
Dyrcona |
Bmagic: Patrons are usually blocked in SIP if they have any block, but it can vary by vendor. |
| 14:48 |
jeff |
bug 1534283 |
| 14:48 |
pinesol_green |
Launchpad bug 1534283 in Evergreen "SIP prevents renewal when user has any blocking standing penalties" [Undecided,New] https://launchpad.net/bugs/1534283 |
| 14:49 |
jeff |
i'll be looking at some other SIP things next week. i'll take a stab at it if nobody gets to it before then. |
| 14:51 |
Dyrcona |
Some vendors see any of the blocks as the patron is blocked, full stop. |
| 14:51 |
jeff |
yes. |
| 14:51 |
Dyrcona |
Even if the field doesn't apply to the transaction at hand. |
| 14:52 |
Dyrcona |
But, anyway, I'm late to the party and probably irrelevant. Was talking about deduping some bibs with catalogers. |
| 14:54 |
jeff |
3M rejects the session on their Phoenix and QuickConnect interfaces if charge_ok is N. Having a config option to help that is another bug I can file. :-) |
| 14:58 |
Dyrcona |
But, on the overdues and not renewing, doesn't the staff client do the same? |
| 15:00 |
Dyrcona |
Ah! Don't mind me. I just read the bug. |
| 15:02 |
* Dyrcona |
thinks he's about had it for the day. |
| 15:10 |
Bmagic |
Dyrcona: it's no problem to renew the items via OPAC or staff client because those dive into the penalties further and tease out the block codes in the block column config.standing_penalty.block_list |
| 15:17 |
|
maryj joined #evergreen |
| 15:18 |
Dyrcona |
Right....once I read the bug, I realized the real problem. |
| 15:20 |
Dyrcona |
I think my swap is full.... ;) |
| 15:20 |
Bmagic |
haha |
| 15:21 |
jeff |
:-) |
| 15:29 |
|
jihpringle joined #evergreen |
| 15:44 |
|
jeff joined #evergreen |
| 15:49 |
|
ldw joined #evergreen |
| 16:02 |
|
bmills joined #evergreen |
| 16:14 |
|
maryj_ joined #evergreen |
| 16:32 |
|
vlewis_ joined #evergreen |
| 16:32 |
|
vlewis__ joined #evergreen |
| 16:33 |
|
jlitrell joined #evergreen |
| 16:35 |
|
ldw joined #evergreen |
| 16:36 |
|
vlewis joined #evergreen |
| 16:43 |
|
vlewis joined #evergreen |
| 16:43 |
jwoodard |
@librarian |
| 16:43 |
pinesol_green |
jwoodard: Management:12, Cataloging:14, Acquisitions:16, Reference:8, Circulation:12, Systems:10, Research:17, Custodial:9 |
| 17:07 |
|
mmorgan left #evergreen |
| 17:30 |
|
rlefaive joined #evergreen |
| 17:33 |
|
rlefaive joined #evergreen |
| 17:44 |
|
vlewis_ joined #evergreen |
| 17:46 |
|
vlewis joined #evergreen |
| 18:00 |
|
vlewis_ joined #evergreen |
| 18:04 |
|
vlewis joined #evergreen |
| 19:09 |
|
mrpeters left #evergreen |
| 19:21 |
csharp |
@upgrade PINES |
| 19:21 |
pinesol_green |
csharp: did you finish your beer? |
| 19:22 |
csharp |
pinesol_green: far too many, so I stopped drinking 4+ years ago |
| 19:22 |
pinesol_green |
csharp: Have you tried turning it off and back on again? |
| 19:22 |
pinesol_green |
csharp: I am only a bot, please don't think I'm intelligent :) |
| 20:46 |
kmlussier |
@librarian |
| 20:46 |
pinesol_green |
kmlussier: Management:16, Cataloging:13, Acquisitions:14, Reference:10, Circulation:8, Systems:11, Research:15, Custodial:10 |
| 20:59 |
|
bmills joined #evergreen |
| 23:59 |
|
mtj_ joined #evergreen |
