| Time |
Nick |
Message |
| 01:23 |
* dcook |
is so lost |
| 01:24 |
dcook |
Have a good Friday, folks :) |
| 01:24 |
|
dcook left #evergreen |
| 05:52 |
|
mrpeters1 joined #evergreen |
| 05:54 |
* csharp |
really wishes postgresql had progress bars :-/ |
| 06:00 |
|
mrpeters joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 08:35 |
|
akilsdonk joined #evergreen |
| 08:51 |
|
kbeswick joined #evergreen |
| 08:54 |
|
mmorgan joined #evergreen |
| 08:57 |
|
ericar joined #evergreen |
| 09:09 |
|
Shae joined #evergreen |
| 09:17 |
|
jtaylorats joined #evergreen |
| 09:18 |
jtaylorats |
Is there a way to import MFHD holdings into Evergreen? |
| 09:19 |
jtaylorats |
Keep finding links that say I can but never one that tells me how. |
| 09:20 |
dbs |
jtaylorats: there is |
| 09:21 |
jtaylorats |
Could you point me towards some info on how to do it? |
| 09:21 |
dbs |
The Open-ILS/src/extras/import/marc2sre.pl was one important part |
| 09:23 |
dbs |
http://permalink.gmane.org/gmane.education.libraries.open-ils.general/3685 has some info about it |
| 09:24 |
jtaylorats |
Thanks. I'll take a look at that. |
| 09:26 |
jtaylorats |
Some reading had indicated that it was also possible via Vandelay but maybe I misunderstood. |
| 09:27 |
dbs |
jtaylorats: You can use vandelay to import the serial *bib* records, but I don't think it supports the associated mfhd records |
| 09:28 |
dbwells |
Correct, there is no support for importing MFHD records in Vandelay. |
| 09:28 |
* dbs |
hasn't really touched marc2sre.pl or the test data or the associated test data README since he put that stuff together for his own migration in 2009 |
| 09:29 |
jtaylorats |
Okay. Appreciate the info. |
| 09:30 |
jtaylorats |
Do you happen to know off the top of your head what table the info resides in? I'm sure I can find it but am lazy enough to ask :-) |
| 09:30 |
dbwells |
jtaylorats: the MFHD records are in serial.record_entry |
| 09:30 |
jtaylorats |
Okay. Thanks. |
| 09:31 |
jeff |
Hrm. There no longer appears to be a way to obtain a list of all holds in the opac. a cgi param of 0 gets overwritten by my $limit = $self->cgi->param('limit') || 15; |
| 09:33 |
jtaylorats |
Just checked serial.record entry again (had looked there before) but it doesn't appear to hold the MFHD data. |
| 09:33 |
jeff |
I'm torn between wanting to have reasonable upper bounds and wanting to have a means of "show them all, no paging". :-) |
| 09:34 |
jtaylorats |
I've looked through all the other tables but not seeing it there either. |
| 09:35 |
dbwells |
jtaylorats: Have you somehow loaded the MFHD records? I am 100% positive that serial.record_entry is where they go. |
| 09:35 |
jtaylorats |
We created one manually. |
| 09:35 |
|
jbfink joined #evergreen |
| 09:36 |
jtaylorats |
and can see it in the PAC as expected. |
| 09:37 |
dbwells |
jtaylorats: And the table is empty? The 'marc' column will have the MFHD data. |
| 09:37 |
jtaylorats |
The record entry table has id info and probably links things together but no actual data resides there as far as I can tell. |
| 09:37 |
jtaylorats |
Never mind... |
| 09:37 |
jtaylorats |
I'm just blind. |
| 09:38 |
jtaylorats |
So it stores it as XML. |
| 09:38 |
dbwells |
jtaylorats: Yes. If you stick with manual MFHD records, it's all rather straightforward. |
| 09:39 |
jtaylorats |
Okay. Maybe I can do the import directly if I can get the right link info. Thanks again. |
| 09:39 |
dbwells |
jtaylorats: the biggest trick to loading MFHD from a legacy system is mapping your MFHD to the appropriate bib records in biblio.record_entry. |
| 09:40 |
jtaylorats |
Yes. Agreed. |
| 09:40 |
jtaylorats |
Guess it is back to the battlefront. |
| 09:40 |
dbwells |
jtaylorats: When we migrated way back when, we intentionally kept our old system IDs. This made things much simpler. |
| 09:41 |
jtaylorats |
That is what I'm doing as well. That way I can also do a re-import and use it as a match point. |
| 09:41 |
jtaylorats |
In case things don't go like we want. |
| 09:41 |
dbwells |
Cool, then you are halfway there :) |
| 09:41 |
dbwells |
good luck |
| 09:41 |
jtaylorats |
Thanks. |
| 09:49 |
jeff |
and the holds history behavior is different from the holds behavior. huh. |
| 09:50 |
|
mllewellyn joined #evergreen |
| 09:54 |
|
collum joined #evergreen |
| 09:58 |
|
finnx joined #evergreen |
| 09:58 |
|
yboston joined #evergreen |
| 10:28 |
bshum |
dbwells++ #LP bug shuffling |
| 10:31 |
|
mcooper joined #evergreen |
| 10:42 |
|
rfrasur joined #evergreen |
| 10:43 |
dbwells |
bshum: Are you still working on bug #1254826? |
| 10:44 |
pinesol_green |
Launchpad bug 1254826 in Evergreen "Missing override permission for PATRON_EXCEEDS_LOST_COUNT" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1254826 |
| 10:44 |
dbwells |
If so, I'd like to assign it to you. |
| 10:52 |
bshum |
Yeah I'll take that one dbwells. |
| 10:52 |
bshum |
I'd kind of forgotten about it. |
| 10:52 |
bshum |
:( |
| 10:52 |
dbwells |
it's yours! |
| 10:52 |
dbwells |
thanks |
| 10:53 |
* jeff |
grins |
| 11:00 |
|
sseng joined #evergreen |
| 11:01 |
|
fparks joined #evergreen |
| 11:03 |
bshum |
berick++ # bug 1269884 fix. One of our libraries finally noticed this was broken. |
| 11:03 |
pinesol_green |
Launchpad bug 1269884 in Evergreen 2.5 "Selfcheck checkout dies on invalid function name: record.id()" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1269884 |
| 11:05 |
|
sseng_ joined #evergreen |
| 11:09 |
pinesol_green |
[evergreen|Bill Erickson] LP#1269884 repair MVR id / doc_id thinko - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ba0852> |
| 11:33 |
|
mrpeters joined #evergreen |
| 12:01 |
|
dMiller__ joined #evergreen |
| 12:32 |
|
smyers_ joined #evergreen |
| 13:51 |
jeff |
backdated checking on already-paid overdue fines. bleh. |
| 13:51 |
jeff |
s/checking/checkin/ |
| 14:03 |
|
akilsdonk joined #evergreen |
| 14:13 |
bshum |
jeff: That one sucks |
| 14:14 |
bshum |
I hate it when that happens. |
| 14:19 |
|
sseng joined #evergreen |
| 14:26 |
|
tfaile_ joined #evergreen |
| 14:30 |
|
akilsdonk joined #evergreen |
| 14:31 |
|
ericar joined #evergreen |
| 14:32 |
|
BigRig joined #evergreen |
| 14:32 |
|
Callender joined #evergreen |
| 14:33 |
|
akilsdonk_ joined #evergreen |
| 14:35 |
|
ericar_ joined #evergreen |
| 14:35 |
jeff |
bshum: especially with mmpbbt. |
| 14:36 |
jeff |
because what do you do with the rest of a payment when you're trying to attribute payments to billings? :-) |
| 14:36 |
jeff |
(answer-for-now is likely to be "attribute with billing -1 and show a billing_type of OVERPAY) |
| 14:37 |
jeff |
er, associate with or attribute to, likely not "attribute with" |
| 14:48 |
jboyer-isl |
Has anyone seen a "_print_tree" error when accepting offline transactions? We're testing a 2.5 client and that's not a comforting thing to encounter. |
| 14:49 |
jboyer-isl |
Fun fact: commenting out the try's and catch's in chrome/content/util/print.js allows it to work with no indication of an unhandled exception. :/ |
| 14:49 |
jboyer-isl |
(in the _print_tree function, that is) |
| 14:50 |
bshum |
jboyer-isl: When you say "accepting offline transactions" what do you mean? |
| 14:50 |
bshum |
Saving them in offline? Uploading them? Processing them? |
| 14:51 |
jboyer-isl |
Sorry, that wasn't very specific. Clicking Save these transations with the Auto Print box checked. |
| 14:51 |
csharp |
jboyer-isl: yes, we're seeing it |
| 14:52 |
csharp |
it appears to be fixed when you go in and configure a printer |
| 14:52 |
csharp |
that's all I know for now |
| 14:52 |
jboyer-isl |
I tried that and it didn't seem to help. I'll try again. |
| 14:52 |
* bshum |
can't find an autoprint button |
| 14:52 |
bshum |
Just a "Print Receipt?" checkbox |
| 14:52 |
jboyer-isl |
Oops, yes, "Print Receipt." |
| 14:53 |
csharp |
it appeared for us this week, just before our (currently ongoing) upgrade and just after we've been pushing more people to use it |
| 14:53 |
bshum |
Fwiw, I'm not getting an error on our production client, it just launches to my XPS printer. |
| 14:53 |
jboyer-isl |
It was happening before the new clients were installed? |
| 14:54 |
csharp |
jboyer-isl: we didn't hear about it before then |
| 14:54 |
csharp |
the details I have are pretty sketchy though |
| 14:55 |
csharp |
from what I understand, though you log in and add a printer, exit completely, enter standalone, and it works |
| 14:55 |
csharp |
bshum: and yes - it appears to be hard to reproduce |
| 14:55 |
csharp |
if may be old profile data vs. new client |
| 14:55 |
csharp |
s/if/it/ |
| 14:56 |
jboyer-isl |
Context must matter, because I've tried that in the Offline context, but only now set up a printer in the default context. |
| 14:56 |
jboyer-isl |
Aha. |
| 14:56 |
jboyer-isl |
And now it works. |
| 14:56 |
jboyer-isl |
:( |
| 14:57 |
csharp |
so you were setting up an offline printer without selecting a default printer? |
| 14:58 |
jboyer-isl |
My current workstation rarely ever prints, so most contexts are unset. |
| 14:58 |
csharp |
yeah - that was my trouble recreating too |
| 14:59 |
jboyer-isl |
I tried setting a printer for the offline context though... |
| 14:59 |
jboyer-isl |
OH. |
| 14:59 |
jboyer-isl |
But I set the offline_checkout template to force the receipt context, not offline. |
| 14:59 |
jboyer-isl |
Oops. |
| 15:02 |
mceraso |
dbwells: I just finished testing the release candidate for 2.5.2 using Ubuntu 12.04 LTS and everything works just fine |
| 15:03 |
csharp |
mceraso++ |
| 15:05 |
dbwells |
mceraso++ # thanks! |
| 15:06 |
mceraso |
Not a problem at all :) Always happy to help! |
| 15:10 |
mmorgan |
jboyer-isl: csharp: Coming in late on this but we had exactly this issue when down for our 2.4 upgrade |
| 15:10 |
mmorgan |
Setting the offline printer, totally exiting the client, then launching again worked - for most |
| 15:11 |
mmorgan |
Some users reported they had to redo their printer settings, though, because they didn't seem to stick the first time |
| 15:29 |
jboyer-isl |
Thanks mmorgan, we'll tell people they can test things ahead of time and hopefully it won't turn out to be a huge issue. |
| 15:30 |
jboyer-isl |
(Though we all know better. <_< >_>) |
| 16:11 |
|
BigRig_ joined #evergreen |
| 16:14 |
|
BigRig__ joined #evergreen |
| 16:16 |
|
BigRig joined #evergreen |
| 16:19 |
|
akilsdonk joined #evergreen |
| 16:25 |
|
stevenyvr joined #evergreen |
| 16:32 |
|
akilsdonk joined #evergreen |
| 16:45 |
|
ericar joined #evergreen |
| 17:08 |
|
mrpeters left #evergreen |
| 17:43 |
|
mmorgan left #evergreen |
| 17:47 |
|
sseng_ joined #evergreen |
