| Time |
Nick |
Message |
| 01:50 |
|
laque joined #evergreen |
| 02:12 |
|
laque joined #evergreen |
| 02:17 |
|
laque joined #evergreen |
| 02:54 |
|
tsbere joined #evergreen |
| 02:55 |
|
tfaile joined #evergreen |
| 03:22 |
|
artunit joined #evergreen |
| 03:38 |
|
Mark__T joined #evergreen |
| 04:07 |
|
laque|2 joined #evergreen |
| 04:51 |
|
laque|2 joined #evergreen |
| 06:12 |
|
serflog joined #evergreen |
| 06:12 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 06:52 |
|
b_bonner joined #evergreen |
| 07:30 |
|
jboyer-isl joined #evergreen |
| 07:36 |
|
rjackson-isl joined #evergreen |
| 07:37 |
csharp |
@later tell kmlussier thanks for the information from CWMARS - I'll see if we can get smaller file sets from our vendor. |
| 07:37 |
pinesol_green` |
csharp: The operation succeeded. |
| 08:31 |
|
kbeswick joined #evergreen |
| 08:36 |
|
RoganH joined #evergreen |
| 08:43 |
|
Dyrcona joined #evergreen |
| 08:44 |
remingtron |
bshum: right, I was meaning to work on those upgrade scripts yesterday.....so now I will work on them today. :) |
| 08:46 |
|
akilsdonk_ joined #evergreen |
| 08:55 |
|
mmorgan1 joined #evergreen |
| 09:03 |
|
ericar joined #evergreen |
| 09:04 |
|
kmlussier joined #evergreen |
| 09:04 |
|
bkuhn joined #evergreen |
| 09:06 |
bshum |
remingtron++ #Greatly appreciate the review and signoffs you've been helping with. |
| 09:07 |
remingtron |
bshum++ #inspired by your youthful enthusiasm |
| 09:19 |
remingtron |
bshum: in your opinion, do we need an upgrade script for #973666? I was thinking no. |
| 09:20 |
remingtron |
*cough*, I mean, for "bug 973666" |
| 09:20 |
pinesol_green` |
Launchpad bug 973666 in Evergreen "Acq: "Print Purchase Order" does not print PO Name" (affected: 2, heat: 10) [Wishlist,Fix committed] https://launchpad.net/bugs/973666 |
| 09:23 |
|
jboyer_isl joined #evergreen |
| 09:23 |
|
wjr_ joined #evergreen |
| 09:25 |
|
bshum_ joined #evergreen |
| 09:26 |
remingtron |
bshum_: I just asked the other you...in your opinion, do we need an upgrade script for bug 973666? I was thinking no. |
| 09:26 |
pinesol_green` |
Launchpad bug 973666 in Evergreen "Acq: "Print Purchase Order" does not print PO Name" (affected: 2, heat: 10) [Wishlist,Fix committed] https://launchpad.net/bugs/973666 |
| 09:27 |
|
moodaepo_nb joined #evergreen |
| 09:27 |
remingtron |
bshum_: just fyi, didn't want you to miss the question. |
| 09:30 |
|
mcooper joined #evergreen |
| 09:31 |
|
jboyer-isl joined #evergreen |
| 09:34 |
|
misilot joined #evergreen |
| 09:36 |
kmlussier |
berick: We were just looking at bug 1029591. It looks like it was left in limbo back in January when I posted a comment that it didn't seem to work when canceling at the copy level. |
| 09:36 |
pinesol_green` |
Launchpad bug 1029591 in Evergreen 2.4 "ACQ backordered items show up as canceled" (affected: 4, heat: 22) [Medium,Confirmed] https://launchpad.net/bugs/1029591 |
| 09:37 |
kmlussier |
berick: I think our libraries would love to see this feature in Evergreen if we could just get that one minor issue ironed out. |
| 09:40 |
* berick |
takes a look-see |
| 09:42 |
|
gsams__ joined #evergreen |
| 09:44 |
|
artunit_ joined #evergreen |
| 09:45 |
|
mrpeters joined #evergreen |
| 09:45 |
berick |
kmlussier: so, i would consider the fact that the lineitem as a whole is not canceled when the last LID is canceled a separate issue. |
| 09:45 |
berick |
one for which I'd be happy to apply a fix |
| 09:45 |
* berick |
also considers Tim's comments a separate issue |
| 09:45 |
kmlussier |
berick++ |
| 09:46 |
kmlussier |
berick: I think Tim's comments are already addressed in another bug. |
| 09:46 |
|
pinesol_green joined #evergreen |
| 09:46 |
berick |
cool |
| 09:46 |
|
mmorgan joined #evergreen |
| 09:46 |
kmlussier |
Yup. https://bugs.launchpad.net/evergreen/+bug/1115599 |
| 09:46 |
pinesol_green |
Launchpad bug 1115599 in Evergreen 2.4 "acq: option to receive lineitems is disabled when the lineitems has been cancelled" (affected: 2, heat: 16) [Undecided,Triaged] |
| 09:47 |
kmlussier |
Addressed as in reported, not as in fixed. :) |
| 09:47 |
berick |
right |
| 09:50 |
|
ericar_ joined #evergreen |
| 09:51 |
|
mtj_ joined #evergreen |
| 09:55 |
|
yboston joined #evergreen |
| 09:55 |
berick |
kmlussier: i assume the LI would just adopt the cancel_reason of the last-canceled item? |
| 09:56 |
berick |
even though the copies themselves may have a variety of cancel reasons.. |
| 09:57 |
|
BigRig joined #evergreen |
| 09:57 |
|
BigRig_ joined #evergreen |
| 09:57 |
berick |
hm, or do we need a new cancel reason, "OMG, All My Copies Are Gone!?!" |
| 09:58 |
kmlussier |
berick: Just checked with my acq person. Could it list all the cancel reasons? |
| 10:00 |
berick |
kmlussier: so, my main question is, we need to cancel the lineitem too, and a lineitem can only have 1 cancel reason |
| 10:00 |
berick |
there's no reason the UI can't show all of the copy cancel reasons, but that's a separate question, i think |
| 10:00 |
kmlussier |
Sure. I'll have to get back to you. I just hopped on to a conference call. |
| 10:01 |
* berick |
nods |
| 10:04 |
|
ericar_ joined #evergreen |
| 10:07 |
|
rfrasur joined #evergreen |
| 10:07 |
|
finnx joined #evergreen |
| 10:07 |
|
rfrasur joined #evergreen |
| 10:07 |
|
jboyer_isl joined #evergreen |
| 10:08 |
rfrasur |
The pain of not being an IT person...but having to do IT...trying to figure out why...after the power goes off and the modem gets replaced...the networked printer shows up on some desktops and not others. |
| 10:09 |
* rfrasur |
thinks it has to do how the computers are connected (wired vs. wireless) |
| 10:09 |
|
Pibbits2 joined #evergreen |
| 10:10 |
|
moodaepo1 joined #evergreen |
| 10:11 |
|
eby_ joined #evergreen |
| 10:11 |
|
mcooper_ joined #evergreen |
| 10:11 |
|
bradl_ joined #evergreen |
| 10:12 |
|
shadowsp1r joined #evergreen |
| 10:15 |
pinesol_green |
[evergreen|Pasi Kallinen] LP1183414: OPAC patron opt-in settings table does not work correctly - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0ebeb8a> |
| 10:15 |
|
Rogan_Ni joined #evergreen |
| 10:16 |
paxed |
Q: where do the surveys show up in OPAC? i created a survey but didn't see it anywhere in action. |
| 10:17 |
rfrasur |
I thought surveys were only in the staff client/user edit |
| 10:17 |
paxed |
so where do they show up there? :) |
| 10:23 |
eeevil |
paxed: at patron registration. in the olden days (pre-1.0), we had a little opac widget that showed random surveys. I'd like to see that come back |
| 10:24 |
paxed |
so the surveys cannot be answered anymore? |
| 10:24 |
|
kmlussier joined #evergreen |
| 10:25 |
|
jboyer-isl joined #evergreen |
| 10:28 |
rfrasur |
paxed: my understanding, and this is old understanding that might have been wrong in the beginning - was you could set it up whenever and when it went into effect, it'd alert you when you went into the patron account. |
| 10:28 |
* rfrasur |
has never used it. |
| 10:28 |
|
Meliss1 joined #evergreen |
| 10:28 |
* rfrasur |
will do a lil test |
| 10:29 |
paxed |
i only quickly glanced at the UI today (and filed bug 1199626) |
| 10:29 |
pinesol_green |
Launchpad bug 1199626 in Evergreen "Add New Survey asks start and end dates in US format" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1199626 |
| 10:30 |
|
bshum joined #evergreen |
| 10:30 |
|
CarrieC joined #evergreen |
| 10:31 |
rfrasur |
hmm, there is an OPAC survey radio button. I'll check a couple things then. |
| 10:34 |
rfrasur |
yeah, I'm not entirely sure how you're even supposed to add questions to the thing. |
| 10:34 |
paxed |
just open the survey after you've added it, and at the bottom of that you can add questions and answers. |
| 10:34 |
pinesol_green |
[evergreen|Thomas Berezansky] Simplified pull list: More name options - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1344fa> |
| 10:35 |
rfrasur |
I'm in 2.2 and there's nothing down there that says add anything. Just a blank field for questions and answers. |
| 10:35 |
paxed |
ah... if the survey active right now? if it is, you can't change it |
| 10:35 |
paxed |
is* |
| 10:36 |
paxed |
(i made that error yesterday) |
| 10:36 |
rfrasur |
ahh, okay, let me try again |
| 10:36 |
rfrasur |
;-) |
| 10:37 |
bshum |
I make that mistake all the time. Darned surveys. |
| 10:38 |
bshum |
remingtron: I saw what you said in the backlog. I've been preoccupied trying to get back into IRC, but I'll take a quick look if someone else hasn't gotten there yet. |
| 10:38 |
paxed |
the UI really should say "The survey is active right now, and cannot be changed." or whatever. |
| 10:39 |
rfrasur |
So, there's only the option for free responses? |
| 10:39 |
remingtron |
bshum: actually, I forgot that dbwells already pushed it, so it is all set. Thanks though! |
| 10:40 |
bshum |
remingtron: Cool deal. |
| 10:45 |
|
mllewellyn joined #evergreen |
| 10:46 |
rfrasur |
paxed: I created a brief survey that I then backdated to begin today (probably should backdate it to begin yesterday though just incase there's a timestamp that makes a diff). Didn't see it show up in the OPAC or staff client. BTW, just discovered there's a "survey" item in the "other" menu in the staff client patron account (nothing showed up in there). Will try once more w/ a broader date range. |
| 10:46 |
|
zerick joined #evergreen |
| 10:47 |
rfrasur |
oh, I see something else I did wrong. |
| 10:48 |
rfrasur |
also, there's a date picker in survey edit screen, but not in the initial set-up |
| 10:51 |
paxed |
like i commented on the bug i filed. |
| 10:51 |
dbwells |
grabbing 0803 |
| 10:52 |
rfrasur |
yeah, just commenting on observations. I did backdate and nothing showed up in the staff client patron editor...or anywhere else that I poked around in. |
| 10:53 |
paxed |
might be it was waylaid when we moved from jspac to tpac...? |
| 10:53 |
rfrasur |
but would that effect the staff client? |
| 10:53 |
paxed |
no idea as i don't know where it showed up there. |
| 10:54 |
|
CarrieC1 joined #evergreen |
| 10:55 |
rfrasur |
paxed: have you created any more bug reports related to surveys? |
| 10:55 |
kmlussier |
berick: In lieu of a new LI cancel reason of "multiple" (or, as you suggest, OMG, All My Copies Are Gone!?!), I think using the reason from the last-canceled copy makes sense. In most cases, I imagine the cancel reasons would be the same. |
| 10:55 |
paxed |
rfrasur: no. i hadn't paid any attention to them before yesterday. |
| 10:55 |
rfrasur |
okay |
| 10:55 |
paxed |
rfrasur: so, to the bug mobile! go file a bug :) |
| 10:56 |
rfrasur |
yup, I'm there...looking at the calendar issue first. Do you think having the date picker there would address the format prob? |
| 10:56 |
paxed |
yes |
| 10:57 |
|
bradl joined #evergreen |
| 10:57 |
paxed |
the dijit DateTimePicker (or whatever it is) does l10n correctly |
| 10:57 |
rfrasur |
okay |
| 11:03 |
pinesol_green |
[evergreen|Pasi Kallinen] Description for circ.holds.default_shelf_expire_interval - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f81eff8> |
| 11:03 |
pinesol_green |
[evergreen|Remington Steed] LP1158211 - add upgrade script to fill empty description - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=21bcf41> |
| 11:03 |
pinesol_green |
[evergreen|Dan Wells] Stamping upgrade script for empty seed description - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c260a67> |
| 11:03 |
rfrasur |
tada - 1st bug report |
| 11:03 |
rfrasur |
(do I get a cookie or something?) |
| 11:06 |
paxed |
@praise rfrasur |
| 11:06 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of rfrasur |
| 11:06 |
rfrasur |
better than a cookie. thank you. |
| 11:07 |
phasefx |
rfrasur: you may need to restart the client after creating surveys; I think it pulls some of that stuff during login |
| 11:08 |
remingtron |
rfrasur++ #congrats on first big report! keep it up! |
| 11:08 |
rfrasur |
phasefx: I'll give a try. |
| 11:08 |
rfrasur |
I did clear the cache, but it might not have been enough. |
| 11:08 |
phasefx |
the view under Other is read-only. I think the patron editor and offline patron registration is the only other places they show up |
| 11:09 |
* paxed |
hopes for several utf-8 related fixes in -m2 ... :P |
| 11:10 |
rfrasur |
testing |
| 11:11 |
rfrasur |
(an automatic reload when saving configuration would be nice as well) |
| 11:13 |
rfrasur |
okay...the read only did show up... |
| 11:13 |
rfrasur |
ty phasefx. hunting around still. |
| 11:15 |
phasefx |
rfrasur: automatic reloads may be trickier than you might think, if you expect all of your workstations to instantly get changes like that. At the time, the mindset was that a lot of these changes were supposed to be treated as big deals and not on the fly tinkering. I'd like instant updates, though |
| 11:15 |
rfrasur |
and it's in the patron registration, but not in the patron acct editor...registration and offline registration. |
| 11:16 |
rfrasur |
phasefx: yeah, I understand...and I tend to do a lot more on-the-fly things anyway. the whole break it and ask questions later. |
| 11:16 |
phasefx |
rfrasur: library settings are the biggest area where you need staff client restarts |
| 11:17 |
rfrasur |
good to know...and it makes sense. |
| 11:17 |
phasefx |
though that wouldn't be difficult for an auto-refresh for that specific workstation.. just broadcasting it out to everyone, that's trickier |
| 11:17 |
rfrasur |
but, what about OPAC visibility. that doesn't seem to work at all. |
| 11:18 |
rfrasur |
well, for our lib, it'd be just as easy to do individual restarts. We have 4 staff computers. |
| 11:18 |
phasefx |
used to be autogen.sh would need to be run for stuff like that, but now I think there's perl code caching org unit data |
| 11:18 |
dbs |
Pretty much everything is "OPAC visible" in the staff client, no? |
| 11:18 |
phasefx |
so you may need to restart or reload apache, and/or restart OpenSRF services, for an OPAC visiblity change to get noticed. I'm not sure |
| 11:19 |
Dyrcona |
gmcharlt: I have a list of name authorities that every 20th to 50th record throws up a MARC::Charset error. |
| 11:19 |
rfrasur |
lol, I don't have the ability to restart or reload apache or OpenSRF |
| 11:19 |
phasefx |
dbs: yeah, I think so |
| 11:19 |
Dyrcona |
gmcharlt: You want me to compress that file and just send it to you? |
| 11:19 |
phasefx |
rfrasur: so yeah, "big deals", even if there is a UI for it |
| 11:21 |
kmlussier |
acq++ #Hearing positive reports on how smoothly our fiscal year close-outs are going. :) |
| 11:21 |
rfrasur |
none of our local libraries do. and it seems like it'd be pretty impractical to even use the surveys if that's what we have to do...we'd have to set it up locally and then have server admins restart/reload services to push it out through OPAC |
| 11:22 |
gmcharlt |
Dyrcona: yes |
| 11:22 |
dbwells |
grabbing 0804 |
| 11:23 |
phasefx |
rfrasur: sorry, I think I may have misunderstood you. When you said OPAC visiblity, I was thinking about the the flag on orgs in the org tree |
| 11:23 |
phasefx |
not on surveys |
| 11:23 |
berick |
kmlussier++ # yay! |
| 11:24 |
rfrasur |
phasefx: ahh, yes. Surveys. There's a radio button that says "OPAC survey?" but then nothing shows up in the OPAC that I could find. I'd assume that it'd be something that'd show up in the patron's online acct. Of course, assuming is probably a bad idea. |
| 11:25 |
phasefx |
rfrasur: no, as eeevil was saying, there used to be a feature that would make use of that, but now it's just cruft, does nothing |
| 11:25 |
phasefx |
would like to see it do something again |
| 11:25 |
rfrasur |
and that WAS because of jspac > tpac? |
| 11:25 |
phasefx |
well, more like prototype -> jspac |
| 11:25 |
rfrasur |
(which makes sense to me...as much as anything else does) |
| 11:26 |
|
acoomes joined #evergreen |
| 11:26 |
phasefx |
was a developer itch, but I don't think it was something PINES was pushing for, so it didn't land in jspac |
| 11:27 |
rfrasur |
personally, I don't have any desire to do a survey through the OPAC. I think it'd cheese some people off and confuse some others. But, if that's the case, and maybe it's already addressed in later versions, that needs to be removed from the UI |
| 11:28 |
Dyrcona |
gmcharlt: If you have a test version of MARC::Charset that you'd like me to try, just let me know. |
| 11:28 |
gmcharlt |
Dyrcona: soon |
| 11:29 |
Dyrcona |
cool |
| 11:29 |
phasefx |
rfrasur: I think the only reason for us to even want to implement over just using a dedicated javascript library is the js-lite mandate for the TPAC |
| 11:30 |
phasefx |
if people wanted that functionality |
| 11:30 |
phasefx |
yeah, better to hide or remove the option for the timebeing |
| 11:31 |
rfrasur |
phasefx++ |
| 11:34 |
|
bshum joined #evergreen |
| 11:42 |
|
stevenyvr2 joined #evergreen |
| 11:43 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix LP1158206 - The language is Gwich'in. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dc36d51> |
| 11:43 |
pinesol_green |
[evergreen|Ben Shum] LP1158206 - include upgrade script to fix Gwich'in typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=24f008f> |
| 11:43 |
pinesol_green |
[evergreen|Dan Wells] Stamping upgrade for Gwich'in language typo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9ae900> |
| 11:46 |
bshum |
eeevil: Curious, was there anything about bug 1125644 that I can help address? You've got it assigned to you, but I just want to make sure what I put together isn't a problem or something... |
| 11:46 |
pinesol_green |
Launchpad bug 1125644 in Evergreen "Desk renewal use original circ library" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1125644 - Assigned to Mike Rylander (mrylander) |
| 11:46 |
rfrasur |
Just so you know, not only do I not know how to program, I also do not know how to fix the a/c here or get the printer to work or much of anything else, and apparently today is meeting day for all our service people. BUT the internet does work...and the electricity. |
| 11:47 |
|
zerick joined #evergreen |
| 11:47 |
jcamins |
rfrasur: we just turned on our A/C. It's a very good thing, to have A/C. |
| 11:48 |
bshum |
I don't think the A/C is working in my office area, just everywhere else. But I have a box fan that's pointed straight at me right now :) |
| 11:48 |
bradl |
bshum: you should make phone calls and claim to be in an open cockpit prop airplane |
| 11:49 |
bshum |
bradl: I totally should have done that during this morning's conference call! |
| 11:49 |
rfrasur |
A/C is a good thing...and it's okay in the rest of the building...just not where my office is (or the nonfiction room). |
| 11:49 |
* rfrasur |
gets grumpy in hot climates...really grumpy |
| 11:49 |
rfrasur |
poor staff |
| 11:50 |
|
moodaepo_nb joined #evergreen |
| 11:51 |
|
finnx left #evergreen |
| 11:51 |
pinesol_green |
[evergreen|Mark Cooper] LP1156905 lineitem worksheet sorts copies by org - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=572e9a2> |
| 11:51 |
rfrasur |
ahh, it's working now. |
| 11:53 |
rfrasur |
bshum:I keep forgetting to get a fan. By the time I leave, I'm in an air conditioned car and just want to go home. |
| 11:54 |
bshum |
rfrasur: I brought mine from home the first day in the new office once we realized nothing was working in our office space. |
| 11:55 |
rfrasur |
lol, the fan I would have brought from home finally died after 10 yrs (no lie) of being on continually |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] Add missing oils_i18n call to upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7b06d1> |
| 11:55 |
jcamins |
rfrasur: no power outages in 10 years? |
| 11:55 |
rfrasur |
well, that...yes. But we never turned it off on purpose. |
| 11:56 |
|
finnx joined #evergreen |
| 11:57 |
phasefx |
rfrasur: programmers and catalogers :) |
| 11:58 |
phasefx |
get you on the details |
| 11:59 |
rfrasur |
phasefx: I like details. They make the broader, more ambiguous stuff. Like knowing what the labels on the circuit panel AND knowing that there's a secondary circuit panel makes understanding why the A/C isn't working that much easier. |
| 12:00 |
* phasefx |
is with you |
| 12:00 |
paxed |
dbwells: re commit a7b06d1, i don't think the oils_i18n_gettext() is really necessary in upgrade scripts, as all it does is pass the 2nd parameter through, and the separate python script is used to grab those for gettext during make. |
| 12:00 |
pinesol_green |
[evergreen|Dan Wells] Add missing oils_i18n call to upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7b06d1> |
| 12:00 |
rfrasur |
apparently nobody else here noticed the crumbling brick at the bottom of our sign or the disconnected downspout either. |
| 12:01 |
pinesol_green |
[evergreen|Dan Wells] Add missing oils_i18n call #2 to upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6693be3> |
| 12:01 |
* rfrasur |
takes a deep breath (of air conditioned air) and decides to get over it. |
| 12:01 |
dbwells |
paxed: thanks, good to know. I already pushed it, and I think there is some value in being consistent in any case, but something to think about for the future. |
| 12:01 |
csharp |
has anyone hacked marc_export so that *only* the chosen library's holdings are attached to the marc record and not *all* holdings? |
| 12:01 |
bshum |
Someday I should go fix all our IDs in coded_value_map. Totally messed me up when working on that one. |
| 12:02 |
|
finnx joined #evergreen |
| 12:02 |
bshum |
Since our IDs don't seem to match what's in master. |
| 12:02 |
bshum |
csharp: Yes. |
| 12:02 |
* csharp |
wishes ids weren't hard-coded anywhere ever |
| 12:02 |
bshum |
csharp: I think I showed you how to do that a few months ago... |
| 12:02 |
csharp |
oh yeah? |
| 12:02 |
paxed |
dbwells: well, perhaps sometime in the future we'll handle the oils_i18n_gettext differently, ... |
| 12:02 |
bshum |
csharp: Well, not in a happy nice way, but a hacky not so nice way |
| 12:03 |
csharp |
ha |
| 12:03 |
bshum |
Let me go poke at some of our custom scripting. |
| 12:04 |
csharp |
bshum: thanks ;-) |
| 12:05 |
* csharp |
's memory of that exchange comes back |
| 12:05 |
bshum |
csharp: http://open-ils.org/irc_logs/evergreen/2012-11/%23evergreen.05-Mon-2012.log#line66 |
| 12:05 |
bshum |
Was faster looking for the IRC entry :) |
| 12:06 |
bshum |
Looks like I didn't paste you a full copy though. |
| 12:06 |
bshum |
I'll try to do that now... once I get a copy going... |
| 12:07 |
csharp |
bshum: excellent - thanks for bearing with my faulty memory |
| 12:07 |
* csharp |
only gets tapped to do marc stuff every so often |
| 12:08 |
bshum |
For some reason, my brain is just filled with old IRC discussions and LP tickets now. |
| 12:08 |
bshum |
So don't take it as a good sign for me either. |
| 12:10 |
bshum |
csharp: http://pastie.org/8128499 is an example of something I run for one of our school libraries. |
| 12:10 |
kmlussier |
csharp: More on Vandelay uploads. In our case, I think central site staff gets the large files from vendors and then breaks them up into the smaller batches. |
| 12:10 |
bshum |
Ack, I just realized that has a custom 949 holding entry instead of 852... |
| 12:10 |
bshum |
But basically around line 402 is the new addition that forces it to look at just a specific library's shortname for holding info. |
| 12:11 |
bshum |
And it skips other CNs and copies |
| 12:11 |
|
laque|3 joined #evergreen |
| 12:11 |
bshum |
I think we wanted to show all holdings including opac invisible ones for that extract, so line 405 is commented out. But you can change that too. |
| 12:12 |
bshum |
Hacky, but it works so I haven't gotten deeper towards changing it up or adding better option support. Yet. |
| 12:16 |
csharp |
kmlussier: thanks for that - I'm seeing if the vendor can chop them up |
| 12:16 |
csharp |
in this case, it's a huge "base file" - I don't think the regular updates will be nearly this large |
| 12:16 |
csharp |
but I don't know ;-) |
| 12:17 |
csharp |
and right now I'm just verifying that the files load at all - we'll have to start playing with matching soon too ;-) |
| 12:18 |
* eeevil |
returns and reads up |
| 12:18 |
eeevil |
bshum: lemme look now |
| 12:25 |
eeevil |
bshum: so, I think your patch is a step in the right direction. if we want to support "use the original circ rule but give the desk location credit" in the future I can see a couple ways to build that. one way would be to (at some future date) 1) move global flag to YAOUS 2) add a second YAOUS for "original rule" that defaults to true. that would preserve the semantics you're encoding but allow finer grained control. there are other ways, but |
| 12:25 |
eeevil |
would probably require ripping out your semantics entirely. do you see my possible future as a useful extension if it ends up being desirable? |
| 12:26 |
eeevil |
s/default to true/defaults to the equivalent alue of the YAOUS in (1) (aka, the old global flag)/ |
| 12:27 |
bshum |
It sounds interesting. The thing I worry about with retaining the actual desk location in the details is that it might still confuse end users if circ behavior becomes different. |
| 12:27 |
bshum |
Like for troubleshooters going, but the circ lib says X, why's the rule this way? And not initially realizing the disconnected reality. |
| 12:27 |
bshum |
But that's something we can train around if said feature ever came to fruition, I suppose. |
| 12:27 |
eeevil |
yeah, without a "matrix context org" it could be confusing |
| 12:28 |
eeevil |
but (obv) there are ways of dealing with that |
| 12:29 |
rfrasur |
bshum: related to desk location...and y'all may never have this problem, but I noticed that two of our circulation computers are registered using the exact same name. Is desk location determined by that workstation registration name? |
| 12:29 |
eeevil |
ok ... I've convinced myself that your approach does not preclude future enhancement, hinted at by michele, in a way that can be made sane ;) |
| 12:30 |
eeevil |
rfrasur: not by the name, but by the org chosen at registration time |
| 12:30 |
rfrasur |
so, it's broader than the actual machine. |
| 12:30 |
eeevil |
rfrasur: and that's possible if you register via a powerful enough user |
| 12:31 |
eeevil |
or if you clone a staff client install |
| 12:31 |
bshum |
I do that all the time, keeping my original registration names when re-registering my workstations over and over as my profile gets lost over time. |
| 12:31 |
rfrasur |
that's probably what happened...though not by me (obviously) |
| 12:32 |
bshum |
eeevil: There's always possiblilities for future enhancements :D |
| 12:32 |
|
acoomes joined #evergreen |
| 12:32 |
bshum |
But at least it's a flag that's shipped off, like other renewal options. |
| 12:33 |
bshum |
I'm not sure about YAOUS personall |
| 12:33 |
bshum |
*personally |
| 12:33 |
bshum |
I fought that battle inside myself before thinking that if one library does it, all of them should do it, else we get into weird worlds where behavior isn't always guaranteed to be the way we expect it to. |
| 12:33 |
bshum |
If YAOUS aren't done well. |
| 12:34 |
bshum |
But our consortium wants a global choice, I don't know if others might want more granular choice in the future... sigh :( |
| 12:34 |
Dyrcona |
"YAOUS!" he cried as our hero leveled his lance and bounded toward the windmill. |
| 12:34 |
eeevil |
bshum: unless you're in a well-separated sorta-consortium |
| 12:34 |
bshum |
Great, now I'm getting confused... |
| 12:34 |
rfrasur |
Dyrcona: that really should be on a t-shirt |
| 12:34 |
bshum |
eeevil: Oy, now I getcha... stupid walled gardends. |
| 12:34 |
eeevil |
bshum: you can do global with YAOUS |
| 12:35 |
bshum |
eeevil: True, just set to CONS (or highest point) and call it a day. |
| 12:35 |
eeevil |
the hammer of CRON can remove unauthorized values :) |
| 12:35 |
Dyrcona |
rfrasur: ty. |
| 12:37 |
bshum |
eeevil: I'd be happy to try either way, I guess. |
| 12:37 |
eeevil |
Dyrcona: http://bighugelabs.com/output/lolcat0d38deb9955782d174232f960587b08842026b9f.jpg |
| 12:38 |
Dyrcona |
eeevil: Ha! It needs a little Don Quixote charging the windmill on foot. |
| 12:38 |
rfrasur |
one sec |
| 12:39 |
eeevil |
grabbing 805 |
| 12:39 |
|
edoceo joined #evergreen |
| 12:40 |
bshum |
@love YAOUS |
| 12:40 |
pinesol_green |
bshum: But bshum already loves YAOUS! |
| 12:40 |
bshum |
:D |
| 12:40 |
rfrasur |
https://dl.dropboxusercontent.com/u/348671/tilting.png |
| 12:41 |
|
CarrieC joined #evergreen |
| 12:42 |
rfrasur |
bshum: ha! |
| 12:42 |
bshum |
Suddenly I think back to the license plate idea again. |
| 12:42 |
eeevil |
nice |
| 12:44 |
rfrasur |
hmm, I should have said "bshum: hah! to already loving YAOUS!" |
| 12:44 |
bshum |
rfrasur: I love and hate them. But mostly love. |
| 12:44 |
rfrasur |
bshum: I think that's pretty standard for most important things. |
| 12:47 |
bshum |
Ugh, offline patron registration doesn't have a dropdown in it to handle net_access_level |
| 12:47 |
pinesol_green |
[evergreen|Ben Shum] Desk Renewal at original circ library - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=931dcde> |
| 12:47 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for Desk Renewal Circ Lib - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6bf2e8f> |
| 12:47 |
bshum |
So everybody registered offline comes through with the wrong level by default and are being blocked. Big sigh. :) |
| 12:48 |
* bshum |
adds to long list |
| 12:48 |
rfrasur |
that might not necessarily be a bad thing though, since it'd require an online doublecheck |
| 12:49 |
bshum |
rfrasur: Now see, that's the logical reasonable answer I was looking for. Not "omg, it's unusable" |
| 12:49 |
bshum |
:D |
| 12:49 |
rfrasur |
bshum++ |
| 12:50 |
|
acoomes joined #evergreen |
| 12:51 |
|
krvmga joined #evergreen |
| 12:51 |
rfrasur |
offline registrations worry me anyway because you can't check existing accounts/notes/exclusions/whatevers. It's convenient...but also has a lot of "honor system" elements to it. |
| 12:51 |
krvmga |
if i want to host my own book jacket images (in the case of privately published authors), does anyone have experience doing that? |
| 12:52 |
bshum |
I suppose if I just change the default in actor.usr definition for net_access_level from 1 (our blocked/"filtered") to 2, that should do the trick. |
| 12:52 |
bshum |
2 being not blocked or "unfiltered" |
| 12:52 |
bshum |
Which is what we set our YAOUS to |
| 12:52 |
bshum |
For regular patron registration anyways. |
| 12:53 |
* bshum |
goes back to grumbling to himself. |
| 12:53 |
rfrasur |
bshum: do your patrons have to sign an internet agreement or anything like that? |
| 12:54 |
|
jhaig joined #evergreen |
| 12:55 |
bshum |
rfrasur: Re: some libraries have their policy displayed , but it doesn't sound like it's an established procedure. |
| 12:55 |
bshum |
I guess they just want it to "work" |
| 12:55 |
bshum |
Without their intervention or poking at it later. |
| 12:55 |
jhaig |
Hi. I'm having trouble with a server that I have just come back to after a long time. From the staff client, when I click 'MARC Batch Import / Export' I get an Internal Server Error. |
| 12:56 |
rfrasur |
of course they just want it to work...but probably don't have anything but a foggy idea (if that) of what it working means. |
| 12:56 |
bshum |
rfrasur: Pretty much :( |
| 12:56 |
* rfrasur |
grumbles something about a/c, rain, and wanting to go home. |
| 12:56 |
jhaig |
The file /var/log/apache2/error.log has the line "File does not exist: /openils/var/web/xul/rel_2_3_5/server/main/OpenILS" |
| 12:59 |
phasefx |
krvmga: re: custom jacket images, you have to drop an image in a certain location on the server and have it named after the ISBN |
| 12:59 |
bshum |
jhaig: I get that error (or one like it) every time someone logs into the staff client. |
| 13:00 |
bshum |
jhaig: That other internatl server error, seems like an apache problem. Maybe check those logs for clues? |
| 13:00 |
* paxed |
hopes for the added-content-by-record-id to get in... |
| 13:00 |
* bshum |
pokes jeff_, see what paxed just said! --^ |
| 13:00 |
bshum |
:D |
| 13:00 |
|
b_sage joined #evergreen |
| 13:01 |
jhaig |
bshum: By 'that error' do you mean the "File not found"? And is that OK to ignore then? |
| 13:01 |
bshum |
jhaig: Sorry yes, that file not found you mentioned should be safe to ignore. |
| 13:02 |
bshum |
(and is probably unrelated to the issue you're describing) |
| 13:03 |
|
jihpringle joined #evergreen |
| 13:03 |
jhaig |
bshum: Thanks. I'm starting to think I didn't want that particular page after all. Long time since I looked at this server and I think I wanted the z39.50 Import, which appears to be working (so far) |
| 13:06 |
krvmga |
phasefx: you wouldn't happen to know what the "certain location" is, would you? :) |
| 13:14 |
|
Meliss joined #evergreen |
| 13:14 |
phasefx |
krvmga: had to dig; so http://phasefx.evergreencatalog.com/opac/extras/ac/jacket/small/9780062101891 is coming from Open Library, and http://phasefx.evergreencatalog.com/opac/extras/ac/jacket/small/9780062101892 by virtue of me having done mkdir -p /openils/var/web/opac/extras/ac/jacket/small/ && cp /usr/share/pixmaps/debian-logo.png /openils/var/web/opac/extras/ac/jacket/small/9780062101892 |
| 13:16 |
krvmga |
phasefx: did you have to have a small, medium and large version of the jacket image? |
| 13:16 |
phasefx |
so basically apache gets a request for a URL based on TPAC templates, and the AddedContent handler checks to see if that path really exists, and if it does, let's apache serve it, otherwise, it fetches the image from the 3rd party server |
| 13:16 |
phasefx |
krvmga: I would if I were to try the corresponding URL's |
| 13:16 |
phasefx |
otherwise, it'd fall back to Open Library, in my case |
| 13:17 |
krvmga |
phasefx: since the jacket image sizes are different in different results screens |
| 13:17 |
phasefx |
krvmga: just right-click open image on a given image to see what the path is, but I'm pretty sure it's ac/jacket/small, ac/jacket/medium, and ac/jacket/large |
| 13:18 |
krvmga |
phasefx++ |
| 13:18 |
phasefx |
so you'd want to create those to cover all cases |
| 13:24 |
jeff_ |
one option is to simply symlink two sizes to the other. another is to have a system which eats the large image and re-sizes to small and medium and uploads to your evergreen web servers. |
| 13:25 |
jeff_ |
we started using javascript in the catalog to report lack of item images, so that those could be given first priority for finding/scanning an image. |
| 13:25 |
phasefx |
imagemagick is good for that from the command-line |
| 13:25 |
jeff_ |
with ac-by-rec-id, it's done not by isbn but by the record ID (meaning the records like puppets don't need a fake isbn), and there's an /r/ in the url before the record id. |
| 13:26 |
jeff_ |
yeah, i think our system uses some drupal module that is using imagemagick. |
| 13:26 |
|
Callender joined #evergreen |
| 13:34 |
|
collum joined #evergreen |
| 13:36 |
rfrasur |
greenstone |
| 14:09 |
pastebot |
"Dyrcona" at 204.193.129.146 pasted "Random MARC::Charset Errors" (5 lines) at http://paste.evergreen-ils.org/12 |
| 14:16 |
Dyrcona |
I'm now trying 1.34 from CPAN to see if it fares better. |
| 14:22 |
Dyrcona |
There is no data, but bad data.... |
| 14:23 |
Dyrcona |
A bib record with a data field 009. 009 is a control field. Why that chokes MARC::Charset, I don't know, and why it survived my earlier runs through the file but dies now, I also don't know. |
| 14:24 |
|
tmccanna_ joined #evergreen |
| 14:26 |
rfrasur |
just talked w/ vendor interested in EG integration. interesting timing. |
| 14:28 |
rfrasur |
though I might have hurt his feelings when he said "we host Evergreen" and I said "lots of people do." |
| 14:32 |
bshum |
Hah |
| 14:33 |
jeff |
other than hosting, what integration services were they offering? |
| 14:35 |
rfrasur |
I dunno that they're even offering hosting. They host it for their own development purposes. It's Fanggle. They do Libserra stuff (mobile). I'm thinking (he's calling back tomorrow to talk more) that they're wanting to market their mobile stuff to libraries with EG integration. |
| 14:36 |
kmlussier |
rfrasur: I've talked to them before. They were hosting one of the community demo servers at one time. |
| 14:36 |
rfrasur |
Honestly...it's a little incidental in my mind and probably only worth anything to a library that just HAS to have an app |
| 14:38 |
rfrasur |
kmlussier: we actually do have a free app they put together for us...but yeah. I'll talk more with him tomorrow and try to take off my lib director hat and put on EG-IN exec com hat. |
| 14:40 |
|
akilsdonk_ joined #evergreen |
| 14:44 |
bshum |
fparks: Interesting find for bug 1103706 |
| 14:44 |
pinesol_green |
Launchpad bug 1103706 in Evergreen 2.4 "Hold ratios in circ policies cause errors when trying to renew items" (affected: 2, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1103706 |
| 14:45 |
|
jdouma joined #evergreen |
| 14:46 |
fparks |
bshum: Interesting in a good way? |
| 14:46 |
bshum |
fparks: I'm sure kmlussier and others will be quite interested in what you've found. |
| 14:47 |
bshum |
Sounds like a good thing though; I'll have to test it out too, but we don't use hold ratios in our system. |
| 14:47 |
kmlussier |
I'm in the process of adding it to Dyrcona's list of development branches. :) |
| 14:48 |
rfrasur |
Okay, lovelies - time to shut 'er down and make the trek south. |
| 14:50 |
kmlussier |
fparks: I'll see if I can test it soon. If it works, you will make a lot of our libraries very happy. :) |
| 15:05 |
jeff_ |
kmlussier: what does hold ratio decide for you? |
| 15:06 |
jeff_ |
kmlussier: are you using it to permit/deny renewals, or something else? |
| 15:07 |
kmlussier |
jeff_: We aren't using it yet because of bug 1103706. What we want to use it for is to prevent renewals when there are holds on the title and no available copies to fill that hold. |
| 15:07 |
pinesol_green |
Launchpad bug 1103706 in Evergreen 2.4 "Hold ratios in circ policies cause errors when trying to renew items" (affected: 2, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1103706 |
| 15:08 |
jeff_ |
kmlussier: got it. thanks! |
| 15:09 |
kmlussier |
There is a library setting to prevent renewals on titles with holds, but, if we use it, it will prevent the renewal even if there are dozens of copies to fill the one hold on the title. We're hoping the ratios will put a little more intelligence behind blocking those renewals. |
| 15:09 |
jeff_ |
*nod* |
| 15:09 |
jeff_ |
"copy needed for hold" is actually "copy could potentially fill a hold" |
| 15:11 |
gsams__ |
I'm actually currently looking into an odd issue that deals with specific copies being allowed to be renewed even though they are on hold |
| 15:11 |
gsams__ |
running 2.3.5, with the "Block Renewal of Items Needed for Holds" set to true. |
| 15:11 |
jeff_ |
gsams__: where there is a copy-level hold on the item? |
| 15:12 |
gsams__ |
yes |
| 15:12 |
gsams__ |
The worst part is I am having trouble duplicating the behavior |
| 15:12 |
gsams__ |
but I have seen it happen |
| 15:13 |
jeff_ |
you can't reproduce it with an item checked out, placing a copy-level hold on the item, then attempting renewal? |
| 15:14 |
gsams__ |
I haven't been able to so far, its really quite odd. I've been trying to track down the items that this has happened on |
| 15:14 |
gsams__ |
I just got a small list of items that this has happened and am about to run tests with those |
| 15:14 |
jeff_ |
gsams__: i suspect it may vary depending on if there are any other holds. |
| 15:15 |
gsams__ |
jeff_: and I can't verify if the holds were the only ones on those items/titles |
| 15:16 |
jeff_ |
my initial thought was that the copy check was done solely on action.hold_copy_map and that copy holds might not use ahcm -- but at least in 2.2, I've confirmed that copy level holds do indeed use ahcm. |
| 15:17 |
bshum |
I can't recall if there's some sort of override. |
| 15:17 |
bshum |
For renews to force them to occur in the staff client? |
| 15:18 |
gsams__ |
Okay, I just looked at one of the offending items and the hold that isn't triggering is a Title hold |
| 15:19 |
gsams__ |
only one copy in the system |
| 15:19 |
gsams__ |
now I'm really confused |
| 15:19 |
jihpringle |
gsams__: we once had a similar sounding problem on 2.2, we discovered that new items weren't being checked in initially and were going straight from In Process to Checked Out and patrons were then able to renew |
| 15:19 |
gsams__ |
jihpringle: I can almost assure you that this is something that happened. |
| 15:20 |
gsams__ |
I tell them to make sure to check items in after processing but I know they forget to most of the time |
| 15:24 |
csharp |
so are there any staff client memory leak improvements in 2.4? many of our libraries are still having to resort to multiple restarts a day... |
| 15:24 |
|
zerick joined #evergreen |
| 15:24 |
phasefx |
bshum: there's a list of overridable events for renewals in server/circ/util.js, line 3883 |
| 15:25 |
|
zerick joined #evergreen |
| 15:27 |
|
zerick joined #evergreen |
| 15:29 |
gsams__ |
jihpringle: I will test this out and submit a bug if I can duplicate it on our system. I don't currently see anything like that. |
| 15:31 |
jihpringle |
I don't think we ever submitted it as a bug, we just told our library to make sure to check things in first, but I agree that it is a bug |
| 15:35 |
|
mtcarlson joined #evergreen |
| 15:37 |
bshum |
csharp: There were improvements to patron search and UI, but yes, there's still something major going on. |
| 15:37 |
csharp |
bshum: thanks |
| 15:38 |
bshum |
csharp: gmcharlt and phasefx had ideas on that which we're still waiting to hear back on :D |
| 15:38 |
csharp |
ok good |
| 15:38 |
bshum |
csharp: But yes, our libraries are still doing restarts, etc. in their workshift rotations to combat issues. |
| 15:39 |
csharp |
we're looking at a Labor Day upgrade, and I'm sure that's going to be the top question |
| 15:40 |
gsams__ |
jihpringle: No dice, went from "in process" to "checked out", place a hold from a different account, tried to renew and it got blocked... |
| 15:40 |
jihpringle |
brand new item never checked in before? |
| 15:41 |
gsams__ |
yeah, just had our cataloger run it up for me |
| 15:42 |
bshum |
csharp: If I recall correctly, the improvement that was made was something that was measurable if one were watching the task manager for the specific scenario, (aka watching the patron search eat up tiny bits of memory forever, or having each patron tab load and never go back down in mem) |
| 15:42 |
bshum |
So it's observable, but the end result is that there's still restarts involved so our libraries take it as "we're still broken" |
| 15:42 |
bshum |
Which we are. |
| 15:42 |
bshum |
Or perhaps... we couldn't convince our libraries that it helped enough by itself :D |
| 15:44 |
gsams__ |
confusion level: super thorough. |
| 15:45 |
bshum |
gsams__: Sure it's an active hold right? Not a suspended one or something? |
| 15:45 |
jihpringle |
gsams: looks like the bug must have been fixed between 2.2 and 2.3, that's the only instance we've seen of anything like that |
| 15:46 |
csharp |
bshum: yeah, our libraries saw an improvement when we went from 2.3.4 to 2.3.6, but a lot of our systems are still struggling |
| 15:47 |
gsams__ |
bshum: Yes, all instances that I've been made aware of were with active holds. I was under the impression that it was related to copy holds, but at least one instance is a title hold |
| 15:47 |
bshum |
Hmm |
| 15:48 |
gsams__ |
and in this case it is allowing it to renew regardless, but there is only one copy in the whole consortium |
| 15:48 |
gsams__ |
I just renewed it with no problems, I hope that patron doesn't mind |
| 15:49 |
gsams__ |
gave them 2 extra days |
| 15:49 |
|
rfrasur joined #evergreen |
| 15:52 |
|
zerick joined #evergreen |
| 15:52 |
eeevil |
bshum/csharp: the big outstanding mem issue is that printing (as in, the moz-internal code that prints stuff) leaks. as you can imaging, that's a rabit hole... |
| 15:57 |
rfrasur |
can someone link me into the TPAC translations? |
| 15:57 |
bshum |
rfrasur: On Launchpad? |
| 15:57 |
rfrasur |
please |
| 15:57 |
rfrasur |
hmm, n/m |
| 16:01 |
|
bshum joined #evergreen |
| 16:02 |
bshum |
Yay, freenode! |
| 16:02 |
rfrasur |
They do seem like particularly nice people. |
| 16:04 |
bshum |
eeevil: That's what I figured. Crazy rabbits. |
| 16:04 |
rfrasur |
err...launchpad isn't working now? |
| 16:04 |
* rfrasur |
wonders "is it me, today? does my presence just break things?" |
| 16:05 |
bshum |
With Launchpad... well... |
| 16:05 |
bshum |
It might not be just you. |
| 16:05 |
rfrasur |
I figured, and it's just the opac.dtd file that's timing out all of a sudden. |
| 16:06 |
bshum |
But yeah I'm able to move around |
| 16:06 |
bshum |
Could be that your session died or something |
| 16:06 |
rfrasur |
well...that's possible. I might or might not have done some sketchy authentication. |
| 16:07 |
rfrasur |
pulling windows apart at the same time and everything |
| 16:10 |
|
mtcarlson joined #evergreen |
| 16:16 |
|
gsams___ joined #evergreen |
| 16:17 |
|
mmorgan1 joined #evergreen |
| 16:18 |
|
tfaile_ joined #evergreen |
| 16:21 |
|
CarrieC joined #evergreen |
| 16:24 |
|
acoomes joined #evergreen |
| 16:33 |
gsams___ |
This issue has beaten me, for now. |
| 16:33 |
bshum |
gsams___: Definitely perplexing. |
| 16:39 |
|
gmcharlt joined #evergreen |
| 16:43 |
|
mtcarlson joined #evergreen |
| 16:43 |
mrpeters |
hey guys, using cap max fines at item price library setting. item price is 29.99. max fines get capped at 30.00. tons of cases like this, where it rounds up to the nearest whole dollar....is this intented? running 2.4 |
| 16:43 |
mrpeters |
but im told it happens in 2.1 as well |
| 16:45 |
rfrasur |
and that $30 isn't including default reprocessing fee? only item price is being added into billings? |
| 16:45 |
|
kbeswick joined #evergreen |
| 16:45 |
mrpeters |
yeah |
| 16:45 |
mrpeters |
they add the processing fee manually if an item is 6 months overdue |
| 16:47 |
|
goooood joined #evergreen |
| 16:47 |
rfrasur |
if it was a spreadsheet, I'd know why it was doing it. obv, it's not. It def should NOT do that though. If the only thing that's going to billing is the item price, with no other fines/fees, it should be $29.99 w/o rounding. |
| 16:47 |
Dyrcona |
mrpeters: Fines are charged in units of the fine rate, ie. 25 cents or whatever. |
| 16:48 |
mrpeters |
hmm |
| 16:49 |
Dyrcona |
rfrasur: He's asking about fines, not lost billing. |
| 16:49 |
rfrasur |
Dyrcona, that wouldn't be a fine though. It'd be a replacement cost. |
| 16:49 |
tsbere |
as Dyrcona has said, if the item price isn't an exact multiple of the fine rate it will go until the fines are over or equal to the item price |
| 16:49 |
mrpeters |
yeah, seems plausible |
| 16:49 |
rfrasur |
oh, I see. |
| 16:49 |
|
mcooper_ joined #evergreen |
| 16:49 |
goooood |
dangit freenode, stop being DDoS'd |
| 16:49 |
rfrasur |
pardon...was thinking re: fines capping at item price. |
| 16:49 |
|
graced joined #evergreen |
| 16:49 |
tsbere |
So if you are fining $1/day you will always get the next dollar amount over the item price, if it is $5/day you will get the next $5 interval, but $0.25/day will allow less than a dollar amounts to be the stop point |
| 16:49 |
|
eby joined #evergreen |
| 16:49 |
rfrasur |
s/was/wasn't |
| 16:49 |
* goooood |
== eeevil |
| 16:49 |
mrpeters |
yeah, gotcha....so it can't charge a $0.24 fine to make $29.99 |
| 16:49 |
tsbere |
right |
| 16:49 |
|
berick_ joined #evergreen |
| 16:49 |
tsbere |
Though someone wanted to change that |
| 16:49 |
goooood |
eeevil's a ghost and there's no nickserv :( |
| 16:50 |
rfrasur |
($30 fine cap! wow) |
| 16:50 |
tsbere |
I thought nickserv was back? |
| 16:50 |
bshum |
mrpeters: Well, not until 2.4. |
| 16:50 |
|
pinesol_green` joined #evergreen |
| 16:50 |
tsbere |
apparently nickserv died again |
| 16:50 |
goooood |
maybe just hates me |
| 16:50 |
bshum |
In 2.4, I think there was a new patch added to handle uneven recurring fine to max ratios. |
| 16:51 |
bshum |
goooood: Quassel was really pissy with me all morning during the outages; turns out that with SASL auth enabled, it died rather than try to connect properly. |
| 16:51 |
bshum |
Drove me nuts. |
| 16:51 |
bshum |
I ended up turning off auth while nickserv was wigging out. |
| 16:51 |
|
Lunchb0x joined #evergreen |
| 16:51 |
dbs |
goooood: that mozilla printing leak - are we sure that happens in Firefox 14 all by itself? Maybe we're aggravating things by dynamically generating the page to print, and then accidentally holding onto references that keep those pages around in memory. |
| 16:52 |
goooood |
bshum: IIRC, jeff did the "stop at max, even if it's a partial fine" stuff a while back |
| 16:53 |
jeff_ |
twas not me, but may have been jeffdavis. |
| 16:53 |
goooood |
dbs: I'm not 100%, but my understanding is that, yes, printing static pages leaks. you don't print much in a browser, but a "cash register"... |
| 16:53 |
bshum |
I think it was jeffdavis |
| 16:53 |
bshum |
"awhile back" is relative :P |
| 16:53 |
goooood |
jeffdavis++ |
| 16:53 |
goooood |
in that case |
| 16:53 |
goooood |
bshum: well, it was first offered several versions ago, IIRC |
| 16:53 |
bshum |
goooood: True :( |
| 16:55 |
rfrasur |
lol, nice |
| 16:55 |
pinesol_green |
Oops |
| 16:55 |
pinesol_green |
LOL |
| 16:55 |
* rfrasur |
laughs |
| 16:55 |
rfrasur |
just think of the fun you could have had |
| 16:55 |
gsams |
nice |
| 16:55 |
bshum |
That's better. |
| 16:56 |
bshum |
LOL |
| 16:57 |
|
zerick joined #evergreen |
| 16:58 |
bshum |
To summarize for channel logs |
| 16:59 |
bshum |
Worked with gsams a bit more and it turns out the holds for the items that were renewing weren't being set to fulfill because of blocks on the patron who placed the hold. |
| 16:59 |
bshum |
Their standing_penalty entry was set to block on CIRC|FULFILL|HOLD|CAPTURE|RENEW |
| 16:59 |
dbs |
heh |
| 16:59 |
bshum |
So, that leads to a hold that looks good and working, but actually isn't. |
| 16:59 |
|
RoganH joined #evergreen |
| 17:00 |
bshum |
And thus, no hold requiring the copy, so the copy renews happily. |
| 17:00 |
bshum |
Fixing the patron with the hold put back the blocking event. |
| 17:01 |
bshum |
And I assume that removing FULFILL|HOLD out of those block types would target the hold properly as well. |
| 17:01 |
bshum |
gsams++ #fighting the good fight |
| 17:02 |
|
jeffdavis joined #evergreen |
| 17:03 |
dbs |
Hmm. Our technicians print spine labels all day and seem to be fine. Maybe it's the volume of the content being printed, or maybe a fundamental difference between spine label and receipt printing |
| 17:03 |
bshum |
eeevil: e902bba4ca0dbb845abb7d7aac47cc5bb91d11f9 |
| 17:03 |
pinesol_green |
[evergreen|Jeff Davis] truncate fines to max fine amount (LP#1145284) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e902bba> |
| 17:03 |
bshum |
jeffdavis++ |
| 17:03 |
bshum |
mrpeters --^ |
| 17:04 |
|
jdouma_ joined #evergreen |
| 17:04 |
bshum |
That's the feature that was added for 2.4 to truncate the fines to fit the max fine. |
| 17:04 |
Dyrcona |
bshum: Yeah, we took those two out of most of our standing penalty blocks. |
| 17:05 |
mrpeters |
thanks bshum |
| 17:05 |
Dyrcona |
It's a good chance to say to the patron, "I'd like to let you have this, but first you have to pay these fines...." |
| 17:05 |
bshum |
Dyrcona: Same for our setup as well. We figured it was better to have holds fill and poke patrons to come in and pay off their fines, etc. |
| 17:05 |
bshum |
Dyrcona++ :) |
| 17:05 |
Dyrcona |
:) |
| 17:06 |
rfrasur |
Dyrcona++ |
| 17:06 |
rfrasur |
bshum++ |
| 17:06 |
rfrasur |
fines_paid++ |
| 17:06 |
Dyrcona |
everybody++ |
| 17:06 |
rfrasur |
and_their_brother++ |
| 17:06 |
* gmcharlt |
always shivers a bit whenever I calculate the total fine balance being brought over during a migration |
| 17:06 |
gmcharlt |
it's so very often rather high |
| 17:07 |
|
eby_ joined #evergreen |
| 17:07 |
jeffdavis |
oh hey karma ... om nom nom |
| 17:07 |
rfrasur |
those of us not having to deal with migrations very intimately anymore prefer to forget them altogether :p |
| 17:08 |
gsams |
bshum++ |
| 17:14 |
|
berick joined #evergreen |
| 17:14 |
|
bradl_ joined #evergreen |
| 17:18 |
|
mmorgan1 left #evergreen |
| 17:27 |
|
gsams joined #evergreen |
| 17:27 |
pinesol_green |
[evergreen|Pasi Kallinen] Clean up the account summary table HTML. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=15d7de9> |
| 17:27 |
pinesol_green |
[evergreen|Remington Steed] Restore look of acct summary table - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aaec1bd> |
| 17:30 |
rfrasur |
I have a question about the translation in launchpad - if the item to be translated reads (for instance) "Are you sure you are ready to charge %1 to your credit card?" and the developer's note says "(money(ctx.fines.balance_owed))," does the translator need to do anything with that note unless it explicitly says "put a space here" or whatever? |
| 17:31 |
rfrasur |
and the translator would just leave the %1 in place? |
| 17:32 |
dbs |
rfrasur: the translator gets to put the %1 wherever it makes sense for it to appear in their translation |
| 17:32 |
dbs |
the note is a hint as to what content is going to replace the placeholder %1 |
| 17:32 |
rfrasur |
dbs: right...but I'm assuming that the developer's note refer to what exactly the %1 calls? |
| 17:33 |
rfrasur |
so, it's just fyi so that the translator knows to make it make sense |
| 17:33 |
dbs |
rfrasur: right |
| 17:33 |
rfrasur |
dbs++ # thanks |
| 17:34 |
|
finnx left #evergreen |
| 17:36 |
|
CarrieC left #evergreen |
| 17:37 |
remingtron |
paxed: I'm learning about the i18n components and wondered how much of this page is correct. Maybe you could look at it when you have a change? http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:customizations:i18n |
| 17:37 |
remingtron |
s/change/chance/ |
| 17:39 |
|
stevenyvr2 joined #evergreen |
| 17:44 |
rfrasur |
please remind me because I don't be able to think in that direction. Author notes...about the author or by the author? |
| 17:47 |
rfrasur |
notes ABOUT...ahah |
| 17:48 |
|
mrpeters left #evergreen |
| 18:02 |
* csharp |
removes and bans "rohaizam" the spammer on Open-ILS-General |
| 18:03 |
rfrasur |
will there be joy in our inbox? |
| 18:03 |
csharp |
and there was great rejoicing |
| 18:10 |
rfrasur |
"blurb?" is there a spanish translation for "blurb? |
| 18:10 |
* rfrasur |
rolls eyes |
| 20:22 |
|
kmlussier joined #evergreen |
| 20:46 |
pinesol_green |
[evergreen|James Fournie] Server maintenance message via Apache config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=56a63f0> |
| 20:56 |
bshum |
dbs: Hmm, that commit reintroduced "your account" vs. "my account" messages. |
| 20:57 |
bshum |
in topnav.tt2 |
| 20:57 |
dbs |
Indeed. |
| 20:58 |
dbs |
also a whole new eg.conf |
| 20:58 |
* dbs |
beats head against keyboard |
| 20:58 |
bshum |
Oh, missed that too. |
| 20:59 |
dbs |
bah, I totally screwed this commit up. |
| 21:00 |
dbs |
got cute doing "git checkout branchname -- filename" instead of applying the commits to master, then resetting and adding only the changes that I wanted. |
| 21:02 |
dbs |
fixoring.... |
| 21:12 |
dbs |
bshum: you wanna take a look at user/dbs/maintenance_message to see if that restores order to the universe? |
| 21:12 |
bshum |
dbs: Sure, I'll take a look. |
| 21:14 |
dbs |
merci |
| 21:15 |
bshum |
dbs: Looks good to my eyes. I'll get it pushed once I get my other laptop going. |
| 21:16 |
dbs |
thanks |
| 21:20 |
bshum |
All set, thanks dbs! |
| 21:23 |
pinesol_green |
[evergreen|Dan Scott] Revert 56a63f03 and try again - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=117a66a> |
| 21:23 |
pinesol_green |
[evergreen|James Fournie] Server maintenance message via Apache config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e030f7> |
| 21:32 |
dbs |
bshum++ # thank _you_ |
| 21:33 |
jeff_ |
oof. |
| 21:33 |
jeff_ |
good evening. |
| 21:37 |
jeff_ |
our mission, should we choose to accept it, is to improve the billing system in a way that does not make it untenably fragile, and does not break workflows for existing libraries, nor invalidate existing data. |
| 21:41 |
bshum |
As always, if any member of your team is caught or killed, the secretary will disavow all knowledge of your actions. |
| 21:53 |
phasefx |
agent 7 was truncated |
| 21:57 |
jeff |
this "two irc clients" thing is going to need a solution soon. "oh, activity in channel! oh, nevermind, it's me." |
| 21:57 |
phasefx |
quassel? |
| 21:57 |
jeff_ |
that's one, yep. |
| 21:57 |
* phasefx |
is a fan of screen and irssi |
| 21:58 |
jeff_ |
and that's the other. |
| 21:59 |
gsams |
quick question, I apologize for being a bug over and over. |
| 21:59 |
gsams |
Is ISBN search in 2.3.5 setup to search the 024 tag as well? |
| 22:00 |
jeff_ |
not to the best of my knowledge. isbn would be 020. |
| 22:00 |
mcooper |
gsams: w/o checking i'm going to say no -- that doesn't make sense |
| 22:01 |
mcooper |
024 is issn i believe |
| 22:01 |
gsams |
jeff_ & mcooper: this was what I figured was the case. |
| 22:02 |
bshum |
gsams: If you get curious, you can sometimes learn what's being indexed to different metabibs by peeking at config.metabib_field. |
| 22:02 |
bshum |
@marc 024 |
| 22:02 |
pinesol_green |
bshum: A standard number or code published on an item which cannot be accommodated in another field (e.g., field 020 (International Standard Book Number), 022 (International Standard Serial Number) , and 027 (Standard Technical Report Number)). The type of standard number or code is identified in the first indicator position or in subfield $2 (Source of number or code). (Repeatable) [a,c,d,z,2,6,8] |
| 22:02 |
jeff_ |
mcooper: 024 is other identifier, which in most of our data is an isbn (with the requisite indicators/etc) |
| 22:02 |
bshum |
Looks like for us, the most common 024 would likely be UPC |
| 22:02 |
mcooper |
i stand corrected =) |
| 22:03 |
gsams |
bshum: ah I am still getting accustomed to the tables. I really should just sit down and look through them shouldn't I haha |
| 22:03 |
jeff_ |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;h=23df6d3a92f3f6759c1ba2b4318d7daf9926b384;hb=refs/heads/tags/rel_2_3_5 confirms that the stock isbn index in 2.3.5 uses the following xpath expression on the marcxml: //marc:datafield[@tag='020']/marc:subfield[@code='a' or @code='z'] |
| 22:03 |
mcooper |
my cataloging knowledge is getting rusty |
| 22:03 |
gsams |
jeff_: Many thanks! |
| 22:03 |
bshum |
gsams: Eh, you get the hang of it eventually ;) |
| 22:04 |
gsams |
bshum: the more I look at it, the better I'm understanding it |
| 22:04 |
jeff_ |
mcooper: i misspoke above, s/in most of our data is an isbn/in most of our data is a upc/ |
| 22:05 |
bshum |
This is a weird night. It's not usually this active this late :P |
| 22:06 |
mcooper |
http://www.oclc.org/bibformats/en/0xx/024.html -- used to use this site a lot once upon a time |
| 22:06 |
bshum |
gsams: Aha, your numeric search dropdown in TPAC doesn't have UPC in it. I guess that's something we put custom in our TPAC for Biblio |
| 22:06 |
gsams |
I work til 9 PM here on Wednesdays |
| 22:07 |
gsams |
bshum: I was just looking into that |
| 22:07 |
gsams |
I will probably be adding that in shortly |
| 22:07 |
bshum |
gsams++ |
| 22:08 |
jeff_ |
we have a tadl schema in our database, mostly for custom reporting things. i find myself idly wondering what bshum uses, since "biblio" is taken. :-) |
| 22:09 |
bshum |
jeff_: In the beginning, dbs set us up with "custom_views" during his training course. So I stuck a bunch of random things in there once upon a time. |
| 22:09 |
bshum |
Nowadays, we just do the whole name... "bibliomation" |
| 22:09 |
jeff_ |
logical, in both cases. :-) |
| 22:09 |
bshum |
(not very original) |
| 22:14 |
jeff |
so with our new phone system, dial plans can make http calls. i'm considering an interface for at least our circulation department whereby the inbound call results in an account lookup with options for the most common things people call about -- renewals, sending password reset via email, etc. |
| 22:15 |
jeff |
has anyone here experimented with similar? |
| 22:18 |
jeff |
in some spot checking, the majority of phone numbers inbound to that department retrieve an active patron or family. |
| 22:18 |
jeff |
(actually, every one i've tried) |
| 22:22 |
jeff |
i'm undecided on if this would be more or less useful than a grpl-like phone renewal system. |
| 22:23 |
jeff |
potentially more friendly, and not limited to renewals. |
| 22:24 |
jeff |
could be complimentary. |
| 22:25 |
jeff |
and i'm monologuing. :-) |
| 22:26 |
|
rfrasur joined #evergreen |
| 22:28 |
bshum |
jeff: To stop that, no I haven't experimented with similar. Though that does sound interesting :D |
| 22:28 |
gsams |
jeff:I would say something, but I know nothing of it |
| 22:28 |
* bshum |
goes back to thinking about sleep. |
| 22:35 |
|
Pibbits joined #evergreen |
| 22:35 |
eby_ |
jeff: glanced at similar with our sip and/or twilio but obv a bit off from doing anything |
| 22:38 |
|
Simon21 joined #evergreen |
| 22:40 |
rfrasur |
@wunder 47353 |
| 22:40 |
pinesol_green |
rfrasur: The current temperature in APRSWXNET Liberty IN US, Liberty, Indiana is 73.9°F (9:55 PM EDT on July 10, 2013). Conditions: Clear. Humidity: 80%. Dew Point: 66.2°F. Pressure: 29.95 in 1014 hPa (Rising). |
