| Time |
Nick |
Message |
| 00:24 |
dbs |
@later tell hbrennan If you can create a new directory / file in your custom template folder, you can override the default template |
| 00:24 |
pinesol_green |
dbs: The operation succeeded. |
| 00:37 |
|
PrabhjyotSodhi joined #evergreen |
| 01:06 |
|
shadowspar joined #evergreen |
| 01:30 |
|
BigRig_ joined #evergreen |
| 01:32 |
|
gdunbar joined #evergreen |
| 01:33 |
|
jeffdavi1 joined #evergreen |
| 05:43 |
|
mtj_ joined #evergreen |
| 07:06 |
|
b_bonner joined #evergreen |
| 07:07 |
|
tfaile joined #evergreen |
| 07:11 |
csharp |
@later tell hbrennan you should ask your IT dept for a testing server that you can play with too |
| 07:11 |
pinesol_green |
csharp: The operation succeeded. |
| 07:25 |
|
timlaptop joined #evergreen |
| 07:40 |
|
kbeswick joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:26 |
|
bshum joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
Shae joined #evergreen |
| 08:41 |
|
rjackson-isl joined #evergreen |
| 08:48 |
|
StephenGWills joined #evergreen |
| 08:50 |
csharp |
jeff: whenever you're around, I have a library who may be interested in adding a local image. I remember at the Hack-a-Way that you demoed that and that it looked like it got into 2.5.X... do you have any docs for how to add an image? |
| 08:50 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
jwoodard joined #evergreen |
| 08:55 |
StephenGWills |
Morning Y'all. I *KNOW* I need to upgrade from 2.3 but.. was it common to have Items not show up in the TPAC that would show up in the JSPAC? I'm having trouble finding LIT on this problem. I'm running 2.3.5 |
| 08:55 |
dbs |
csharp++ |
| 08:55 |
dbs |
StephenGWills: yep, that sounds familiar |
| 08:55 |
bshum |
901c? |
| 08:55 |
dbs |
bshum++ |
| 08:56 |
dbs |
also the inverse; items would show up in tpac that weren't in jspac, due to incomplete checking of various deleted properties |
| 08:57 |
_bott_ |
I have 479 copies with action.transit_copy rows, with null dest_receive_time, and current status of something other than "In Transit" ...good times |
| 08:58 |
|
mmorgan1 joined #evergreen |
| 08:58 |
|
mmorgan1 left #evergreen |
| 08:59 |
_bott_ |
Seems like staff error, combined with floating='t' provides the ability to never finish a transit, and allow a copy to lead a normal productive life |
| 09:00 |
|
mmorgan joined #evergreen |
| 09:03 |
csharp |
StephenGWills: you have have to reingest all the bibs - at minimum reingest ones with no 901c |
| 09:03 |
csharp |
(then vacuum analyze metabib.* tables) |
| 09:04 |
|
ericar joined #evergreen |
| 09:04 |
StephenGWills |
sharp I remembered that there is that reingester but on looking for it the other day didn't find it. I'm just picking this problem back up. is reinvest a support_script? |
| 09:07 |
csharp |
StephenGWills: one sec... there are reingest improvements in 2.4+, so I don't want to give you the wrong info |
| 09:09 |
jeff |
csharp: sure, if you want a custom local image for record 12345: |
| 09:09 |
csharp |
StephenGWills: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/version-upgrade/2.2-2.3.0-upgrade-db.sql;h=a6cfd9a93ba2e32b57805b9d593bf037d717b8d0;hb=refs/heads/tags/rel_2_3_5#l2238 |
| 09:09 |
|
rfrasur joined #evergreen |
| 09:09 |
jeff |
create three dirs /openils/var/web/opac/extras/ac/jacket/{small|medium|large}/r |
| 09:09 |
csharp |
StephenGWills: the lines beginning with \qecho will let you know what you need |
| 09:10 |
StephenGWills |
kk looking |
| 09:10 |
jeff |
place an .htaccess file in each dir (you might be able to do this at a common ancestor directory -- i've not tried) containing: "ForceType image/jpeg" |
| 09:11 |
jeff |
place a jpeg file named "12345" in the large/r/ medium/r/ and small/r/ directories |
| 09:11 |
jeff |
if you have multiple app servers without /openils/var/web/opac/extras/ac/jacket being shared storage between them all, you'll need to copy the images to each app server. |
| 09:11 |
jeff |
then, test. |
| 09:12 |
csharp |
so the ../r directory contains any custom jpegs that are named by the bib id number, correct? |
| 09:12 |
jeff |
right |
| 09:12 |
StephenGWills |
the bib in question does not have a 901$c, I'm feeling hopeful :) thanks Chris |
| 09:12 |
csharp |
StephenGWills: happy to help! |
| 09:13 |
* csharp |
has been through that battle before ;-) |
| 09:13 |
csharp |
jeff: okay - cool - I'll experiment |
| 09:14 |
jeff |
csharp: let me know how i goes. in describing it to you just now i think i realized at least one of those things (the ForceType trick) isn't described in documentation yet. |
| 09:14 |
jeff |
csharp: if you have a strong need to do both jpg and png and other formats, i'm sure it can be done with mod_rewrite and/or content negotiation. not sure which would be simpler. |
| 09:14 |
jeff |
csharp: in our case, we opted for "just jpeg" |
| 09:15 |
jeff |
we currently have 22,419 local jacket images. |
| 09:15 |
bshum |
jeff and his puppets |
| 09:16 |
jeff |
some of them could be deemed superfluous by additional code to search for more URLs in the MARC for jacket images. |
| 09:16 |
jeff |
or "use this url with this identifier from the MARC for bibs from this source" |
| 09:16 |
jeff |
but we don't have that yet (though there's a wishlist bug for the former) |
| 09:16 |
jeff |
(or something like the former) |
| 09:18 |
csharp |
wow |
| 09:18 |
csharp |
well, we're discussing sustainability at this point - we're pretty sure we can't handle an influx of local image requests at this point |
| 09:18 |
bshum |
jeff: I was thinking about custom images the other day as I looked at some random 856 lines. |
| 09:18 |
csharp |
but I still want to test it (and possibly script it) |
| 09:19 |
jeff |
yeah, we have an interface that staff use to upload jacket images. |
| 09:19 |
* csharp |
imagines a staff upload interface that would act like an "incoming" directory |
| 09:19 |
csharp |
heh |
| 09:19 |
csharp |
well if we have that, I'm game ;-) |
| 09:19 |
jeff |
any staff can create a jacket image for any record. |
| 09:19 |
jeff |
also, there are leaderboards. |
| 09:20 |
csharp |
leaderboards? |
| 09:20 |
bshum |
leaderboards++ |
| 09:21 |
* bradl |
imagines uploading all grumpy cat |
| 09:23 |
jeff |
csharp: "all time" and "past 30 days" leaderboards listing staff name ordered by how many jackets they've uploaded. |
| 10:54 |
|
serflog joined #evergreen |
| 10:54 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 11:04 |
senator |
what's a right size for a marc record? |
| 11:05 |
Dyrcona |
0 bytes? |
| 11:05 |
rfrasur |
(whatever ebsco wants because they rule the world and we all must bow) |
| 11:05 |
Dyrcona |
Seriously, they say that many of our records don't match the size in the LDR, and they sent me some output from their software showing a few records being off by one. |
| 11:06 |
Dyrcona |
Of course, they haven't told me which records. |
| 11:06 |
Dyrcona |
I didn't think any sane software actually paid attention to the size field. |
| 11:06 |
senator |
i had totally forgotten it existed |
| 11:07 |
Dyrcona |
They must be using MARC4J. |
| 11:07 |
Dyrcona |
It is apparently thousands of our records. |
| 11:07 |
* berick |
wonders if it's a unicode bytes vs characters thing |
| 11:08 |
Dyrcona |
that's one of my suspicions. |
| 11:09 |
|
jbfink joined #evergreen |
| 11:11 |
jcamins |
senator: definitely zero bytes. |
| 11:11 |
jcamins |
You know, that was so much cleverer when I typed it 7 minutes ago. |
| 11:11 |
senator |
heh |
| 11:11 |
Dyrcona |
They sent me one example, actually: "ERROR - Record size not valid: Record could not be fixed -- Leader specified length (1981) but rather was (1980)) Errant data (01981cjm 2200433Ia" |
| 11:14 |
jeff |
how did you send the records to them? |
| 11:15 |
jeff |
in terms of, i'm assuming they're MARC and not MARCXML... |
| 11:15 |
jeff |
how were they generated on your end? |
| 11:19 |
Dyrcona |
Using my Marque.pm branch and the usual rain dance with MARC::Record. |
| 11:20 |
Dyrcona |
Yes, they are MARC, not MARCXML. |
| 11:20 |
Dyrcona |
EBSCO prefers MARC, not MARCXML. |
| 11:22 |
eeevil |
just a guess, but perhaps m::r is counting the record separator as part of the preceding record, but marc4j is not |
| 11:23 |
eeevil |
(also, the marc specs are ambiguous WRT characters vs bytes, and use the terms interchangeably throughout) |
| 11:24 |
Dyrcona |
I'm wildly speculating on the marc4j only because I had trouble with it during our migration. It expected the size fields from Horizon to be correct and they were off by miles. |
| 11:25 |
Dyrcona |
I don an insert_grouped_field when adding holdings. Should I call the method to recalculate the size after that? I *thought* it was handled automatically. |
| 11:26 |
Dyrcona |
s/don/do/ |
| 11:28 |
Dyrcona |
I'll try that with this Friday's dump. I don't think it will make a difference, but why not? |
| 11:30 |
Dyrcona |
Oh. I actually have to know the length to use that method. |
| 11:48 |
Dyrcona |
Ah well, another email in the chain with EBSCO.... |
| 12:01 |
|
akilsdonk joined #evergreen |
| 12:02 |
|
afterl joined #evergreen |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:22 |
jboyer-isl |
jeff, possibly Dyrcona: Some time in the last week or so I was in here asking about an issue that only seemed to effect the conify interfaces and there was some curiosity about how it turned out. What happened was that the wrong hostname was set for OSRFTranslatorCacheServer. |
| 12:23 |
jeff |
Ah. Sorry, should have suggested that first. :-) |
| 12:23 |
jeff |
I think the two causes have similar symptoms, but I went with the more subtle possible cause. Sorry. :-) |
| 12:24 |
jboyer-isl |
No problem, it's humming along now. (And just in time! upgrade is in 11 days. D: ) |
| 12:27 |
jeff |
Basic postgres question... I can use the output of a function returning SETOF (in this case, actor.address_alert_matches) using EXISTS (SELECT 1 FROM actor.address_alert_matches([arguments]))... but given a query that returns a number of addresses with an alert, what's a good way to include the actual alert, the data returned by the function? |
| 12:27 |
jeff |
Right now I'm discarding it. |
| 12:27 |
jeff |
(with SELECT 1 FROM in the EXISTS clause) |
| 12:39 |
tsbere |
jeff: Use it as part of a join? |
| 12:41 |
tsbere |
SELECT whatever FROM whatever JOIN actor.address_alert_matches(blah) aaam... |
| 12:44 |
|
snowball joined #evergreen |
| 12:45 |
jeff |
not sure i can do that without an ON |
| 12:45 |
|
dbs_ joined #evergreen |
| 12:46 |
|
adbowling-isl_ joined #evergreen |
| 12:46 |
|
dconnor joined #evergreen |
| 12:46 |
tsbere |
jeff: "ON true"? |
| 12:47 |
jeff |
heh. it was worth a shot: |
| 12:47 |
jeff |
ERROR: invalid reference to FROM-clause entry for table "au" |
| 12:47 |
jeff |
LINE 18: JOIN actor.address_alert_matches(au.home_ou, aaua.street1, a... |
| 12:47 |
jeff |
^ |
| 12:47 |
jeff |
HINT: There is an entry for table "au", but it cannot be referenced from this part of the query. |
| 12:48 |
tsbere |
jeff: Ahh, you want to use other parts of your query. That complicates matters. |
| 12:48 |
jeff |
i'll gist the query as i have it thus far. it might require a completely different approach, or i might just want to punt to creating a new function. |
| 12:48 |
* tsbere |
probably needs to know the actual goal at this point |
| 12:49 |
jeff |
tsbere: https://gist.github.com/jeff/2e682cecdbf2f7b8af11 |
| 12:50 |
jeff |
i am reporting on patrons with an address alert |
| 12:50 |
jeff |
ideally, i'd like to have the text of the address alert also show. |
| 12:50 |
jeff |
(be included in the output of the query) |
| 12:50 |
jeff |
i can probably just unroll the actor.address_alert_matches function into my query. |
| 12:51 |
jeff |
but the "can i do this with a function returning SETOF in this circumstance" seemed useful to determine an answer to, for future. |
| 12:52 |
tsbere |
jeff: Well, I can give you "the first alert in the list" easily. "All alerts in the list" is harder. |
| 12:52 |
jeff |
i'll take that for starters. |
| 12:53 |
* tsbere |
could be wrong on the "all" front now that he ran a test |
| 12:54 |
tsbere |
jeff: Add this to the end of your SELECT DISTINCT line: , (actor.address_alert_matches(au.home_ou, aaua.street1, aaua.street2, aaua.city, aaua.county, aaua.state, aaua.country, aaua.post_code, aaua.mailing, aaua.billing))).alert_message |
| 12:54 |
jeff |
ah, see i was trying to think of how to do it with a subselect -- suddenly, easier! |
| 12:56 |
tsbere |
I might have an extra ) in there |
| 12:56 |
tsbere |
<_< |
| 12:56 |
jeff |
you did, i'm pretty sure. |
| 12:56 |
* tsbere |
can't actually test this due to MVLC not *having* any such alerts defined right now |
| 12:57 |
jeff |
we recently started using them, and i'm trying to make them do double duty for reporting as well as the alerts in the user editor. |
| 12:58 |
jeff |
currently takes over a minute to run, but that's reasonable for this report. |
| 13:01 |
|
jeffdavis joined #evergreen |
| 13:01 |
tsbere |
jeff: Still, that trick is generally useful whenever a "record" is returned from a function, SETOF or no. The extra () around the function (or variable, in some cases) is needed though. <_< |
| 13:08 |
csharp |
okay - I'm interested in the practical difference between 'next' and 'return' in perl, in light of commit 174c7db5bb5be07b19d564412fc5651405ba5b1c |
| 13:08 |
pinesol_green |
[evergreen|Dan Scott] return, not next, from eval BLOCK - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=174c7db> |
| 13:08 |
csharp |
and then commit f040814c7507291c388a35a23c8878293a2524e4 |
| 13:08 |
pinesol_green |
[evergreen|Liam Whalen] Fixes error with generate_fines for overdues returned after closed date - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f040814> |
| 13:10 |
csharp |
(following up on the fine generator issue we found around our snOMG experience last week) |
| 13:10 |
Dyrcona |
csharp: return causes the current code block to stop executing, be that a function or an eval. |
| 13:10 |
tsbere |
csharp: eval blocks get processed more as functions, I believe, so return exits that function, compared to next which would be trying to continue the outer loop. I think. |
| 13:11 |
Dyrcona |
tsbere: We haven't had any complaints of this, have we? |
| 13:11 |
tsbere |
I don't recall any. Doesn't mean it hasn't happened. |
| 13:12 |
csharp |
in our case, it appears to be going back and charging patrons for library closed dates |
| 13:12 |
csharp |
looks like normal hours of operation are okay |
| 13:13 |
csharp |
so if we *want* it not to continue evaluating the outer loop, we want return, right? |
| 13:14 |
csharp |
next means 'okay next step'? |
| 13:14 |
jeff |
one unfortunate aspect of an IDE for reports generation... when your query takes >1m to run, it takes >1m for the IDE to fetch your field names and data types. :-) |
| 13:16 |
Dyrcona |
csharp: I looks like the next could be doing what you describe, but I have no empirical evidence to back that up. |
| 13:16 |
|
ktomita joined #evergreen |
| 13:16 |
Dyrcona |
s/I/It/ |
| 13:16 |
csharp |
Dyrcona: thanks |
| 13:16 |
tsbere |
csharp: I don't think there is a way for the eval block to terminate the outer loop directly, somewhat by design |
| 13:17 |
csharp |
our end result is that we don't want fines to be charged for days that have been marked as closed dates, even after the fact |
| 13:18 |
csharp |
looks like closed dates are acting more like grace periods with the current behavior |
| 13:19 |
Dyrcona |
next breaks from the loop at that point and starts again at the top with the next iteration. |
| 13:21 |
dbwells |
csharp: I am pretty sure the code is meant to do what you want it to do. If I understand your situation correctly, for some reason, actor::org_unit::closed_date->search_where() isn't finding your closed dates. |
| 13:22 |
csharp |
dbwells: I can dig for this, but can you see a simple-ish way to test that hypothesis? |
| 13:22 |
Dyrcona |
I was about to say something along the lines of what dbwells just said. |
| 13:22 |
Dyrcona |
I needed more context. :) |
| 13:23 |
dbwells |
csharp: That function basically is a straight DB lookup (I think), so I'd start by looking in the DB and see if everything is in line there. |
| 13:24 |
Dyrcona |
csharp: Are you expecting it go by the copy's circ_lib closed day or the circulation's circ_lib closed? |
| 13:24 |
csharp |
Dyrcona: circulation circ_lib |
| 13:24 |
Dyrcona |
ok. that is what it looks like it should be doing. |
| 13:26 |
csharp |
qq |
| 13:28 |
dbwells |
csharp: I'd grab one of the bogus bills, figure out the timestamp and circ_lib for that, then do a select from the actor.org_unit_closed table and make certain you are finding what you want. Who knows, maybe it is something simple like a wrong year, or a closed date not propogated into all the branches. |
| 13:28 |
csharp |
dbwells: thanks |
| 13:52 |
csharp |
okay - mystery solved - it's not a bug ;-) |
| 13:53 |
csharp |
we run our fine generator at 12:30 a.m. and the closing was set later that day |
| 13:53 |
csharp |
so fines had already been generated |
| 13:53 |
* csharp |
bangs head on desk |
| 13:56 |
csharp |
dbwells++ Dyrcona++ tsbere++ # thanks as always for your help |
| 13:59 |
jeff |
so we're back to the original "need a new feature for that" conversation of yesterday. :-) |
| 13:59 |
csharp |
yeap |
| 13:59 |
* csharp |
presses the "forgive all fines for closed day" button and calls it a day |
| 13:59 |
jeff |
and i think it could be a useful new feature. i wouldn't want to undertake it until the new-style voids are in, though. |
| 14:00 |
jeff |
csharp: wait, you HAVE one of those buttons? :-) |
| 14:00 |
jeff |
actor.usr_address.address_type being completely freeform yet having a NOT NULL requirement sure does lead to some interesting things. |
| 14:00 |
* tsbere |
wonders if we should all move the fine generator to run *before* midnight so that libraries have the day to add the closed date for snow days and such |
| 14:02 |
bshum |
Sigh |
| 14:02 |
bshum |
Snow days make me sad. |
| 14:02 |
csharp |
tsbere: right - we were just having that conversation here |
| 14:03 |
tsbere |
csharp: In your conversation you should note that checkin time fine generation will catch "today" if they are open anyway |
| 14:03 |
csharp |
our conversation was very much academic |
| 14:04 |
csharp |
I actually think jeff's feature idea is probably better |
| 14:04 |
csharp |
snow-- |
| 14:04 |
csharp |
man I used to love snow days - now they're just a PITA |
| 14:04 |
tsbere |
It has been a long time since I loved snow days. |
| 14:05 |
bshum |
I think I've been pestering jeff about that "feature" for a few years now. Every winter, probably. :) |
| 14:05 |
tsbere |
Basically since I was expected to shovel said snow. <_< |
| 14:24 |
* gmcharlt |
adds a "snowday" tag to lp1276259 |
| 14:24 |
csharp |
snow-OMG!2014 |
| 14:26 |
gmcharlt |
tsbere: the pushme to your pullyou is libraries who want to display accumulated fines on their notices, after the fine generator has run |
| 14:27 |
gmcharlt |
though that may be an argument for scheduling it to run at more like 7 a.m., at least for small enough systems where you don't need all of the early morning to process notices |
| 14:31 |
|
pinesol_green` joined #evergreen |
| 14:32 |
Dyrcona |
Sure, send someone binary MARC records in a docx, why the Hell not!? |
| 14:32 |
bshum |
Are we putting that in Marque.pm? Cause if so, then I think we may have gone too far now.... ;) |
| 14:32 |
Dyrcona |
EBSCO sent me this. |
| 14:33 |
Dyrcona |
Or, rather sent it to a library director who sent it to someone else who finally sent it to me today. |
| 14:34 |
bshum |
Sounds like the usual chain of screaming to me. |
| 14:35 |
dbs |
bshum: Marque.pm.docx? |
| 14:36 |
csharp |
docquex |
| 14:36 |
Dyrcona |
csharp++ |
| 14:36 |
senator |
\Dyrcona: at least it wasn't printed and faxed somewhere along the way |
| 14:37 |
Dyrcona |
I think I've seen that or very close, a printed an faxed screen shot of the MARC editor came my way once just after migration. |
| 14:37 |
* csharp |
often gets "screenshots" taken with a smarthphone camera |
| 14:37 |
csharp |
smartphone, even |
| 14:37 |
Dyrcona |
bshum: screamshots. :) |
| 14:38 |
Dyrcona |
Well, I can figure out the record IDs, at least. |
| 14:38 |
Dyrcona |
Of course, the records have probably changed in the past month. |
| 14:39 |
Dyrcona |
I like this error message though: Record could not be fixed -- Leader specified length (2545) but rather was (2544)) |
| 14:39 |
|
kbutler joined #evergreen |
| 14:39 |
Dyrcona |
So, you figure out what the length *should* be, but you can't fix it? |
| 14:39 |
dbs |
Dyrcona++ # screamshots |
| 14:40 |
csharp |
@quote add < Dyrcona> Sure, send someone binary MARC records in a docx, why the Hell not!? |
| 14:40 |
pinesol_green` |
csharp: The operation succeeded. Quote #77 added. |
| 14:41 |
csharp |
@quote random |
| 14:41 |
pinesol_green` |
csharp: Quote #37: "bkuhn: ... my wife is watching the Les Miserables anniversary concert... and it was just at that point where that Jonas brother comes on as Marius and he's really bad. :)" (added by Dyrcona at 10:16 PM, December 01, 2012) |
| 14:41 |
csharp |
bkuhn++ |
| 14:43 |
jeff |
landscape formatted report, approx 32 patrons per page, we have 29 pages worth of patrons having an address matching an address alert. |
| 14:44 |
jeff |
berick++ for using regular expressions for address alerts. |
| 14:44 |
tsbere |
jeff: With an unknown number of duplicate patrons due to matching multiple alerts? |
| 14:45 |
jeff |
tsbere: correct, though i already eliminated a large number of those that were due to an alert overlap. :-) |
| 14:47 |
jeff |
i have 16 active address alerts configured for 16 addresses -- not doing anything clever like trying to match multiple addresses with one alert. |
| 14:48 |
jeff |
so, using regex only to make the matching a little more fuzzy-yet-not-too-fuzzy, we have 175 distinct strings matching those 16 alerts. :-) |
| 14:49 |
Dyrcona |
berick wins the prize! The problem I am having with EBSCO appears to be multibyte characters. They're counting 1 character, we're counting 2 or more bytes. |
| 14:49 |
Dyrcona |
jeff: Now, you've got two problems. :) |
| 14:50 |
jeff |
175 goes down to 126 when case is no longer a consideration. |
| 14:51 |
berick |
yay, i guess |
| 14:52 |
jeff |
i found these to be most helpful: "^123 +(W.*)? *(Eleventh|11th)" and "^456 +(E.*)? *(Eighth|8th)" |
| 14:53 |
jeff |
match 123 W Eleventh St and 123 West Eleventh Street and 123 11th but not 123 W 11th Street, etc. |
| 14:58 |
Dyrcona |
I wonder what they'll do if I send them UTF-8, instead of trying to convert to MARC-8. |
| 15:08 |
|
ktomita_ joined #evergreen |
| 15:17 |
AaronZ-PLS |
Hmmm, apparently my earlier message didnt go through. |
| 15:17 |
AaronZ-PLS |
Is there a permission to control if a user (or group of users) can perform pre-cataloged checkouts? |
| 15:18 |
csharp |
AaronZ-PLS: I think it's just CREATE_COPY |
| 15:18 |
* csharp |
may be wrong |
| 15:22 |
Dyrcona |
Cannot decode string with wide characters at /usr/local/lib/perl/5.14.2/Encode.pm line 176. |
| 15:22 |
Dyrcona |
Does that mean it is already decoded? |
| 15:23 |
AaronZ-PLS |
csharp: I dont think that is the case as we have circ users who can create pre-cat copies, but they dont have the CREATE_COPY permission |
| 15:23 |
Dyrcona |
AaronZ-PLS: Actually, I was looking at that just the other day, lemme check the code again. |
| 15:23 |
AaronZ-PLS |
Dyrcona: Thanks |
| 15:25 |
|
bradl_ joined #evergreen |
| 15:27 |
Dyrcona |
There are no explicit permission checks that I can find for creating a copy with a precat checkout. |
| 15:29 |
|
finnx_ joined #evergreen |
| 15:30 |
Dyrcona |
CREATE_NONCAT_TYPE && DELETE_NONCAT_TYPE appear to be the permissions involved. |
| 15:30 |
Dyrcona |
When I say I was looking at that, I really mean I was looking at circulation in general. |
| 15:34 |
AaronZ-PLS |
Dyrcona: Thanks. I think that those are for non-catalouged circulation types. What I am lookign at is making it so that when they misscan a barcode or type it in wrong and it comes up saying "Mis-scan or non-cataloged item. Checkout as a pre-cataloged item?" they do not have the option to continue |
| 15:35 |
AaronZ-PLS |
(ie: the screen seen in page 2 of: http://www.biblio.org/documentation/wp-content/uploads/2011/04/05Circ234CheckOut.pdf ) |
| 15:36 |
Dyrcona |
Oh, that's a different question from what I was answering. Just remove those permissions and it should fail. |
| 15:38 |
AaronZ-PLS |
Dyrcona:The "circ" users do not have the "CREATE_NONCAT_TYPE", "DELETE_NONCAT_TYPE" or "CREATE_COPY" permissions. Is there another permission that I need to remove? |
| 15:39 |
Dyrcona |
I didn't see anything other than the permission that allows them to circulate in the first place. |
| 15:39 |
Dyrcona |
Are you just trying to make the window go away? |
| 15:41 |
AaronZ-PLS |
Various libraries are having problems with staff checking out items as pre-cat items and then they have a pre-cat item with a barcode such as "0000000029849284u892309" sitting on their "bad stat cat report" |
| 15:42 |
Dyrcona |
Yes, what do you want to do. |
| 15:42 |
AaronZ-PLS |
We would like to make it so that the circ users cant "accidently" create pre-cat items |
| 15:42 |
csharp |
AaronZ-PLS: not a whole lot to do about that other than deleting the errant copy |
| 15:43 |
* tsbere |
keeps thinking about, but not doing anything about, adding a "pre-cat barcode regex" |
| 15:44 |
tsbere |
Theory being "if the barcode doesn't match said regex don't let them make it a pre-cat" to help distinguish "not in the DB" from "horrible mis-scan" |
| 15:44 |
csharp |
tsbere: that seems like the only solution software-wise |
| 15:44 |
tsbere |
That and maybe a permission for creating the things. >_> |
| 15:44 |
csharp |
we treat it as a training issue and/or inevitable annoyance ;-) |
| 15:44 |
AaronZ-PLS |
csharp: The problem being that (in the cases with barcodes that have leading zeros) the libraries open up the report in Excel, it deletes the leading zeros and they cant access the item |
| 15:45 |
Dyrcona |
The copies are created without a permission check. |
| 15:45 |
AaronZ-PLS |
Dyrcona: So it would appear. |
| 15:45 |
Dyrcona |
I just assumed that everything in NonCat.pm was involved in circulation, but I guess it isn't. |
| 15:46 |
Dyrcona |
Looks like creating noncat types is orthogonal to circulating noncat copies. |
| 15:47 |
Dyrcona |
Only thing you can do right now is remove their circ privileges, and I'm sure that is out of the question. |
| 15:47 |
Dyrcona |
What you want requires code modifications. |
| 15:47 |
gmcharlt |
I've looked at it as well, and I agree with Dyrcona |
| 15:48 |
AaronZ-PLS |
Dyrcona: Removing their circ previliges would be slightly counterproductive :D. Should I create a bug report/wishlist for this? |
| 15:48 |
|
kbutler joined #evergreen |
| 15:48 |
gmcharlt |
yeah, it's a wishlist item |
| 15:48 |
* Dyrcona |
agrees with gmcharlt. |
| 15:48 |
gmcharlt |
currently, the bias is towards getting the circulation done and the patron out the door |
| 15:49 |
csharp |
patron_out_the_door++ |
| 15:49 |
Dyrcona |
We had a copy with barcode of '3' after migration that changed libraries on a regular basis. |
| 15:50 |
AaronZ-PLS |
gmcharlt: I understand, the issue we are running into is misscans of items in the catalog which then cost much more staff time to fix than forcing the checkout staff member to re-scan the item and also mess with circulation stat cats |
| 15:51 |
gmcharlt |
AaronZ-PLS: yeah, I'm not disagreeing with you, just expressing the current state of affairs |
| 15:51 |
AaronZ-PLS |
Is there a section of the code that I should point to in the wishlist/bug report? |
| 15:52 |
gmcharlt |
I suggest keeping it broad -- several different ways to address it have been suggested during this conversation, and the bug report probably shouldn't over-determine it |
| 15:52 |
Dyrcona |
Circ/Circulate.pm and Circ/Noncat.pm is where I'd make changes. |
| 15:53 |
Dyrcona |
I'd be inclined to add a NONCAT_CIRC.override permission and handle it that way. |
| 15:54 |
gmcharlt |
there would also necessarily be some XUL changes |
| 15:54 |
gmcharlt |
and ITEM_NOT_CATALOGED would be what one would grep for regarding pre-cats, as opposed to non-cats |
| 15:54 |
Dyrcona |
Yes, most likely. |
| 15:55 |
AaronZ-PLS |
Dyrcona:I agree. It would be useful to allow certian users to create pre-cat circs but not require that they have the same permissions as a cataloger. |
| 15:55 |
Dyrcona |
gmcharlt: I want to change the subject, and since you're responsible for MARC::Charset, you hopefully know the answer. |
| 15:55 |
* gmcharlt |
does have a preference, unless a patch is accompanying it right away, that bug reports list problems, maybe suggest solutions, but don't try to overdetermine the implementation of said solutions |
| 15:55 |
gmcharlt |
Dyrcona: I'm all ears |
| 15:55 |
* Dyrcona |
agrees that bug reports should detail problems and not define solutions. |
| 15:56 |
Dyrcona |
gmcharlt: I'm trying to count characters, not bytes in a multi-byte string in Perl. |
| 15:56 |
Dyrcona |
I've googled and tried the suggestion of using decode(), but that doesn't work. |
| 15:56 |
csharp |
AaronZ-PLS: also, the "tabular output" in the reports display should show leading zeroes, jsyk |
| 15:57 |
Dyrcona |
In fact, it spits out what I pasted above about not being able to decode a string with a multi-byte character. |
| 15:57 |
Dyrcona |
If I encode, I get the same result as from just using length() alone, so that can't be right. |
| 15:57 |
AaronZ-PLS |
csharp: We use a custom reporting interface which saves the data as a .xls file for the staff to use |
| 15:58 |
gmcharlt |
Dyrcona: well, decode() or decode_utf8() is in fact what needs to happen to get a UTF8 string, to make CORE::length count characters and not octets |
| 15:58 |
gmcharlt |
the question would be what the characer encoding of the octets are at the point where you're doing the decode |
| 15:59 |
Dyrcona |
It's a MARC record from our database, they should already be UTF-8. |
| 15:59 |
gmcharlt |
AaronZ-PLS: is the reporting interface capable of specifying that all selected fields should be text, not general? |
| 15:59 |
gmcharlt |
(when it outputs the spreadsheet) |
| 15:59 |
Dyrcona |
And the character in question is a musical flat symbol, which looks good on my UTF-8 terminal. |
| 16:00 |
gmcharlt |
Dyrcona: does 'use Encode; $str = decode_utf8($your_octets);' work any better for you? |
| 16:00 |
|
hbrennan joined #evergreen |
| 16:02 |
Dyrcona |
It does, and I added a print to stderr that shows I'm not using set_leader_lengths correctly. |
| 16:03 |
Dyrcona |
Or, does as_usmarc call set_leader_lengths again? |
| 16:03 |
Dyrcona |
I'm trying to mangle the size of my MARC record in case you couldn't tell. |
| 16:05 |
gmcharlt |
as_usmarc does in fact call st_leader_lengths |
| 16:05 |
gmcharlt |
and if it's working correctly, should always be setting the leader and directory fields to be based on octets, not characters |
| 16:06 |
Dyrcona |
gmcharlt: It is, but ebsco apparently counts characters, not octets. |
| 16:07 |
gmcharlt |
bless their hearts |
| 16:07 |
Dyrcona |
gmcharlt: When I get the character count, I get the same size that they tell me the record *should* be. |
| 16:07 |
gmcharlt |
would they prefer to accept MARC8 instead? |
| 16:08 |
Dyrcona |
gmcharlt: They would, but then they tell me the record size is wrong also, and I have a hunch I might be doing the conversion incorrectly. |
| 16:10 |
Dyrcona |
so, UTF8 sets the leader size to 02546, MARC8 to 02545, and length() on both tells me 02544. |
| 16:11 |
Dyrcona |
Leader specified length (2545) but rather was (2544)) is what EBSCO had to say about the record that I sent. |
| 16:11 |
gmcharlt |
could you past the original MARCXML from your database? |
| 16:13 |
Dyrcona |
I can, but I'm seeing consistent results with the other records. |
| 16:14 |
AaronZ-PLS |
gmcharlt: I'll have to check if it can be set to text. |
| 16:14 |
Dyrcona |
The length() of the record in characters matches what EBSCO says it should be, and the header on the MARC8 record matches what they said we said it was. |
| 16:14 |
AaronZ-PLS |
I created the bug report: https://bugs.launchpad.net/evergreen/+bug/1276328 |
| 16:14 |
pinesol_green` |
Launchpad bug 1276328 in Evergreen "Add a way to block "pre-cat" item creation based on permissions or settings" (affected: 1, heat: 6) [Undecided,New] |
| 16:15 |
* bshum |
wonders if it's time to change pinesol_green back to just simple ol' pinesol. |
| 16:15 |
* Dyrcona |
would love to email EBSCO and say, you're counting the record length incorrectly, but I doubt that they would listen. |
| 16:20 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "MARCXML for EBSCO" (199 lines) at http://paste.evergreen-ils.org/11 |
| 16:21 |
Dyrcona |
gmcharlt: That is not straight out of our database because I am also exporting item info in 852 tags. |
| 16:29 |
dbwells |
Dyrcona: probably just a past problem, but your example record has an extra </datafield> after the 852 |
| 16:29 |
dbwells |
s/past/paste/ |
| 16:29 |
* Dyrcona |
doesn't care enough to bother with that. |
| 16:29 |
Dyrcona |
Straight out of the MARC documentation: Computer-generated, five-character number equal to the length of the entire record, including itself and the record terminator. The number is right justified and unused positions contain zeros. |
| 16:30 |
Dyrcona |
So, MARC doesn't say it it is octets or characters. |
| 16:30 |
Dyrcona |
"length. A measure of the size of a data element, field, or record and is expressed in number of octets." |
| 16:31 |
Dyrcona |
But they do, and EBSCO is wrong! |
| 16:32 |
Dyrcona |
I am now done with this conversation, and I'm making no changes for EBSCO. |
| 16:32 |
Dyrcona |
Thank you all for putting up with me. |
| 16:40 |
eeevil |
Dyrcona++ |
| 16:41 |
eeevil |
Dyrcona: for your next trick, convince B&T a library might want to use all 35 bytes available to name itself in EIDFACT, not just 5. ;) |
| 16:42 |
eeevil |
see also: item identifiers |
| 16:45 |
|
roses joined #evergreen |
| 16:46 |
roses |
Several months ago (almost a year) I was working on setting up a test Evergreen server and someone here told me about where to find some fake/test records to import into my catalog? Where can I find something like that? |
| 16:50 |
bshum |
roses: If you're just setting up some sort of demo system, you can always use the stock concerto dataset that comes with Evergreen 2.4+ |
| 16:50 |
roses |
bshum: I installed 2.3.7 |
| 16:51 |
bshum |
That step gets described a bit in step 9.1 of the 2.5 README |
| 16:51 |
bshum |
http://evergreen-ils.org/documentation/install/README_2_5.html#_loading_sample_data |
| 16:51 |
bshum |
roses: Ah, well, 2.3 doens't have the concerto options. |
| 16:51 |
bshum |
Also, 2.3 is dead to me. |
| 16:52 |
roses |
bshum: crud - yep I will be updating it soon to 2.5 - in fact it might be sooner! |
| 16:52 |
bshum |
roses: Yeah I think official support of 2.3 ended a couple months ago. |
| 16:53 |
roses |
bshum: thanks - will be updating tomorrow |
| 17:07 |
|
stevenyvr joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:27 |
phasefx |
ooh, Civilization humble bundle |
| 17:46 |
|
smyers_ joined #evergreen |
| 18:12 |
|
sseng_ joined #evergreen |
| 18:15 |
hbrennan |
We're planning an upgrade from 2.3.4 to 2.5... Can someone confirm that we need to first upgrade to 2.4.6 before upgrading to 2.5.2? |
| 18:32 |
gmcharlt |
hbrennan: no, it's not necessary to pause |
| 18:32 |
gmcharlt |
during the process, the database would in some sense be at 2.4.x, but only for a moment |
| 18:32 |
hbrennan |
Oh, okay. I read something about not skipping versions, but it was old stuff |
| 18:32 |
hbrennan |
wonderful |
| 18:33 |
hbrennan |
so 2.3.4 to 2.5.2 is no problem |
| 18:33 |
gmcharlt |
yeah, that was about the DB schema updates that are part of the process, where you do have to make sure that you don't skip intermediate versions (although I'm simplifying a bit) |
| 18:33 |
gmcharlt |
the software itself would get straight from 2.3.4 to 2.5.x |
| 18:34 |
hbrennan |
http://docs.evergreen-ils.org/2.5/_upgrading_the_evergreen_server.html |
| 18:34 |
hbrennan |
Are these instructions still good then? |
| 18:35 |
gmcharlt |
mostly; http://docs.evergreen-ils.org/2.5/_upgrade_the_evergreen_database_schema.html would be a bit different to include some bits referenced by the 2.4 upgrade instructions |
| 18:36 |
hbrennan |
good to know |
| 18:36 |
hbrennan |
We're all nervous about it, but if we wait until we're not nervous... we'll never upgrade |
| 18:36 |
hbrennan |
I'm trying to convince everyone to just jump with me :) |
| 18:37 |
gmcharlt |
there's no kersplat at the end, just new functionality ;) |
| 18:38 |
hbrennan |
And TONS of it |
| 18:38 |
hbrennan |
our catalogers will be so happy to have the 2.4 stuff, and I'm excited about some of the bits from 2.5 |
| 18:40 |
|
dluch joined #evergreen |
| 18:41 |
hbrennan |
Someone has to be on board who knows next to nothing about databases, git, etc |
| 18:41 |
hbrennan |
That's me |
| 18:42 |
hbrennan |
so so so excited about Day 1 of the conference! |
| 18:43 |
|
sseng joined #evergreen |
| 18:46 |
|
dcook joined #evergreen |
| 19:33 |
|
sseng joined #evergreen |
| 19:42 |
|
jbfink joined #evergreen |
| 19:50 |
|
artunit joined #evergreen |
| 20:08 |
|
jbfink joined #evergreen |
| 20:28 |
|
jbfink joined #evergreen |
| 20:41 |
|
jbfink joined #evergreen |
| 21:00 |
|
pmurray_away joined #evergreen |
| 22:21 |
|
jbfink joined #evergreen |
| 23:07 |
|
hbrennan joined #evergreen |
| 23:34 |
|
jbfink joined #evergreen |
