| Time |
Nick |
Message |
| 05:01 |
|
pmurray_away joined #evergreen |
| 07:23 |
|
jeff__ joined #evergreen |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 07:37 |
|
sarabee joined #evergreen |
| 07:51 |
|
mrpeters joined #evergreen |
| 08:12 |
|
ericar joined #evergreen |
| 08:23 |
|
rlefaive joined #evergreen |
| 08:26 |
|
remingtron joined #evergreen |
| 08:32 |
|
collum joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:46 |
|
Shae joined #evergreen |
| 08:48 |
|
dbwells joined #evergreen |
| 08:57 |
csharp |
okay, looking at the fix for bug 1379815 again this morning |
| 08:58 |
pinesol_green |
Launchpad bug 1379815 in Evergreen "Assign stat cats during Vandelay import/overlay of items" [Wishlist,Fix released] https://launchpad.net/bugs/1379815 |
| 09:00 |
csharp |
line 115 of Open-ILS/src/perlmods/lib/OpenILS/Application/Cat/AssetCommon.pm is 'if(! grep { $_->id == $map->stat_cat_entry } @$entries ) {' and that looks like it says "if the id column of the asset.stat_cat_entry_copy_map row doesn't equal the stat_cat_entry column" which, if true means the map row should be considered stale and gets deleted - is that right? |
| 09:00 |
csharp |
"is that right?" == "is my understanding correct?" |
| 09:02 |
csharp |
because if my understanding is correct, that means pretty much all stat cat entry copy map rows will be deleted with each bib update |
| 09:02 |
csharp |
(which is what I'm seeing happen in practice) |
| 09:05 |
csharp |
I don't have a solid understanding of that fix's overall purpose, so I'm kind of shooting in the dark |
| 09:08 |
csharp |
dbwells: do you mind taking a look when you get a moment? |
| 09:10 |
dbwells |
csharp: What do you mean when you say "fix"? You mean this new feature code, or is there another bug with a fix for it? |
| 09:11 |
csharp |
dbwells: I mean the new feature code |
| 09:12 |
csharp |
dbwells: this: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b1c8c14 |
| 09:12 |
pinesol_green |
[evergreen|Dan Wells] LP#1379815 Add missing behavior to update_copy_stat_entries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b1c8c14> |
| 09:14 |
|
jboyer-isl joined #evergreen |
| 09:15 |
mmorgan |
csharp: There's mention of an add_or_update_only flag in this comment: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Cat/AssetCommon.pm;h=626595ba9bad577c876dd82fe30d48f9127e8d7c;hb=HEAD#l84 |
| 09:15 |
tsbere |
csharp: I haven't looked at the code, but I can't think of many cases where an entries array would compare on id to the maps. id to id, maybe, but not id to stat_cat_entry... |
| 09:15 |
mmorgan |
"adds missing maps, updates present maps with any new values, and leaves the rest alone" |
| 09:16 |
* tsbere |
would see stat_cat_entry to stat_cat_entry as being more likely, for that matter |
| 09:17 |
dbwells |
csharp: I'm looking at the changes now. One thing I'll say right away is that it doesn't look like that code branch actually changed at all, it's just wrapped in a new option flag. I'm guessing it isn't the source of your issue, but still looking. |
| 09:18 |
|
Dyrcona joined #evergreen |
| 09:25 |
csharp |
hmm - yeah - looks like the original code came in in 2011 |
| 09:26 |
csharp |
well, I'll try reverting the feature and seeing if the problem still happens |
| 09:26 |
dbwells |
csharp: sounds like a plan |
| 09:27 |
|
maryj joined #evergreen |
| 09:28 |
dbwells |
I've been staring at it for 10 minutes, and can't see how this change would matter for normal copy editing, but who knows. |
| 09:28 |
csharp |
tsbere: in this case "$_" appears to be a stat_cat_entry_copy_map row ("my $maps = $editor->search_asset_stat_cat_entry_copy_map({owning_copy=>$copy->id});" then "for my $map (@$maps)") |
| 09:28 |
csharp |
so $_->id would be the row id, right? |
| 09:29 |
* csharp |
hates perl |
| 09:29 |
csharp |
that kind of shorthand makes debugging harder than it needs to be |
| 09:30 |
dbwells |
not sure I follow, but "$_->id" in this case is pulling the 'id' of each member of "$entries", which is a list of "stat_cat_entry" objects attached to the copy. |
| 09:30 |
tsbere |
csharp: yes, but how much harder is it than defining the variable name for the loop? ;) |
| 09:31 |
csharp |
dbwells: okay - that helps - I was thinking that $map (the map table rows) was what that was receiving |
| 09:31 |
tsbere |
dbwells: So there are a pile of stat_cat_entries passed in, and we are comparing them to existing maps.....in which case the code is saying "if none of the entries are already in the maps"? |
| 09:34 |
csharp |
btw, on a stock master DB, I'm not seeing the problem, but there weren't any existing asset.stat_cat_entry_map rows in the concerto dataset |
| 09:34 |
csharp |
or stat cats at all, actually |
| 09:34 |
Dyrcona |
tsbere: You can't specify variables names in a map. |
| 09:34 |
dbwells |
From the comment: "if there is no stat cat entry on the copy who's id matches the current map's id, remove the map from the database". As csharp says, that logic has been there since 2011, and I'd say it's not an issue. |
| 09:35 |
|
rlefaive joined #evergreen |
| 09:37 |
Dyrcona |
@love/hate Perl |
| 09:37 |
pinesol_green |
Dyrcona: http://images.cryhavok.org/d/1291-1/Computer+Rage.gif |
| 09:37 |
Dyrcona |
Too funny, pinesol_green. |
| 09:39 |
* Dyrcona |
gets to ask the vendor: If you're not sending PickupLocation in RequestItem, which of the four, five, or even six possible Agency fields am I suppose to use to determine the pickup location for the hold? |
| 09:40 |
Dyrcona |
Of course, they're probably only sending three or four. |
| 09:40 |
dbwells |
csharp: If you are losing all your entries with any update, and you aren't getting any errors, it suggests your copy is perhaps arriving at this function with ->stat_cat_entries not set properly. Not sure why that would be. |
| 09:41 |
csharp |
dbwells: yeah, I think I'll add some debugging statements before trying the "revert" everything (in part because reverting the change is not straightforward) |
| 09:42 |
|
yboston joined #evergreen |
| 09:42 |
csharp |
of course, in the past when trying this approach, I only see things like ARRAY(XDF#@$@) |
| 09:43 |
csharp |
and I've never learned how to get the actual data |
| 09:43 |
dbwells |
csharp: Data::Dumper is your friend :) |
| 09:44 |
csharp |
yeah, I've not quite learned how to use it - my perl skills don't go very deep, and I get lost in the docs :-( |
| 09:45 |
Dyrcona |
AcceptItem, not RequestItem.... |
| 09:45 |
Dyrcona |
Today is not off to an auspicious start. |
| 09:57 |
|
berick joined #evergreen |
| 10:04 |
dbs |
Data::Dumper is everyone's friend! |
| 10:06 |
Dyrcona |
@praise Data::Dumper |
| 10:06 |
* pinesol_green |
Data::Dumper can run a report without assistance |
| 10:12 |
|
ericar_ joined #evergreen |
| 10:16 |
csharp |
huh - this is new - after changing the file to add Data::Dumper, I'm getting this seemingly unrelated error: Can't locate OpenILS/Application/Penalty.pm in @INC |
| 10:17 |
csharp |
and indeed, that doesn't exist on my system, nor in my branch, even though OpenILS::Application::Penalty is specified in opensrf.xml is specified and this has always worked before |
| 10:18 |
|
ericar_ joined #evergreen |
| 10:18 |
Dyrcona |
Was penalty recently removed? |
| 10:18 |
Dyrcona |
Something like that was.... |
| 10:18 |
tsbere |
csharp: That seems odd. It should be in /usr/local/share/perl/<version>/ or similar, I think... |
| 10:19 |
csharp |
...and indeed, it's not in the source code either |
| 10:19 |
csharp |
oh - was open-ils.penalty removed? |
| 10:19 |
csharp |
this might be a GenaSYS lag issue |
| 10:20 |
csharp |
(referring to our cluster-building scripts) |
| 10:20 |
tsbere |
That could be too. |
| 10:20 |
* tsbere |
doesn't recall if it was moved/removed |
| 10:20 |
csharp |
yup - it is removed |
| 10:23 |
bshum |
Definitely deprecated and removed. |
| 10:27 |
csharp |
yeah - it's a GenaSYS bug |
| 10:27 |
csharp |
damn - it really is Monday, isn't it |
| 10:37 |
bshum |
It might be. |
| 10:44 |
Dyrcona |
It definitely looks like Monday to me. |
| 10:47 |
csharp |
okay, I can see that $entries (my $entries = $copy->stat_cat_entries;) is "undef", but there are rows in asset.stat_cat_entry_copy_map for the copy in question, so why would it be returning undef? |
| 10:47 |
csharp |
<link field="stat_cat_entries" reltype="has_many" key="owning_copy" map="stat_cat_entry" class="ascecm"/> looks right |
| 10:50 |
berick |
csharp: i may be missing context here, but be sure whatever code fetches the copies is fleshing that field. |
| 10:51 |
csharp |
berick: I'm looking the update_copy_stat_entries sub in Open-ILS/src/perlmods/lib/OpenILS/Application/Cat/AssetCommon.pm |
| 10:52 |
Dyrcona |
You alos might be hitting lp 1496977. |
| 10:52 |
pinesol_green |
Launchpad bug 1496977 in Evergreen "Duplicate Code in O::A::Cat::AssetCommon" [Medium,Fix released] https://launchpad.net/bugs/1496977 |
| 10:52 |
csharp |
Dyrcona: aha! I think that's it |
| 10:52 |
bshum |
deja vu |
| 10:52 |
Dyrcona |
alos? aslo? olsa? ;) |
| 10:53 |
csharp |
I hit that before |
| 10:53 |
csharp |
but it was because of log noise, not data loss :-/ |
| 10:53 |
csharp |
@eightball it *is* Monday, right? |
| 10:53 |
pinesol_green |
csharp: NO. |
| 10:54 |
dbwells |
csharp: I thought you just applied that fix last week or so? |
| 10:54 |
* dbwells |
is confused |
| 10:55 |
csharp |
dbwells: I found it, but was waiting to do a full upgrade to 2.9.1 this weekend :-/ |
| 10:55 |
csharp |
needless to say, I'll at least be changing that on the live server |
| 10:55 |
csharp |
er.. live *test* server that is |
| 10:55 |
Dyrcona |
Yeah, it's a straightforward cherry-pick if you only want the one fix. |
| 10:55 |
csharp |
@blame csharp |
| 10:55 |
pinesol_green |
csharp: It really IS csharp's fault! |
| 10:55 |
csharp |
pinesol_green: yep |
| 10:55 |
pinesol_green |
csharp: http://images.cryhavok.org/d/1291-1/Computer+Rage.gif |
| 10:55 |
pinesol_green |
Factoid 'yep' not found |
| 10:56 |
Dyrcona |
pinesol_green should pick a different dunno. |
| 10:56 |
pinesol_green |
Dyrcona: Sorry, we can't do that because, you know, SOFTWARE. |
| 10:56 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 10:56 |
dbwells |
csharp: ah, ok. Sorry to rule it out prematurely! At least you got some basic exercise in using Data::Dumper :) |
| 10:56 |
Dyrcona |
@praise pinesol_green |
| 10:56 |
* pinesol_green |
In days of old, it was prophesied that a hero would come and restore karmic balance to #evergreen. itself is that hero. |
| 10:57 |
csharp |
dbwells: yes! thanks again for that tip |
| 10:57 |
dbwells |
"itself is that hero!" :D |
| 10:59 |
|
bwicksall joined #evergreen |
| 11:02 |
|
ericar_ joined #evergreen |
| 11:08 |
|
ericar_ joined #evergreen |
| 11:16 |
Dyrcona |
@praise 11 bshum |
| 11:16 |
* pinesol_green |
I come to praise bshum, not to bury them. |
| 11:20 |
csharp |
haha |
| 11:20 |
csharp |
@who came to bury bshum? |
| 11:20 |
pinesol_green |
hopkinsju came to bury bshum. |
| 11:20 |
bshum |
I always suspected! |
| 11:20 |
csharp |
oh, I nearly forgot |
| 11:21 |
csharp |
Dyrcona++ dbwells++ # helpin' |
| 11:23 |
|
sarabee joined #evergreen |
| 11:42 |
|
Christineb joined #evergreen |
| 11:44 |
jboyer-isl |
jeff_: When you have time to talk Twilio, let me know. I'm curious about some things. |
| 11:55 |
bshum |
Well this is fun |
| 11:56 |
bshum |
A circulation is supposed to get a max fine of $10.00 |
| 11:56 |
bshum |
Accruing at $1.00 per day |
| 11:57 |
bshum |
The item goes lost |
| 11:57 |
bshum |
And so the overdues get voided out |
| 11:57 |
bshum |
And a lost fee is added |
| 11:57 |
bshum |
Then the item gets returned, the lost fee is voided, and overdues are reinstated |
| 11:57 |
bshum |
But oddly, it has now $18.00 in overdues |
| 11:57 |
bshum |
Not just $10.00 |
| 11:57 |
* bshum |
wonders where the extra $8.00 came from |
| 11:58 |
csharp |
bshum: 10.00 on the same circ? or 2 circs (one renewal) |
| 11:58 |
bshum |
That... is a good question. |
| 11:58 |
bshum |
It is a -1 renewal |
| 11:58 |
bshum |
For the transaction ID anyways |
| 11:59 |
csharp |
well, what usually happens in that case (last I looked) is that the original circ's fines aren't removed by setting it lost and that confuses staff |
| 11:59 |
bshum |
Hmmmm |
| 11:59 |
tsbere |
bshum: Also check for manually added bills. Those never count towards max fines. |
| 11:59 |
csharp |
I bet a staff member did something and they aren't talking to each other |
| 12:00 |
csharp |
tsbere: ah - good point |
| 12:00 |
bshum |
tsbere: It's not manually added, according to the detailed history, I can see 18 $1.00 overdue materials entries. |
| 12:00 |
bshum |
And one 8.00 lost materials fee which is voided |
| 12:00 |
bshum |
The note on all the overdues is like: "System Generated Overdue FineSystem: VOIDED FOR BACKDATESystem: LOST RETURNED - OVERDUES REINSTATED" |
| 12:00 |
csharp |
what is the max fine on the circ row? |
| 12:00 |
bshum |
So something funky did happen |
| 12:00 |
bshum |
The max fine on the circ row itself is 10.00 |
| 12:00 |
tsbere |
bshum: Hmmmm. Could 8 $1.00 fees have been added before the 10 $1.00 fees were un-voided? |
| 12:01 |
tsbere |
Wait, there was a backdate void as well? That seems weird... |
| 12:01 |
bshum |
csharp: Shouldn't renewals split into separate xact IDs though? So I should see any overdues on separate line |
| 12:01 |
tsbere |
Unless lost voiding adds a backdate note |
| 12:01 |
csharp |
bshum: yes, they should not be the same xact |
| 12:02 |
dbwells |
tsbere: Yes, that "VOIDED FOR BACKDATE" message is bogus in some cases. I should file a bug about that. |
| 12:03 |
dbwells |
Basically, if you don't supply a void note, you get the "backdate" message :( |
| 12:04 |
bshum |
Hmmm |
| 12:04 |
bshum |
Interesting |
| 12:05 |
tsbere |
dbwells: I recall fixing an amnesty + backdate bug at one point....actually I seem to recall fixing that *twice* due to other work replacing the area the original fix was in... |
| 12:05 |
bshum |
So it does look like there's 8 overdues associated with this billing that predate the due date on the actual circulation row entry |
| 12:06 |
bshum |
And that matches up with what might be if the transaction occurred and was renewed |
| 12:06 |
bshum |
So it does seem like maybe it's from a previous circ and a new circ |
| 12:06 |
bshum |
And so $8 came from the first xact, and $10 from the second |
| 12:06 |
bshum |
But it's all put in the same line item in bills |
| 12:07 |
|
jmvwoolf joined #evergreen |
| 12:07 |
dbs |
Mmm, max fines makes me think of our penalty situation, which blocks users at our library once they reach max fines of $0.01 |
| 12:07 |
tsbere |
bshum: I believe bills tends to favor circ chains, not individual circs. I could be wrong. |
| 12:07 |
dbs |
Which is the policy our library wanted, but other libraries don't want those same users to be blocked at their libraries |
| 12:07 |
bshum |
tsbere: It seems logical to me |
| 12:08 |
bshum |
I just have to explain it to the library at some point. |
| 12:08 |
dbs |
but a penalty is a penalty across the board right? |
| 12:08 |
tsbere |
dbs: Not always. Some are applied at the threshold library, and you can set the depth it should jump to in most cases as well |
| 12:09 |
dbwells |
bshum: The explain-ain-ing is the hard-est part... ;) |
| 12:09 |
|
jeff joined #evergreen |
| 12:09 |
dbs |
tsbere: oh groovy! |
| 12:09 |
jeff |
jboyer-isl: what twilio things are you curious about? |
| 12:09 |
tsbere |
dbs: So if the penalty type is set to depth 0 then it will be "everywhere". Depth "null" should be "workstation or threshold depth" I believe. |
| 12:10 |
tsbere |
dbs: We have some "system local" ones set to depth 1 so that it applies to all branches in the system when staff apply them, for example, with the standard three manual ones set to depth 0 to be global. |
| 12:10 |
tsbere |
We also have had (dunno if we still do) some system and branch level limits... |
| 12:12 |
tsbere |
dbs: Fair warning: The system doesn't always play fully nice with the same penalty threshold at multiple levels from a clearing them POV. Staff may have to manually refresh patrons to re-generate them at times. |
| 12:12 |
bshum |
A negative renewals remaining number indicates staff forced renewal at the desk |
| 12:12 |
tsbere |
bshum: Generally true. |
| 12:12 |
bshum |
Hmm, maybe they edited the due date |
| 12:13 |
bshum |
It's just one xact row |
| 12:13 |
dbs |
hrm, csp.org_depth == NULL for the penalties in question |
| 12:13 |
tsbere |
dbs: And what org unit are the penalties being created with? |
| 12:14 |
dbs |
tsbere: Whatever in-db circ creates penalties at when the patron reaches max fine or max overdue count I guess |
| 12:15 |
dbs |
org_unit 1 I guess |
| 12:15 |
dbs |
actually, no, system depth |
| 12:16 |
tsbere |
dbs: And is the system where the penalty threshold is defined at? |
| 12:16 |
dbs |
So that makes sense, now I just need to figure out how to make it apply at the branch level |
| 12:16 |
* mmorgan |
catches up on bshum's bill issue, and would suspect an edited due_date, too. |
| 12:17 |
mmorgan |
But there would have to have been at least one renewal to get the -1 in allowed renewals. |
| 12:17 |
bshum |
mmorgan: I tracked the originating circ with the parent_circ |
| 12:17 |
bshum |
And that didn't have bills tagged to it |
| 12:18 |
bshum |
So I wonder if maybe it's a quirk in the fine catchup code |
| 12:18 |
bshum |
Where it missed that there were previous overdues because they happened before the due date |
| 12:18 |
bshum |
So it added max fines past the due date |
| 12:18 |
bshum |
Which exceeded the actual max fines that ought to be allowed |
| 12:18 |
bshum |
And it's cause there was staff intervention to edit the due date that led to an odd turn of events |
| 12:19 |
mmorgan |
ok. That's beginning to sound familiar. |
| 12:20 |
Dyrcona |
Tricksy staffsses.... |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:22 |
bshum |
I guess we'd have to look at where the fine catches up on checkins and see how it tallies things |
| 12:22 |
mmorgan |
bshum: lp 1393533? |
| 12:22 |
pinesol_green |
Launchpad bug 1393533 in Evergreen "New fines generated on lost return exceed max fine amount" [High,Fix released] https://launchpad.net/bugs/1393533 |
| 12:23 |
dbs |
tsbere: found them, it was system level in permission.grp_penalty_threshold. yay. |
| 12:23 |
bshum |
mmorgan: Hmm, since dbwells indicated that those commits were reverted, I guess it was dealt with then. But maybe it came back when we finally remerged everything |
| 12:26 |
bshum |
mmorgan: But yeah that definitely seems to be describing the problem that we're seeing there |
| 12:27 |
dbs |
tsbere++ |
| 12:28 |
bshum |
mmorgan: https://bugs.launchpad.net/evergreen/+bug/1443952 came later |
| 12:28 |
pinesol_green |
Launchpad bug 1443952 in Evergreen 2.8 "Fines can accrue past max (up to double) on lost item return with certain settings" [High,Fix released] |
| 12:28 |
bshum |
And that's also "fixed" |
| 12:28 |
bshum |
So I feel like this problem shouldn't be happening |
| 12:28 |
bshum |
But clearly something is still awry |
| 12:33 |
dbwells |
bshum: Is it possible that the $18 accrued while the bug was still in effect, then just got restored? And we are certain all 18 billings point to the same xact? |
| 12:33 |
bshum |
dbwells: I checked money.billing for the xact ID |
| 12:33 |
bshum |
And there were the 18 overdues there |
| 12:33 |
bshum |
I'm doublechecking when we upgraded :) |
| 12:34 |
bshum |
Okay, our last major upgrades were 2015-04-11 and 2015-10-10 |
| 12:34 |
bshum |
These things happened in between hmm |
| 12:35 |
bshum |
Yep |
| 12:35 |
bshum |
It's possible it's just an example of the bug |
| 12:35 |
bshum |
dbwells: Based on those dates, we may not have added 1443952 till after the events occurred |
| 12:36 |
bshum |
Guess it's hard to say when playing with live ammo during the 2.8 era |
| 12:36 |
bshum |
But... hmm |
| 12:36 |
bshum |
Hmm |
| 12:36 |
bshum |
I must have patched that |
| 12:37 |
bshum |
In live somewhere |
| 12:37 |
bshum |
Cause I mean, I pushed it to master/rel_2_8 according to the bug notes on 4/14 |
| 12:37 |
bshum |
So that was a few days after our major upgrade |
| 12:37 |
bshum |
Blergh |
| 12:37 |
* bshum |
*hates* billings |
| 12:38 |
mmorgan |
We had this issue with some hourly circs which caused us to add the patch shortly after upgrading to 2.8. Don't think we've seen the problem since, but I haven't gone looking. |
| 12:45 |
bshum |
Unrelated, iii-- #their users are causing me grief today cause they can't seem to understand FTP != SFTP (and I want them to use SFTP) |
| 12:46 |
bshum |
@dessert |
| 12:46 |
* pinesol_green |
grabs some of kmlussier's cookies for bshum |
| 12:46 |
bshum |
Perfect |
| 12:46 |
dbwells |
bshum: If you find the circumstances which can cause this on a current branch, I will drop everything and work out a fix. |
| 12:46 |
kmlussier |
bshum: Heh, good timing. I just made cookies over the weekend. |
| 12:47 |
bshum |
dbwells: Thanks man, if we can figure it out, I'll definitely write something up. But it could easily just be timing on our part as you say. |
| 12:47 |
bshum |
kmlussier: I could use a cookie. |
| 12:47 |
bshum |
Or lunch. |
| 12:47 |
bshum |
Maybe lunch is a good place to start. |
| 12:49 |
kmlussier |
bshum: There are a whole bunch at C/W MARS right now. Just take a drive up during your lunch hour. :) |
| 12:49 |
bshum |
kmlussier: Don't tempt me............ |
| 13:03 |
|
collum joined #evergreen |
| 13:07 |
|
sarabee joined #evergreen |
| 13:57 |
|
mdriscoll joined #evergreen |
| 14:15 |
collum |
http://www.cincinnati.com/story/news/2015/12/14/libraries-suit-ends-tax-rate-method-stays/77292992/ |
| 14:15 |
collum |
Yay! It's over. |
| 14:16 |
kmlussier |
collum: Congrats! |
| 14:22 |
kmlussier |
It's always interesting to see governance models from different states. It never even occurred to me that there are places where library boards could set tax rates. |
| 14:22 |
collum |
Yep. It was new to me when I moved here. |
| 14:29 |
|
mtj_ joined #evergreen |
| 14:29 |
|
ldw joined #evergreen |
| 14:30 |
|
ldw joined #evergreen |
| 14:46 |
kmlussier |
Bmagic++ #Setting up MOBIUS Sandbox for Bug Squashing Day |
| 14:53 |
|
bwicksall joined #evergreen |
| 14:54 |
csharp |
@who calls dibs on "MOBIUS Sandbox" as their band name? |
| 14:54 |
pinesol_green |
miker calls dibs on MOBIUS Sandbox as their band name. |
| 15:08 |
|
jlitrell joined #evergreen |
| 15:32 |
|
_bott_ joined #evergreen |
| 15:45 |
Dyrcona |
Whee! Fun with git and messed up rebases. |
| 15:50 |
kmlussier |
Bah! Just accidentally used the old #egils hashtag. |
| 15:50 |
jboyer-isl |
Dyrcona: quick NCIP Q if you know off hand, when the temporary users are created for remote circs, is that "real" information or are they dummy patrons? |
| 15:51 |
Dyrcona |
There are not temporary patrons. You need to pre-populate your database with remote users from a list provided by the vendor/service provider. |
| 15:52 |
Dyrcona |
And, not so coincidentally, it was NCIPServer that I'm having the git fun with. |
| 15:52 |
Bmagic |
SIP-- |
| 15:52 |
jboyer-isl |
Oh, that's a little gross. pre-populate as in "one user per remote system" or is this something that has to be done regularly? |
| 15:52 |
csharp |
sip-- |
| 15:53 |
jboyer-isl |
Dyrcona: so are you trying to merge better_abstraction with master, or is this just generic git issues? |
| 15:54 |
Dyrcona |
jboyer-isl: We get occasional updates for changes in information or new "patrons." |
| 15:54 |
Dyrcona |
jboyer-isl: Just general git issues, mostly me botching the work flow on the rebase. |
| 15:54 |
Dyrcona |
I edited a commit message and forgot a rebase --continue. |
| 15:55 |
Dyrcona |
Anyway. |
| 15:55 |
Dyrcona |
But basically, it depends on how you're setup with the system that you're talking to. In our case there is one patron per remote library. |
| 15:56 |
Dyrcona |
We get a spreadsheet with everybody in it, and I have a script to parse it and manage the creation of new accounts and updates of existing ones. |
| 15:58 |
jboyer-isl |
Excellent, that's what I was hoping. We want to know where items are, but not who has them (but none of their docs really spelled it out). I'm hoping the contract-types can get a move on soon, I'd rather make them answer these questions than have to bother you. |
| 15:58 |
jboyer-isl |
Dyrcona++ |
| 15:58 |
Dyrcona |
Most of the fun is figuring WTF is going with any particular NCIP implementation. |
| 15:59 |
Dyrcona |
jboyer-isl: I would think that as the Indiana State Library, you'd be the ones in charge of it? How are you going to use the ILL software? |
| 15:59 |
* Dyrcona |
needs to slow down. |
| 16:02 |
jboyer-isl |
We are, it's just that the state rules about talking to vendors before all of the papers are signed are such that I guess we can't ask them this stuff directly yet. Also it's not my project, I'm just the tech contact and responsible for the getting the Evergreen consortium connected. |
| 16:03 |
Dyrcona |
jboyer-isl: I'd think you would be making the decisions on that part of it. Basically, each library gets a "barcode." |
| 16:03 |
Dyrcona |
Here, we're using some codes assigned by the consortium that is running it on behalf of the state. |
| 16:05 |
Dyrcona |
Part of the fun has been making sure with get the proper shortnames from the other side to identify our locations. |
| 16:06 |
jboyer-isl |
I may, but we've not talked at all about implementation details yet (probably Jan for all of that). What we have done is started to put out presentations to drum up interest and now libs are asking questions I don't yet have answers to. |
| 16:06 |
Dyrcona |
Too many incorrect assumptions get made by all parties in these kinds of things, I have found. |
| 16:06 |
jeff |
"oh! when we said we wanted nightly extracts of your bibs and holdings, you thought we meant ALL of them? goodness no!" |
| 16:15 |
Bmagic |
anyone know off hand where in Evergreen the "quality" score of MARC is used? I see it in biblio.record_entry.quality |
| 16:16 |
Dyrcona |
I've used quality when deciding which bib to keep during a deduplication attempt. |
| 16:16 |
bshum |
What Dyrcona said |
| 16:17 |
Bmagic |
Nothing in the staff client? |
| 16:17 |
bshum |
Bmagic: Do you want to do something with it? :) |
| 16:18 |
Bmagic |
I want to make it better |
| 16:18 |
Dyrcona |
Oh, that's easy, just go to bib source and increase the base scores. :) |
| 16:18 |
Bmagic |
We found that the numbers do not support what we think of as the better record |
| 16:18 |
bshum |
Better... stronger... faster... |
| 16:18 |
Dyrcona |
Well, then, maybe lower the base score for OCLC. |
| 16:19 |
Bmagic |
"more accurate" |
| 16:19 |
Dyrcona |
I know what you mean. :) |
| 16:19 |
* Dyrcona |
tries to remember what calculates it, a db function, IIRC. |
| 16:19 |
Bmagic |
some years back, we consulted some librarians in a 4 hour powow, to come up with a scoring method |
| 16:19 |
Bmagic |
yes, it's a DB function |
| 16:20 |
Bmagic |
so, we have been using this other method to score MARC, for various reasons. I was thinking that this would be great in a z39.50 result set, we could sort the results by score |
| 16:20 |
Dyrcona |
yeah, I could see that being useful. |
| 16:21 |
Dyrcona |
Or in other places, maybe. |
| 16:21 |
Bmagic |
and basically do what BookWhere does. Some of our libraries go outside of Evergreen to find MARC records |
| 16:21 |
Dyrcona |
Turns out a number of ours are using the tool to turn Amazon into MARC or whatever that thing does. |
| 16:21 |
Bmagic |
One of the tools they use is basically a z30.50 tool with a "user friendly" 5 star rating system |
| 16:22 |
Bmagic |
All that Evergreen is lacking, is exposing the score in the results |
| 16:22 |
|
jonadab joined #evergreen |
| 16:22 |
Bmagic |
Dyrcona: haha - some of our libraries discovered that tool as well |
| 16:24 |
Bmagic |
kind of a side note: I migrated a library into our consortium who's old ILS DID NOT HAVE MARC. So I had to compose the MARC from the information that I could get from their old ILS. Part of that routine, was to go out to external places and attempt to find MARC |
| 16:24 |
jeff |
Heh. I had a query last week that shows records likely created from that tool, and another query that shows you the ones where staff didn't remove the Amazon referral link form the 856 tag. |
| 16:24 |
Bmagic |
I included code to scrape that amazon tool for the MARC! |
| 16:24 |
Bmagic |
jeff: I have a handy query to remove that link from the marc. I run it every now and then |
| 16:25 |
kmlussier |
Bmagic: Vandelay has a way to configure quality metrics for records and to use them to determine if a record should be overlaid or not. It would be nice functionality to leverage for Z39.50 searches. |
| 16:25 |
kmlussier |
http://docs.evergreen-ils.org/2.9/matchsets.html#_quality_metrics_2 |
| 16:25 |
|
jihpringle joined #evergreen |
| 16:25 |
Bmagic |
kmlussier: right! I had thought of that as well. |
| 16:25 |
Dyrcona |
Yep, that's where it mostly gets used. |
| 16:26 |
jeff |
I asked this question elsewhere last week, but here (and at least one other channel) seems a good audience also: |
| 16:26 |
Bmagic |
Anyway, I was thinking about submitting a wishlist item to get this other scoring algorithm into EG. Or at least expose our method of scoring for a bigger discussion |
| 16:27 |
jeff |
Other than general encoding errors/mix-ups, does anyone here have any examples of errors introduced by a batch update or import/export/re-import process due to a software flaw, not human error? |
| 16:27 |
jeff |
e.g., an error in a well-known tool like MarcEdit or MARC::Record or pymarc that left a lasting legacy on records |
| 16:27 |
jeff |
(and apologies to at least one person who has already seen that question) |
| 16:28 |
Bmagic |
jeff: I see diacritic issues all the time |
| 16:28 |
Bmagic |
although I can not say that they were caused by the import process |
| 16:29 |
Dyrcona |
jeff: We had some fun sorting out how not to send "on-order" records to Backstage. |
| 16:29 |
Bmagic |
I know for a fact that some of the MARC that I convert from other ILS's into XML for import into Evergreen, ends up with a certain number of diacritic issues |
| 16:29 |
Dyrcona |
Backstage would process them and send them back, and inevitably a cataloger had overlaid the record in the mean time, and the batch process would replace the good record with the old one. |
| 16:29 |
Bmagic |
and I have just accepted a level of error for that |
| 16:30 |
Dyrcona |
Bmagic: I get emails almost daily because there are things in UTF-8 records that can't go into MARC8, and some vendor wants MARC8. |
| 16:31 |
jeff |
Which vendor wants MARC8? |
| 16:31 |
jeff |
@who wants MARC8? |
| 16:31 |
pinesol_green |
mtj_ wants MARC8. |
| 16:31 |
Dyrcona |
Emails from cron, that is. |
| 16:31 |
jeff |
Dyrcona: I guessed. |
| 16:32 |
Dyrcona |
yep. just making it clear that it isn't the vendor emailing me. |
| 16:32 |
jeff |
Or vendor calling library staff and library staff emailing you? :-) |
| 16:32 |
Dyrcona |
ugh. |
| 16:34 |
kmlussier |
gmcharlt: Has user/gmcharlt/lp1508477-better-webstaff-hotkeys been added to webby? |
| 16:35 |
bshum |
iii-- # because the hits just keep on coming today... |
| 16:35 |
Dyrcona |
ftp-- |
| 16:35 |
Dyrcona |
sftp++ |
| 16:35 |
Dyrcona |
;) |
| 16:36 |
bshum |
ftp-- sftp++ # indeed, if only the rest of the world understood |
| 16:37 |
* kmlussier |
is going to answer her own question with a 'yes' based on a quick test of webby. |
| 16:37 |
tsbere |
ftps-- # Too many people assume it is interchangeable with sftp |
| 16:38 |
Dyrcona |
That's exactly bshum's problem as I understand it. |
| 16:41 |
bshum |
"You keep using that word. I do not think it means what you think it means." |
| 16:44 |
|
tsbere_ joined #evergreen |
| 16:49 |
|
mdriscoll left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:17 |
|
ningalls joined #evergreen |
| 18:17 |
|
rlefaive joined #evergreen |
| 18:33 |
|
jlitrell joined #evergreen |
| 18:45 |
|
sarabee joined #evergreen |
| 19:20 |
|
jihpringle joined #evergreen |
| 22:14 |
|
rlefaive joined #evergreen |
| 22:35 |
|
rlefaive joined #evergreen |
| 22:46 |
|
tsbere_ joined #evergreen |
| 23:02 |
|
tsbere__ joined #evergreen |
| 23:30 |
kmlussier |
@sortinghat |
| 23:30 |
pinesol_green |
Hmm... kmlussier... Let me see now... HUFFLEPUFF! |
| 23:32 |
bshum |
@sortinghat |
| 23:32 |
pinesol_green |
Hmm... bshum... Let me see now... SLYTHERIN! |
| 23:32 |
bshum |
:D |
| 23:32 |
kmlussier |
bshum: Darn! I wanted to be in Slytherin |
| 23:32 |
bshum |
Hacks |
| 23:36 |
|
rlefaive joined #evergreen |
| 23:40 |
|
HoloIRCUser1 joined #evergreen |
| 23:42 |
|
HoloIRCUser2 joined #evergreen |
