| Time |
Nick |
Message |
| 02:05 |
|
fparks joined #evergreen |
| 02:40 |
paxed |
hm. so TPAC doesn't support metarecord holds? i'm boggled. |
| 02:40 |
paxed |
our patrons would scream murder if that didn't work. |
| 03:11 |
paxed |
(assuming i understood things correctly...) |
| 05:26 |
paxed |
is it intentional the "random" password in Patron Reg (uEditMakeRandomPw() in register.js) is right-padded with zeroes, instead of left-padded? if the rand number is 1, 10, 100 or 1000, the password will be "1000" |
| 07:09 |
|
timf joined #evergreen |
| 07:31 |
|
collum joined #evergreen |
| 07:32 |
csharp |
bug 1053397 |
| 07:32 |
pinesol_green |
Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" (affected: 4, heat: 26) [Wishlist,Confirmed] https://launchpad.net/bugs/1053397 |
| 07:34 |
csharp |
the "guts" for metarecord holds are still there. I have no idea what's required on the front end to get it working in tpac |
| 07:42 |
csharp |
funny, I think I may have heard like 2 complaints about it since moving to TPAC in March, so I'm not sure it's a big deal for us... |
| 07:43 |
paxed |
or maybe i've misunderstood the concept? |
| 07:44 |
csharp |
it's so a patron can place a hold on a title, regardless of format (e.g. regular print, large print, audio, video) |
| 07:45 |
paxed |
oh. so it's for the format that's the defining factor there. |
| 07:45 |
csharp |
it "joins" all the related titles together for the sake of the hold |
| 07:45 |
csharp |
s/titles/bibs/ |
| 07:45 |
paxed |
ok, i don't think that's such an important one after all. |
| 07:46 |
|
jboyer-isl joined #evergreen |
| 07:46 |
csharp |
it can be a big deal if cataloging quality is poor - e.g., many copies of Gone with the Wind on separate records |
| 07:46 |
csharp |
but that's been improved a lot in our system |
| 07:47 |
paxed |
so the "normal" hold is when a patron places a hold on a book, he gets the first available copy (with the same format), or does he have to explicitly put hold on the free one? |
| 07:47 |
csharp |
first available copy |
| 07:48 |
paxed |
ok. thanks. |
| 07:48 |
csharp |
hold is placed on the bib (normally), so any eligible copy (that is, marked holdable, not in a bad status, etc.) attached to that bib is game |
| 07:49 |
csharp |
paxed: so is there still a race between EG and Koha for your institution? ;-) |
| 07:49 |
|
rjackson-isl joined #evergreen |
| 07:50 |
* csharp |
has been watching with interest |
| 07:50 |
paxed |
i really don't know. |
| 07:50 |
csharp |
just curious |
| 07:51 |
paxed |
as far as kivilahtio is concerned, it's koha all the way down. |
| 07:51 |
csharp |
I'm really interested in what sorts of features/lack of features/showstoppers libraries find to be decisive when evaluating EG |
| 07:51 |
csharp |
since it was developed for PINES, I have a very insider-y view of it all ;-) |
| 07:52 |
paxed |
i wasn't involved when they evaluated EG and Koha, but i think it was the hierarchical structure. |
| 07:52 |
* csharp |
keeps saying he needs to start getting familiar with Koha but never seems to find the time |
| 07:52 |
paxed |
tree structure for the consortia, etc. |
| 07:53 |
csharp |
makes sense |
| 07:54 |
paxed |
i think kivilahtio got scared that Eg is too complex and we can't possibly fix everything we need before deployment. |
| 07:55 |
paxed |
in a recent meeting someone compared Eg to Lego Technic and Koha to Duplo |
| 07:55 |
csharp |
yeah - you guys revealed some "growing edges" in i18n, shall we say ;-) |
| 07:55 |
csharp |
ha! |
| 07:56 |
paxed |
the i18n is basically good now (other than a xulrunner bug on win32), but there's so much other stuff that we need. |
| 07:56 |
paxed |
also, Koha would need to be translated - and i've come to hate their translation toolchain. |
| 07:58 |
paxed |
but, in few weeks, we're going to a meeting in northern Finland, and hash our all this stuff with the consortias from up north and couple others. |
| 07:58 |
paxed |
hash out* |
| 07:59 |
paxed |
if thiif this isn't resolved there, i'm seriously considering quitting. |
| 08:00 |
csharp |
I'll be interested to hear about how that turns out |
| 08:00 |
paxed |
"thiif"? where did that come from ... |
| 08:01 |
csharp |
heh |
| 08:01 |
paxed |
i guess my fingers can't keep up with my brain, or vice versa. |
| 08:02 |
* jeff |
yawns |
| 08:02 |
jeff |
morning! |
| 08:02 |
paxed |
afternoon. |
| 08:02 |
csharp |
morning |
| 08:02 |
paxed |
dreary. |
| 08:23 |
paxed |
csharp: how do you handle when patron wants to place a hold on a book, and doesn't care which edition he gets? does normal hold, or metarecord hold handle that kind of situation? |
| 08:24 |
csharp |
paxed: metarecord holds would do that, yeah - without metarecord holds, you have to place separate holds on each edition |
| 08:24 |
paxed |
ok |
| 08:26 |
paxed |
do you know off the top of your head what fields the metarecord hold looks for to determine which records are the same? |
| 08:26 |
csharp |
not off the top of my head... |
| 08:27 |
csharp |
I believe biblio.record_entry.fingerprint is consulted, but I may be wrong |
| 08:29 |
csharp |
yeah - metabib.metarecord maps each metarecord to the source bib and uses fingerprint to match, looks like from the DB view |
| 08:30 |
|
Shae joined #evergreen |
| 08:32 |
csharp |
s/DB view/DB perspective/ - since "view" has an unambiguous meaning in the db context ;-) |
| 08:34 |
|
berick joined #evergreen |
| 08:36 |
|
akilsdonk joined #evergreen |
| 08:38 |
|
mrpeters joined #evergreen |
| 08:40 |
|
Dyrcona joined #evergreen |
| 08:46 |
|
rfrasur joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:50 |
paxed |
apparently in our current ILS it's possible to do a ... "selected records" hold. patron does a search, and can tick records he wants to put a hold on, and all of those are considered filled when any one copy of the selected records is caught. |
| 08:52 |
csharp |
sounds like a nice feature |
| 08:52 |
rfrasur |
Yeah, it does. |
| 08:54 |
|
kbeswick joined #evergreen |
| 08:54 |
|
_zerick_ joined #evergreen |
| 08:56 |
|
ericar joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:01 |
|
ningalls joined #evergreen |
| 09:02 |
|
graced_ joined #evergreen |
| 09:06 |
rfrasur |
(all the times...where do they go? can we buy extras?) |
| 09:12 |
|
dkyle joined #evergreen |
| 09:14 |
dbs |
Huh. I wonder how much usage that feature actually gets. Sounds like it would be a complex thing for patrons to figure out, but I could see staff using it. |
| 09:24 |
_bott_ |
Is there anyone from LYRASIS in the room? |
| 09:24 |
rfrasur |
yeah, I can see staff using it more so than patrons...although some power patrons might. |
| 09:25 |
rfrasur |
hah...power patrons. |
| 09:28 |
jeff |
arbitrary alternate holds was something we had and used often, mostly for things that metarecord holds can do, but not exclusively. it was also used for "i need one of these books about dogs, i don't care which one" |
| 09:28 |
jeff |
and it was exclusively used by staff -- there was no patron interface |
| 09:29 |
rfrasur |
that's also something we'd probably use but not very often. |
| 09:29 |
jeff |
it was also frequently used when we had rentals that were holdable. some people wanted the first available copy, and didn't care if that meant they paid a rental fee -- some patrons preferred not to pay the rental fee, and would wait for a non-rental copy of the title. |
| 09:30 |
jeff |
in our prior system, the rental copies and non-rental copies were on distinct bibs to support this. |
| 09:30 |
rfrasur |
do you still have rentals? |
| 09:30 |
jeff |
we have since eliminated rentals, and our "hot" titles are non-holdable. there are typically still both hot and non-hot copies, and they are no longer artificially on distinct bibs. |
| 09:31 |
rfrasur |
gotcha. makes sense. |
| 09:31 |
jeff |
so that use case is gone -- the "don't surprise me with a rental copy" case |
| 09:31 |
jeff |
i don't know how often the "give me one of these books about dogs" use case was encountered. |
| 09:37 |
rfrasur |
o0(why Excel? why do you hate me today?) |
| 09:37 |
jeff |
_bott_: the only nickname i see present that i associate with Lyrasis ends in _away, so that might be a no. |
| 09:38 |
jeff |
rfrasur: because #REF! |
| 09:39 |
rfrasur |
hah...#REF are my initials. Sounds about right. |
| 09:39 |
* rfrasur |
IS the wrench in the machine. |
| 09:40 |
* rfrasur |
thinks about cursing indignantly against the fates. |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:41 |
rfrasur |
o0(and now the public computers won't turn on...wt(f or h...take your pick)) |
| 09:41 |
* csharp |
always enjoyed his reference job more when the public PCs weren't working ;-) |
| 09:43 |
* rfrasur |
has never been a reference librarian. |
| 09:52 |
rfrasur |
My kingdom for a big stock of brand new surge protectors. |
| 10:01 |
|
hangermeet_agent joined #evergreen |
| 10:08 |
rfrasur |
Yay...all the things fixed. w00t Monday. |
| 10:11 |
|
yboston joined #evergreen |
| 10:24 |
Dyrcona |
I'm feeling a bit lazy, and Holds.pm is a mess anyway, so I'll ask. |
| 10:25 |
Dyrcona |
Are closed dates meant to affect hold fulfillment, i.e. if the pickup_library is closed on the date the hold targeter runs will its holds be skipped? |
| 10:27 |
Dyrcona |
As far as I am able to tell, the answer is "No." |
| 10:28 |
csharp |
I thought so |
| 10:28 |
csharp |
I mean to say, I *think* it *does* make the targeter skip |
| 10:32 |
bshum |
To my recollection |
| 10:32 |
bshum |
If a library is marked closed, no holds will target for that pickup lib |
| 10:32 |
bshum |
During that day |
| 10:33 |
Dyrcona |
Yes. I was looking in the wrong place. I'm deciphering the runes in O::A::Publisher::Storage::action |
| 10:35 |
bshum |
Someone was actually complaining about holds not targeting closed libs the other day. |
| 10:35 |
bshum |
Because they were open while others were not. |
| 10:35 |
Dyrcona |
There is also a setting that controls this, circ.holds.target_when_closed, just for the sake of completeness. |
| 10:35 |
Dyrcona |
We have a member closing for two weeks. |
| 10:36 |
csharp |
yeah - we set that setting to true and they don't get targeted |
| 10:36 |
Dyrcona |
Oh, and I inverted two of the module names above, it should be: OpenILS::Application::Storage::Publisher::action |
| 10:36 |
csharp |
I mean false, I guess |
| 10:37 |
Dyrcona |
csharp: or just don't set it. |
| 10:40 |
Dyrcona |
Naturally, we have that setting turned on consortium-wide. |
| 10:40 |
Dyrcona |
Back to the code to see if it obeys the hierarchy. |
| 10:42 |
dbwells |
dbs++ # reviewing branches on the weekend :) |
| 10:43 |
Dyrcona |
Errm.... Looking at the code again, that setting doesn't do what *we* thought it did. |
| 10:44 |
Dyrcona |
It checks based on the copy's circ lib, not the pickup lib. I haven't yet seen anywhere in action.pm that it applies to the pickup lib. |
| 10:44 |
* Dyrcona |
looks some more. |
| 10:44 |
dbs |
dbwells: I can't resist the lure of cleaner HTML + CSS |
| 10:45 |
rfrasur |
dbs++ |
| 10:46 |
dbs |
dbwells++ # for actually doing the cleaning! |
| 10:46 |
rfrasur |
dbwells++ |
| 10:46 |
jeff |
Dyrcona: is your focus on items being picked from the shelves at the library that is closed, or items transiting there from other libraries during the closed time? |
| 10:46 |
jeff |
Dyrcona: it sounds like the latter. |
| 10:46 |
rfrasur |
All_the_Dans++ |
| 10:47 |
jeff |
Dyrcona: short of suspending the holds that have the closed library set as their pickup_lib (which has a number of issues), i don't think there is current code that will do what you want. |
| 10:47 |
jeff |
Dyrcona: but if I'm wrong, let me know! :-) |
| 10:49 |
Dyrcona |
jeff: You are correct, sir! |
| 10:50 |
jeff |
short of adding new code, most of the tricks you can try will look a bit odd to patrons. |
| 10:50 |
jeff |
but suspending the holds is likely going to involve the least amount of consternation. |
| 10:50 |
jeff |
stash a list of the holds that you suspended (that were not already suspended), and un-suspend them a day or two before open. |
| 10:51 |
jeff |
some patrons will unsuspend their own holds, and new holds will not be suspended... |
| 10:51 |
jeff |
or -- perhaps better, but slightly more under the hood -- adjust the proximity / boundary for the holds that are for pickup at that lib. |
| 10:52 |
jeff |
so that they will not pull from copies at any other libraries. |
| 10:52 |
jeff |
then set it back before they open. |
| 10:52 |
jeff |
(using the same "stash a list of the ids you changed" method, since someone could edit their pickup lib) |
| 10:54 |
jeff |
you could change defaults for that lib during the close time |
| 10:54 |
Dyrcona |
Yeah, I thought of the latter, basically turning them off temporarily. |
| 10:55 |
Dyrcona |
I don't like any of the "solutions" other than make hold targeter skip pickup libs when closed. |
| 10:55 |
Dyrcona |
For it to be effective though, it would probably need some "slop." |
| 10:57 |
Dyrcona |
Hm... |
| 10:57 |
* Dyrcona |
runs off to calculate the "average" time things spend in transit, if he can. |
| 10:57 |
* jeff |
nods |
| 10:57 |
|
ericar joined #evergreen |
| 10:58 |
jeff |
unless you have libraries that are closed for several days in a row on a frequent basis, it might be better to have a normally unset OUS that says "don't capture holds for this pickup library" |
| 10:59 |
csharp |
I thought that's what "skip for hold targeting" did? |
| 10:59 |
csharp |
oh wait - the pickup lib |
| 10:59 |
csharp |
nevermind |
| 11:00 |
jeff |
csharp: that will take care of "don't ask staff to pull items from $CLOSED_LIB's shelves, staff won't be there", but the intent here is to prevent items from other libraries from being sent to fulfill holds at $CLOSED_LIB, since the patrons will not be able to get them, and the items will sit unused. |
| 11:02 |
csharp |
that's a great point |
| 11:03 |
Dyrcona |
jeff: That's a thought. |
| 11:03 |
Dyrcona |
I got a bit more precision that I expected: 2 days 20:57:13.369663 |
| 11:04 |
Dyrcona |
s/that/than/ |
| 11:04 |
jeff |
nice. is that excluding outliers? |
| 11:04 |
Dyrcona |
Nope. That just the average all dest_recv_time - source_send_time where both are not null. |
| 11:04 |
Dyrcona |
Whoa. Can't seem to type today. |
| 11:05 |
jeff |
i don't think we see that kind of performance with our transits, though that could be due to the statewide nature of the delivery system, and that county transits are (afaik) not exempt from the regional sorting hubs. |
| 11:08 |
Dyrcona |
Based on my anecdotal experience, we have pretty good delivery, and I guess the query backs that up. |
| 11:09 |
Dyrcona |
Oh. This would wreak havoc with single-day closings..... |
| 11:10 |
jeff |
Dyrcona: did you exclude self-transits? |
| 11:10 |
Dyrcona |
jeff: No, I didn't. Guess I should. We have a few of those, I'm sure. |
| 11:11 |
Dyrcona |
Still, not bad: 2 days 21:25:34.577243 |
| 11:11 |
jeff |
nice. |
| 11:11 |
csharp |
"5 days 13:32:58.353526" - since 1/1/13 |
| 11:12 |
csharp |
that's mostly because of internal courier services |
| 11:12 |
csharp |
we do statewide hq to hq courier |
| 11:12 |
csharp |
and that's probably more like 2 days |
| 11:13 |
jeff |
interesting. only 22% of our transits in the last 30 days were self-transits. i would have thought that number was higher. |
| 11:14 |
jeff |
only one branch uses capture local holds as transits, but it is where a large percentage of circ is done. |
| 11:14 |
Dyrcona |
One of our libraries uses that setting for their automated materials handler. |
| 11:17 |
jeff |
same. inside rfid bookdrop and two returns (one staff, one drive-through) attached to a sorter. |
| 11:18 |
Dyrcona |
I wonder if it is really worth coding something up. |
| 11:18 |
Dyrcona |
I suppose the check should be made optional. |
| 11:19 |
|
test1215415 joined #evergreen |
| 11:19 |
Dyrcona |
It should calculate the average "fulfillment time" and only apply on closings of that duration or greater. |
| 11:19 |
|
test1215415 left #evergreen |
| 11:19 |
jeff |
you might be bordering on overthinking. :-) |
| 11:20 |
Dyrcona |
It should not target holds average fulfillment time before the close start and start targeting again average fulfillment time before close end. |
| 11:20 |
jeff |
at least, your statements are causing me to overthink. |
| 11:20 |
Dyrcona |
It seems pretty simple to me, as simple as anything can be in an ILS. :) |
| 11:22 |
Dyrcona |
Heh. I should write this up as an enhancement and look for sponsors. :p |
| 11:25 |
jboyer-isl |
Was there a discussion recently about possibly adding a flag or two to copy statues so some of the lists of "magic" statues can be replaced by a SELECT id FROM etc... instead of status IN (0,3,7,etc.)? |
| 11:25 |
jeff |
jboyer-isl: there was some discussion about where certain statuses where hardcoded. |
| 11:26 |
jboyer-isl |
jeff: Did anything come of it? |
| 11:26 |
jeff |
jboyer-isl: what did you have in mind? |
| 11:27 |
jboyer-isl |
We're looking to add a Display status so you'd have some idea where an item is if it's not on the shelf. But it's id won't be in any of the lists, so Display items would require an override. |
| 11:27 |
jeff |
jboyer-isl: ah. we use a number of display shelving location for that -- then the catalog tells patrons exactly where the item they're looking for is. :-) |
| 11:27 |
Dyrcona |
jboyer-isl: Display probably works better as a copy location. |
| 11:28 |
jboyer-isl |
I found the right list to add it to, but just tacking on a "circulate?" flag or something similar (possibly 2-3 flags? "Good" vs. "Bad"?) to that table would take care of several lists. |
| 11:28 |
Dyrcona |
jboyer-isl: I'd suggest that using a copy status is "doing it wrong." |
| 11:28 |
jeff |
what we'd be interested in there is a way to return the item to its original location -- similar to copy transparencies original intent, as i understand it. |
| 11:28 |
jboyer-isl |
Drycona: The intent is that when it's checked in, it just goes back to "normal." Which does happen with statues. |
| 11:29 |
Dyrcona |
jboyer-isl: Um, why? So, its only on Display for a single circ? |
| 11:29 |
rfrasur |
o0(I've never known a statue to be normal) |
| 11:29 |
jeff |
in our case, we have an alert message on the copy location so that the items go back to the display when returned |
| 11:29 |
jboyer-isl |
We're looking for something that anyone can use, vs. each location creating their own Display XYZ locations. |
| 11:29 |
Dyrcona |
A consortium-wide Display location, perhaps? |
| 11:30 |
jboyer-isl |
Dyrcona: If it's a public display, it's possible that the item was replaced while it was out. Also, when the display is changed, you just check all of the items in and chuck them in the bin. |
| 11:30 |
jeff |
or even a small number of cons-wide display locations... Adult Display, Children's Display, Teen Display |
| 11:30 |
Dyrcona |
Lazy...lazy...lazy... |
| 11:30 |
* Dyrcona |
shakes his head. |
| 11:30 |
jboyer-isl |
Laziness is a benefit for coders (re-use) why not catalogers? ;D |
| 11:31 |
Dyrcona |
This is what copy locations are meant for. IMHO, it is an abuse of copy status to do it that way. |
| 11:32 |
Dyrcona |
Re-use is overhyped and overrated. Surprisingly little happens in actual practice. |
| 11:32 |
rfrasur |
Dyrcona: for the display status? |
| 11:32 |
Dyrcona |
rfrasur: Display should be a location, not a status. |
| 11:32 |
* rfrasur |
thinks a display should be a copy location...but I'm not going to fight with people over it. |
| 11:32 |
jboyer-isl |
I may have to go back to our Cat comm. and see if they are dead-set on the status or if a global location will work. |
| 11:32 |
rfrasur |
since....it's a location. |
| 11:33 |
Dyrcona |
jboyer-isl: It's pretty easy to scan a bunch of barcodes into item status and then bulk change the copy location. |
| 11:33 |
jboyer-isl |
Sure, that's how we used to do it at my last job. |
| 11:34 |
Dyrcona |
It seems to me that using a status instead of a location is fighting the system. |
| 11:35 |
jboyer-isl |
Or possibly bringing some old-system baggage along to the new. |
| 11:35 |
Dyrcona |
Even so, it's fighting Evergreen and staff should alter work flow when necessary. |
| 11:35 |
Dyrcona |
Old system baggage is more trouble than its worth. |
| 11:36 |
Dyrcona |
After all, if you wanted that baggage, you could have stayed on the old system, no? ;) |
| 11:36 |
mmorgan |
We recently created a Display status just for the reason jboyer-isl described. Library has a bunch of books, usually new, that they put out on tables |
| 11:37 |
mmorgan |
They want to be able to locate them easily when they show up on the pull list |
| 11:37 |
* Dyrcona |
puts hands over his ears and starts singing, "La la la la!" ;) |
| 11:37 |
Dyrcona |
cf. What I said above. |
| 11:37 |
mmorgan |
They get checked out, display status clears, everyone's happy. |
| 11:38 |
Dyrcona |
Except for me. :p |
| 11:38 |
mmorgan |
Well, almost everyone, apparently :) |
| 11:38 |
rfrasur |
and me |
| 11:38 |
Dyrcona |
But, you don't have to listen to me. |
| 11:38 |
rfrasur |
We just won't use it. |
| 11:38 |
rfrasur |
We already have a shelving location for new materials...because they're there for a time duration rather than a number of circs (one). |
| 11:39 |
rfrasur |
I guess it just depends on how you want the stuff to behave. |
| 11:39 |
mmorgan |
Certainly it is a choice, libraries that don't want to don't have to use it, but it works well for some. |
| 11:39 |
dbwells |
jboyer-isl: I think jeff is right in noting that what you really want is some sort of temporary location support, I think. It's a concept missing from Evergreen, but it could solve these in-between cases, where essentially an attribute can be viewed as both a status and a location. |
| 11:40 |
dbwells |
We have more-or-less an identical problem, but the status is "New Books" |
| 11:40 |
jboyer-isl |
dbwells, jeff: Actually, that would also work (possibly better, as you could use the "generic" location, or your own) |
| 11:40 |
jeff |
being able to select a number of items in item status and "return to normal shelving location" or a checkin modifier for "return to normal shelving location" could help part of what jboyer-isl is looking for |
| 11:42 |
jeff |
mmorgan: in your case, as i understand things, the items in Display status that are sitting on those tables would not show up in a patron catalog search where the patron selected "limit to available" -- is that your experience? |
| 11:43 |
kmlussier |
Copy locations have that nice check-in alert feature now that helps with these types of temporary locations so that, at a minimum, staff are alerted that they might want to change the location. But it would sure be nice to automate it. |
| 11:44 |
kmlussier |
jeff: They do not show as available. We were just discussing that issues locally a couple of weeks ago. |
| 11:44 |
mmorgan |
jeff: nobody has brought that to my attention, but I'll see if I can confirm. Sounds like that should be the case. |
| 11:45 |
jeff |
kmlussier: and now we're full circle -- that conversation in here the other day is what jboyer-isl was asking about, I think. :-) |
| 11:45 |
jeff |
at least, it's what I thought of when he asked. |
| 11:46 |
kmlussier |
We had a wishlist item here for some easy way to identify which statuses should be used when limiting to available. I guess we have a handful of statuses that are used for items that are available. |
| 11:46 |
jeff |
interesting. |
| 11:47 |
jeff |
kmlussier: what other statuses do you have that you'd like to treat as "available"? if you mentioned it previously, I don't remember. |
| 11:47 |
jboyer-isl |
There used to be several that we also wanted to be able to check in without an override; I think Temporarily Unavailable was one. |
| 11:48 |
jeff |
What was that used for, and how "temporary" was that status? :-) |
| 11:49 |
jboyer-isl |
Things that would sit in Tech Services while they waited for cleaning, binding, repair, etc. |
| 11:49 |
kmlussier |
I don't think I mentioned it. It was primarily a local discussion that happened here. http://masslnc.cwmars.org/node/2876. Now that I look at it, the original idea was for something slightly different. "Display" and "Storage" are the two statuses I see that are being used. |
| 11:50 |
jboyer-isl |
It was used for a little bit, but staff didn't want to have to override them all the time (we wanted them to think an override was unusual, not business as usual). |
| 11:52 |
|
smyers_ joined #evergreen |
| 11:53 |
mmorgan |
jeff: limiting to available does exclude the On Display status items. I think items in this status don't stay in it long, getting scooped up by browsers, or by staff pulling for holds. |
| 11:55 |
dbs |
It's a good way to force patrons to visit in-person :) |
| 12:05 |
|
Sato`kun joined #evergreen |
| 12:25 |
csharp |
apple-- |
| 12:26 |
csharp |
@karma apple |
| 12:26 |
pinesol_green |
csharp: Karma for "apple" has been increased 0 times and decreased 5 times for a total karma of -5. |
| 12:26 |
* csharp |
is building a mac staff client |
| 12:26 |
csharp |
putting the files in place is pretty simple, but making the .dmg is a humongous PITA |
| 12:27 |
csharp |
it would probably be easier if I used macs, well, EVER |
| 12:28 |
|
frank_____ joined #evergreen |
| 12:37 |
rfrasur |
Am I understanding correctly that the clustered index refers to the column that a table sorts by? |
| 12:38 |
bshum |
csharp: Yeah :) |
| 12:38 |
bshum |
csharp: Making the DMG was the FUN part! |
| 12:38 |
bshum |
(for me) |
| 12:39 |
csharp |
yeesh |
| 12:39 |
csharp |
now I have to upgrade the OS to be able to install xcode :-/ |
| 12:39 |
jeff |
why are you installing xcode? |
| 12:39 |
bshum |
That's usually how folks hide the background imagers |
| 12:40 |
csharp |
I'm following a tutorial... what bshum said |
| 12:40 |
bshum |
Cause Mac is stupid and puts in xcode the attribute modifier tool |
| 12:40 |
bshum |
There's a workaround to that |
| 12:40 |
bshum |
I don't remember off the top of my head |
| 12:41 |
bshum |
That might be faster to google than to install xcode |
| 12:46 |
bshum |
csharp: http://lifehacker.com/hide-any-file-or-folder-on-your-mac-with-a-one-simple-t-521434930 |
| 12:46 |
bshum |
For example |
| 12:46 |
bshum |
Probably not the best example... per say |
| 12:47 |
csharp |
I'll try it - thanks |
| 12:48 |
* bshum |
installed xcode on his macbooks for other reasons back in the day |
| 12:48 |
bshum |
It just takes so long :( |
| 12:51 |
csharp |
bshum++ # that worked |
| 12:53 |
bshum |
Yay! |
| 12:53 |
* bshum |
goes off to hunt for some lunch |
| 12:53 |
frank_____ |
goof morning, could someone help me, I have a problem with the mfhd, these doesn´t show in the issues held label, it appears, but is empty |
| 12:53 |
* csharp |
envisons bshum in camo with a crossbow in the woods |
| 13:03 |
|
gsams joined #evergreen |
| 13:13 |
eeevil |
rfrasur: sort of ... not really. you don't cluster an index, you cluster the heap based on an index |
| 13:17 |
rfrasur |
eeevil: okay...then what this dude is saying doesn't jive...but I guess once I get a db app of some sort or another and actually starting doing things it might make more sense. |
| 13:17 |
rfrasur |
ty |
| 13:18 |
eeevil |
rfrasur: which dude is this? |
| 13:18 |
jeff |
and if you're asking in a postgresql sense, or if an example would help, i'd suggest the first two paragraphs under "Description", here: http://www.postgresql.org/docs/9.2/static/sql-cluster.html |
| 13:19 |
rfrasur |
Simon Allardice - one of the Lynda instructors. |
| 13:19 |
jeff |
and stealing the definition of "index" from http://www.postgresql.org/docs/9.2/interactive/indexes.html "Indexes are a common way to enhance database performance. An index allows the database server to find and retrieve specific rows much faster than it could do without an index. But indexes also add overhead to the database system as a whole, so they should be used sensibly." |
| 13:19 |
jeff |
rfrasur: in what context was the instructor using the term? |
| 13:20 |
rfrasur |
He was kinda referring to a column as an index, it seemed. |
| 13:20 |
eeevil |
rfrasur: ah, well, is it a postgres-specific course? if not, there are other meanings for "clustered index" in other databases |
| 13:20 |
rfrasur |
or a column BEING indexed...one or the other. |
| 13:20 |
rfrasur |
eeevil: no..it's general. I've not gotten into postgres yet |
| 13:21 |
rfrasur |
"Foundations of Programming: Databases" |
| 13:21 |
* rfrasur |
is at the very beginning...well, the end of the very beginning now. |
| 13:21 |
eeevil |
ok ... yeah, don't believe any description of specific implementations (or specific optimization techniques) from a general DB course |
| 13:21 |
rfrasur |
k, that sounds very reasonable. |
| 13:22 |
rfrasur |
Not sure if it's GOOD but reasonable. |
| 13:22 |
eeevil |
:) |
| 13:22 |
|
smyers__ joined #evergreen |
| 13:22 |
rfrasur |
though I'm feeling some deja vu right now...and wondering if I haven't seen this before. |
| 13:28 |
jeff |
general database course says: "some database systems use the term 'cluster' in the vicinity of the term "index". they often mean different things." ;-) |
| 13:29 |
jcamins |
rfrasur: a bit of Googling tells me that what he means by "clustered index" might be "index used to determine the order that rows are stored to disk." |
| 13:29 |
jcamins |
My Googling also tells me that might *not* be what he means. |
| 13:29 |
rfrasur |
yeah, I think I'll not get particularly tied to most terms until I eventually get into postgres |
| 13:30 |
rfrasur |
jcamins: I'm getting the impression that he's trying to get everything and the kitchen sink into 4 hours. |
| 13:30 |
jcamins |
No, no, there's no need to thank me for the brilliant light I shed on the matter. :) |
| 13:31 |
jcamins |
rfrasur: the introduction to databases course is four hours long? |
| 13:31 |
rfrasur |
hah! I'm more thankful to just not get booted out of here. No, I read it wrong. It's 3 hours 11 minutes...or in my case...5 weeks long |
| 13:32 |
jcamins |
3:11 minutes for an entire databases course? |
| 13:33 |
rfrasur |
yep |
| 13:33 |
rfrasur |
so....a lot is glossed over |
| 13:33 |
jcamins |
Yeah... I guess so. |
| 13:57 |
|
RoganH joined #evergreen |
| 14:37 |
|
mjingle joined #evergreen |
| 14:50 |
* bshum |
waves at mjingle |
| 14:50 |
mjingle |
*waves at bshum* |
| 14:50 |
mjingle |
Long time no see! |
| 14:50 |
mjingle |
(My fault, of course) |
| 14:50 |
bshum |
Indeed! How are things up in Canada? |
| 14:53 |
mjingle |
Weather-wise: surprisingly dry for Vancouver. Work-wise: Great! |
| 14:56 |
bshum |
Sounds good |
| 14:56 |
|
ningalls left #evergreen |
| 14:56 |
|
ningalls joined #evergreen |
| 14:59 |
csharp |
mjingle: a hearty "Hey" from your Georgia friends |
| 14:59 |
rfrasur |
mjingle! How's it? |
| 14:59 |
mjingle |
csharp: And a welcome one at that! Thanks! |
| 15:00 |
mjingle |
rfrasur: It goes, it goes! |
| 15:00 |
rfrasur |
:D |
| 15:29 |
|
mrpeters1 joined #evergreen |
| 15:32 |
* rfrasur |
is accomplishing like a professional accomplisher today. |
| 15:32 |
rfrasur |
Just saying |
| 15:32 |
mjingle |
rfrasur++ |
| 15:32 |
mjingle |
Not bad for a Monday |
| 15:32 |
rfrasur |
Nope, not bad atll. |
| 15:33 |
|
mtate joined #evergreen |
| 15:42 |
|
stevenyvr2 joined #evergreen |
| 15:45 |
pinesol_green |
[evergreen|Mike Rylander] Make sure that # can be used in auth browse - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ce3e4b> |
| 15:51 |
|
graced_ joined #evergreen |
| 15:51 |
jeff |
do other libraries use the term "renew" in the context of "renewing a patron account" that has expired? |
| 15:52 |
jeff |
i.e., if you saw a button next to the expire date on a patron account, would it make sense for that button to say "Renew"? would you expect that button to set the value in the expire date field to a date that is today + profile interval? |
| 15:53 |
csharp |
jeff: I would want it to say "Renew Account" or "Renew Card" or something |
| 15:53 |
rfrasur |
jeff: some of my staff do, but I prefer reactivate or update. |
| 15:53 |
jeff |
"Renew Patron"? |
| 15:53 |
jeff |
hrm. "Update" next to the expire date might make sense. |
| 15:54 |
* bshum |
likes "Renew Account" too. |
| 15:54 |
jeff |
there are three problems in programming... naming things, and off by one errors. |
| 15:54 |
rfrasur |
I just like unique vocabulary for essential tasks so that there's less chance for confusion. |
| 15:55 |
jeff |
heh |
| 15:55 |
rfrasur |
If we were to go with "renew account," I already know people would think it was dealing with materials rather than account info. |
| 15:55 |
csharp |
rfrasur: you're almost certainly correct |
| 15:56 |
gsams |
jeff:Most of our patrons have to update their information every three years so we say "Update Account" |
| 15:56 |
jeff |
okay, I'm going with "Update Expire Date Field -- You Will Still Need to Click Save" |
| 15:56 |
jeff |
(kidding) |
| 15:56 |
rfrasur |
lol, I like that "You will still need to click save" part :D |
| 15:56 |
csharp |
"Renew the PATRON - No, not ITEMS, the PATRON" |
| 15:57 |
rfrasur |
"What the heck are you touching a computer for? There's a typewriter in the back." |
| 15:57 |
csharp |
"Have you tried turning off and back on again?" |
| 15:57 |
gsams |
rfrasur++ |
| 15:57 |
jeff |
the click save part is due to a disconnect between how some buttons in the patron editor take immediate effect, and others require a Save. :-) |
| 15:57 |
gsams |
csharp++ |
| 15:58 |
eeevil |
jeff: oh? |
| 15:59 |
jeff |
eeevil: the contact invalidation buttons take immediate effect. i'm not sure if there are others. i'm checking right now to see if they cause an xact collision, since I wondered about that earlier. |
| 15:59 |
rfrasur |
Oh, I thought you had to save everything. |
| 15:59 |
* rfrasur |
does anyway. |
| 15:59 |
eeevil |
rfrasur: that's always safe, IIUC |
| 16:00 |
rfrasur |
yep....actually I save multiple times because I tend to forget/get distracted pretty easy. |
| 16:00 |
jeff |
yeah. i'm not sure if the bug is to make the Invalidate buttons queue their action until you hit Save, or to just fix it so that clicking them doesn't prompt you to save changes. |
| 16:00 |
rfrasur |
(it's good that I'm not at the circ desk often) |
| 16:01 |
eeevil |
jeff: probably the former, IMO |
| 16:02 |
jeff |
and no, the contact Invalidate buttons (rather, the method behind them) do not update last_xact on the patron record, so there's no collision. again, i'm not sure how i feel about that. :-) |
| 16:04 |
jeff |
adding some client-side logic for "queue invalidation of email" combined with "and cancel that if you ALSO update the email address"... though actually, calling the invalidate method then calling update user would probably be cleaner. |
| 16:04 |
jeff |
though it would result in some immediately archived standing penalties if you clicked "Invalidate" and then entered the same value that was there before. |
| 16:05 |
jeff |
that could be the one corner case that is handled client-side. |
| 16:05 |
* jeff |
babbles |
| 16:06 |
jeff |
i can't think of a current reason why it's bad that OpenILS::Application::Actor::BadContact doesn't bump last_xact on a user... in the current interface, it's good for the UI that it doesn't. |
| 16:07 |
bshum |
gmcharlt++ |
| 16:07 |
bshum |
(for new OpenSRF) |
| 16:24 |
jeff |
gmcharlt++ |
| 16:29 |
csharp |
gmcharlt++ |
| 17:11 |
|
mmorgan left #evergreen |
| 17:24 |
|
Sato`kun joined #evergreen |
| 17:28 |
|
ningalls joined #evergreen |
| 18:06 |
|
dMiller_ joined #evergreen |
| 18:10 |
|
akilsdonk joined #evergreen |
| 19:36 |
|
stevenyvr2 left #evergreen |
| 20:05 |
|
hbrennan joined #evergreen |
| 20:07 |
hbrennan |
Anyone here? (Probably not since it's late afternoon in Alaska...) grumble |
| 20:07 |
jeff |
hbrennan: what's up? |
| 20:08 |
hbrennan |
We've lost the ability for patrons to place a hold on a specific part (like disc 1 of a DVD series) |
| 20:08 |
hbrennan |
only on the OPAC end, staff side is fine |
| 20:08 |
jeff |
some monitor on and off and will respond if you ask a question and hang around. :-) |
| 20:08 |
hbrennan |
We've been having power glitches that are knocking out settings, weird as that soiunds |
| 20:09 |
jeff |
and.. i'm being pulled away. parts are not something i have a lot of experience, but others here do. |
| 20:09 |
hbrennan |
Yeah, I can always count on bshum or gmcharlt to be here day or night |
| 20:09 |
hbrennan |
I've been searching around but can't find clues as to where the setting is |
| 20:09 |
hbrennan |
Thanks jeff! |
| 20:16 |
hbrennan |
I'll be monitoring IRC, while bouncing around doing other things too, so if anyone knows the name of this setting I will be forever grateful |
| 20:23 |
gmcharlt |
hbrennan: should be more better now -- take a look at /openils/var/templates_homer/opac/parts/record/copy_table.tt2 |
| 20:23 |
gmcharlt |
just looks like a copy recent template updates were stomping on each other |
| 20:23 |
hbrennan |
Ahhh! Did you just change it? |
| 20:23 |
gmcharlt |
yep |
| 20:23 |
hbrennan |
You should have just seen my face over here |
| 20:23 |
hbrennan |
I thought the situation got STRANGER |
| 20:23 |
* gmcharlt |
checks calendar |
| 20:23 |
gmcharlt |
oops, it's not Halloween yet |
| 20:24 |
hbrennan |
phew |
| 20:24 |
hbrennan |
seriously, that scared me :) |
| 20:24 |
hbrennan |
Well, thank you |
| 20:24 |
hbrennan |
Now for part two |
| 20:24 |
hbrennan |
Why the heck is this happening? |
| 20:25 |
gmcharlt |
in this case, it was a recent change to the same template that happened to undo the bit that enabled volume-level holds |
| 20:25 |
hbrennan |
During the first power outage blip we lost the ability to receive text message hold notifications |
| 20:25 |
hbrennan |
No one here is changing settings |
| 20:25 |
hbrennan |
Can you see the time stamp of that change? |
| 20:26 |
gmcharlt |
10/23 |
| 20:26 |
hbrennan |
around 5:15 pm AK time I'm guessing |
| 21:29 |
|
smyers_ joined #evergreen |
| 22:28 |
|
stevenyvr2 joined #evergreen |
| 22:33 |
|
stevenyvr2 left #evergreen |
| 23:54 |
|
zerick joined #evergreen |
