Evergreen ILS Website

IRC log for #evergreen, 2015-03-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:38 RBecker joined #evergreen
07:34 Callender joined #evergreen
07:53 Callender joined #evergreen
07:59 akilsdonk joined #evergreen
08:00 rjackson_isl joined #evergreen
08:00 graced joined #evergreen
08:07 collum joined #evergreen
08:18 _bott_ left #evergreen
08:21 _bott_ joined #evergreen
08:41 maryj joined #evergreen
09:06 ericar joined #evergreen
09:13 remingtron gmcharlt: The security team wiki seems to have an incomplete sentence in the "restricted resources" section near the end
09:13 remingtron First bullet: "membership in the private security group on LaunchPad, which will allow them to see and" [should continue?]
09:13 gmcharlt remingtron: oops, yeah, copy and paste fail
09:13 gmcharlt thanks for the heads up
09:14 jeff remingtron: sorry, i don't think you're authorized to know the rest of that sentence...
09:14 * jeff ducks
09:14 remingtron gmcharlt: thank you for the proposal
09:14 gmcharlt jeff: no, we can't let anybody know about the purple cats we have petting access to!
09:14 gmcharlt ... oops
09:14 remingtron *jeff narrowly misses a plush angry bird
09:15 remingtron gmcharlt: librarians everywhere would be jealous
09:17 gmcharlt remingtron: not a copy and paste fail, just an incomplete thought :/
09:17 gmcharlt I've fixed it
09:18 remingtron gmcharlt++
09:26 yboston joined #evergreen
09:38 csharp "which will allow them to see and..."  OOOH! A plush angry bird!
09:43 jboyer-isl joined #evergreen
09:44 dbwells_ joined #evergreen
09:47 abowling joined #evergreen
09:52 ericar_ joined #evergreen
09:53 Bmagic Does evergreen check to see if a copy will fill a hold when you check it in even if that copy was not the target of the hold? We have a situation where a hold was on a pull list for library A and by the time they came back to check it in, it was filled by library B. The hold targeter hadn't changed the target copy in that time
09:55 bshum Bmagic: Yeah, that's "opportunistic" hold capture at work.
09:55 Bmagic bshum: ah! That explains it
09:55 bshum Where lib B can fill a hold if the hold has been around too long (too long being if you use the settings)
09:56 bshum We use the "soft stalling" option in the library settings to try to mitigate that.
09:56 bshum Soft stalling will prevent opportunistic capture by other libraries before X time
09:56 bshum So in our consortium, for example
09:56 bshum We use an interval of "3 days" soft stalling
09:57 Bmagic interesting
09:57 Bmagic I need to bring this up
09:57 bshum To give the pickup library up to 3 days to opportunistically capture the item
09:57 bshum Before it's open season to any library that owns a copy and checks it in
09:57 bshum This operates separately from the hold targeter.
09:57 bshum Which may select any library anyways
09:57 bshum But only the pickup lib can initiate an opportunistic capture with any copy initially.
09:58 bshum If you haven't seen it, I highly recommend this powerpoint slides from an earlier Evergreen conference where folks from ESI tried to "explain" how holds work:
09:58 bshum http://evergreen-ils.org/~corinne/Hippos_Final.ppt
09:59 Bmagic bshum++
09:59 bshum It's a little older, but still helpful for the basic ideas.
09:59 bshum Though things have evolved ever so much with all the newer features for hold targeting in 2.4+
10:00 bshum But in any case, the behavior you described is... "normal"
10:00 bshum That's basically the "whoever is fastest wins" default.
10:00 bshum Tell Library A to stop slacking, obviously....
10:00 bshum :D
10:03 Bmagic lol
10:03 jboyer-isl Bmagic: we have some experience messing with that. EI went from 2-3 days of soft stalling to 0, now we’re back at 1 day for specifically the reason you mentioned about the hold pull list.
10:05 Bmagic So, if the hold is targeted on library's A's copy. Library A has 2 copies but they can't find the exact barcode that it calls for, then the other copy should fill the hold just fine?
10:06 collum \me has a desire to write up a LP enhancement for a popup that reads "Stop Slacking"
10:06 bshum Uh, it depends.
10:06 bshum So if the pickup library is library A, then yes, any copy at Library A will work.
10:06 bshum But if the pickup library is Library B, and it's a "targeted" hold at a specific copy at Library A, then it will only work with that specific copy.
10:07 bshum Until the hold stalling period ends, and then any copy from anywhere will work.
10:07 bshum Basically it's the least number of transits required idea
10:07 bshum If you're going to pick it up at that library, any copy there shall do.
10:08 bshum If you've got to send it somewhere, only send what we're asking for, no more.
10:08 bshum Unless the hold has been waiting around too long, then please send the next available copy, anybody!
10:09 Newziky joined #evergreen
10:09 Bmagic 3 days seems weird
10:09 Bmagic because the hold targeter will pick a different copy anyway every 24 hours
10:09 bshum It was the happy medium that worked for our consortium.
10:09 bshum Originally, we were 5 days actually.
10:09 bshum Because our first two pilot libraries were estimated to be about 5 days apart.
10:10 Bmagic Your hold targeter doesn't change the target every 24 hours?
10:10 bshum In terms of trying to calculate based on how often the delivery truck went to the libs in question.
10:10 bshum We still need to play more with proximity to try grouping libs into better combinations for delivery.
10:11 bshum But meh
10:11 bshum It depends on the item.
10:11 Bmagic so, you changed your hold targeter as well?
10:11 bshum Nope, that's just what it is.
10:11 bshum It doesn't *always* pick a new copy from elsewhere.
10:11 bshum And not all libs check their pull list consistently every day.
10:11 bshum So some will do it twice a week
10:11 bshum And others will do it four times a day.
10:11 Bmagic so, you see why I'm confused about a soft stall for any interval greater than 24 hours?
10:12 bshum It gives the pickup library a few days to get their act together.
10:12 bshum The hold target may shift constantly
10:12 bshum But opportunistic capture at the pickup lib can happen at any time within those initial 3 days.
10:13 bshum So if a hold is captured by target elsewhere in the consortium, then yeah whatever, it locks on that, and that's the copy you get.
10:13 bshum Unless you use more settings to trump that and use the local copy first.
10:13 Bmagic So it shows up on thier pull list even though it's targeted a different copy in the meantime?
10:13 bshum No, it's not about the pull list
10:13 bshum It's about check-in
10:13 bshum You asked about during checkin, do holds get checked and filled
10:13 bshum And yes, they do, opportunistically at the pickup lib level
10:14 bshum These are separate things;  opportunistic holds work at the same time as targeted holds
10:14 csharp argh - we should really stop letting people clone and edit reports
10:14 Bmagic csharp: I agree!
10:15 csharp I spend literally hours getting a template just right, then someone clones and mangles it and I end up having to fix it
10:15 csharp @tantrum
10:15 pinesol_green csharp: No, you're a puzzleheaded kraken!
10:15 bshum It's too microscopic to try defining the scenario, in reality, you've got dozens of copies and lots of holds at the same time.
10:15 * csharp stops whining and gets back to it ;-)
10:15 jeff csharp: what's that you say? you'd prefer that a smaller subset of people DESIGN the reports, and then there's an easier self-service means of running them?
10:16 csharp jeff: haha
10:16 * csharp knows what's coming
10:16 jeff csharp: seems like there's a library doing something along thoes lines somewhere...
10:16 * jeff grins
10:16 csharp exactly
10:17 collum jeff beat me too it ;-)
10:17 bshum Bmagic: So the soft stall of 3 days is mainly to give the pickup library a good interval to get the book back and check it in, to capture the next hold and get it to fill for that.  Instead of having any checkin at any library that has that copy to capture, transit, and fill the hold.
10:17 bshum Bmagic: This is separate from the hold targeting process itself, which does try for a new target every 24 hours (based on when the hold was placed and how often you run hold_targeter) and that's what drives the pull lists and tells people what they should pull from the shelves to check in and see if it's still needed.
10:18 Bmagic bshum: Back to my original scenario where library B filled A's hold opportunistically. With the soft stall in place for library A, this would not be possible? I'm confused because the hold targeter will target a different copy, and the other library might be commaned to pull it and fill it, during the stall interval for A
10:18 afterl joined #evergreen
10:18 bshum Bmagic: That is correct.  It's whoever is faster in that scenario you describe then.
10:18 csharp the soft stall was originally invented to deal with PINES courier delays, which were serious at the time, but those delays went away (probably before the feature was fully implemented)
10:18 bshum *still whoever was faster
10:19 csharp so people in our consortium who don't remember those days wonder why there's a 5 day stall
10:19 bshum Even if we don't have courier delays, irregular hold pull list checking, etc., the perception of delays still makes people feel better knowing that they've got the chance to use their copy to fill the hold ahead of transit copies, if they're efficient about it.
10:20 bshum So I go back to my earlier statement:  "Tell Library A to stop slacking, obviously...."
10:21 Bmagic Im still fuzzy on this. Let me ask another question that might help. If the hold is inside of the soft stall interval, nobody can fill the hold opportunistically except the library who has the soft stall?
10:22 bshum Bmagic: To be honest, I've never used soft stalling settings except consortially.  So I do not know what happens if you only apply it to a specific library.
10:22 Bmagic OK, consortially then
10:22 bshum If it's consortial, then only the pickup library can capture opportunistically.
10:22 bshum Everyone else checks in normally
10:23 bshum And only uses their copy for targeted holds
10:23 bshum Or holds that are past the soft stalling and can be captured opportunistically.
10:23 Bmagic I got it
10:24 Bmagic bshum++ #OMG holds
10:25 * bshum mostly gets it.
10:26 Dyrcona joined #evergreen
10:29 kmlussier I think soft stalling was the one setting we had the most trouble figuring out when we were learning about Evergreen holds.
10:30 * kmlussier doesn't think any of the MassLNC consortia are using it.
10:30 * bshum disappears to head over for his next meetings
10:31 bshum Good luck, Bmagic++ # stay strong!
10:31 Bmagic LOL!
10:32 dreuther joined #evergreen
10:48 ericar joined #evergreen
10:51 mllewellyn joined #evergreen
10:58 hopkinsju bshum++
10:58 hopkinsju Just got caught up on this. We should do a conference session titled #OMG HOLDS
10:59 hopkinsju We can do the OMG part and bshum can explain everything
11:09 csharp hopkinsju++
11:10 csharp @quote add < hopkinsju> Just got caught up on this. We should do a conference session titled #OMG HOLDS.  We can do the OMG part and bshum can explain everything.
11:10 pinesol_green csharp: The operation succeeded.  Quote #108 added.
11:16 vlewis joined #evergreen
11:24 hopkinsju heh
11:38 kbutler joined #evergreen
11:39 bmills joined #evergreen
11:45 jeff I swear I just saw the string "facepalm" in this SRU output...
11:46 jihpringle joined #evergreen
11:50 bmills joined #evergreen
11:50 bmills1 joined #evergreen
11:55 bshum Bleh
11:55 bshum 0898 hates me
11:55 bshum Oh wait, I know why
11:55 bshum Stupid restore
11:56 bshum Darn search_path gets me every time
11:57 jeff i want to kill those lingering issues.
11:57 jeff the only good fix that i'm aware of is to fully qualify.
11:58 bshum Right.
12:02 sandbergja joined #evergreen
12:05 Dyrcona Let me check my restore script, I think we fix it in a script we run after.
12:07 Dyrcona Yep: ALTER DATABASE :db_name SET search_path=evergreen, public, pg_catalog;
12:08 Dyrcona with -v db_name=actual_database_name on the command line
12:09 Dyrcona And, I don't think it is necessary (or didn't used to be) if your database user's name is evergreen.
12:09 Dyrcona IIRC, postgres looks in a schema named for the current user, then in public, then in pg_catalog by default, but as always, I could be wrong or misremembering.
12:14 jeff pg_restore still breaks some things.
12:14 jeff because it will explicitly set the search path.
12:15 jeff so unless you're also hand-editing the pg_restore commands, you're going to be doing things like (at least) re-creating a few indexes that fail due to search path.
12:15 jeff though it's possible that THAT was fixed and I just missed that it's been fixed in more-recent versions.
12:15 jeff I'll try and bother to look.
12:16 Dyrcona We haven't had trouble with indexes in quite a while.
12:16 Dyrcona We do have trouble with config.z3950_index_field_map from time to time.
12:17 Dyrcona So, we check if select * returns anything and if not, we insert the values that should be in the table in our script we run post-restore.
12:18 Dyrcona Just below setting the path, actually.
12:18 Dyrcona I believe the index problems were fixed at some point.
12:20 bshum ~search_path
12:20 pinesol_green After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog;
12:20 bshum Yeah.
12:20 pastebot "Dyrcona" at 64.57.241.14 pasted "MVLC's post restore SQL script." (22 lines) at http://paste.evergreen-ils.org/44
12:26 jeff Dyrcona: and you no longer have issues with the by_heading_and_thesaurus or by_heading indexes in the authority schema?
12:28 mglass_ joined #evergreen
12:28 jeff "issues" meaning "they break at pg_restore time due to oils_xpath_string not being in the search path"
12:36 * csharp noticed that if he uses PGUSER=postgres that the restore drops things but doesn't with PGUSER=evergreen
13:08 Dyrcona jeff: No, we don't have that one any more. Forget what fixed it.
13:08 jeff Dyrcona: thanks.
13:09 * Dyrcona was AFK for a bit.
13:09 jeff the nerve.
13:18 Dyrcona heh
14:10 kmlussier gmcharlt / eeevil: Do you know if work is being done on webby at the moment?
14:12 gmcharlt kmlussier: not at the moment; does it need a kick?
14:12 kmlussier I'm not retrieving any results when I try catalog searches.
14:13 jeff new feature. prevents "the result at position 2 should OBVIOUSLY be at position 1" complaints.
14:13 Dyrcona :)
14:13 jeff also, permanently ends argument about what the default search order should be!
14:14 Dyrcona I tought it was to prevent DOS by running an insane search that returns the whole database.
14:14 jeff that ability is now restricted to only GoogleBot
14:15 jeff (and Yandex, if you set the proper OU setting)
14:17 afterl joined #evergreen
14:18 gmcharlt kmlussier: kick duly administered
14:18 kmlussier gmcharlt++
14:18 gmcharlt Harry Potter retrieval service now restored
14:19 kmlussier Ha! It's spooky how you said that just as I saw the harry potter search results filling the screen.
14:19 Dyrcona :)
14:21 * gmcharlt is now musing about organizing a super-library-geeky social event at #egconf15 that would have the effect of reshuffling all of our default catalog searches ;)
14:22 kmlussier That would be fun.
14:23 kmlussier My default search is "pugs", but I never use it on systems with test data because it rarely pulls up results. Interestingly, it does get a couple of hits on webby.
14:28 bmills joined #evergreen
14:39 bshum I need to add my own "star trek" bib record to the stock data :)
14:40 bshum I usually do "mozart" as my concerto test.  And "Harry potter" if I want that one sample :)
14:40 Dyrcona We should add a bunch of "fictional" books written by community members, with notes extolling things they've done for Evergreen.
14:41 bshum That would be hilarious
14:41 bshum And awesome
14:41 bshum Yeah, where is the book of Evergreen?  That totally needs to be original cataloged...
14:42 Dyrcona Yeah.
14:42 kmlussier When I'm creating records in a test system, I usually do "Kathy's adventures in Evergreen."
14:43 kmlussier There's also a serial version: "Kathy's journal of Evergreen."
14:47 Dyrcona I've got some books on the shelf in my office with barcodes on them that I use if I need test copies.
14:49 Dyrcona I don't usually create MARC data.
14:50 Dyrcona We actually have a barcode prefix for our central site, though we do not have a circulating collection.
14:52 Dyrcona Cataloged a Coca Cola bottle once, now that I think of it.
14:54 dbs Hmm. Running through acquisitions PO notes, I had a use case for copying and pasting multi-line notes and hoping the formatting would stick
14:55 dbs Munged it all onto one line, of course.
14:55 dbs But, imagine my surprise and delight when sticking in <br> tags introduced linefeeds into the output!
14:55 dbs So now I "just" need to teach the notes widget to convert line feeds to <br> tags and bob's my uncle
14:58 Dyrcona small matter of programming. :)
15:01 bshum Yay, open source!
15:02 collinanderson just don't open up any xss holes :)
15:09 dbs collinanderson: I wouldn't be opening up any that don't already exist. heh.
15:09 gmcharlt dbs: good plan!
15:09 gmcharlt ;)
15:46 Dyrcona Oh noes!!!
15:50 maryj joined #evergreen
15:53 bshum joined #evergreen
15:55 jeff vague ticket is vague.
16:01 Dyrcona Yes, it is.
16:01 bshum csharp: I hate my email response already and want to add more supplemental asterisk with expanded explanations for everything I said about upgrade and version-upgrade scripts.
16:02 bshum The whole thing is a mess :)
16:02 bshum And I'm glad we run master instead where it's neatly sequential without any gaps.
16:07 jboyer-isl @hate Launchpad search
16:07 pinesol_green jboyer-isl: The operation succeeded.  jboyer-isl hates Launchpad search.
16:08 kmlussier @whocares Launchpad search
16:08 pinesol_green kmlussier, Dyrcona and jboyer-isl hate Launchpad search
16:08 bshum Launchpad search sucks.
16:09 bshum My head is filled with the names and descriptions of so many bugs now... past, present
16:09 Dyrcona I seriously think it only searches bug titles, even in advanced search.
16:09 jboyer-isl my terms are unique, ugly, weird, and should only retrieve the one ticket I’m looking for, but no.
16:09 bshum They haunt my dreams
16:09 kmlussier Does it really, though? I sometimes find the problem has nothing to do with Launchpad, but everything to do with the fact that I describe problems in an entirely different way than somebody else.
16:09 maryj Can the launchpad search be enhanced at all?
16:10 maryj (or is that my hopeful optimism showing?)
16:10 bshum kmlussier: Typos too.
16:10 bshum :)
16:10 Dyrcona "Why can't search work like [insert multi-billion dollar online corporation here]?"
16:10 bshum maryj: To be honest, I usually just use google search and append whatever I'm looking for with "Evergreen launchpad"
16:11 bshum And 90% of the time, that gets me a link to the real LP bug entry that I was hoping for ;)
16:11 Dyrcona I just got to create a new bug. That usually finds the one I'm looking for.
16:11 bshum Or I just search my email to find the reference too.
16:11 bshum Which is also gmail, so, heh
16:11 kmlussier I think it would help if the default search included more types of bugs. I know duplicates are automatically excluded as well as ones marked as opinion or invalid.
16:12 Dyrcona yeah, I sometimes search my bug email folder.
16:13 jboyer-isl git tells me the thing I’m searching for has not been changed. Does anyone know whatever happened to any discussion of the money.m_b_x_open_xacts_idx index? It’s only an index on money.billable_xact (usr) and doesn’t have anything to do with xact_finish being null (as the name implies)
16:14 jeff jboyer-isl: do you recall discussion?
16:15 jboyer-isl I could have sworn I saw someone ask about it at some point, but Google tells me I’m making it up. :-/
16:17 Dyrcona My email search tells me you're making it up, too. :)
16:17 Dyrcona 'Course, I'll have saved bug mails back to November 9, 2012.
16:17 Dyrcona I only have...
16:17 jboyer-isl Anyway, I find myself needing such an index and didn’t know if I had missed a fix for it. Apparently not.
16:17 Dyrcona I could check the dev list.
16:19 Dyrcona Nothing on the dev list back to 2008 either.
16:20 Dyrcona I hate to start a flame war, but I don't think we should be mucking with the schema on point (i.e. bug fix) releases.
16:23 jboyer-isl Oh well. Thanks for the sanity check everyone. I’ll look into my project a little more and then probably hit launchpad so no one can find my bug later. ;)
16:23 jboyer-isl Dyrcona: agreed (re: schema)
16:24 jonadab As a general principle, I (in complete and total ignorance of the specific thing being referred to) would tend to agree with that.
16:24 Dyrcona The schema is the database layout, including tables and columns.
16:25 jonadab Right, I know what a schema is.
16:25 jonadab I meant I don't know of the specific schema mucking that is being discussed.
16:25 Dyrcona I think if a bug fix requires a change to the schema, then it should not go into a point release.
16:25 Dyrcona I'm speaking in general terms, not to anything specific.
16:25 jonadab Oh, I see.
16:25 jonadab In that case I would tend to agree.
16:25 Dyrcona A discussion of running database upgrade scripts came up on the general mailing list.
16:26 * csharp hates when he drops closing quotes and parens
16:26 jonadab Unless the bug is extremely important (think: data loss crash) and the schema change can be done in a backward-compatible way.
16:26 * Dyrcona hates when he makes any kind of typo.
16:27 * Dyrcona usually lets it go when others do.
16:27 csharp jboyer-isl: you may be remembering when I learned the need for m_b_voider_idx to speed up patron merge
16:29 csharp Dyrcona: in theory, I agree with you - it would be great if the DB was static throughout a major release's lifetime and point releases just fixed EG application-level stuff
16:29 jboyer-isl csharp: Possibly. There doesn’t appear to be a whole lot else I could be remembering at this point.
16:30 csharp jboyer-isl: I mention it because it wasn't in email and I know you were there when I was working on it ;-)
16:31 csharp but since so much app logic has moved to the DB, I can see that it's probably necessary to add DB stuff to even point releases
16:32 gmcharlt well, a distinction could be made between changing table structures and changing stored procedures
16:33 csharp true
16:33 gmcharlt the latter being (oftne, but not always) easier to backport
16:33 gmcharlt as long, of course, as tables that they use haven't changed
16:33 gmcharlt :)
16:37 afterl joined #evergreen
16:38 dreuther_ joined #evergreen
16:38 mglass joined #evergreen
16:38 bshum gmcharlt: You know I've often wondered about that
16:38 chatley_ joined #evergreen
16:38 vlewis_ joined #evergreen
16:38 bshum In terms of seeing whether we can minimize the actual changes in minor versions vs. major versions.
16:39 bshum I've been told before by postgresql developers that they've found our schema changes in even minor versions of Evergreen to be a little weird.
16:41 gmcharlt FWIW, Koha has a reasonably strict policy that new stuff goes in master and only bugfixes get backpatched
16:41 Dyrcona Do bugfixes include schema changes in Koha, or is that always considered new stuff?
16:41 vlewis joined #evergreen
16:41 gmcharlt there are exceptions, of course, but there's rather less DB schema churn during maintenance release cycles as a consequence of that policy
16:41 mglass joined #evergreen
16:42 chatley joined #evergreen
16:42 Dyrcona We are supposed to have a similar policy, but I think we elide the definition of bug fix a bit.
16:42 dreuther joined #evergreen
16:42 gmcharlt Dyrcona: there's some of that elision in Koha too, but less
16:44 Dyrcona It's kind of funny that bshum and I would be pushing this, since we both run master and therefore shouldn't care. :)
16:44 gmcharlt looking at the changes in the Koha 3.18.x maint cycle so far, the only actual schema changes as such are one change of a column type and adding an index
16:44 Dyrcona I'd have no problem with adding an index.
16:46 gmcharlt yeah
16:46 Dyrcona The question of how to run the upgrade scripts or problems with them come up often enough, though.
16:46 bshum Heh, CREATE INDEX IF NOT EXISTS, it's fun reading threads that google throws at you
16:47 gmcharlt idempotence is a virtue :)
16:47 Dyrcona eeevil's deprecates idea sound like it would help.
16:48 gmcharlt Dyrcona:  I AM THE ONE TRUE REINGEST. ALL OTHERS ARE DEPRECATED BEFORE ME
16:48 gmcharlt ;)
16:49 * bshum should look again at sqitch
16:49 * bshum saw a presentation about it once at a PGCon
16:49 bshum http://sqitch.org/
16:49 Dyrcona gmcharlt: haha. But my reingest forks. ;)
16:50 gmcharlt your reingest is legion? /me ducks
16:50 Dyrcona ha
16:54 afterl left #evergreen
16:58 Dyrcona Have a good weekend, everybody!
17:01 phasefx_ joined #evergreen
17:03 kmlussier Hooray - it's quitting time! See y'all on Monday!
17:05 berick It's 5 o'clock somewhere!  Oh yeah, here.
17:07 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:20 * berick calls 0915
17:24 * csharp answers "Hello?  Hello, this is 0915, is anyone there?"
17:26 berick "have you checked the children?"
17:26 csharp heh
17:32 pinesol_green [evergreen|Bill Erickson] LP#1234220 Improve hold/copy ratio renewal messages - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=06a35b3>
17:32 pinesol_green [evergreen|Bill Erickson] LP#1234220 hold ratio renewal override perms - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=919a07d>
17:32 pinesol_green [evergreen|Bill Erickson] LP#1234220 Stamping DB upgrade copy/ratio messages - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2acd1c2>
17:51 Newziky left #evergreen
17:59 akilsdonk joined #evergreen
19:27 bmills joined #evergreen
21:25 akilsdonk joined #evergreen
22:34 book` joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat