| Time |
Nick |
Message |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
graced joined #evergreen |
| 07:57 |
|
mrpeters joined #evergreen |
| 07:58 |
|
graced joined #evergreen |
| 08:00 |
|
rjackson_isl joined #evergreen |
| 08:10 |
|
collum joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 08:30 |
Dyrcona |
@tea |
| 08:30 |
* pinesol_green |
brews and pours a pot of Home, and sends it sliding down the bar to Dyrcona (http://ratetea.com/) |
| 08:30 |
Dyrcona |
Heh. Guess pinesol_green's tea pot is on the fritz, too. |
| 08:31 |
Dyrcona |
I should have made my own this morning, 'cause the McDonald's still doesn't have a working tea pot. |
| 08:31 |
Dyrcona |
They got the replacement but it has a different kind of plug, so they have to the outlet/circuit changed. |
| 08:35 |
|
ericar joined #evergreen |
| 08:39 |
kmlussier |
@tea |
| 08:39 |
* pinesol_green |
brews and pours a pot of None, and sends it sliding down the bar to kmlussier (http://ratetea.com/tea/teehaus-bachfischer/bio-pao-chung-pouchong/7609/) |
| 08:40 |
Dyrcona |
Still busted. :) |
| 08:40 |
kmlussier |
I think I would have preferred Home over None. |
| 08:40 |
Dyrcona |
:) |
| 08:40 |
kmlussier |
That's okay. It's a coffee kind of day anyway. |
| 08:40 |
kmlussier |
@coffee |
| 08:40 |
* pinesol_green |
brews and pours a cup of Colombia Tolimas, and sends it sliding down the bar to kmlussier |
| 08:40 |
Dyrcona |
On a different note there has been a hawk hanging out by one of the doors to our offices over the past couple of days. |
| 08:43 |
kmlussier |
Oh nice! The question I was planning to ask here this morning is no longer an issue. I love it when problems resolve themselves over night. |
| 08:45 |
|
mmorgan1 joined #evergreen |
| 08:45 |
Stompro |
Good morning, is it unusual for a cstore drone to be using 1.8GB of ram? |
| 08:48 |
tsbere |
Thay may depend on what it has been asked to retrieve. |
| 08:48 |
tsbere |
er, that |
| 08:48 |
* tsbere |
should probably have breakfast before typing |
| 08:49 |
Stompro |
tsbere, So cstore caches info? I've got two cstore drones using 1.8GB, and have been since I noticed yesterday afternoon. So I don't think there is an active request, would they keep the cached data for a while? |
| 08:50 |
tsbere |
Stompro: I was thinking more along the lines of "it probably has to store things in memory before it can return them" due to the various things it does to the result set and all. |
| 08:50 |
tsbere |
And sometimes things don't give memory up right away. |
| 08:51 |
Dyrcona |
Wouldn't be surprised if you see connection failures for those two drones' pids in your logs. |
| 08:51 |
Dyrcona |
I wager they're off in lala land. |
| 08:52 |
Stompro |
tsbere, thanks. |
| 08:52 |
Stompro |
Dyrcona, I'll check the logs, thanks for the suggestion. |
| 08:55 |
|
jwoodard joined #evergreen |
| 08:59 |
|
akilsdonk joined #evergreen |
| 08:59 |
Stompro |
Dyrcona, It seems to be related to loading authority data yesterday morning.. but no failure messages. |
| 09:00 |
|
Shae joined #evergreen |
| 09:23 |
Stompro |
Dyrcona, I dumped the memory for one of the cstore drones, and it contains copies of all the authority records it was asked to store. Memory leak? |
| 09:24 |
|
maryj joined #evergreen |
| 09:24 |
Dyrcona |
Either that or Perl's GC is very lazy. |
| 09:24 |
tsbere |
cstore is a c app, not a perl app |
| 09:25 |
|
yboston joined #evergreen |
| 09:26 |
Stompro |
I wouldn't think that doing an authority record store is much different than doing any other type of record store, oils_cstore.c seems pretty general. I would think a memory leak would have caused problems by now. |
| 09:29 |
mmorgan1 |
jeff: Been looking at your patron registration form at https://www.tadl.org/tadleg/newuser/register/ |
| 09:29 |
mmorgan |
Is yours based on the stock tt2 file, or are you using something different? |
| 09:29 |
jeff |
heh. we were just talking about how dated that was. |
| 09:29 |
jeff |
no, ours pre-dates evergreen's ability to accept pre-registrations. |
| 09:30 |
jeff |
it's a django app written in python. |
| 09:31 |
jeff |
it used to have a number of features like printing out a paper registration form for a signature, support for auto-creation of an actual evergreen account if certain criteria were met, and staff approval of the rest, patrons getting an email and being able to bring a barcode (or their license) in with them if they did the reg from home... |
| 09:31 |
mmorgan |
Ah, interesting. |
| 09:32 |
jeff |
nowadays, it just submits the data to Evergreen as a pending patron, and also (depending on user selection) submits their email address via the MailChimp api to be subscribed to the library's monthly newsletter. |
| 09:32 |
jeff |
(we got rid of paper forms long ago, etc.) |
| 09:32 |
mmorgan |
To me it looks less dated than the stock one ;-) |
| 09:32 |
jeff |
the majority of new users in the library sign up via that page first, then go back to the desk to get an actual card (or have their license put on file) |
| 09:33 |
mmorgan |
That's what our libraries are looking to use it for. We're running into some issues with the stock one, though. |
| 09:33 |
jeff |
i suspect that the bulk of use outside the library is actually patrons who already have an account and are either logging in for the first time or are just in need of a password reset and are in the wrong place. |
| 09:33 |
jeff |
but i haven't measured that. |
| 09:34 |
mmorgan |
Using the back button, we can see the previous data that had been entered in the form. |
| 09:35 |
mmorgan |
Yours nicely clears that info. |
| 09:35 |
csharp |
quick question - we enabled Google Analytics in the OPAC yesterday, and it worked fine in all the browsers we tested, but we got mixed secure/insecure content warnings in the staff client (until we re-disabled it). Do others see that? How do you handle it? |
| 09:36 |
jeff |
csharp: pretty sure recent commit disables it in the staff client. |
| 09:36 |
tsbere |
csharp: That probably has to do with the oils protocol bit in the staff client for faking out "remote xul" and all. |
| 09:36 |
mmorgan |
lp 1466201 |
| 09:36 |
pinesol_green |
Launchpad bug 1466201 in Evergreen "Google Analytics should not be enabled in the staff interface" (affected: 1, heat: 6) [Wishlist,Fix committed] https://launchpad.net/bugs/1466201 |
| 09:37 |
bshum |
csharp: https://bugs.launchpad.net/evergreen/+bug/1452883 |
| 09:37 |
pinesol_green |
Launchpad bug 1452883 in Evergreen 2.8 "prevent staff client warnings with Google Analytics" (affected: 1, heat: 6) [Undecided,Fix released] |
| 09:37 |
csharp |
jeff++ tsbere++ bshum++ # thanks for the info! |
| 09:38 |
bshum |
That's the bug that fixed the errors in supported versions. The bug mmorgan linked to is the removal during 2.9. |
| 09:39 |
csharp |
phasefx++ # fixin' stuff |
| 09:39 |
jeff |
csharp: backport the removal -- it's a simple !ctx.is_staff conditional. |
| 09:39 |
csharp |
mmorgan: oh - I missed yours |
| 09:39 |
csharp |
mmorgan++ |
| 09:39 |
* bshum |
agrees, remove it |
| 09:40 |
csharp |
kmlussier++ |
| 09:40 |
csharp |
everybody++ |
| 09:40 |
csharp |
@oprah karma |
| 09:40 |
pinesol_green |
csharp: Leave me alone, I'm busy right now. |
| 09:41 |
jeff |
there are a number of places within evergreen that deal with "hold is available" or "item is on a hold shelf"... |
| 09:41 |
csharp |
pinesol_green: boo |
| 09:41 |
pinesol_green |
csharp: Have you tried taking it apart and putting it back together again? |
| 09:41 |
jeff |
the good news: they're mostly consistent! |
| 09:41 |
jeff |
anyone have ideas of places i should look? so far, i have: |
| 09:41 |
jeff |
Browse Hold Shelf in staff client (web and xul); HoldIsAvailable A/T check |
| 09:41 |
* csharp |
remembers opening a bug about hold counts in the summary not matching the list |
| 09:42 |
jeff |
; TPAC Available holds; SIP Available holds; Staff client "ready for pickup" count when viewing patron account (web and xul) |
| 09:42 |
jeff |
csharp: have that bug handy? |
| 09:42 |
csharp |
https://bugs.launchpad.net/evergreen/+bug/1427664 |
| 09:42 |
pinesol_green |
Launchpad bug 1427664 in Evergreen "hold summary count/"Ready for pickup" holds list status do not always match" (affected: 1, heat: 6) [Undecided,New] |
| 09:42 |
csharp |
just found it |
| 09:43 |
jeff |
underlying good news: i didn't need to list (tpac and jspac) above -- and soon i won't have to list (xul and web) for the staff client, either! ;-) |
| 09:43 |
tsbere |
jeff: For varying definitions of "soon" I assume |
| 09:44 |
jeff |
tsbere: *nod* |
| 09:47 |
jeff |
csharp: i'm going to go out on a limb and assume that you don't have the hold in question in the state that it was in at the time of your internal ticket? |
| 09:49 |
jeff |
hrm. why do i have bug 632381 open in a tab? |
| 09:49 |
pinesol_green |
Launchpad bug 632381 in Evergreen "remove offline-config.pl" (affected: 1, heat: 6) [Low,Opinion] https://launchpad.net/bugs/632381 |
| 09:51 |
* jeff |
shrugs |
| 09:51 |
jeff |
it's a mystery! |
| 09:56 |
bshum |
wow that's an old bug too. |
| 09:57 |
jeff |
bshum: low + opinion = bottom of the pile! |
| 09:57 |
bshum |
The "opinion" part would definitely hide it from regular LP views. |
| 09:58 |
|
Christineb joined #evergreen |
| 09:58 |
Dyrcona |
Won't fix? ;) |
| 09:58 |
bshum |
Hehe |
| 09:59 |
jeff |
26 holds with a capture_time but null current_copy... 2 holds with a shelf_time and frozen is true... |
| 10:00 |
jeff |
0 holds with hold_type of 'C' where current_copy <> target, though... :-) |
| 10:06 |
Dyrcona |
Stompro: Speaking of memory use, top says one of my VMs has 0.011t of resident memory. I guess 11g would be too high of a number. :) |
| 10:07 |
bshum |
Heh |
| 10:08 |
Stompro |
Dyrcona, that format does leave lots of room to grow. |
| 10:13 |
pinesol_green |
[evergreen|Galen Charlton] LP#1487143: remove legacy_script_support from example SIP config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6260738> |
| 10:14 |
bshum |
gmcharlt: I pushed along that changeset, but longer-term I think we do have to reconcile the oils_sip.xml.example vs. sipconfig.xml that ships with SIPServer. |
| 10:15 |
* bshum |
references https://bugs.launchpad.net/evergreen/+bug/1399790 |
| 10:15 |
pinesol_green |
Launchpad bug 1399790 in Evergreen "deprecate oils_sip.xml.example" (affected: 1, heat: 6) [Wishlist,Triaged] |
| 10:15 |
* dbs |
is glad we're not running SIP anymore |
| 10:17 |
jeff |
dbs: that means you're running NCIP now, right? |
| 10:17 |
* jeff |
ducks |
| 10:25 |
csharp |
Christineb: hi! long time no hike... so we were discussing bug 1269574 here and your last comment, and were wondering whether it makes sense to open a new bug basically saying that cancelling line items *period* does not delete the bibs/copies created and mark bug 1269574 as a duplicate of that new bug - thoughts? |
| 10:25 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" (affected: 8, heat: 40) [Medium,Confirmed] https://launchpad.net/bugs/1269574 |
| 10:26 |
Christineb |
csharp: I think that sounds reasonable |
| 10:26 |
csharp |
awesome - I'll work up a bug :-) |
| 10:27 |
Christineb |
Thanks csharp Hope all is well with you :) |
| 10:27 |
csharp |
Christineb: yep, right back atcha! |
| 10:30 |
dbs |
jeff: we mothballed our one self-check when it went on the fritz earlier this year |
| 10:30 |
jeff |
dbs: i figured :-) |
| 10:35 |
|
maryj joined #evergreen |
| 10:37 |
|
Shae joined #evergreen |
| 10:40 |
kmlussier |
csharp / Christineb: I think there are some cases where canceling the lineitem does delete the copies. In the PO UI? But, in those cases, it also deletes them for delayed items. |
| 10:41 |
* kmlussier |
would just update the description for the current bug rather than opening a new bug. But I guess it doesn't matter. |
| 10:41 |
csharp |
Christineb: hmm - I found bug 1175740, in which Lebbeous added a fix with a prompt to delete fund debits and copies, but kmlussier wasn't able to reproduce, so the code was never applied |
| 10:41 |
pinesol_green |
Launchpad bug 1175740 in Evergreen 2.4 "Acq: Certain workflows produce orphaned fund debits" (affected: 2, heat: 14) [Undecided,Incomplete] https://launchpad.net/bugs/1175740 |
| 10:43 |
csharp |
kmlussier: this came to me as "there are acq-orphaned copies floating around in the OPAC", so I haven't investigated deeply enough to know when copies/bibs aren't orphaned |
| 10:44 |
csharp |
in any case, I think Lebbeous's "prompt the user for copy deletion" approach is the best |
| 10:44 |
kmlussier |
Yes, I did some testing around those a while back and reported my results on bug 1269574. Not sure if the behavior has changed since then. |
| 10:44 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" (affected: 8, heat: 40) [Medium,Confirmed] https://launchpad.net/bugs/1269574 |
| 10:45 |
csharp |
kmlussier: oh - I inexplicably missed your comment on that bug :-/ |
| 10:47 |
kmlussier |
In re-reading bug 1175740, it looks like the initial issue reported was that fund debits stuck around if the lineitem was deleted without first being canceled. AFAIK, you can no longer delete lineitems in the UI, which is why I wasn't able to replicate it. |
| 10:47 |
pinesol_green |
Launchpad bug 1175740 in Evergreen 2.4 "Acq: Certain workflows produce orphaned fund debits" (affected: 2, heat: 14) [Undecided,Incomplete] https://launchpad.net/bugs/1175740 |
| 10:47 |
kmlussier |
Of course, we want people to be able to delete lineitems in the UI, but only when they are in the "correct" state. Correct being pending or truly canceled. |
| 10:47 |
kmlussier |
I think that's on another bug. |
| 10:48 |
kmlussier |
So many bugs |
| 10:50 |
Christineb |
We have seen issues very similar to 1175740 - orphaned fund debits - I have it on my list to do additional testing and add notes |
| 10:50 |
Christineb |
so many bugs |
| 10:52 |
csharp |
yep |
| 10:53 |
kmlussier |
Christineb / csharp: If you can identify another scenario that creates orphan debits, let me know. I'll be happy to re-test an set the bug back to confirmed. :) |
| 10:54 |
kmlussier |
I'll also check back with my acq people to see if they are still seeing the problem. |
| 10:54 |
kmlussier |
I think one of our sites was the original source of that bug report from senator. But I could be mistaking it with another one because...so many bugs. |
| 10:55 |
kmlussier |
Speaking of so many bugs, I've been negligent on scheduling a Bug Squashing Day. We usually do one between beta and the full release. |
| 10:55 |
Christineb |
I think for us - when a line item is cancelled/delayed but then later received, an orhphan debit is created for the encumbrance - so we have a fund_debit where encumbrance = false and a fund_debit where encumbrance = true |
| 10:56 |
kmlussier |
Ah, that makes sense. |
| 10:56 |
Christineb |
I will test and add comments |
| 11:09 |
* kmlussier |
just spent 20 minutes typing up an email with a question to the dev list only to realize what the answer was as she was about to hit 'send.' |
| 11:09 |
dbs |
kmlussier: sounds like a blog post to me! |
| 11:09 |
kmlussier |
I think it would have taken less time if I had just talked to a rubber duck. |
| 11:09 |
jboyer-isl |
kmlussier would prefer that she realize the answer after hitting send? ; |
| 11:09 |
jboyer-isl |
;) |
| 11:10 |
kmlussier |
jboyer-isl: Fair point. |
| 11:10 |
bshum |
kmlussier: Remind me to give you a penguin on Friday. |
| 11:11 |
kmlussier |
bshum: Do penguins work as well as rubber ducks? |
| 11:11 |
bshum |
It's not the same as a rubber duck, but I think they're cuter. |
| 11:11 |
* mmorgan |
loves it when a library staff member calls in with a problem and figures it out by the time they finish explaining it :) |
| 11:12 |
jeff |
i have literally answered the phone to hear "hi! oh! nevermind, i figured it out!" |
| 11:18 |
kmlussier |
On the plus side, most of the details in the email can be reused as explanation for people here on apostrophes, normalization, stemming, etc. |
| 11:24 |
dbs |
kmlussier++ |
| 11:24 |
dbs |
seriously, turn it into a blog post :0 |
| 11:24 |
mmorgan |
Apostrophes, Normalization and Stemming, oh my! :) |
| 11:24 |
jeff |
seconding dbs on "sounds like a blog post" |
| 11:24 |
mmorgan |
kmlussier++ |
| 11:24 |
|
akilsdonk joined #evergreen |
| 11:24 |
kmlussier |
dbs: I might do that. But I actually have a follow-up question for you now. |
| 11:26 |
kmlussier |
When you created search_normalize, I now you did it to handle words like l'histoire so that searchers could find the term entering either l'histoire or histoire. |
| 11:27 |
kmlussier |
But if somebody enters the search term l'histoire, and there are records in the database with histoire, I'm guessing they won't be able to retrieve those records unless there is some other word that begins with l' |
| 11:29 |
kmlussier |
That's what I generally find when doing searches with apostrophe s. Finnegans wake is an expample I like to use because many users think it has an apostrophe. But they won't retrieve the record because the system isn't finding a match for 's'. |
| 11:29 |
kmlussier |
expample. That should be a real world. |
| 11:30 |
dbs |
And also because PostgreSQL's full-text search Snoball parser doesn't recogize "Finnegans" as a plural of "Finnegan" |
| 11:31 |
dbs |
Oh, I see, you mean they search for "Finnegan's wake", search normalize turns that into "Finnegan s wake" |
| 11:32 |
kmlussier |
dbs: Yeah. Snoball is storing both finnegan and finnegans in the index vector. But I think it is being normalized at search time to "finnegan s wake." |
| 11:33 |
jeff |
localhost kernel[0]: ACPI: System Finnegan State [S0 S3 S4 S5] (Finnegan S3 Wake) |
| 11:33 |
dbs |
So do you propose that search_normalize should strip "'s" entirely? Or concatenate it and hope that snoball recognizes it as a pluralization and it just happens to do the right thing in that particular instance? |
| 11:33 |
kmlussier |
NACO Normalizers handles finnegans wake so that it can be entered both with and without the apostrophe. But then we have trouble with l'histoire |
| 11:34 |
kmlussier |
dbs: I don't think I'm proposing anything yet. I'm just trying to understand it and see if it's also a problematic for other uses of an apostrophe. |
| 11:35 |
dbs |
oh wait, you're guessing or you're sure that users won't be able to retrieve records with "histoire" unless there is some other word that begins with "l'"? |
| 11:36 |
kmlussier |
dbs: I'm not sure. That's why I was asking you. I thought you may be more likely to encounter the issue in the wild. |
| 11:36 |
dbs |
Sorry, travelling too far back in time to revisit all of these decisions on the basis of uncertainty |
| 11:36 |
dbs |
We still have the case that we return zero hits for searches like "the", "a", and "Canada" because otherwise search spins forever, so I've pretty much given up on trying to address search corner cases |
| 11:37 |
kmlussier |
I hadn't thought of stripping the s entirely. That might work. We also have problems where records are being retrieved because some other word has the apostrophe s. |
| 11:38 |
dbs |
Trying to approximate google/yahoo/bing search with auto spell corrections given our current foundation is probably not going to be too fruitful |
| 11:38 |
kmlussier |
Yes, well, I think we have a lot of users who enter the apostrophe when they shouldn't or don't enter it when they should, so it's a question that comes up on a fairly regular basis. |
| 11:39 |
dbs |
And while it might work for suffix "'s" because of the fortunate English pluralization effect of the Snoball parser, I doubt the same sort of rule will work for "'t'" as in "isn't" or "wouldn't", and other similar issues |
| 11:40 |
dbs |
So sure, search_normalize might be able to be tweaked for that one particular case, and it might help a bit I guess |
| 11:47 |
dbs |
then again, if "wouldn't" became "wouldnt" consistently, that might be better |
| 11:47 |
dbs |
If "O'Hara" became "OHara" consistently, that might be better too |
| 11:48 |
dbs |
But "l'histoire" becoming "lhistoire" would suck |
| 11:50 |
kmlussier |
dbs: Yeah. I think NACO normailzer works really well for English, but our database covers titles in many languages. |
| 11:51 |
kmlussier |
I noticed this comment from miker https://bugs.launchpad.net/evergreen/+bug/1187433/comments/8 from a couple of years ago that proposed implementing multi-lingual stemming support and returning to NACO as a default. |
| 11:51 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 22) [High,Fix released] |
| 11:51 |
kmlussier |
Don't know how effective that would be. |
| 11:52 |
kmlussier |
Anyway, I think I have a good handle on how we're currently handling apostrophes, so I'm a lot further than I was yesterday. Thanks for your thoughts dbs! |
| 11:52 |
kmlussier |
And +1 to speed improvements so we no longer return zero hits for "the". |
| 11:56 |
dbs |
I'm tempted to suggest stopwords for single letters as a partial solution, but then that probably screws up exact searches (memory is fuzzy on that) |
| 12:04 |
dbs |
kmlussier: ugh, that whole bug... |
| 12:05 |
kmlussier |
dbs: Sorry to send you there. :( |
| 12:06 |
kmlussier |
There are many bugs where I just cringe at the thought of re-reading the history. Fortunately, that's not one of them. |
| 12:15 |
gmcharlt |
dbs++ |
| 12:19 |
Stompro |
Does floating not happen if the item can fill a hold at the location it is checked in at? It looks like in Circulate.pm http://goo.gl/s2UOBt that the item only floats if it needs to transit home. |
| 12:24 |
|
buzzy joined #evergreen |
| 12:28 |
kmlussier |
Stompro: Sorry, we don't use floating collections (yet), but that would be my expectation using default holds behavior. Evergreen basically wants to keep it at the checkin library if there is a hold to fill, unless you've changed the Best Holds Sort Order. |
| 12:29 |
kmlussier |
Stompro: Maybe if you change the Best Holds Sort Order to always send the hold home if there is one to fill? I don't know how that would interact with floating collections. Also, I think it would only apply if that home location has a hold to fill. |
| 12:32 |
Stompro |
kmlussier, thanks, I'm trying to figure out how to give capture priority only to capture locations in the same system as the item. hprox would almost work, if the item floated to the checking location first, before starting to fill holds, and if a change was reverted that changes hprox from using cp.circ_lib to acn.owning_lib. |
| 12:33 |
bshum |
Don't forget the library setting for how long to wait before holds go home. |
| 12:33 |
bshum |
In addition to using best-sort order for holds go home. |
| 12:33 |
kmlussier |
bshum: I was referring to the setting that always sends the hold home. No wait. |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:35 |
bshum |
Setting that option in the library settings doesn't affect things I thought until you altered the best hold sort order too. |
| 12:35 |
bshum |
Or maybe I'm getting those two things confused. |
| 12:36 |
Stompro |
I don't really want the holds to go home though. |
| 12:36 |
Stompro |
Where home=owning location. |
| 12:36 |
|
bmills joined #evergreen |
| 12:36 |
kmlussier |
Stompro: You want them to go home where home=circulation library? |
| 12:39 |
Stompro |
Yes, that would get them back to the last location they floated to... but when they go to another location, the circ_lib isn't updated to that location until all the holds are filled, at which point it doesn't matter anymore. |
| 12:40 |
bshum |
How are you deciding floating? |
| 12:40 |
bshum |
I would expect the item to change to be the given circ lib it's checked in at |
| 12:40 |
bshum |
And if it's there, it'll start doing hold fulfillment |
| 12:41 |
* bshum |
doesn't remember how floating groups work though. |
| 12:42 |
bshum |
It's not just plain true/false anymore right? |
| 12:42 |
Stompro |
bshum, It looks like the floating doesn't happen unless the item is set in transit to go home, that is the point where the ability to float is checked and the circ_lib change is made. |
| 12:43 |
Stompro |
bshum, and if there are no holds. |
| 12:44 |
Stompro |
bshum, floating groups let you specify specific patterns for floating now. |
| 12:54 |
tsbere |
I believe floating only adjusts the circ location *if* the item isn't going to fill a hold. |
| 12:54 |
tsbere |
AKA, it is going to reshelving |
| 12:54 |
tsbere |
And with the "more than just an on/off" floating it also will need to match the floating rules, obviously. |
| 13:06 |
Dyrcona |
yboston: There will be no 2.9-RC tomorrow if your branch is not ready. |
| 13:09 |
yboston |
Dyrcona: Understood. Will try to be done by 3:30 PM today. It is the start of semester so my time is more limited than usual |
| 13:10 |
Dyrcona |
No pressure. :) |
| 13:10 |
yboston |
Dyrcona: I am really enjoying learning a bunch of stuff I did not know how to do up to now |
| 13:10 |
yboston |
Dyrcona: any quick feedback on the commits as they stand so far? |
| 13:11 |
Dyrcona |
yboston: Not at this time, no. I'm a bit busy, too. |
| 13:12 |
yboston |
Dyrcona: no worries |
| 13:12 |
Dyrcona |
I don't mind postponing or canceling the RC, by the way. I really mean it when I say take your time. |
| 13:15 |
jeff |
"here's this thing! it doesn't work well, but it's on time!" |
| 13:16 |
yboston |
Dyrcona: thanks for the clarification. I worked late last night so I would have time this afternoon to work on cleaning up my code |
| 13:16 |
dbs |
well, the idea of time-based releases is that it should always work well, and that cutting a release is relatively arbitrary; but realistically, yeah, fit and finish of release notes etc are worth spending some time on :) |
| 13:16 |
Dyrcona |
yboston++ |
| 13:20 |
mmorgan |
Stompro: Looking back at your questions about floating and holds - Do you really need the items to float? Or do you just want them to fill holds wherever they get checked in? |
| 13:33 |
Bmagic |
Is there a feature request already for penalties for patron groups? One member of the group gets a penalty, should affect the others in the group a configured way? |
| 13:38 |
bshum |
Bmagic: You mean user groups? Rather than profile groups, right? |
| 13:38 |
bshum |
Like families or otherwise related users |
| 13:38 |
* bshum |
doesn't think that sort of penalty exists. |
| 13:39 |
bshum |
And I'm not sure it'd always be something we'd want to have enforced. |
| 13:39 |
bshum |
Meaning sometimes it makes sense, for like kids and parents? |
| 13:39 |
bshum |
But not necessarily in all cases? |
| 13:51 |
|
ericar_ joined #evergreen |
| 13:52 |
bshum |
My kneejerk reaction to the 2.9-beta email question is "did you do an autogen? and apache restart" |
| 13:53 |
kmlussier |
bshum: That was my kneejerk reaction too, but I didn't think I knew what I was talking about. :) |
| 13:54 |
dbs |
autogen was my kneejerkiness too |
| 13:56 |
bshum |
Well, google tells me that every time someone has reported an error like Call to [open-ils.actor.org_tree.descendants.retrieve] failed for session |
| 13:56 |
bshum |
Someone mentions autogen |
| 13:57 |
bshum |
And usually that fixes it. |
| 13:57 |
bshum |
Or apparently oom killage |
| 13:57 |
bshum |
So many threads |
| 14:05 |
csharp |
@who 's knees are jerking? |
| 14:05 |
pinesol_green |
Christineb 's knees are jerking. |
| 14:06 |
Christineb |
haha |
| 14:06 |
csharp |
:-D |
| 14:25 |
Stompro |
mmorgan, We do want the items to float, we want them to stay where they land, if they land at a branch in the same region. I would be fine with them filling holds wherever they are checked in, as long as they are checked in at a branch in the same system. |
| 14:26 |
mmorgan |
Stompro: Gotcha. Just asking because filling holds where they are checked in is default behavior - without involving floating. |
| 14:33 |
|
jlitrell joined #evergreen |
| 14:39 |
Stompro |
mmorgan, The hprox (home proximity? - Owning Lib <=> Pickup Location) is probably the closest we are going to get without modification. We need a new sort fprox (Floating proximity, Capture Lib if float possible, else owning lib <=> Pickup Lib) |
| 14:41 |
bshum |
Hmm, this old bug https://bugs.launchpad.net/evergreen/+bug/1167979, the last comment by berick seems to indicate that maybe the bug was dealt with in two other bugs (both of which are now fix released past 2.8+). So maybe it no longer applies and can be closed out. Or relaunched by someone if they can still confirm issues... |
| 14:41 |
pinesol_green |
Launchpad bug 1167979 in Evergreen "Circulation > Clear Shelf-Expired Holds fails " (affected: 7, heat: 32) [Medium,Confirmed] |
| 14:42 |
* bshum |
makes a note on the bug and removes old series targets. |
| 14:45 |
* bshum |
wandered past it while looking for https://bugs.launchpad.net/evergreen/+bug/1189980 |
| 14:45 |
pinesol_green |
Launchpad bug 1189980 in Evergreen "Clear Shelf-Expired Holds confirmation needed" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 14:45 |
bshum |
Which still seems like a good idea someday :P |
| 14:48 |
Stompro |
Wow, samsung/sprint/ting actually sent out a patch for my Galaxy S3 to fix the stagefright vulnerability, I didn't think that was going to happen. |
| 14:49 |
bshum |
Stompro: That's nice. But aren't you afraid that you're just secretly getting new code that'll allow them deeper access to your... wait, no, stopping my paranoid rants. |
| 14:51 |
Stompro |
bshum, bug fixes have never ever created new bugs before, so I think I'm safe. |
| 14:51 |
bshum |
that's cool. I like what I read about Ting. |
| 14:52 |
bshum |
If I wasn't living out in the middle of nowhere in the woods, I would really like to consider other service providers :( |
| 14:53 |
Bmagic |
bshum: yes, user groups. The usrgroup column in actor.usr. I dont think Evergreen handles it currently and I was thinking about submitting a feature request but I didn't want to be redundant |
| 14:53 |
kmlussier |
My son used ting for a while, but his current phone doesn't work with it. I liked it. |
| 14:53 |
Stompro |
$24 a month for two phones is pretty good, I also like ting. |
| 14:54 |
bshum |
Bmagic: Not that I'm aware of, but let's say there's lots of old LP tickets around and maybe sometime is eluding my memory. |
| 14:54 |
kmlussier |
I wonder if any sites intentionally use the "Clear Shelf-Expired Holds" menu option. When I say intentional I mean they might actually use one of the other methods if they knew they were available. |
| 14:54 |
* kmlussier |
likes simply removing dangerous options from the client. |
| 14:55 |
kmlussier |
Like the "Transfer All Holds" option. |
| 14:55 |
* bshum |
wants to push the shiny button. |
| 14:56 |
gsams |
bshum++ #as did I |
| 14:56 |
mmorgan |
bshum isn't the only one that likes to push the shiny buttons ;-) |
| 14:56 |
gsams |
glad I disabled that option, because it was impossible to miss apparently. |
| 14:57 |
bshum |
But it's a good point, if so many of us remove or disable it, maybe it shouldn't be there at all. |
| 14:57 |
gsams |
I'd get calls all the time about "mysterious disappearing holds" |
| 15:15 |
mmorgan |
Today's discussion reminded me to file lp 1491097 |
| 15:15 |
pinesol_green |
Launchpad bug 1491097 in Evergreen "More granular permissions needed for Clear Holds Shelf process" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1491097 |
| 15:34 |
|
book` joined #evergreen |
| 15:34 |
|
artunit joined #evergreen |
| 15:34 |
|
tsbere joined #evergreen |
| 15:34 |
|
Callender joined #evergreen |
| 15:35 |
|
ericar_ joined #evergreen |
| 15:49 |
|
tsbere joined #evergreen |
| 15:52 |
|
ericar joined #evergreen |
| 15:52 |
|
artunit joined #evergreen |
| 15:52 |
|
Callender joined #evergreen |
| 15:55 |
yboston |
Dyrcona: I just finsihed rebasing/squashing a new branch for lp 1484281 |
| 15:55 |
pinesol_green |
Launchpad bug 1484281 in Evergreen "authority data may be deleted during propagation with current values of authority.control_set_authority_field" (affected: 1, heat: 10) [Critical,Confirmed] https://launchpad.net/bugs/1484281 - Assigned to Yamil (ysuarez) |
| 15:56 |
Dyrcona |
yboston: Thanks! I'll take a look. |
| 16:31 |
|
pgardella joined #evergreen |
| 16:34 |
pgardella |
I'm running into some trouble getting password reset emails to go out. Looking at the osrfsys.log, I see one WARN, and the rest INFO. It does roll back the db session near the end though. |
| 16:34 |
pgardella |
Should I look into the rollback or the WARN? The rollback was because the "open-ils.cstore.direct.action.circulation.search.atomic: returned 0 result(s)" |
| 16:36 |
kmlussier |
Funny. I was just looking at a local post about password reset not working just as pgardella was asking his question. In our case, I think it was an issue of the password reset being seriously delayed. |
| 16:38 |
pgardella |
The email being delayed, or the sending of the email in Evergreen being delayed? |
| 16:39 |
tsbere |
We have a "every 5 minutes" granularity set up for password reset emails in A/T |
| 16:39 |
kmlussier |
pgardella: The sending was delayed because I think the cron job that sends it was configured for every 30 minutes or something like that. |
| 16:42 |
pgardella |
What cronjob sends it? I've tried manually running the —run-pending |
| 16:46 |
mmorgan |
pgardella: Is your "Password reset request notification" action trigger enabled? It is not enabled by default. |
| 16:48 |
pgardella |
mmorgan: There isn't one in the example, nor listed anywhere I could find. |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:52 |
tsbere |
pgardella: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;h=2532ba552eb1e9ae65e2fff98e45716fed1bad19;hb=master#l8164 |
| 16:52 |
mmorgan |
pgardella: If you look in the database table action_trigger.event_definition, it should be id 20. |
| 16:54 |
pgardella |
Ah. OK. I'll take a look. |
| 16:54 |
mmorgan |
If you are looking at action triggers in the client, you can try a filter using Name - is like - Password% |
| 16:55 |
|
neady joined #evergreen |
| 16:55 |
pgardella |
mmorgan: it is enabled. |
| 16:57 |
gsams |
pgardella: we gave password resets their own granularity. The cronjob looks like: */1 * * * * /openils/bin/action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --run-pending --granularity password --granularity-only |
| 16:58 |
mmorgan |
pgardella: does the user requesting the password reset have an email address set in their account? |
| 16:58 |
pgardella |
Yes. I tested it with mine, as have several other library staff. |
| 16:58 |
tsbere |
gsans: Ours is very similar, but we only run it every five minutes instead of every minute. |
| 16:58 |
gsams |
of course, we had problems with A/T working without granularity settings |
| 16:59 |
pgardella |
I'll take a look and make sure the A/T is set up correctly. It looks like it, but I'll verify it against the git commit tsbere sent. |
| 17:00 |
mmorgan |
We don't have a granularity set for our password reset notification trigger, it's working fine without one for us. |
| 17:01 |
gsams |
mmorgan: It was an odd time, and I still don't know why things didn't work quite right at the time. We just setup granularity for everything and run separate commands for each now. |
| 17:02 |
mmorgan |
pgardella: You can try looking in the action_trigger.event table to see if the events were created. select * from action_trigger.event where event_def = 20 |
| 17:03 |
mmorgan |
gsams: I can see merits in a granularity for everything. You certainly have more control that way. |
| 17:04 |
kmlussier |
mmorgan: How often do your action triggers run? What I like about the approach from gsams and tsbere is that the password reset runs quite frequently. |
| 17:04 |
gsams |
mmorgan: We split it into 4 types, with overdue notices being by OU. The others are passwords, holds, and predue notices. |
| 17:05 |
* mmorgan |
checks the crontab |
| 17:05 |
gsams |
I was impatient when testing so I set it to 1 minute and never ended up changing it to 5 which was intended |
| 17:05 |
gsams |
it hasn't been a problem though, so bonus. |
| 17:05 |
kmlussier |
gsams: I think most users expect to receive the password reset immediately, so that seems like a good approach. :) |
| 17:06 |
mmorgan |
Our triggers run every two minutes. |
| 17:06 |
pgardella |
mmorgan: No events have been created since 8/15. Hum. Time to go figure out what we did that day! I'll check back in tomorrow once I talk to the engineers! |
| 17:07 |
pgardella |
mmorgan: for event_def = 20. We have others in the table. |
| 17:09 |
mmorgan |
gotta run now. Goodnight all! |
| 17:09 |
* mmorgan |
will likely dream about action triggers tonight ;-) |
| 17:09 |
kmlussier |
mmorgan++ gsams++ tsbere++ |
| 17:09 |
jeff |
octagon triggers |
| 17:09 |
kmlussier |
mmorgan: Try not to! |
| 17:09 |
gsams |
I might now too, I haven't looked at them in a while and I have so much to do... |
| 17:10 |
|
mmorgan left #evergreen |
| 17:10 |
gsams |
I need to redo our print notices... |
| 17:31 |
|
mrpeters joined #evergreen |
| 17:36 |
|
drigeny joined #evergreen |
| 17:52 |
gmcharlt |
An OS X staff client for 2.8.3 is now available at http://evergreen-ils.org/downloads/Evergreen_2_8_3_osx.dmg |
| 18:30 |
|
akilsdonk joined #evergreen |
| 19:48 |
|
drigney joined #evergreen |
| 20:00 |
|
finnx joined #evergreen |
| 20:02 |
|
finnx joined #evergreen |
| 20:26 |
|
akilsdonk joined #evergreen |
