| Time |
Nick |
Message |
| 02:12 |
|
mceraso joined #evergreen |
| 02:12 |
|
bshum joined #evergreen |
| 02:12 |
|
book` joined #evergreen |
| 02:16 |
|
ldwhalen joined #evergreen |
| 02:16 |
|
rri joined #evergreen |
| 03:05 |
|
mjingle joined #evergreen |
| 03:29 |
|
mjingle left #evergreen |
| 07:41 |
|
rjackson-isl joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:57 |
|
book` joined #evergreen |
| 08:21 |
|
Bmagic joined #evergreen |
| 08:24 |
|
akilsdonk joined #evergreen |
| 08:32 |
|
mrpeters joined #evergreen |
| 08:35 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
rfrasur joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
|
ktomita_ joined #evergreen |
| 08:49 |
|
kmlussier joined #evergreen |
| 08:50 |
|
kbeswick joined #evergreen |
| 08:58 |
paxed |
senator: re. the bibcn xpath change yesterday: the problem is we need to be able to search the exact text, and the normalizer replaces the dot with space. |
| 09:00 |
|
ericar joined #evergreen |
| 09:06 |
jeff |
you should be able to specify a normalizer when defining a new metabib field. |
| 09:06 |
jeff |
i don't know without looking what the normalizer is on the stock bibcn field def. |
| 09:06 |
jeff |
and i don't know offhand if there's a simple "don't normalize" normalizer or "null means don't normalize" |
| 09:12 |
paxed |
i don't see a normalizer in config.metabib_field |
| 09:13 |
paxed |
hm. config.metabib_field_index_norm_map? no idea how that works. |
| 09:13 |
dbwells |
paxed: yes, that is the right table |
| 09:15 |
dbwells |
paxed: if you don't have any rows in that table where 'field' is your bibcn field id in config.metabib_field, then you won't have any additional normalizers applied. |
| 09:16 |
phasefx_ |
I had to play with that yesterday; removed a dewey normalizer from the bibcn index, and then did UPDATE metabib.identifier_field_entry SET id = id WHERE field = 25; to effectively reindex everything. But some services and apache also had to be restarted |
| 09:17 |
dbwells |
paxed: I say 'additional' because the tranform you choose to extract the data itself in the xpath can also apply its own changes to the data. I wouldn't expect that for a cn field, though. |
| 09:17 |
|
7CBAAAWUZ joined #evergreen |
| 09:17 |
|
timf joined #evergreen |
| 09:19 |
jeff |
phasefx_: wouldn't you have to update biblio.record_entry (triggering a reingest) to make that change in normalizer take effect? |
| 09:20 |
jeff |
phasefx_: the only trigger i see on metabib.identifier_field_entry doesn't look like it would do the trick. |
| 09:20 |
phasefx_ |
it worked, but I don't know why it worked |
| 09:20 |
jeff |
phasefx_: wondering, because if what you describe is possible and does what i think it does, it could be handy. |
| 09:21 |
* phasefx_ |
was leaning heavily on gmcharlt :) |
| 09:21 |
jeff |
looking at oils_tsearch2 now. |
| 09:22 |
jeff |
ah, i think i see. |
| 09:23 |
phasefx_ |
yeah |
| 09:23 |
phasefx_ |
changes index_vector |
| 09:23 |
jeff |
right |
| 09:24 |
jeff |
i think my memory and i were incorrect in thinking that the normalization happens before value is populated. |
| 09:25 |
jeff |
(similar to how metabib.full_rec's value column is already normalized) |
| 09:27 |
dbwells |
paxed: Also, bibcn normalizers were recently dropped from master for the same reason, see here: https://bugs.launchpad.net/evergreen/+bug/1234367 Maybe your DB already had that applied, but it seems like maybe not? |
| 09:27 |
pinesol_green |
Launchpad bug 1234367 in Evergreen 2.4 "Fix problems searching Bib Call Numbers" (affected: 2, heat: 14) [Medium,Fix committed] |
| 09:27 |
paxed |
i'll take a look and see later, now is a naptime. |
| 09:28 |
jeff |
dbwells++ |
| 09:30 |
Dyrcona |
naptime++ |
| 09:34 |
|
akilsdonk_ joined #evergreen |
| 09:36 |
jeff |
hear, hear! |
| 09:37 |
rfrasur |
naps. They're great. |
| 09:42 |
rfrasur |
jboyer-isl++ #link in staff client for daily reconciliation |
| 09:45 |
jboyer-isl |
rfrausr: Also Notices. Sneak feature. |
| 09:46 |
rfrasur |
Oooooo, my life just became easier. TY. |
| 09:47 |
rfrasur |
I see it. Rock on. My staff is gonna be pretty happy about that (which makes me happy). |
| 09:47 |
jeff |
Notices? |
| 09:47 |
rfrasur |
overdue notices that we print out and mail to people |
| 09:48 |
jboyer-isl |
The coherently-themed icons will also be a nice upgrade. |
| 09:48 |
jeff |
ah. |
| 09:48 |
rfrasur |
or collection notices for some libraries (we don't do that...for good or bad) |
| 09:48 |
jeff |
yeah, happy to have that handled by a service. |
| 09:48 |
jeff |
we send 'em a file, they mail the notices. |
| 09:48 |
jeff |
process is automatic. |
| 09:49 |
rfrasur |
most libraries in Indiana use a collection service...but the cost benefit was enough for us to lose the "nice" factor. |
| 09:49 |
jboyer-isl |
jeff: Some here do that, some don't. |
| 09:49 |
jeff |
cool. |
| 09:50 |
jeff |
i'm a fan. |
| 09:51 |
rfrasur |
I'm a part-time fan. |
| 09:52 |
* Dyrcona |
is the genie of the LAMP! |
| 09:54 |
Dyrcona |
youtube-- |
| 09:54 |
rfrasur |
heh |
| 09:55 |
* csharp |
starts dojo tutorials and finally understands why replacing 1.3 with 1.9 will be very painful |
| 09:55 |
csharp |
or at least time-intensive |
| 09:55 |
csharp |
of course, the web client work may make that redundant? |
| 09:56 |
rfrasur |
jboyer-isl: will there be a menu link somewhere in the staff client apart from the splash screen as well? |
| 09:57 |
Dyrcona |
more videos that only work on my phone, but not on the laptop.... |
| 09:57 |
csharp |
Dyrcona: wild - I usually see the opposite problem |
| 09:58 |
mrpeters |
rfrasur: not to speak for jboyer-isl but what you're asking would require a custom staff client being deployed with everyone upgrading their clients |
| 09:58 |
rfrasur |
and, jboyer-isl: the daily reconciliation report only shows transactions where the billing library is separate from the payment library? |
| 09:59 |
rfrasur |
mrpeters: oh...okay. I thought it could potentially just be a patch. |
| 09:59 |
jboyer-isl |
rfrasur: mrpeters is right, these are only on the new tab page. |
| 09:59 |
rfrasur |
k |
| 09:59 |
jboyer-isl |
And yes, the reconciler only cares about payments where the the money belongs to another system, not another branch. |
| 10:00 |
rfrasur |
k, just making sure my explanation to staff is concise. |
| 10:02 |
csharp |
we just got a feature request from a library to have a direct button/menu item to edit a patron account without bringing up the checkout screen first |
| 10:03 |
csharp |
I'm assuming that's in part because of network/workstation slowness in UI loading, but would others see that as a win? |
| 10:03 |
jeff |
csharp: i've pondered it recently, but that might be because i've been doing a lot of work in the user editor. |
| 10:03 |
rfrasur |
csharp: not me personally. I like that it brings up the entire account. |
| 10:04 |
rfrasur |
I'd just rather see a performance boost there. |
| 10:04 |
csharp |
I guess I'm envisioning a Circulation menu item and an option button for the toolbar - Patron Edit |
| 10:04 |
jeff |
csharp: i'd be more interested in the reason behind the request -- is this because there's a desk at the library where staff are typically updating accounts but not checking items out? |
| 10:04 |
csharp |
rfrasur: yeah - that was my first though |
| 10:04 |
csharp |
t |
| 10:04 |
csharp |
jeff: yeah - I'm going to get more information |
| 10:05 |
csharp |
I was just polling the channel to see if anyone else saw that as a need/desire |
| 10:05 |
rfrasur |
but either way, you're going to get into the account the same way...with their barcode (generally)...and when we do that, that's also when we tend to circ issues. Maybe if there was a way to "quick jump" into the full account, it'd be worthwhile. |
| 10:06 |
rfrasur |
but there'd still need to be a summary of items out/overdue, notes, and any monies owed. At least for me to care much. |
| 10:10 |
jboyer-isl |
rfrasur: I think the feature csharp is describing would load the patron as it does today, but instead of being on the checkout "tab" it would go straight to the edit "tab." As I understood it anyway. |
| 10:10 |
rfrasur |
oh. |
| 10:10 |
csharp |
jboyer-isl: yeah - that would probably be the implementation that would make the most sense |
| 10:10 |
csharp |
however, I'm not convinced that the real problem is loading speed |
| 10:11 |
csharp |
s/is/isn't/ |
| 10:11 |
rfrasur |
it seems lazy to me. Like added work for developers when all an end user needs to do is press a button right now. |
| 10:11 |
dbs |
I think it would be pretty easy to do that today, via an extra menu item, given that the patron editor lives pretty much on its own |
| 10:11 |
csharp |
I assumed it would probably be straightforwared |
| 10:12 |
csharp |
@karma typos |
| 10:12 |
pinesol_green |
csharp: Karma for "typos" has been increased 0 times and decreased 5 times for a total karma of -5. |
| 10:12 |
csharp |
typos-- |
| 10:13 |
jeff |
i think that there should be a way to retrieve an account and bring up the editor in one step. either something like the "set bottom interface as default" that we have in catalog views, or just a different UI entry. |
| 10:14 |
csharp |
that would work too |
| 10:14 |
csharp |
I'll need to get more information on what's behind the request |
| 10:14 |
rfrasur |
csharp++ |
| 10:17 |
kmlussier |
csharp: In general, I'm in favor of anything in the client that saves clicks for staff. I could see staff really liking a direct way to get to the patron editor. With custom toolbars, it would be easy to add that toolbar button for those who find it useful and remove it for those who don't. |
| 10:17 |
csharp |
right |
| 10:18 |
rfrasur |
or...if we don't, we could just not click on it. I suspect even within a building, you'll have one person that likes to do something one way and one person that likes to do it another way. |
| 10:18 |
kmlussier |
But, yeah, the performance boost would be nice too. But a harder problem to fix. |
| 10:24 |
jeff |
it would be good to have performance at such a point that for most things performance isn't a reason to have the "bring up the editor by default". that said, i still think that if you're doing something that is frequently using the editor, there should be a good way to have an entry point to that default. :-) |
| 10:26 |
Dyrcona |
I always like to remind our staff, when they complain about Evergreen performance, that they had to have a special WAN connection to central site in order to even make Horizon usable. It was absolutely abysmal over the Internet. |
| 10:33 |
csharp |
yeah - I have a hard time communicating about network issues - there are so many layers |
| 10:34 |
csharp |
many of our libraries have moved to high-broadband ISPs and still see issues because of outdated equipment inside their buildings |
| 10:34 |
* jeff |
stops trying to talk in irc and converse on a conference call |
| 10:34 |
jeff |
(because the conference call has ended) |
| 10:34 |
rfrasur |
Yeah, I should note that my mentioning of performance wasn't a complaint. |
| 10:34 |
Dyrcona |
csharp: Latency kills. Often it isn't the bandwidth that is the issue, it is the number of router hops between end points. |
| 10:36 |
Dyrcona |
rfrasur: There are places where performance could be improved in Evergreen. Unfortunately, doing so mean untangling the ball of code required because librarians want everything to be "simple, except for...." :) |
| 10:36 |
csharp |
yep |
| 10:36 |
dbs |
Obvious solution: multi-master database replication with a replica in each building. /me dusts hands, walks away |
| 10:36 |
phasefx_ |
we could emulate old form-based green screens on the web :) send all data at once, get all the results back in one shot <runs and hides> |
| 10:37 |
csharp |
dbs++ |
| 10:37 |
rfrasur |
Dyrcona: Right and I understand that. I'm pretty pleased with it all as is. Each release is a bonus from my standpoint. |
| 10:37 |
csharp |
phasefx_++ |
| 10:37 |
Dyrcona |
phasefx_: That's actually how HTTP is supposed to work. You're not emulating green screens at all. |
| 10:37 |
phasefx_ |
Dyrcona: you are if you make it green |
| 10:38 |
Dyrcona |
All this other stuff (AJAX) is a work around because people want local applications but they don't want local applications. |
| 10:38 |
dbs |
phasefx_: well, there is a lot to be said for that approach (albeit web based). that's the recommended approach for building mobile apps, for example; get all data in one chunk |
| 10:38 |
* phasefx_ |
nods |
| 10:38 |
dbs |
(although one of the primary reasons for that is also to keep the radio fired up as little as possible to conserve juice) |
| 10:39 |
Dyrcona |
green make me think of Kermit the Frog, which makes me think of Kermit, the terminal software/modem file transfer protocol. |
| 10:40 |
* phasefx_ |
still remembers making a crystal radio with some electronic kit; powered by radio waves, no batteries needed :-( |
| 10:40 |
Dyrcona |
Maybe we should make it green and replace OpenSRF with Kermit? |
| 10:40 |
csharp |
telnet! |
| 10:40 |
rfrasur |
oy |
| 10:40 |
eeevil |
zmodem, dude |
| 10:41 |
dbs |
slide those windows |
| 10:41 |
rfrasur |
phasefx_, did you have to ground it to the pipes under the sink? |
| 10:41 |
rfrasur |
(pvc..the death of crystal radios) |
| 10:42 |
phasefx_ |
rfrasur: no, it was all handheld, little bits in cardboard. The reason I think it worked at all is that it only had to weakly power an earpiece |
| 10:42 |
rfrasur |
oh, mine had to be grounded to the sink. |
| 10:43 |
phasefx_ |
probably wouldn't be able to hear it in today's noise polluted environment |
| 10:45 |
phasefx_ |
rfrasur: kmlussier: just curious, could staff tolerate scanning in a bunch of barcodes into a textbox and getting feedback on checkin/checkout/status/what-not only after hitting submit? |
| 10:45 |
|
mllewellyn joined #evergreen |
| 10:46 |
rfrasur |
phasefx_: barely. They're just getting up to speed on understanding the output from offline transaction exceptions. But my staff is a pretty small pool. |
| 10:47 |
rfrasur |
They could tolerate it...but it'd be a pretty steep learning curve for most of them. |
| 10:47 |
phasefx_ |
I'd imagine we could make it much friendlier than the way offline xact processing works |
| 10:48 |
kmlussier |
phasefx_: Not sure. How would that work for something like checkin? They check in 10 items, some of which will have hold slips and others will have transit slips. I assume the slips also wouldn't print until they hit submit, so then they would need to match up slips with books. My gut reaction is that it wouldn't be looked upon favorably. |
| 10:48 |
rfrasur |
If you make it, I will teach it. |
| 10:48 |
phasefx_ |
kmlussier: yeah, that'd less than fun |
| 10:49 |
* rfrasur |
didn't understand exactly what you were saying. |
| 10:50 |
rfrasur |
What kmlussier said is right. And there are scenarios when an item might require multiple steps though I can't think of them offhand right now. |
| 10:50 |
kmlussier |
rfrasur: There is always a need for training, but I think the ultimate goal is to make it as intuitive as possible so that you don't have to spend too much time training a less than ideal process. |
| 10:50 |
phasefx_ |
rfrasur: a more painful thought experiment; you scan all the barcodes into an email, send it off, and the return email has the consolidated results :) |
| 10:51 |
kmlussier |
And then the email never arrives because it's been flagged as spam. ;) |
| 10:51 |
rfrasur |
kmlussier++ |
| 10:51 |
Dyrcona |
All email is spam. |
| 10:51 |
rfrasur |
phasefx_: I'm not understanding the "why." |
| 10:52 |
phasefx_ |
or the web page gets filtered as having "dangerous javascript" |
| 10:52 |
Dyrcona |
No javascipt and that won't happen. :) |
| 10:52 |
* rfrasur |
starts handing out Hogwart's School of Development applications |
| 10:53 |
Dyrcona |
If you're going back to a web 1.0 form and response, then javascript should not be an issue....all validation on the server. |
| 10:53 |
phasefx_ |
rfrasur: the problem with highly interactive applications over the network is latency; was curious how staff might tolerate less-interactive applications, and how workflows might would have to change |
| 10:53 |
rfrasur |
Hmm, let me think about that for a minute. Have we already discussed telnet? |
| 10:53 |
* rfrasur |
chuckles to self. |
| 10:53 |
phasefx_ |
Dyrcona: I was just thinking back to the existing staff client; that's happened :-/ |
| 10:54 |
Dyrcona |
rfrasur: ssh instead of telnet. ;) |
| 10:54 |
phasefx_ |
ssh might have too much latency ;) |
| 10:55 |
Dyrcona |
telnet might have not enough encryption. |
| 10:55 |
phasefx_ |
what's that cool thing out now, mosh? |
| 10:55 |
jcamins_ |
Use mosh, so that it's more forgiving of network glitches. |
| 10:55 |
* Dyrcona |
is fond of tin cans on a string. :) |
| 10:55 |
rfrasur |
phasefx_, I think it might be okay with check-ins so long as it was a limited thing...say only 10 for bundled transaction...so that if there were a bunch of hold slips or whatever, they were easy to manage by staff. I'm not sure that it's necessary though. |
| 10:56 |
mmorgan |
I can't envision a less interactive application working well in our environment - at least not in circulation. |
| 10:56 |
mmorgan |
Circ isn't a batchy thing. |
| 10:56 |
rfrasur |
Check out would in higher demand (in my mind)...and I don't think you can really do that well with bundled transactions because of different alerts/status exceptions whatever. |
| 10:56 |
kmlussier |
phasefx_: Thnking back to your original question, I think item status is the place where it has the most likelihood of being tolerable. Staff are using checkout while they are working with patrons, so that immediate feedback is important. If item 1 has an alert saying it can't be checked out because it's reference and the patron has already put the item in their bag by the time staff receive the alert after item 10, t |
| 10:57 |
phasefx_ |
kmlussier: got truncated "after item 10, th" |
| 10:57 |
kmlussier |
the patron isn't going to be happy. |
| 10:57 |
* csharp |
plans "fax-only" staff client for april fools |
| 10:58 |
* rfrasur |
prefers not to think about csharp's plans for april fools |
| 10:58 |
csharp |
new Open-Surf brand fax client! |
| 10:58 |
rfrasur |
:D |
| 10:58 |
* Dyrcona |
wonders what was wrong with rubber stamps and paper cards. |
| 10:59 |
phasefx_ |
alright, bbl |
| 10:59 |
dbs |
the batch approach would, plain and simple, be a band-aid for performance problems at the circ UI and below |
| 11:00 |
rfrasur |
nothing. ask some librarians. |
| 11:00 |
jcamins |
Dyrcona: rubber allergies. |
| 11:00 |
jcamins |
And paper cuts. |
| 11:00 |
* rfrasur |
still gets paper cutes |
| 11:00 |
* dbs |
always hated grabbing the wrong stamp |
| 11:00 |
rfrasur |
and we actually still use stamps for some things (so embarrassing) |
| 11:01 |
dbs |
We use stamps for everything. No receipt printers here. |
| 11:02 |
|
akilsdonk joined #evergreen |
| 11:02 |
rfrasur |
Hmm, that's pretty retro and cool. (I wonder if I could earn boss browny points for that) |
| 11:03 |
Dyrcona |
Batch is one thing that the current Evergreen staff client does extremely poorly. Just ask anyone who has tried updating more than 100 or so things in a bucket. |
| 11:04 |
Dyrcona |
I also don't consider HTTP request and response to be batch in and of itself. |
| 11:05 |
Dyrcona |
It sounds like what we really need is a TCP socket connection with a client that is smart enough to say, "Hey, the connection dropped, I should try making a new one." |
| 11:06 |
dbs |
Dyrcona: by "batch" i meant "scanning 10 checkins into a textbox and waiting until hitting submit to send them off" |
| 11:06 |
Dyrcona |
dbs: 10 is not a batch to me. Get to 10,000, now we're talking about a batch. :) |
| 11:06 |
dbs |
heh, point taken |
| 11:06 |
csharp |
so small batches, like blending soup ;-) |
| 11:06 |
Dyrcona |
I see you're point too. |
| 11:07 |
rfrasur |
I consider anything I have upload as a set (generally 20 or more) a batch. personal vocabulary though. |
| 11:09 |
dbs |
We still use script-based circ here, but I thought in-db circ was supposed to fix the speed thing :/ |
| 11:10 |
Dyrcona |
dbs: You can't fix lasagna that was made with spaghetti noodles. |
| 11:10 |
jeff |
phasefx_: where we've toyed with the idea of a textarea for multiple barcodes is with rfid pads. |
| 11:10 |
rfrasur |
Dyrcona: you just change the name to baked spaghetti |
| 11:13 |
Dyrcona |
dbs: circ is slow because of the all the "simple, except for" that it has to check. |
| 11:13 |
dbs |
Dyrcona: well, I guess the performance eval will tell, but if the actual circ is fast and the performance gets dragged down by "request results of circ; request updated patron record with fleshed out bills; request yada yada" before the display updates (along with all the setTimeout() tricks of the trade), then it's not the circ transaction itself |
| 11:14 |
dbs |
but yeah, I have no benchmark for that. masslnc++ etc for funding the performance eval |
| 11:16 |
Dyrcona |
dbs: The multiple requests for retrieving bits and pieces of information has come up in the evaluation. |
| 11:17 |
Dyrcona |
I will add, it isn't just the staff client. The backend does its share of that sort of thing, too. |
| 11:34 |
|
ningalls joined #evergreen |
| 11:36 |
mmorgan |
Now for something that IS batchy ... |
| 11:36 |
mmorgan |
I have some copies in a bucket that are checked out to different patrons. Is there no way to declare them lost as a batch? |
| 11:36 |
rfrasur |
oh...you said batchy |
| 11:37 |
mmorgan |
:-D |
| 11:37 |
rfrasur |
I dunno the answer though. sorry. |
| 11:39 |
Dyrcona |
mmorgan: I am pretty sure that you can change the status in the bucket, but I usually write a script if there are more than a hundred or so items in the bucket. |
| 11:41 |
mmorgan |
Drycona: Not seeing an option to do this from the bucket - or item status. |
| 11:42 |
mmorgan |
It's not an overflowing bucket, so the client could handle it, but I don't see an option to mark Lost. |
| 11:42 |
rfrasur |
mmorgan: from item status, you'd go into edit attributes |
| 11:42 |
rfrasur |
Though I'm not sure if just changing the status triggers all the right stuff. |
| 11:43 |
mmorgan |
rfrasur: That's what I'm concerned about, triggering that Right Stuff. |
| 11:44 |
mmorgan |
We want the patrons billed for these. |
| 11:45 |
csharp |
mmorgan: I would work from the assumption that all that would do is change the item status |
| 11:45 |
rfrasur |
yes. looking...but I don't think you can do it from buckets. Again, i think it calls too many things because w/ a traditional change to lost status, it brings up an alert saying "do you want to bill them?" with options of modify the amount. |
| 11:46 |
rfrasur |
yeah, I agree w/ csharp |
| 11:47 |
Dyrcona |
Well, I was going to look at my buckets in the staff client, but I have almost 7,000 of them, so my client is frozen.... |
| 11:47 |
csharp |
haha |
| 11:48 |
Dyrcona |
I thought you could batch edit in copy buckets. I know you can batch marc edit in record buckets. |
| 11:48 |
jeff |
batch editing the items will not do what mmorgan wants. |
| 11:49 |
mmorgan |
Right. I want them to end up as if I individually went to each patron record and declared them lost. |
| 11:49 |
rfrasur |
As far as I know, you'll just have to do them individually. |
| 11:49 |
jeff |
we have a homegrown perl script that does that, since we're not currently using A/T. |
| 11:51 |
mmorgan |
I'd be happy to use an action trigger, but don't see that an A/T can act on a bucket. |
| 11:51 |
rfrasur |
mmorgan: I think you're right. |
| 11:52 |
jeff |
mmorgan: my mention of A/T here was just because in our case we're using it in place of an A/T that marks things lost on a regular basis after being overdue for X days. |
| 11:54 |
csharp |
the "Longoverdue" feature in 2.5 is similar, but puts them into a "longoverdue" status (system-set only) vs. "lost" (manually set) |
| 11:54 |
csharp |
(at least that was the logic PINES had in mind when funding development for that feature) |
| 11:54 |
mmorgan |
jeff: Gotcha. We're not marking things Lost automatically with an A/T either, yet and are looking forward to the 2.5 stuff. |
| 11:55 |
Dyrcona |
mmorgan: I'd do that with a perl script calling the backend code to set them lost. You'd have to run it on a utility server or somewhere else that has access to the backend. |
| 11:56 |
Dyrcona |
I could probably write one for you real quick. |
| 11:56 |
mmorgan |
Drycona: Would you be willing to share a script you've done? |
| 11:57 |
mmorgan |
I can anticipate needing to do this periodically. |
| 11:57 |
Dyrcona |
Dunno if I have any that set bucket items to lost, but I'll look. |
| 11:58 |
Dyrcona |
If the script takes the bucket id as a parameter, it is easy to run it more than once on different buckets, or even the same one. |
| 11:58 |
mmorgan |
Doesn't need to specifically run on a bucket. That's just where they happen to be at the moment. |
| 11:59 |
Dyrcona |
Using buckets makes it easy to identify the copies: they're all in the same bucket. |
| 12:01 |
|
smyers_ joined #evergreen |
| 12:03 |
Dyrcona |
mmorgan: http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=blob;f=scripts/copy_delete_from_copy_bucket.pl;h=5eca8ac414a3ae7847e4ea19d8d50d6d62fc223a;hb=HEAD |
| 12:03 |
Dyrcona |
That's something I wrote to delete the copies in a bucket. That's the most common request that we get. |
| 12:03 |
Dyrcona |
I could modify that to set them lost rather easily. |
| 12:04 |
csharp |
using_software_as_a_workaround_to_actual_management-- |
| 12:05 |
csharp |
(apropos of nothing) |
| 12:06 |
mmorgan |
Dyrcona++ |
| 12:07 |
|
francisco joined #evergreen |
| 12:08 |
Guest58637 |
Hi, Is there a place where I could update the default mfhd marc template? |
| 12:10 |
|
yboston joined #evergreen |
| 12:11 |
mmorgan |
Dyrcona: Gotta run, but I'll take a look at your script ... |
| 12:27 |
Dyrcona |
On the subject of batches, "batch" often signifies (to me) that all the operations on the items succeed, or none succeed. |
| 12:27 |
rfrasur |
Dyrcona: for me as well. |
| 12:31 |
dbs |
Guest58637: sorry for the delay, Frank, I believe it's still hardcoded in a perl module. one second |
| 12:33 |
|
dMiller_ joined #evergreen |
| 12:33 |
dbs |
Guest58637: yes, it's hardcoded in Open-ILS/Application/Cat.pm (although it looks like it could accept passed-in xml for a template) |
| 12:34 |
jeff |
i really thought there was a supercat url for marchtml or similar. i seem to have been wrong. |
| 12:35 |
eeevil |
jeff: there's ... a url |
| 12:35 |
* eeevil |
looks |
| 12:35 |
phasefx_ |
there's an osrf method |
| 12:35 |
jeff |
phasefx_: i think that's what i'm running into. |
| 12:36 |
eeevil |
there is in deed that, but I thought there was a supercat/retrieve format ... hrm, but not for the format that the opensrf method produces |
| 12:36 |
phasefx_ |
there is a stylesheet |
| 12:37 |
eeevil |
which means there /can/ be url :) |
| 12:37 |
phasefx_ |
hey, here's a URL :) server/cat/marc_view.html |
| 12:38 |
phasefx_ |
meh, doesn't work outside of the staff client |
| 12:39 |
|
akilsdonk_ joined #evergreen |
| 12:40 |
jeff |
heh |
| 12:40 |
Guest58637 |
dbs: thanks, so It couldn´t be modify by us to could add our specific tags? |
| 12:46 |
Dyrcona |
mmorgan: For when you get back: http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=blob;f=scripts/set_copy_lost_from_copy_bucket.pl;h=b2c7c12566dcd8c64745c6248ee501b44f9ee6b2;hb=HEAD |
| 12:46 |
dbs |
Guest58637: well, you can modify the Perl module to add your own tags and default values. or maybe I don't understand what you want to do |
| 12:47 |
Guest58637 |
yes,is what I want to do, But my question is about if I had to compile something, or is just modify and apply de changes |
| 12:49 |
|
RobertL_ joined #evergreen |
| 12:55 |
dbs |
Guest58637: modify and apply the changes. you'll have to restart the open-ils.cat service |
| 12:56 |
Guest58637 |
ok, excellent, thanks dbs for your response |
| 13:25 |
rfrasur |
buying air is very ironic to me |
| 13:27 |
dbs |
rfrasur++ |
| 13:28 |
bshum |
From Druidia? |
| 13:29 |
rfrasur |
well, from Amazon...Innovera |
| 13:30 |
rfrasur |
(I can buy air from [the] Amazon) |
| 13:32 |
rfrasur |
(oy...the people that don't think about listserv etiquette) |
| 13:34 |
bshum |
Heh |
| 13:35 |
bshum |
"Bad search" = JSPAC and "Good Search" = TPAC? :D |
| 13:38 |
rfrasur |
Um...Nathan Fillion, Joss Whedon and Shakespeare? I'm not sure I'm mentally stable enough to handle the awesome |
| 13:41 |
mmorgan |
Drycona: Thanks!!! |
| 13:42 |
dbs |
rfrasur: yep, we're just waiting for a good time to watch teh awesomeness that will be |
| 13:42 |
rfrasur |
I just ordered it for the library. |
| 13:43 |
jcamins |
rfrasur: this sounds intriguing. What is it? |
| 13:44 |
rfrasur |
Much Ado About Nothing |
| 13:44 |
bshum |
Huh... for the browse catalog function. The spinner appears next to the button when you hit Browse instead of replacing it like it does in the regular search. Intended or just avoiding more weird looking JS? |
| 13:44 |
* rfrasur |
started out buying Magic Erasers for the janitor. |
| 13:44 |
csharp |
@karma bad |
| 13:44 |
pinesol_green |
csharp: bad has neutral karma. |
| 13:50 |
jeff |
cool. circ staff are happy with our user editor changes. |
| 13:51 |
collum |
@karma good |
| 13:51 |
pinesol_green |
collum: good has neutral karma. |
| 13:51 |
collum |
how zen |
| 13:51 |
rfrasur |
sounds kinda nice |
| 13:53 |
* rfrasur |
eats candy corn because nothing says Halloween like corn syrup and food coloring. |
| 14:02 |
smyers_ |
has anyone run into an error with the marc_field_importer? 'tempfile' can't be called as a method at ./marc_stream_importer.pl line 335 |
| 14:10 |
bshum |
I haven't tried marc_stream_importer.pl recently, since we don't use that feature in our consortium |
| 14:11 |
bshum |
But given that error, it sounds again like wacky perl module issues? |
| 14:11 |
eeevil |
smyers_: probably a missing or mis-versioned module |
| 14:11 |
bshum |
Have you checked the line in the file |
| 14:11 |
bshum |
Looks like it's referencing File::Temp |
| 14:12 |
bshum |
smyers_: Might be the version of whatever that is too low or whatnot. (like all presumably crazy CentOS evils you face) |
| 14:12 |
smyers_ |
bshum: File::Temp is up to date (0.2304). |
| 14:12 |
smyers_ |
bshum: which version do you have |
| 14:12 |
jeff |
eeevil++ costume |
| 14:13 |
eeevil |
jeff: let me be frank, I like halloween |
| 14:13 |
jeff |
*groan* |
| 14:14 |
rfrasur |
eeevil++ #I think...and yet |
| 14:14 |
eeevil |
hot dog, it's good fun! |
| 14:14 |
* bshum |
grumbles as he tries remembering how to look up what versions of perl modules are installed on a server... |
| 14:15 |
eeevil |
bshum: perl -MFile::Temp -e 'print "$File::Temp::VERSION\n";' |
| 14:15 |
jeff |
yeah, eeevil beat me to it |
| 14:15 |
eeevil |
would be my first attempt |
| 14:15 |
bshum |
eeevil: Thanks, that helps :) |
| 14:15 |
bshum |
smyers_: fwiw, my ubuntu server says 0.22 |
| 14:15 |
smyers_ |
bshum: wonder if I need to downgrade? |
| 14:16 |
phasefx_ |
eeevil: you mean you like hallowieners |
| 14:16 |
eeevil |
phasefx_++ |
| 14:17 |
bshum |
http://www.dagolden.com/index.php/2109/why-the-latest-filetemp-might-surprise-you/ |
| 14:17 |
bshum |
That might be relevant, I think |
| 14:18 |
eeevil |
smyers_: the API has changed some ... and there's that |
| 14:18 |
smyers_ |
eeevil: API of File::Temp or marc_import? |
| 14:18 |
eeevil |
yep, that's it |
| 14:18 |
eeevil |
smyers_: File::Temp |
| 14:19 |
smyers_ |
eeevil: so I need version 0.22 |
| 14:19 |
eeevil |
bshum's link tells the tale |
| 14:19 |
|
dconnor_ joined #evergreen |
| 14:19 |
eeevil |
smyers_: for now. it'd be great if you would put up an LP bug about this (or even greater, create a fix!) |
| 14:19 |
csharp |
eeevil++ # always hot dogging it! |
| 14:19 |
smyers_ |
eeevil: Will do on the LP bug |
| 14:20 |
rfrasur |
csharp++ |
| 14:20 |
smyers_ |
eeevil: create a fix, maybe after we get off centos/rhel |
| 14:20 |
smyers_ |
eeevil++ bshum++ thanks guys |
| 14:21 |
eeevil |
np |
| 14:23 |
|
akilsdonk joined #evergreen |
| 14:28 |
smyers_ |
eeevil: at least only one place in evergreen that I found uses File::Temp |
| 14:28 |
smyers_ |
./usr/lib/perl5/site_perl/5.8.8/OpenILS/Utils/RemoteAccount.pm |
| 14:29 |
Dyrcona |
@quote get 69 |
| 14:29 |
pinesol_green |
Dyrcona: Quote #69: "jeff: All the pain of RHEL, with none of the support." (added by Dyrcona at 08:57 AM, October 30, 2013) |
| 14:29 |
eeevil |
smyers_: there may be several more (and several where we should use it, if not) |
| 14:30 |
eeevil |
IME, that statement is redundant |
| 14:30 |
eeevil |
(re rhel) |
| 14:33 |
* jeff |
attempts to open bug tickets for the top commits in http://git.evergreen-ils.org/?p=evergreen/tadl.git;a=shortlog;h=refs/heads/rel_2_2_tadl_user_edit_work |
| 14:33 |
jeff |
i want gitweb urls to be natively more concise. |
| 14:39 |
dbs |
jeff: agreed. and for launchpad not to munge the URL so I end up going to the Italian Linux Society page all the time. |
| 14:48 |
|
polonel joined #evergreen |
| 14:49 |
|
kbutler joined #evergreen |
| 14:51 |
eeevil |
dbs: OMGYESTHAT |
| 14:52 |
smyers_ |
eeevil: lp 1246839, let me know if I can provide more info. |
| 14:52 |
pinesol_green |
Launchpad bug 1246839 in Evergreen "marc_stream_importer.pl crashes with vs 0.23 of File::Temp" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1246839 |
| 14:52 |
smyers_ |
eeevil: I might get sign off to fix marc_stream_importer which I would then commit to community as well |
| 14:52 |
eeevil |
jeff: do you have a branch for payment-by-billing-type, even partial? I'd be happy to polish it |
| 15:01 |
* jeff |
frowns |
| 15:01 |
jeff |
i should. |
| 15:07 |
|
hbrennan joined #evergreen |
| 15:10 |
|
polonel joined #evergreen |
| 15:15 |
bshum |
mceraso++ # installed her first Evergreen VM today |
| 15:15 |
jeff |
eeevil: i'm not finding a working branch on my end. will check git stashes and fire up the VM I was using for testing against real data. |
| 15:16 |
kmlussier |
mceraso++ |
| 15:16 |
kmlussier |
mceraso: And welcome to the Evergreen community! :) |
| 15:17 |
eeevil |
jeff++ |
| 15:18 |
jeff |
eeevil: are you in a "this week" hurry? |
| 15:18 |
rfrasur |
Is mceraso a Bibliomation person? or somewhere else? |
| 15:18 |
jeff |
mceraso++ greetings again! |
| 15:18 |
eeevil |
jeff: no, not at all |
| 15:18 |
jeff |
rfrasur: new bibliomation employee, bshum's new co-worker |
| 15:18 |
rfrasur |
rock on! |
| 15:18 |
eeevil |
but I might keep bugging you ;) |
| 15:18 |
rfrasur |
mceraso++ #welcome |
| 15:18 |
jeff |
eeevil: got it. i'll comment on the bug and try to re-visit next week. it's still on my list here. |
| 15:19 |
mceraso |
Thank you! :) |
| 15:19 |
eeevil |
jeff: or, I might stop being lazy and just work from the code on the bug... |
| 15:20 |
jeff |
sorry for the bugspam, folks. |
| 15:21 |
kmlussier |
jeff: New bug reports that promise working branches are never bugspam in my book. :) |
| 15:21 |
|
gsams joined #evergreen |
| 15:22 |
eeevil |
huh ... best unshelved in a long time today: http://www.unshelved.com/2013-10-30 "I love the sound policy makes when I break it." |
| 15:22 |
jeff |
kmlussier: and fwiw, the code's already committed, just against rel_2_2 in the Evergreen/tadl repo on git.evergreen-ils.org. :-) |
| 15:25 |
* jeff |
re-phrases a bug title to make it less wishlist, more bug. |
| 15:27 |
Dyrcona |
@blame policy for the complication in holds and circ |
| 15:27 |
pinesol_green |
Dyrcona: policy is NOT CONNECTED TO THE NETWORK!!! for the complication in holds and circ |
| 15:27 |
Dyrcona |
@blame pinesol_green |
| 15:27 |
pinesol_green |
Dyrcona: itself stole Dyrcona's ice cream! |
| 15:28 |
Dyrcona |
That it did. That it did. |
| 15:32 |
jeff |
berick++ for commit 4a3a719 |
| 15:32 |
pinesol_green |
[evergreen|Bill Erickson] LP1207396 user stage allows username selection - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4a3a719> |
| 15:41 |
Dyrcona |
And here we'd like to make usrname allow nulls. |
| 15:41 |
Dyrcona |
oh well. |
| 15:41 |
* jeff |
nods |
| 15:42 |
* rfrasur |
mumbles something obscene about school administrators |
| 15:53 |
Dyrcona |
A bit of seasonal humor: Real Programmers always confuse Christmas and Halloween because Oct31 == Dec25. |
| 15:55 |
remingtron |
eeevil: I'd like to help review critical bug 1245944, and I have some questions. Do you have a min? |
| 15:55 |
pinesol_green |
Launchpad bug 1245944 in Evergreen "Use all subfield values to link authority records to bibs" (affected: 1, heat: 8) [Critical,New] https://launchpad.net/bugs/1245944 |
| 15:56 |
eeevil |
remingtron: just a min |
| 15:57 |
rfrasur |
Dyrcona: clever |
| 15:57 |
* rfrasur |
needs two more jokes |
| 16:04 |
rfrasur |
jboyer-isl: will the new splash screen just be there in the morning when we log into the staff client or do we need to do something? |
| 16:06 |
jboyer-isl |
rfrausr: So long as you close evergreen each night, you don't have to do anything special. If, however, it's left up overnight, the cache would need to be cleared. (or close and re-open it, etc.) |
| 16:06 |
eeevil |
remingtron: sorry, I meant that I had just a minute... but it's gone now. email, or on the bug, and I'll look this evening? |
| 16:06 |
eeevil |
remingtron: sorry, again :( |
| 16:09 |
remingtron |
eeevil: ah I understand now. sure, I'll add to the bug. thanks. |
| 16:14 |
|
yboston joined #evergreen |
| 16:28 |
|
mjingle joined #evergreen |
| 16:33 |
|
smyers_ joined #evergreen |
| 16:40 |
|
hopkinsju joined #evergreen |
| 16:46 |
hopkinsju |
Hey guys. I'm looking at the Syndetics TPAC stuff. I'd like to add Series information to what's displayed. At first glance it looks like I could just add it to the ac_types list in opac/parts/record.tt |
| 16:46 |
hopkinsju |
Is there more to do? Is it being so simple just wishful thinking? |
| 16:47 |
hopkinsju |
rep, record/addedcontent.tt2 |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
stevenyvr2 joined #evergreen |
| 18:30 |
|
stevenyvr2 left #evergreen |
| 21:30 |
|
mjingle joined #evergreen |
| 21:31 |
|
stevenyvr2 joined #evergreen |
| 21:32 |
|
stevenyvr2 left #evergreen |
| 21:48 |
|
Dyrcona joined #evergreen |
| 21:48 |
|
Dyrcona1 joined #evergreen |
| 21:51 |
|
Dyrcona joined #evergreen |
