Time |
Nick |
Message |
01:25 |
|
Mark__T joined #evergreen |
06:40 |
|
rlefaive joined #evergreen |
07:26 |
|
mrpeters joined #evergreen |
07:39 |
|
rlefaive joined #evergreen |
07:51 |
|
ericar joined #evergreen |
08:00 |
|
jboyer-isl joined #evergreen |
08:06 |
|
akilsdonk joined #evergreen |
08:19 |
|
rjackson_isl joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
08:43 |
|
Shae joined #evergreen |
09:02 |
|
mrpeters joined #evergreen |
09:07 |
|
Dyrcona joined #evergreen |
09:07 |
|
mmorgan joined #evergreen |
09:09 |
|
mrpeters joined #evergreen |
09:15 |
|
Bmagic joined #evergreen |
09:15 |
|
hopkinsju joined #evergreen |
09:23 |
* jeff_ |
reattaches |
09:28 |
|
graced joined #evergreen |
09:33 |
|
mrpeters joined #evergreen |
09:33 |
|
yboston joined #evergreen |
10:01 |
csharp |
would someone mind sharing what they have as the "Patron barcode format" library setting? We use 14-digit codabar barcodes and I'm seeing some regex examples via the Goog, but they seem to just check for "is the entire string 14-digits long?" |
10:06 |
csharp |
without further input, I think we're just going to set it to check whether the entire string is 14-digits |
10:07 |
csharp |
the only use case I can think of is the patron who never changed her username from the default card number, then updates her card, but continues to use the old cardnumber as a username - that seems like a corner case |
10:07 |
* csharp |
fully expects 15 helpdesk tickets created with that exact issue, now that he's said it out loud |
10:07 |
Dyrcona |
csharp: We don't seem to have set one. |
10:08 |
Dyrcona |
We often get requests to fix patrons after registration, but it's usually when the staff tries to use a barcode that got assigned as the usrname on a previous user. |
10:08 |
|
collum joined #evergreen |
10:08 |
csharp |
Dyrcona: we discovered the need for it when testing the built-in selfcheck, which says "check whether the string the patron has entered matches the opac.barcode_regex setting... if not, treat the string like a username" |
10:09 |
csharp |
since our setting is null, all entered values are being treated like usernames |
10:09 |
Dyrcona |
Well, our opac.barcode_regex setting is a bit strange. It doesn't check length, for one thing. |
10:09 |
Dyrcona |
I thought you were asking about a different setting. |
10:10 |
Dyrcona |
But, the patron's barcode and usrname not matching, but both being barcodes, seem to happen in registration when the staff start out using 1 barcode and end up issuing a different one. |
10:10 |
Dyrcona |
That is, they switch barcodes during the process. |
10:10 |
Dyrcona |
Not sure why that happens, but it does. |
10:11 |
csharp |
I've seen that too |
10:11 |
Dyrcona |
Well, I know why the original barcode is the usrname. I'm not sure why staff would switch barcodes halfway through, except possibly in error. |
10:41 |
|
Christineb joined #evergreen |
10:56 |
jeff |
interruptions, possibly. |
11:11 |
* mmorgan |
reads backscroll |
11:12 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
11:12 |
mmorgan |
Our opac.barcode_regex specified the barcode must have at least five digits, that's all. Not sure where it actually comes into play. |
11:14 |
Dyrcona |
The test failure looks like one of those things we can't control. |
11:14 |
Dyrcona |
Got a 503 while trying to download the phantomjs package. |
11:17 |
phasefx |
start local repos for everything? |
11:27 |
Dyrcona |
Nope. It'll probably succeed when the issue on the server is discovered and resolved. |
11:27 |
Dyrcona |
5xx errors are usually temporary. |
11:36 |
|
pams joined #evergreen |
11:40 |
|
mdriscoll joined #evergreen |
11:44 |
|
akilsdonk joined #evergreen |
12:06 |
|
jihpringle joined #evergreen |
12:17 |
jboyer-isl |
csharp: I know it's late, but if you're still interested in what others are doing for opac.barcode_regex, ours is currently ^[0-9]+$ so all numbers. There's no reliable way I can see to catch those barcode=barcode1, usrname=barcode2 style situations. (Those people don't know they have usrnames anyway, so who cares.) |
12:19 |
jboyer-isl |
Dyrcona: As for common reasons that a user might have different barcodes in their barcode and usrname fields, we usually see that when someone looses their card a gets a replacement. Staff a supposed to change both fields in that case, but that doesn't always happen. |
12:26 |
* dbs |
wonders what people are doing to generate useful invoices for lost items, etc, as the workstation receipts for current bills are super-limited (no title/author info on a per-bill basis, for example) |
12:55 |
csharp |
jboyer-isl: thanks! |
13:04 |
Bmagic |
anyone had luck getting aggregate filters to work in the reporting module? I want the report to suppress lines where the sum of the billing is not greater than 0. |
13:05 |
csharp |
Bmagic: can you share what you've tried so far? |
13:07 |
Bmagic |
source table: Billable Transaction. Aggregate filter: Billable Transaction -> Billing Line Items -> Amount (sum) add -> Change value->0. Change operator -> Greater Than |
13:08 |
Bmagic |
Various stuff in the display. Two Base filters on Billable Transaction -> Circulation Billing Link -> Circulating Library (in List). Billable Transaction -> Circulation Billing Link -> Circulating Item -> Call Number -> Owning Library (in list) |
13:09 |
Bmagic |
I am trying to expose the situation when one library that charges lost fines has been circed by a library that doesn't. And when the item goes lost, the bill occurs for patrons who are not used to getting bills from their home lib |
13:09 |
Bmagic |
in that case, the circing lib owes the owning lib |
13:10 |
Bmagic |
I dont want the report to display all of the circs between the two libs, just those that created a bill (>0) |
13:11 |
Bmagic |
I suppose the issue is that for those that do not have a single billing line, they are getting displayed because there is nothing that the report engine has to add up, so I need to check for null? |
13:17 |
csharp |
Bmagic: do you have the generated SQL? that might give me a hint as to what to change... |
13:18 |
csharp |
on the face of it, sounds like you'd want to tinker with nullability selection so that only transactions with billings attached will be returned\ |
13:18 |
Bmagic |
Thanks. I'll take a look with those ideas in mind. |
13:30 |
berick |
Can someone confirm my understanding of circ limit sets? Is it correct to say they don't affect whether a circ rule is chosen, only how it behaves after it is chosen? |
13:31 |
berick |
For example, if I have a limit set with a copy location linked to a circ rule, that circ rule may still be used when checking out copies that don't use said copy location. |
13:34 |
csharp |
berick: that is correct to my understanding. PINES use case is adding a limit to the number of items one can have of certain circ modifiers (dvd/video/game) |
13:35 |
|
ehardy joined #evergreen |
13:35 |
berick |
thanks csharp |
13:35 |
csharp |
that is to say that the limit set itself doesn't affect which rule is chosen - I can't speak to your specific use case, though |
13:35 |
* csharp |
always consults tsbere on such matters |
13:36 |
csharp |
@seen tsbere |
13:36 |
pinesol_green |
csharp: tsbere was last seen in #evergreen 1 week, 3 days, 3 hours, 13 minutes, and 32 seconds ago: <tsbere> I think it was disconnected but left sitting there.....so yea. |
13:36 |
berick |
well, what i'm really trying to do is change the circ policy for a big list of copy locations (without affecting other copies). wondering if it's possible w/o creating a rule for every location. |
13:37 |
berick |
limit sets looked enticing, but if they don't affect rule selection, then they don't give me what I need (I don't think) |
13:38 |
Dyrcona |
tsbere is on vacation this week as well as last week. |
13:39 |
Dyrcona |
berick: You and csharp are correct, the limit sets are applied after matchpoints are chosen. |
13:39 |
berick |
thanks Dyrcona |
13:46 |
|
mbcraw joined #evergreen |
14:25 |
jeff |
hrm. more timeouts when processing patron information (63) messages with hold details in the summary request. |
14:27 |
* jeff |
digs |
14:29 |
|
wjr joined #evergreen |
14:50 |
|
Gabby joined #evergreen |
14:52 |
|
Gabby left #evergreen |
14:53 |
|
Gabby joined #evergreen |
14:54 |
|
Gabby joined #evergreen |
15:26 |
|
jlitrell joined #evergreen |
15:27 |
jeff |
ah. title hold on a bib whose only volume is deleted. |
15:33 |
jeff |
and we have a surprising number of those. |
15:35 |
pinesol_green |
[evergreen|Michael Peters] LP#1394989: Make users_of_interest test for defined actor.usr.card values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13da6b8> |
15:35 |
pinesol_green |
[evergreen|Bill Ott] LP#1394989: Do not include deleted users when retrieving for Collections - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0f8ec14> |
15:39 |
|
berowskim joined #evergreen |
15:57 |
Bmagic |
I have a bib that is sorted to the bottom of the list search when sorted newest to oldest. Come to find out, there is no entry in metabib.record_sorter for pubdate for this bib. When I reingest the bib, it still doesnt get created. Where is the glue? |
16:02 |
Bmagic |
I found it. sorry, that was easy, Date1 in the 008 |
16:07 |
hopkinsju |
Hey Dyrcona! I've been toying with your BSLW import/export scripts. The documentation is great, but I'm still not having awesome luck getting it working. I feel like there is some undocumented sauce that I'm missing. |
16:08 |
hopkinsju |
I have the BIB.MRC and AUTH.MRC files locally, and am trying to pass those to the BSLWimport.pl script. |
16:09 |
Dyrcona |
hopkinsju: The scripts expects to get everything in one zip file. |
16:09 |
hopkinsju |
I zipped up a small sample from BIB.MRC to BIB.ZIP, and ran 'BSLWimport.pl BIB.ZIP' |
16:09 |
hopkinsju |
The output says it's updating authorities, but the marc doesn't get updated AFAICT |
16:11 |
hopkinsju |
Dyrcona: So, a zip file containing both BIB.MRC and AUTH.MRC will be handled correctly? |
16:11 |
Dyrcona |
Yep, it should. |
16:11 |
Dyrcona |
If you look, it processes bibs from a file matching BIB. |
16:11 |
Dyrcona |
It handles authority deletes from a file matching DEL |
16:12 |
Dyrcona |
Anything else that doesn't begin with R followed by 2 digits is treated as an authorities file. |
16:13 |
Dyrcona |
We get zips with bibs, authorities, and reports all in one and it handles them OK. |
16:13 |
hopkinsju |
So if I have a zip file with ONLY a file called BIB.MRC in it, shouldn't that get overlayed? |
16:14 |
hopkinsju |
I'm trying to do some smaller scale testing before i set it loose. |
16:15 |
Dyrcona |
It depends. If you look in Backstage::Import->do_bibs you'll see there are some criteria, but you should get some output to the screen as each record is processed. |
16:15 |
Dyrcona |
Sorry, it's doBibs not do_bibs. |
16:15 |
hopkinsju |
Ok |
16:17 |
hopkinsju |
Hmm. Looks like I should get a print of either "Import $id" or "Keep $id" |
16:18 |
Dyrcona |
What are you seeing? You said something about updating authorities. If the file is indeed named BIB.MRC it should say just Import or Keep followed by a bre.id. |
16:18 |
Dyrcona |
Yeah. |
16:19 |
Dyrcona |
The file name checks are case sensitive. |
16:19 |
hopkinsju |
Right, when I passed it a zip file with a file named msplitsomethingsomething004.mrc it thought it was authorities. I figured that out and renamed the msplit file to BIB.mrc and zipped it up. Now I get no output. |
16:20 |
hopkinsju |
Let me check this out real quick. brb. |
16:21 |
Dyrcona |
OK. If you got a zip file from Backstage. I suggest just processing it as-is. That's what I do. |
16:21 |
Dyrcona |
commas, periods, what's the difference? :) |
16:24 |
Dyrcona |
Ah, you might be getting nothing if the print_import setting is false or not set. |
16:25 |
Dyrcona |
Looks like they are true in the sample config. |
16:47 |
hopkinsju |
They are set to true. Looks to me like it's not even checking the file. I'm gonna keep looking - not trying to make you do support, just thought I might be missing something obvious. |
16:54 |
Dyrcona |
hopkinsju: unzip -l might help turn something up. It will show the listing in the zip, anyway. |
16:57 |
hopkinsju |
Looks like the part of BSLWimport.pl that calls doFile() is running, but doFile() is not in fact running. |
16:58 |
hopkinsju |
http://pastebin.com/QA8TvgMm |
16:59 |
|
mdriscoll left #evergreen |
17:00 |
Dyrcona |
It's probably because of the full path to BIB.MRC in the zip file. |
17:01 |
Dyrcona |
The zip files that I get from Backstage have no directory information in the member file names. |
17:02 |
Dyrcona |
Anyway, signing off for now. |
17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:05 |
|
mmorgan left #evergreen |
17:14 |
jeff |
deleted bibs with non-deleted call numbers. deleted call numbers with non-deleted copies. |
17:14 |
jeff |
always fun to try to determine which way to "fix" this. |
18:07 |
|
gdunbar joined #evergreen |
18:09 |
|
TaraC_ joined #evergreen |
18:09 |
|
Callender_ joined #evergreen |
19:27 |
|
jonadab joined #evergreen |
20:47 |
|
jonadab joined #evergreen |