| Time |
Nick |
Message |
| 00:16 |
|
wjr joined #evergreen |
| 06:39 |
|
b_bonner joined #evergreen |
| 06:39 |
|
mtcarlson_away joined #evergreen |
| 06:59 |
|
timlaptop joined #evergreen |
| 08:06 |
|
granitize joined #evergreen |
| 08:10 |
|
granitize joined #evergreen |
| 08:14 |
|
collum joined #evergreen |
| 08:29 |
|
akilsdonk joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:50 |
|
Dyrcona joined #evergreen |
| 08:52 |
|
ericar joined #evergreen |
| 08:53 |
|
adbowling-isl joined #evergreen |
| 09:00 |
|
mrpeters joined #evergreen |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
mmorgan joined #evergreen |
| 09:04 |
|
kbeswick joined #evergreen |
| 09:46 |
* csharp |
takes down the fedora and ubuntu buildslaves for a bit |
| 09:56 |
|
AaronZ-PLS joined #evergreen |
| 09:57 |
|
BigRig joined #evergreen |
| 10:24 |
|
kmlussier joined #evergreen |
| 10:30 |
|
roses joined #evergreen |
| 10:32 |
roses |
I have a library that has a limit set - a new youth or adult can only check out 3 items. When you start checking out the items - on the 4th it tells you that you can't do anymore - and that's okay. It's when you go back into the system and search for that patron you get a message that says "patron EXCEEDS checkout limit" - that's not true - it doesn't exceed - it has only REACHED? Is this behavior correct? |
| 10:33 |
|
yboston joined #evergreen |
| 10:33 |
tsbere |
roses: I suppose it could say "Meets or exceeds", though that is more of a language string issue if anything. |
| 10:34 |
bshum |
It might just be showing the raw penalty name (PATRON_EXCEEDS_CHECKOUT_LIMIT) and not even an actual string. |
| 10:35 |
roses |
bshum: So we can make a nice message for PATRON_EXCEEDS - but why does it do it at 3 - not 4 - you've just searched for the patron - you haven't even tried to check out the 4th? |
| 10:37 |
tsbere |
roses: Because if we waited for checkout #4 then they have 4 items out, not 3. |
| 10:38 |
roses |
tsbere: That's what we have been going round and round with this library - it's kinda like glass half full or empty. So I'm thinking the language of the message is what needs changing (if I can do that?) |
| 10:38 |
Dyrcona |
roses: Does it really prevent you from or your staff from doing their jobs? |
| 10:38 |
roses |
Dyrcona: No, it's just confusing to the staff (but not sure why)? |
| 10:40 |
Dyrcona |
Just tell them it is minutia and ask them to get on with life. :) |
| 10:41 |
roses |
Dyrcona: I wish. |
| 10:41 |
bshum |
It seems like there would be some bigger fish to fry. |
| 10:42 |
mmorgan |
So, is this a problem when patrons try and do things like place holds or renew? |
| 10:43 |
roses |
mmorgan: Not sure, I'm just getting complaints from the staff (volunteers at a very small library) |
| 10:44 |
Dyrcona |
roses: Is the question just about the wording or is it about behavior? |
| 10:44 |
roses |
Dyrcona: Just wording at this point - how can I change it? |
| 10:45 |
bshum |
roses: Untested, but perhaps this is where the "label" column in config.standing_penalty comes into play. |
| 10:45 |
bshum |
Though I don't know if all the GUI parts use the label vs. the name |
| 10:45 |
bshum |
I personally don't feel comfortable suggesting changing the name of the penalty without knowing whether anything depends on that vs. the IDs. |
| 10:46 |
Dyrcona |
"has reached" is probably better than "exceeds" |
| 10:46 |
Dyrcona |
Make a game of it: Achievement Unlocked: Checkout Limit! |
| 10:47 |
* bshum |
suggests roses tests and submit a patch to change the language if it does end up making the world a better place :) |
| 10:48 |
* Dyrcona |
better not let the reference crew see these logs. He'll be asked to add patron achievements as an enhancement. |
| 10:49 |
|
ericar joined #evergreen |
| 10:49 |
jeff |
called up our primary isp... "hi. just sitting here reading the article in the newspaper about the outage we're still experiencing, and wondered if you had any more information for us." |
| 10:50 |
jeff |
i did not say "congratulations on your two nines of uptime for the year, by the way -- where should we send the cake?" |
| 10:50 |
bshum |
csharp: I'm asking our catalogers to check on bug 1259665 |
| 10:50 |
pinesol_green |
Launchpad bug 1259665 in Evergreen "Series search in 2.5 does not retrieve 800 |t" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1259665 |
| 10:50 |
jeff |
but that's off-topic. sorry. :-) |
| 10:50 |
bshum |
I can see 800 in the xslt entry so I'm not sure it's a problem as of yet. |
| 10:50 |
roses |
Drycona: You guys have made my day! I'm just going to go away now and think about this some more. |
| 10:50 |
bshum |
Maybe it's a reingest issue with your server. |
| 10:51 |
bradl |
jeff: I can tell you where to send the cake... :) |
| 10:51 |
senator |
@wunder traverse city, mi |
| 10:51 |
pinesol_green |
senator: The current temperature in SlabTown, Traverse City, Michigan is 13.5°F (10:51 AM EST on December 11, 2013). Conditions: Heavy Snow. Humidity: 85%. Dew Point: 10.4°F. Windchill: 14.0°F. Pressure: 30.26 in 1025 hPa (Rising). |
| 10:51 |
jeff |
bradl: but would it fit inside po box 69? |
| 10:51 |
senator |
jeff: ^-- i'm guessing your packets just didn't want to get out of bed in the morning |
| 10:52 |
Dyrcona |
senator++ |
| 10:52 |
bradl |
jeff: we can make miracles happen for cake |
| 10:52 |
bradl |
or bacon |
| 10:52 |
dbs |
@wunder sudbury, on |
| 10:52 |
dbwells |
I wonder how on earth the windchill can be higher than the temperature. Must be a nice warm wind. |
| 10:52 |
pinesol_green |
dbs: Error: No such location could be found. |
| 10:53 |
Dyrcona |
or bacon cake! |
| 10:53 |
dbs |
meh |
| 10:53 |
dbs |
@wunder p3e 2c6 |
| 10:53 |
pinesol_green |
dbs: The current temperature in Hwy 69 @ Richard Lake, Sudbury, Ontario is 6.8°F (10:40 AM EST on December 11, 2013). Conditions: Partly Cloudy. Humidity: -999%. Dew Point: -74.2°F. Windchill: -4.0°F. Pressure: 30.16 in 1021 hPa (Rising). |
| 10:53 |
jeff |
@weather kysb |
| 10:53 |
pinesol_green |
jeff: Error: HTTP Error 500: Server Error |
| 10:53 |
jeff |
@weather ysb |
| 10:53 |
pinesol_green |
jeff: The current temperature in Sudbury, Ontario is -4.0°F (10:00 AM EST on December 11, 2013). Conditions: Partly Cloudy. Humidity: 85%. Dew Point: -7.6°F. Windchill: -14.8°F. Pressure: 30.16 in 1021 hPa (Rising). |
| 10:53 |
jeff |
oh, because canada. |
| 10:53 |
Dyrcona |
@wunder nzwn |
| 10:53 |
pinesol_green |
Dyrcona: The current temperature in Wellington, New Zealand is 62.6°F (4:30 AM NZDT on December 12, 2013). Conditions: Overcast. Humidity: 88%. Dew Point: 59.0°F. Pressure: 29.83 in 1010 hPa (Steady). |
| 10:53 |
Dyrcona |
@wunder 01845 |
| 10:53 |
pinesol_green |
Dyrcona: The current temperature in North Andover, Massachusetts is 29.1°F (10:47 AM EST on December 11, 2013). Conditions: Clear. Humidity: 60%. Dew Point: 17.6°F. Windchill: 28.4°F. Pressure: 30.20 in 1023 hPa (Steady). |
| 10:54 |
jeff |
it would be cysb not kysb. :-) |
| 10:56 |
* senator |
definitely feels warmer now, except of course by comparison to the aforementioned locale entering summer |
| 11:13 |
|
smyers__ joined #evergreen |
| 11:15 |
|
smyers__ joined #evergreen |
| 11:30 |
csharp |
okay ubuntu buildslave is alive again, but the fedora slave is plum tore up |
| 11:33 |
bshum |
csharp: Seems like we're seeing some weird 800t issues as well. I'll probably mark the bug confirmed and see if we can dig deeper |
| 11:34 |
csharp |
bshum++ |
| 11:34 |
bshum |
By the by, the mods32 stuff in config.metabib_field always just feels like such a blackhole. :( |
| 11:35 |
|
RoganH joined #evergreen |
| 11:35 |
csharp |
yeah - I was looking at that too, but it looks like MODS 3.2 series should include 800$t from what Elaine and I were seeing yesterday |
| 11:35 |
csharp |
and we see it working in 2.3.6 |
| 11:35 |
bshum |
Yeah that's why I'm confused right now. |
| 11:37 |
* bshum |
is already getting a headache thinking about another round of reingests after we figure this out |
| 11:39 |
tsbere |
bshum: You should see Dyrcona's gist for that. :P |
| 11:39 |
Dyrcona |
I am considering making some changes to that gist and moving it to my evergreen_utilities repo. |
| 11:40 |
Dyrcona |
Why I didn't just put it there in the first place, I don't know. |
| 11:40 |
bshum |
csharp: Yep, definitely confirmed. It's not just 800t even |
| 11:41 |
bshum |
I'm seeing systemic lack of series entries for certain bibs from our system. |
| 11:41 |
bshum |
Oh wait, maybe not |
| 11:41 |
bshum |
Damn indicator flags |
| 11:42 |
Dyrcona |
Bad cataloging is bad? |
| 11:42 |
bshum |
I don't know enough about cataloging either way. |
| 11:44 |
bshum |
All the samples I have seem to show 490 with ind1 of 1. Along with the 800 t. But the 490 doesn't show up in the series table because it's looking for 490 with 0 it seems |
| 11:44 |
bshum |
If I'm reading the xslt transform entry right... |
| 11:45 |
bshum |
And my catalogers tell me now that it's "normal" |
| 11:45 |
bshum |
Nevermind me then :) |
| 11:45 |
bshum |
Though not normal that the 800 t isn't indexed though |
| 11:45 |
csharp |
@blame [marc 800] |
| 11:46 |
pinesol_green |
csharp: An author/title series added entry in which the author portion is a personal name. (Repeatable) [a,b,c,d,e,f,g,h,j,k,l,m,n,o,p,q,r,s,t,u,v,4,6,8] caused the white screen of death! |
| 11:46 |
bshum |
Nice. |
| 11:47 |
Dyrcona |
You could always add a new title index for the marcxml, similar to what I shared with you in private chat yesterday for adding the 550$t. |
| 11:51 |
RoganH |
Anyone here dealt with 856 entries in a consortium much? |
| 11:52 |
bshum |
Dyrcona: Yeah I could do that, but I should probably figure out why it's broken out of the box with the existing structure :( |
| 11:52 |
csharp |
RoganH: not much, but I might be able to help |
| 11:52 |
RoganH |
Issue we're having is that one member has added a ton of ebook holdings and the OPAC is fine but the staff client searches are getting flooded with the results. |
| 11:52 |
RoganH |
So, regardless of org unit search restrictions in staff client they're showing up. |
| 11:52 |
Dyrcona |
RoganH: I think that is by design. |
| 11:53 |
tsbere |
RoganH: Do they even show up in the public opac? If "no" then they are likely falling into "no copies" mode with no located URIs. |
| 11:53 |
RoganH |
I thought so and if it were a smaller number it would be fine. |
| 11:53 |
kmlussier |
RoganH: Are you using located URI's? |
| 11:53 |
bshum |
There's actually a bug for that |
| 11:53 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/925776 |
| 11:53 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 4, heat: 22) [Medium,Confirmed] |
| 11:53 |
RoganH |
They don't show up in the public opac. |
| 11:53 |
bshum |
So even if you're using $9 the staff client view is all screwy |
| 11:54 |
bshum |
Looks like ldwhalen was working on it, not sure where it ended up. |
| 11:54 |
RoganH |
hmmm... I just did a trivial skim, so it's not restricted to URI's but any bibs without copies? |
| 11:56 |
bshum |
RoganH: Yeah, that's how it works. We used to call that the "gray bibs problem" back in JSPAC, when empty bibs were styled with gray background. |
| 11:56 |
bshum |
*we being Bibliomation |
| 11:56 |
kmlussier |
It looks like ldwhalen has a branch that's ready to be tested. But it doesn't have a pullrequest tag. |
| 11:57 |
RoganH |
bshum: yeah, I know the gray bib problem, it just didn't occur to me that this was the same thing |
| 11:57 |
bshum |
They're white now :) |
| 11:57 |
csharp |
heh |
| 11:57 |
bshum |
Or whatever background your catalog is set to |
| 11:57 |
RoganH |
We have blues :) |
| 11:58 |
csharp |
@blues |
| 11:58 |
pinesol_green |
csharp: Go away, or I'll replace you with a very small shell script! |
| 11:58 |
RoganH |
In fact because of our color scheme you would have to look really closely to tell the difference which is probably why none of us did. |
| 11:58 |
kmlussier |
Reading the comments on that bug, I didn't think that the intent was for Located URI bibs to be one of the gray bibs. |
| 11:58 |
* csharp |
writes a very small shell script to poke pinesol_green every few hours |
| 11:59 |
RoganH |
So .... I don't really want to do this but if I add copies to a sample batch I can see if it goes away and confirm its a subset of that behavior. |
| 12:00 |
RoganH |
I remember some vague argument once about if the empty bibs should show up or not in staff client. |
| 12:00 |
tsbere |
Catalogers want them to show up. Everyone else not so much by comparison. >_> |
| 12:00 |
|
ktomita_ joined #evergreen |
| 12:01 |
csharp |
catalogers want *truly* empty bibs to show up, not ones with URIs |
| 12:01 |
RoganH |
Right, except in this case catalogers don't want to see the URI ones either. |
| 12:01 |
csharp |
well, I take that back, tsbere may be right |
| 12:01 |
* csharp |
can't speak for catalogers |
| 12:01 |
RoganH |
And the volume has changed. We do periodic cleanups of empty bibs so the numbers never become huge for reference staff searching. |
| 12:02 |
kmlussier |
No, I think csharp was right on this one. Catalogers don't want to see the ones with Located URI's. Those located URI's should be treated as if they are copies. |
| 12:02 |
tsbere |
csharp: *everyone* wants located URI bibs to show up in the right contexts, as far as I know. Catalogers want the empty bibs to show up so they can attach copies to them. :P |
| 12:02 |
RoganH |
kmlussier: correct |
| 12:02 |
RoganH |
tsbere: correct |
| 12:02 |
tsbere |
MVLC has a script we are running now to find the truly empty bibs and delete them |
| 12:03 |
tsbere |
Would need some modification to be generally applicable to everyone, though. >_> |
| 12:03 |
RoganH |
tsbere: I do that about once a year around Christmas time |
| 12:03 |
RoganH |
tsbere: except we skip those where the last item was deleted within the last 90 days |
| 12:04 |
tsbere |
RoganH: Well, we have the "delete the bib when the last item goes away" option turned on, so that isn't a problem for us. |
| 12:04 |
RoganH |
tsbere: we don't. some scenario as csharp mentioned - catalogers want them to stick around so that they can replace a last copy |
| 12:10 |
tsbere |
RoganH: our problem seems to be more along the lines of "cataloger creates bib, cataloger never attaches an item to the bib...." |
| 12:10 |
RoganH |
tsbere: trust me, it happens to us too, that's just the path we eventually picked |
| 12:10 |
* eeevil |
reads up |
| 12:11 |
|
RoganH joined #evergreen |
| 12:11 |
eeevil |
FWIW, the "gray bib problem" was by design, so that empty bibs could be found at all after being added, before copies were attached. |
| 12:13 |
* csharp |
*knows* this will be an issue for PINES if the policies around batchloading e-book bibs into the database are ever resolved |
| 12:13 |
RoganH |
eeevil: I get that, no argument, its the 856 twist that's the issue for us |
| 12:13 |
eeevil |
RoganH: right ... that's orthogonal, of course |
| 12:13 |
RoganH |
eeevil: agreed |
| 12:13 |
|
rfrasur joined #evergreen |
| 12:14 |
csharp |
our cataloger here thinks that if the icons were clearer (an extra/different icon for ebooks/eresources for example) or if there was a checkbox to include/not include/exclude bibs with 856s, the problem would probably be resolved |
| 12:14 |
eeevil |
the original intent was not that located uris show up /exactly/ where copies do, but (unfortunately) they've been described (by me, even) as "like "virtual" copies" |
| 12:16 |
eeevil |
copies make bibs show up at the location or "above" in the hierarchy. originally, located uris made bibs show up at-and-below the named org unit |
| 12:16 |
eeevil |
so if you mention a system-level OU in the $9 you'd see them when searching at that system or any of its branches |
| 12:16 |
eeevil |
but /not/ when searching globally or at other systems |
| 12:17 |
eeevil |
the reason is that that's where the bib is "valid" ... within the system that, say, paid for the overdrive item |
| 12:18 |
eeevil |
at some point (IIRC, dbs was involved in this discussion, and others too, I'm sure) it was decided that that should change |
| 12:18 |
eeevil |
(I mention dbs because he may have clearer memories of that discussion than I) |
| 12:19 |
eeevil |
now located uris act like copies, and show up in global (top-level) searches |
| 12:19 |
kmlussier |
csharp: If your catalogers want clearer icons, I have a great development partnership opportunity I'm willing to sell you. :) |
| 12:21 |
kmlussier |
eeevil: Located URI"s show up in top-level searches? I think you have that wrong. |
| 12:21 |
eeevil |
kmlussier: that's certainly possible :) |
| 12:21 |
kmlussier |
I believe they show up at or below the OU that owns them. |
| 12:22 |
bshum |
That sounds correct to me. Based on what I remember seeing lately in our systems. |
| 12:22 |
bshum |
It kind of flips from time to time :) |
| 12:22 |
kmlussier |
We have people who would love to see them show up in consortium searches as well, so that they truly behave like copies. It comes up in development discussions all the time. |
| 12:23 |
RoganH |
chsarp: kmlussier: clearer icons would be nice but in our use case because of volume it would be like putting a bandaid on a sword wound |
| 12:23 |
csharp |
RoganH: I agree that it doesn't solve your "flooding" issue |
| 12:23 |
csharp |
mixing_metaphors++ |
| 12:24 |
RoganH |
I think all my analogies from now on should involve disemboweling |
| 12:24 |
eeevil |
kmlussier: they want /all/ located uris to show up everywhere? for those that should show up everywhere, using the top OU for $9 would make that happen selectively, of course |
| 12:24 |
kmlussier |
RoganH: No. Please don't. |
| 12:25 |
kmlussier |
eeevil: But that's not what we want. If you add a copy for SYS1, it shows up when you scope your search at the consortium, because you're searching the entire consortium. It also shows up when you search SYS1 or BR1, but not SYS2 or its child branches. |
| 12:25 |
RoganH |
kmlussier: awwwwww..... |
| 12:25 |
dbs |
eeevil: yeah, I think you have the current behaviour flipped. If $9 = SYS1, only SYS1 and below see them, because SYS1 is expected to have licensed it for all of its branches |
| 12:26 |
eeevil |
but, in any case, it sounds like he staff search variant just doesn't take located uris into account. that sounds like a bug to me, and should be easily fixable |
| 12:26 |
kmlussier |
Our people would love it if located URI's worked the same way. Because maybe the person who is a patron of BR1 is searching the entire consortium and doesn't know that they are missing out on this great electronic resource owned by their branch. |
| 12:27 |
eeevil |
kmlussier: sorry, by "everywhere" I meant a search at the top of the org tree... we're saying the same thing, I just said it badly ;) |
| 12:27 |
dbs |
kmlussier: hey, wasn't that the rationale for preferred library? |
| 12:27 |
dbs |
Good old preferred library :) |
| 12:27 |
kmlussier |
dbs: Yes, and that works wonderfully for when the patron is logged in. |
| 12:27 |
kmlussier |
But the patron isn't always logged in. |
| 12:27 |
eeevil |
dbs: good, I'm glad I got the current patron behavior wrong ;) |
| 12:28 |
kmlussier |
dbs: I was just going through old Launchpad bugs and reminiscing about preferred library work yesterday. :) |
| 12:32 |
csharp |
Dyrcona++ # silencing the z3950 active services undefined message |
| 12:33 |
Dyrcona |
csharp: We're already using the last commit in production, since it is a server-side JS change. The staff client picks it up from the server. |
| 12:34 |
Dyrcona |
Just copy z3950.js to the right place. |
| 12:35 |
bshum |
Yeah, I confirmed it works for us too |
| 12:35 |
bshum |
I didn't get to look at the other commit yet though |
| 12:35 |
csharp |
yeah - I just put in the last commit |
| 12:51 |
|
j_scott joined #evergreen |
| 12:53 |
|
stevenyvr2 joined #evergreen |
| 13:03 |
|
j_scott left #evergreen |
| 13:09 |
|
gsams joined #evergreen |
| 13:19 |
|
RoganH joined #evergreen |
| 13:42 |
jeffdavis |
Is there i18n for patron profile group labels? Or to put it another way, if I want to rename the "Juvenile" profile to "Young Adult," do I need to rebuild locales or anything? |
| 13:43 |
jeffdavis |
I think the answer is "no," hoping I'm correct ;) |
| 13:47 |
eeevil |
jeffdavis: the answer is "no" ... it's all in the db. you might need to restart apache and public services, though |
| 13:47 |
jeffdavis |
thanks! |
| 13:54 |
dbwells |
eeevil (or anyone else): Is there any untapped code (or planned code) for supporting Record Attributes as facets in the OPAC? |
| 13:55 |
eeevil |
dbwells: I generally plan on doing something with that, yes ... "when" is an open question |
| 13:57 |
dbwells |
eeevil: Ok, thanks. Just wanted to make sure I wasn't missing out. |
| 14:16 |
|
ElliotFriend joined #evergreen |
| 14:18 |
ElliotFriend |
What's the best way to handle fines that recur hourly alongside fines that recur daily? |
| 14:21 |
ElliotFriend |
I s'pose the only thing I'm uncertain of is when to run fine_generator.pl? |
| 14:22 |
|
RoganH joined #evergreen |
| 14:22 |
dbs |
ElliotFriend: we run fine_generator.pl a lot; like, every 15 minutes (or maybe even more often) |
| 14:23 |
* dbs |
seems to recall one library that has per-minute late fees |
| 14:24 |
csharp |
we run it nightly, but our libraries have wanted hourly fines |
| 14:24 |
ElliotFriend |
So, if an overdue with a daily late fine is fined today, it's not gonna get "double-fined" if fine_generator runs again that day? |
| 14:25 |
dbs |
nope |
| 14:25 |
ElliotFriend |
awesome. Thanks! |
| 14:26 |
|
j_scott joined #evergreen |
| 14:27 |
dbwells |
ElliotFriend: be warned, though, that hourly fines are not well supported. In particular, they do not properly avoid closed times. Also, Evergreen's method of "post-dating" fines can cause staff confusion (e.g. the timestamp is an hour later than the fine time). These issues could use some TLC if you want to contribute :) |
| 14:30 |
dbs |
:q |
| 14:30 |
dbs |
what, IRC isn't vim yet? dang |
| 14:31 |
ElliotFriend |
dbwell: I'd love to contribute, and I'll see if I can whip something up, although I wouldn't depend solely on my code if I were you :-) |
| 14:31 |
csharp |
jjjkkkllllmmmm - nope, not vim |
| 14:31 |
ElliotFriend |
Our use case is a closed-reserve shelf, so everything would ideally be on that shelf during closed hours |
| 14:32 |
ElliotFriend |
I'll bring up that disclaimer to our staff and see what their thoughts are. Thanks! |
| 14:32 |
dbwells |
ElliotFriend: yes, we also use hourly fines for our reserves. As long as we are careful, they work alright :) |
| 14:41 |
kmlussier |
dbwells / ElliotFriend: DPearl was telling me a couple of days ago he might try looking into bug 1064679. |
| 14:41 |
pinesol_green |
Launchpad bug 1064679 in Evergreen "Hourly due dates and fines ignore library closings" (affected: 3, heat: 20) [Medium,Confirmed] https://launchpad.net/bugs/1064679 |
| 14:44 |
kmlussier |
When you do a query in a bucket, you can only retrieve the first 100 results. Is there any way to increase that cap? |
| 14:47 |
|
kbeswick joined #evergreen |
| 14:48 |
csharp |
dbs: FYI - I updated the fedora buildslave to fedora 19 (6 days away from the release of 20, yes ;-)), so even though everything is still labelled 18, it's 19 |
| 14:49 |
|
ktomita joined #evergreen |
| 14:50 |
ElliotFriend |
This might be a really dumb question: where in the source tree would I find the files that are installed to '/openils/bin' ? |
| 14:51 |
dbs |
csharp: sweet :) F20 is working okay on two laptops and a desktop here, for anyone looking to upgrade :) |
| 14:51 |
dbs |
csharp++ |
| 14:51 |
dbs |
ElliotFriend: not dumb at all; there are a few places |
| 14:51 |
csharp |
I'll upgrade the slave to 20 via fedup after it's released |
| 14:52 |
dbs |
Open-ILS/src/support-scripts for one |
| 14:52 |
dbs |
Open-ILS/src/extras for another |
| 14:54 |
ElliotFriend |
dbs: thanks! |
| 14:54 |
* jeffdavis |
wishes for a way to automatically identify the destination path for arbitrary parts of the source tree |
| 14:55 |
jeffdavis |
and vice versa |
| 14:55 |
ElliotFriend |
jeffdavis++ |
| 14:56 |
jeffdavis |
sadly I can't see a way to do that :( |
| 14:57 |
jeffdavis |
we're working on some deployment tools, and the best way I've come up with to map source to destination is by explicitly specifying paths in a config file |
| 15:01 |
csharp |
those paths have historically been an obstacle to packaging efforts, too, btw, but dbs and others have been working to improve that ;-) |
| 15:07 |
|
ktomita_ joined #evergreen |
| 15:22 |
eby |
jeff: back |
| 15:54 |
gsams |
So I've got some reports that I've used for migrating libraries out of Evergreen, and I'd like to extract them so that they can be used in other systems easily. What would be the best method to go about doing that? |
| 15:56 |
gsams |
more to the point, I'd like to make those reports available to the community. |
| 16:03 |
jeffdavis |
is config.bib_source.quality used for anything by default? |
| 16:07 |
tsbere |
jeffdavis: I believe the overall bib quality calc uses it, though I don't know if *that* is used by anything... |
| 16:07 |
eeevil |
jeffdavis: to choose the lead record of metarecords |
| 16:08 |
eeevil |
jeffdavis: as a component of what tsbere said |
| 16:11 |
jeffdavis |
hm, where does that take place? I was looking at biblio_fingerprint.js and don't see the bib source quality value being pulled in |
| 16:15 |
tsbere |
jeffdavis: biblio.extract_quality function, maybe? |
| 16:17 |
* tsbere |
is guessing and has no real clue, for the record |
| 16:18 |
jeffdavis |
I don't think so, that seems to give a quality metric based just on the MARC record itself |
| 16:18 |
jeffdavis |
sorry to be a pain, I have been poking around in git and haven't found a place where it is actually used so far |
| 16:18 |
jeffdavis |
I am probably missing something obvious though :S |
| 16:27 |
gsams |
Nevermind, it was a silly question. i figured it out. SQL against reporter.template |
| 16:28 |
gsams |
Although, sharing them with the community is a different matter I suppose |
| 16:50 |
ElliotFriend |
If anyone's still around from the hourly fines discussion... |
| 16:50 |
ElliotFriend |
our assistant librarian mentioned that when she worked out the county library, the reserves were intentionally charged fines during closings |
| 16:50 |
ElliotFriend |
Anyone seen that before? |
| 16:56 |
|
Bmagic joined #evergreen |
| 16:56 |
Bmagic |
I am new to opensrf for EG 2.4. Should I use open-ils.circ.money.payment to make a payment with my perl script? or is there a better method? |
| 17:02 |
|
smyers__ joined #evergreen |
| 17:12 |
Dyrcona |
Bmagic: open-ils.circ.money.payment is probably the best way, if not the only way. |
| 17:13 |
Bmagic |
Dyrcona: Thanks! Of course my next question is the arguments that it needs....... I just want to make a generic payment (if possible) .. this looks like the arguments my($self, $client, $auth, $payments, $last_xact_id) = @_; |
| 17:15 |
|
mmorgan left #evergreen |
| 17:15 |
|
roses joined #evergreen |
| 17:15 |
Dyrcona |
Bmagic: What goes in the payments arrayref is documented in the comments for the function in OpenILS/Application/Circ/Money.pm. |
| 17:16 |
Bmagic |
that is what Im looking at |
| 17:16 |
Dyrcona |
These are supposed to show up if you introspect the method in srfsh, but they always get cutoff for me. |
| 17:17 |
tsbere |
Bmagic: self and client are handled at the opensrf layer, I believe, and as such you aren't passing them in yourself. So the first argument you need to pass in should be the authtoken. |
| 17:17 |
roses |
Dyrcona++bshum++ Just wanted you to know from my question this morning about exceeds or reached it was just a very simple "label" change. Thanks for your help and the morning humor. |
| 17:19 |
jeff |
hooray. primary internet service outage resolved! |
| 17:20 |
Bmagic |
Dyrcona: TY |
| 17:20 |
jeff |
(42 hours later) |
| 17:23 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagic: an example might be helpful" (81 lines) at http://paste.evergreen-ils.org/43 |
| 17:24 |
Bmagic |
Dyrcona: that helps a lot!!! |
| 17:26 |
Dyrcona |
IIRC: It retrieves and pays all outstanding bills. I wrote it when we were getting complaints about payments via SIP to help test if the problem was the backend or what. |
| 17:27 |
Bmagic |
Dyrcona: that is the example that I needed. Thanks so much. I hope that forgive is similar |
| 17:27 |
Dyrcona |
Yeah, just set the payment_type to forgive. |
| 17:28 |
Dyrcona |
forgive_payment, actually. |
| 17:28 |
Dyrcona |
anyway, time for me to go home. |
| 17:28 |
Dyrcona |
Bmagic: Have fun! |
| 17:29 |
|
yboston left #evergreen |
| 17:33 |
|
dcook joined #evergreen |
| 19:20 |
|
j_scott joined #evergreen |
| 19:21 |
|
smyers__ joined #evergreen |
| 19:30 |
|
j_scott joined #evergreen |
| 19:33 |
|
j_scott joined #evergreen |
| 19:57 |
|
stevenyvr2 left #evergreen |
| 22:20 |
|
BigRig_ joined #evergreen |
| 22:20 |
|
artunit_ joined #evergreen |
| 23:38 |
|
mdsteinholz joined #evergreen |
| 23:38 |
mdsteinholz |
Hello - anyone here? |
