| Time |
Nick |
Message |
| 00:03 |
|
stevenyvr2 joined #evergreen |
| 00:03 |
|
stevenyvr2 left #evergreen |
| 00:41 |
|
stevenyvr2 joined #evergreen |
| 00:42 |
|
stevenyvr2 left #evergreen |
| 00:59 |
|
adbowling-isl joined #evergreen |
| 00:59 |
|
jboyer-isl joined #evergreen |
| 07:36 |
|
rjackson-isl joined #evergreen |
| 08:14 |
|
remingtron joined #evergreen |
| 08:40 |
|
Shae joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:48 |
|
RoganH joined #evergreen |
| 08:55 |
|
kbeswick joined #evergreen |
| 09:02 |
|
rfrasur joined #evergreen |
| 09:23 |
|
kbutler joined #evergreen |
| 09:30 |
|
hopkinsju joined #evergreen |
| 09:40 |
|
hopkinsju joined #evergreen |
| 10:18 |
phasefx |
csharp: sometime back someone sent a question to open-ils-general-owner. Do you see that? Have any clue on the answer? |
| 10:20 |
phasefx |
looks like whatever digest mode is doing, their email is still being seen by others okay, so probably not a big deal |
| 10:31 |
* csharp |
looks |
| 10:37 |
csharp |
http://www.list.org/mailman-member/node28.html looks relevant |
| 10:38 |
csharp |
I'll respond to him |
| 10:48 |
jboyer-isl |
Are there any downsides to creating additional MARC Record Attribute Definitions and coded value maps? (i.e. slowing something down, creating confusion for catalogers, etc.) For reference, I'm thinking of a new view of item_form for the advanced search page. |
| 10:50 |
|
hopkinsju joined #evergreen |
| 11:04 |
bshum |
Whoa, did the color of markmail change? It was red and now gray? |
| 11:05 |
* bshum |
assumes there was fancy upgrading involved |
| 11:06 |
phasefx |
csharp++ re: mailman |
| 11:09 |
bshum |
jboyer-isl: I haven't poked much at those, but my gut feeling is there's gotta be some reingest or such required in tweaking those. |
| 11:13 |
bshum |
Yeah I think I'm probably right |
| 11:13 |
bshum |
jboyer-isl: I'll refer to this old thread on the catalogers mailing list: http://list.evergreen-ils.org/pipermail/evergreen-catalogers/2013-April/000280.html |
| 11:14 |
bshum |
In that thread, gmcharlt gives an example of creating a new MARC Record Attribute and then reingesting the affected bibs |
| 11:16 |
jboyer-isl |
Ouch. That's the end of that idea. I was just hoping to not have to hard-code a search box, I'm thinking that looks pretty good now. |
| 11:17 |
bshum |
The dreaded word for me nowadays is "reingest" :( |
| 11:17 |
csharp |
jboyer-isl: that's the kind of thing we would add as a "feature" of the next upgrade since the reingest would be happening anyway ;-) |
| 11:17 |
bshum |
csharp++ |
| 11:17 |
csharp |
reindigestion-- |
| 11:17 |
bshum |
Precisely |
| 11:18 |
* berick |
chuckles |
| 11:19 |
csharp |
well, I'm glad I'm *not* running from master, because that seems to increase the number of reingests anyway |
| 11:19 |
csharp |
upgrading from 2.5-beta1 to 2.5-rc1 required one for instance |
| 11:20 |
bshum |
:D |
| 11:21 |
bshum |
If we hadn't caught onto it then, I think 2.5.1 would have been slightly more exciting down the road. Or maybe even 2.5.2... |
| 11:22 |
Bmagic|2 |
jeff: Eurika! The script was correct, the problem was the user that I was using to make the update penalties was not in the same OU as the target patron. With some expierementing, authenticating with a user that is in the same OU as the target, the script successfully created the overdue count penalty |
| 11:22 |
bshum |
Though, the same thing happened in 2.4.1 if memory serves. That there was a major last minute snafu that required poking at reingests. |
| 11:24 |
bshum |
I largely wish we could more accurately predict the outcome of reingest work. |
| 11:24 |
* csharp |
tries to fight off holiday fever |
| 11:24 |
jboyer-isl |
Well, I am thinking about this for an upgrade, I guess I just have to make sure it's definitely right ahead of time... |
| 11:24 |
bshum |
jboyer-isl: I say that every time we upgrade to my catalogers. "So you're sure you've picked all the fields you want?" |
| 11:25 |
bshum |
Because I'm not reingesting again till the next time I'm forced to :P |
| 11:25 |
rfrasur |
end users never know exactly what they want :D |
| 11:26 |
bshum |
Fortunately (or unfortunately), we seem to find plenty of times to force reingests. |
| 11:26 |
bshum |
@blame chaos monkey |
| 11:26 |
pinesol_green |
bshum: It really IS chaos monkey's fault! |
| 11:28 |
|
hopkinsju joined #evergreen |
| 11:44 |
jeff |
Bmagic|2: interesting. |
| 11:47 |
bshum |
Blah |
| 11:47 |
bshum |
I hate finding old bugs that got lost in the shuffles |
| 11:47 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/969312 has working code on there but was never targeted to a future branch |
| 11:47 |
pinesol_green |
Launchpad bug 969312 in Evergreen "No warning for Delete All from Catalog in Copy Buckets" (affected: 5, heat: 28) [Wishlist,Confirmed] |
| 11:48 |
jeff |
Bmagic|2: at what org unit was the group penalty threshold defined, and what home_ou was the target user and the calling user? i'm curious. |
| 11:48 |
bshum |
I'll assign it to 2.next this time... :9 |
| 11:48 |
csharp |
hmm - are there known problems with autocomplete and Firefox? |
| 11:49 |
bshum |
csharp: What sort of difficulities are you encountering? |
| 11:49 |
csharp |
at http://laurentian.concat.ca/eg/opac/home?locg=105 if I start typing "harr..." I don't get anything, but in Chromium, it works |
| 11:49 |
bshum |
Oh, autocomplete... not autosuggest |
| 11:49 |
bshum |
Or is that what you meant? |
| 11:50 |
csharp |
ah sorry - I did mean autosuggest |
| 11:50 |
bshum |
My kneejerk reaction is to blame it on ancient dojo |
| 11:51 |
bshum |
But there could be more to it |
| 11:52 |
bshum |
Hmm, clean master tests fine with Firefox 25.0.1 for me. But I can see what you mean about that particular catalog having issues. |
| 11:52 |
csharp |
https://catalogue.libraries.coop/eg/opac/home?physical_loc=1&locg= too |
| 11:53 |
csharp |
looks like it's off in Indiana |
| 11:53 |
bshum |
So it sounds like autosuggest is having some struggles with the latest Firefox |
| 11:53 |
Bmagic|2 |
jeff: ou penalty defined: 4 - target user: 4 calling user: 1 |
| 11:54 |
bshum |
And only on systems with say more than 100 bibs :) |
| 11:54 |
bshum |
Well, at least more than the sample data loaded |
| 11:56 |
csharp |
dayum |
| 11:56 |
csharp |
rfrasur++ |
| 12:02 |
jeff |
bshum: can you explain what you mean by "wish we could more accurately predict the outcome of reingest work"? |
| 12:03 |
bshum |
jeff: In our case, I'm thinking I need to apply some more testing methods to look for potential issues. |
| 12:03 |
bshum |
Or rather, learn how to do better testing |
| 12:04 |
bshum |
We have the servers presently to test full scale reingests of all our bibs, but this last round we made a huge glaring mistake by not noticing that an entire field was lost in the reingest process. |
| 12:04 |
bshum |
I'm referring to the alternate titles bug |
| 12:04 |
bshum |
But it didn't get noticed in our manual testing, and nobody saw it till a few days or weeks post upgrade / reingest |
| 12:05 |
bshum |
I guess it's hard to predict everything though |
| 12:05 |
bshum |
Given that we all have little tweaks to our metabib tables |
| 12:10 |
|
hopkinsju joined #evergreen |
| 12:15 |
|
kitteh_ joined #evergreen |
| 12:26 |
eeevil |
bshum: tangentially related: I'd like to see/do more work on ingest logic splitting. made some good progress in 2.5, but there's more to do, like splitting off record attrs as search/facet/browse are now |
| 12:27 |
|
stevenyvr joined #evergreen |
| 12:28 |
eeevil |
and then be able to subdivide even those, so you can reingest just one field/facet/attr. that's relatively easy to do in a naive, badly-performing way, hard to make fast in both the reingest-one-part and reingest-all-parts cases |
| 12:36 |
bshum |
eeevil: That sounds like it could be fun |
| 12:38 |
|
mjingle joined #evergreen |
| 13:12 |
RoganH |
Quick question because I haven't messed with the circ_matrix_limit_set_map yet. If I set fallthrough to true does it fall through on any null values set in the matchpoint? |
| 13:13 |
bshum |
Hmm |
| 13:13 |
bshum |
I don't remember exactly how that works |
| 13:13 |
bshum |
tsbere probably would, but not sure he's around. |
| 13:14 |
csharp |
RoganH: give me a minute to parse your question and remember what the answer is ;-) |
| 13:14 |
RoganH |
csharp: you haven't even filled up on turkey yet and mind is going blank? |
| 13:14 |
bshum |
I have this feeling the fallthrough means let the limit apply to any circ matchpoints it can link to |
| 13:15 |
csharp |
RoganH: if fallthrough is set to false, the limit set will only apply to the matchpoint if it's the one that "wins" |
| 13:15 |
bshum |
So that if you attach it to rule 37 and rule 37 gets combined with rules 1, 2, 3, it'll still apply the limit set |
| 13:15 |
csharp |
bshum: exactly |
| 13:15 |
RoganH |
gotcha, thanks |
| 13:15 |
RoganH |
csharp++ |
| 13:15 |
RoganH |
bshum++ |
| 13:15 |
csharp |
it allows you to say "only apply the set if this specific rule matches" |
| 13:16 |
RoganH |
it's not immediately relevant but if I ever get around to trying to clean some of this up I'll probably make use of that |
| 13:16 |
RoganH |
right now I just ran into it while doing a more immediate task |
| 13:17 |
csharp |
it's handy to be able to apply circ limits to specific circ modifiers (like DVDs or other high-demand items) |
| 13:17 |
csharp |
we don't have rules on copy locations, but that sounds handy too ;-) |
| 13:17 |
RoganH |
I do that already but I'm considering using the fall through in the future to reduce the number of specific rules in some cases |
| 13:17 |
csharp |
fallthrough++ |
| 13:18 |
eeevil |
the_term_fallthrough-- |
| 13:19 |
csharp |
heh |
| 13:19 |
eeevil |
(says the guy what thought up "conjoined items") |
| 13:19 |
csharp |
eeevil++ |
| 13:20 |
eeevil |
though, in fairness, vandelay is a good/cool name for what it does, so I've got at least one good name to my credit ;) |
| 13:21 |
eeevil |
doesn't balance the more than one less-good name, but I'll claim it proudly ;) |
| 13:27 |
csharp |
eeevil: don't forget Clark Kent ;-) |
| 13:33 |
bshum |
So hmm |
| 13:33 |
bshum |
In troubleshooting some other unrelated stuff |
| 13:34 |
bshum |
I see in "fetch_user_circs" that we don't include LOST, CLAIMSRETURNED, LONGOVERDUE among circs retrieved. |
| 13:34 |
bshum |
And this is why those transactions don't show in My Account to patrons. |
| 13:34 |
bshum |
I'm pondering the logic behind those decisions. Especially the LOST ones. |
| 13:35 |
bshum |
Some folks on my end have been trying to figure out why LOST transactions weren't showing as checked out to patrons in their accounts in TPAC, while the staff client did show the full details. |
| 13:35 |
bshum |
I'm wondering if this is oversight or some legacy choice when it was first coded up |
| 13:36 |
bshum |
Or if there's intentional reasons for excluding them from being listed. |
| 13:36 |
eeevil |
bshum: the answer to that would probably be found in comparing the call used by the JSPAC |
| 13:37 |
eeevil |
but I'm at lunch! **disappears** |
| 13:37 |
bshum |
My lunch just arrived so I'll ponder it afterwards. |
| 13:38 |
mmorgan |
bshum: For after lunch: Are these LOST, but not yet paid for? Or is there a difference? |
| 13:38 |
bshum |
mmorgan: There isn't a difference as far as I can tell. |
| 13:39 |
bshum |
mmorgan: Actually the things that are lost and not paid for (that actually have real bills) show up in the bills part of My Account |
| 13:39 |
bshum |
So at least there's that |
| 13:40 |
mmorgan |
Hmm. Could definitely be a problem if Lost and paid show up with current checkouts. |
| 13:40 |
bshum |
mmorgan: That's what I'm thinking too, but that all largely depends on how the lost library settings are done in the system |
| 13:41 |
bshum |
Otherwise, a transaction that closes when fines are paid, I would expect to not show in checked out anymore at all. |
| 13:41 |
bshum |
Even in staff view |
| 13:41 |
eeevil |
bshum: ah... then I think what it's doing is correct. lost, longoverdue (arguably) and claims-returned aren't really "checked out" anymore, and only the money matters (for the first 2) |
| 13:41 |
bshum |
So this can be super complicated depending on how one sets up Evergreen |
| 13:47 |
csharp |
so I guess it comes down to whether you(/we/anyone) define "lost" to mean "still checked out" |
| 14:31 |
bshum |
mmorgan: Part of me wonders if maybe after MVLC does their "Lost & Paid" status development, maybe that'll be when we can keep LOST as showing but have the new lost and paid hidden from view. |
| 14:31 |
bshum |
Maybe I'll check with Dyrcona on that when we all get back after the holidays. |
| 14:33 |
mmorgan |
bshum: That sounds logical. Right now, LOST can mean too many different things so it's hard to make blanket decisions on where it should show. |
| 14:34 |
bshum |
mmorgan: Yeah I agree. I think we're going to table the discussion on our end till we get further along. |
| 14:34 |
bshum |
The fun one for us right now is defining how LOST works with the new penalty we've setup to define PATRON_EXCEEDS_LOST_COUNT |
| 14:35 |
bshum |
With it set to 1 and you're blocked, people are staying blocked even though they appear to have paid off their lost bills. Kind of a wacky unforseen issue in our system. |
| 14:35 |
bshum |
I think we can get around it by closing out the transactions |
| 14:35 |
bshum |
But then I think people want to still *see* those LOST transactions on their record till they check in / delete the items |
| 14:35 |
bshum |
It's confusing :( |
| 14:35 |
bshum |
My head hurts |
| 14:37 |
bshum |
ldwhalen: If/when you get some free time, I'm curious to know how your changes turned out for https://bugs.launchpad.net/evergreen/+bug/925776 |
| 14:37 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 4, heat: 22) [Medium,Confirmed] |
| 14:37 |
bshum |
I'd like to get all of them together into a working branch so that we can test it out as well down the road. |
| 14:38 |
mmorgan |
bshum: So "people" meaning staff still want to see the Lost items on patron accounts after they're paid? |
| 14:38 |
bshum |
mmorgan: Right, staff :P |
| 14:39 |
bshum |
I think that's just so that until the lost item is actually dealt with, they want to know who had it last and quickly see that when they pull up the record. |
| 14:39 |
mmorgan |
Just curious as to why staff need to see them associated with the patron ... |
| 14:40 |
bshum |
I actually don't really get how that's different than just pulling up the last patron to circ the item via the recent patrons list |
| 14:47 |
|
dbwells joined #evergreen |
| 14:47 |
dbs |
bshum: agreed, looks like the lack of autosuggest is a firefox-specific issue; see also https://catalogue.libraries.coop for a recent-ish example where it works in current Chrome but not current Firefox |
| 14:47 |
dbs |
Oh our aging dojo |
| 14:48 |
dbs |
aging, non-accessible dojo :) |
| 14:49 |
RoganH |
dojo-- |
| 14:52 |
jeffdavis |
does it work in IE? |
| 14:53 |
* dbs |
does not have easy access to IE atm |
| 14:53 |
dbs |
jeffdavis: fwiw I was pointing at Sitka's catalogue as a partner in crime to Conifer's, which exhibits the same behaviour |
| 14:55 |
jeffdavis |
I'm just surprised we haven't had a support request about it ;) |
| 14:56 |
bshum |
Yeah I saw it in SCLENDS catalog too with new Firefox |
| 14:56 |
|
stevenyvr joined #evergreen |
| 14:56 |
bshum |
That said, I got my recent master server to work |
| 14:56 |
bshum |
So I'm not sure why it's dying out |
| 14:58 |
bshum |
The demo server from ESI is working just fine too |
| 14:58 |
bshum |
http://demo.evergreencatalog.com/eg/opac/home |
| 14:58 |
bshum |
So it seems okay with small databases |
| 15:01 |
dbs |
Or perhaps with default settings |
| 15:01 |
bshum |
Hmm, perhaps |
| 15:02 |
dbs |
It doesn't make sense to me that firefox would care about how long it takes for a request to return, vs. chrome |
| 15:02 |
jeffdavis |
mjingle just tested IE and it works, fwiw |
| 15:03 |
dbs |
watching the network requests in firefox suggest that it never actually sends a request |
| 15:09 |
bshum |
Autosuggest doesn't seem very happy with IE11 fwiw |
| 15:09 |
bshum |
Not sure which IE mjingle was poking with |
| 15:11 |
bshum |
But with my IE11, the demo site looks fine for autosuggest too. |
| 15:11 |
bshum |
Ho hum |
| 15:17 |
mjingle |
bshum: didn't check. Laptop currently away from me now. however OS = Windows8 |
| 15:18 |
bshum |
The default for Win8 is IE10, unless it was updated to 11, I think. |
| 15:19 |
bshum |
I think 11 might be new for 8.1 |
| 15:19 |
* bshum |
doesn't really track these things often |
| 15:22 |
mjingle |
Can check within an hour, methinks... |
| 15:23 |
bshum |
mjingle: No rush, but thanks for taking a look for us! |
| 15:46 |
jboyer-isl |
@later tell jeff Hey, I heard back from my old library: if you've got a penalty on your account Bibliotheca's Liber8 selfcheck doesn't even let you log in. There are "My Account" and "Checkout" options if your account is ok. |
| 15:46 |
pinesol_green |
jboyer-isl: The operation succeeded. |
| 15:47 |
jeff |
jboyer-isl: thanks for checking. :-) |
| 15:47 |
jboyer-isl |
No problem. |
| 15:48 |
jeff |
jboyer-isl: i'm in the process of testing things here. i'm able to let a patron who could not otherwise circ but can perform renewals to get in and do a renewal, and they're still rejected at checkout time, but the message is a tad too generic, so i'm going to improve that. |
| 15:55 |
|
stevenyvr joined #evergreen |
| 16:20 |
|
gmcharlt joined #evergreen |
| 16:31 |
|
mmorgan1 joined #evergreen |
| 16:32 |
|
mmorgan1 left #evergreen |
| 16:49 |
|
mmorgan joined #evergreen |
| 17:07 |
|
hopkinsju left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:42 |
|
stevenyvr joined #evergreen |
| 18:03 |
mjingle |
bshum: So IE browser used was 10.0.9 |
| 18:21 |
|
liteIRC_ joined #evergreen |
| 18:38 |
|
kitteh_ joined #evergreen |
| 19:48 |
|
stevenyvr2 joined #evergreen |
| 20:05 |
|
stevenyvr2 left #evergreen |
| 23:55 |
dbs |
bshum++ |
| 23:55 |
bshum |
dbs++ |
