Evergreen ILS Website

IRC log for #evergreen, 2015-03-11

| 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
02:32 bmills joined #evergreen
04:15 chatley joined #evergreen
04:54 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:57 TaraC joined #evergreen
07:20 dkyle1 joined #evergreen
07:21 _bott_ joined #evergreen
07:28 graced joined #evergreen
07:29 jboyer-isl joined #evergreen
07:53 collum joined #evergreen
07:56 rjackson_isl joined #evergreen
08:04 akilsdonk joined #evergreen
08:31 mmorgan joined #evergreen
08:39 Shae joined #evergreen
08:46 Dyrcona joined #evergreen
09:21 * jeff yawns
09:25 mrpeters joined #evergreen
09:32 gmcharlt jeff: WAKE UP
09:32 kmlussier gmcharlt: Shhhhh...you're interrupting my morning nap.
09:33 gmcharlt kmlussier++
09:34 Dyrcona I'm finding it very difficult to figure out why we would run out of settings drones, particularly in the middle of the night.
09:37 yboston joined #evergreen
09:42 Dyrcona So, running hold targeter right now.
09:42 Dyrcona 56 SettingsClient have been initialized, and for all of that only 1 call to opensrf.settings has actually been made.
09:42 Dyrcona I'll see what a/t runner does after this finishes, but I exepect to see something similar there.
09:42 gmcharlt Dyrcona: grasping at straws here -- //hold_targter/parallel in opensrf.xml isn't set to a super-high value, right?
09:42 Dyrcona gmcharlt: It is set to 6.
09:42 Dyrcona Same as we use in production, IIRC.
09:42 * gmcharlt tosses that straw away
09:42 Dyrcona I added log statements to Storage when it does soemthing with SettingsClient yesterday.
09:42 Dyrcona Today, I added log statements in OpenSRF::Application::Settings to log what method is called.
09:42 Dyrcona I started with hold targeter to rule it out. I don't think it could have been our problem Thursday night.
09:42 Dyrcona I just checked, 6 is used in production, too.
09:42 Dyrcona All the parallel settings, except a/t are set to 6.
09:43 mllewellyn joined #evergreen
09:53 berick i still suspect spawning apache children as the source, since each of those will have to talk to the settings server.
09:53 kmlussier berick: You had asked the other day if today was too early for the RC1 release. I didn't have an opinion at the time, but, in thinking about it further, one week seems like a very short beta period.
09:54 berick ... unlike perl/c drones
09:54 berick kmlussier: yeah, it is
09:55 berick if we have to trim anyhing, and we don't necessarily have to.., probably would make more sense to have a longer beta and a shorter RC period
09:55 berick perhaps a beta2 is in order, to pick up the latest db upgrade script
09:57 Newziky joined #evergreen
10:02 Dyrcona berick: But my access.log has only two entries at the time we ran out of settings drones last Thursday at midnight.
10:02 Dyrcona It goes from 00:15:02 to 00:15:09 and osrfsys.log starts complaining at 00:15:07.
10:03 berick well, dang, probably not that then
10:08 Dyrcona Library Elf does start showing up at 00:15:21.
10:08 Dyrcona I could just blame them and be done with it. :)
10:10 berick apache and log server times are synced?
10:10 Dyrcona Gone through 136 SettingsClients and still only 1 opensrf.settings called.
10:10 Dyrcona They're on the same system, so they use the same clock.
10:11 * berick nods
10:12 Dyrcona If the access.log entries don't show up until the request is complete, it could be that Elf is causing it.
10:12 Dyrcona If the request took more than 14 seconds to process.
10:12 Dyrcona Which wouldn't surprise me, since it is auth via XML-RPC followed by an actor and a circ call.
10:13 berick yes, good point.  access logs do happen after the request
10:13 berick so they can log the response code, size, etc.
10:13 Dyrcona Yep.
10:14 Dyrcona Ok, so, I'll blame Library Elf. :)
10:14 Dyrcona BTW, I haven't had luck getting auth to work via XML-RPC lately. I wonder how Library Elf still works.
10:15 Dyrcona I didn't try too hard, though.
10:16 berick i just remember having to change the API name, but you're probably past that step
10:16 Dyrcona Yep.
10:17 jwoodard joined #evergreen
10:17 Dyrcona I should load my access.log that includes the apache child pid.
10:17 Dyrcona That would be helpful in this case.
10:18 Dyrcona I can see how many different child processes they're causing to be spawned.
10:21 Dyrcona <sarcasm>Oh. Nice.</sarcasm> It has a completely different format from my regular custom log.
10:38 jboyer-isl joined #evergreen
10:40 Dyrcona Hrm.
10:40 Dyrcona Looks like I can make it inherit an existing table.
10:41 Dyrcona If I add a column to the child table, can I update that column based on the parent table's id?
10:42 Dyrcona Except...the domain in the pid log doesn't match the access.log, 'cause a different format specifier was used. Drats.
10:45 Dyrcona Hmm. I'll see what I can come up with anyway.
10:45 Dyrcona Something to do while I wait on other things.
10:59 Dyrcona Hm. When you make a new table that inherits another table, I thought the rows from the parent table showed up in the child table.... Do I have that reversed?
10:59 Dyrcona y'know. I think I od.
10:59 Dyrcona do.
10:59 eeevil yep
10:59 Dyrcona Ok.
10:59 eeevil (just to confirm)
11:00 Dyrcona No. I had it backwards.
11:00 Dyrcona The child rows show up in the parent, but parent rows don't show up in the child.
11:00 eeevil yep to "rows show up in the parent table", sorry
11:00 eeevil or, rather, yep to "do I have that reversed"
11:01 Dyrcona Right. But, for the sake of the logs.....
11:01 Dyrcona "Won't somebody think of the logs?"
11:01 Dyrcona ;)
11:02 Dyrcona So, the fact that my local domain names differ, one log has the value of the HTTP HOST header and the other the canonical name, and that I have multiple matching requests per timestamp, complicates what I'd like to do.
11:03 Dyrcona I should just make these completely separate tables to avoid duplication in the parent.
11:28 jihpringle joined #evergreen
11:31 sarabee joined #evergreen
11:33 Dyrcona And the timestap is a different format....
11:34 Dyrcona Just for fun, y'know.
11:37 Dyrcona And, natrually, DateTime::Format:HTTP can't parse it.
11:37 vlewis joined #evergreen
11:38 * kmlussier notes that holds would be a great topic for a documentation sprint
11:39 * Dyrcona notes that consistency in log output is often a good thing.
11:39 Dyrcona ;)
11:39 kmlussier Dyrcona: consistency in anything is a good thing.
11:42 gmcharlt almost anything -- I dislike consistently tripping over the same cat every morning ;)
11:42 gmcharlt kmlussier: +1 to a holds doc sprint
11:43 kmlussier gmcharlt: Do you have a cat? You didn't seem like a cat person to me. ;)
11:43 mmorgan gmcharlt: Would tripping over a different cat each morning be preferable?;-)
11:43 gmcharlt kmlussier: I am now weeping at the complete failure of my social media #brand ;)
11:43 gmcharlt mmorgan: it would at least add some variety :)
11:44 collum gmcharlt: you can borrower mine, but they are very difficult not to see, and shipping will be costly.
11:45 gmcharlt collum++
11:49 bmills joined #evergreen
12:11 akilsdonk joined #evergreen
12:12 Dyrcona @hate the wifi in the office.
12:12 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates the wifi in the office..
12:14 Dyrcona joined #evergreen
12:15 mceraso joined #evergreen
12:16 dreuther joined #evergreen
12:16 bmills joined #evergreen
12:17 Dyrcona joined #evergreen
12:18 Dyrcona Well, let's see how long that fixes things.
12:23 * mmorgan is trying to understand the difference between permissions UPDATE_RECORD and UPDATE_MARC
12:23 mmorgan It looks like UNdeleting a record requires UPDATE_RECORD.
12:23 bmills1 joined #evergreen
12:25 mmorgan What else does UPDATE_RECORD allow? Merging two records maybe?
12:30 mmorgan Hmm. Merging requires MERGE_BIB_RECORDS.
12:32 mmorgan I would like to give users permission to undelete records, but UPDATE_RECORDS sounds like it could be more permissive than that.
12:33 Dyrcona You were expecting consistency? ;)
12:34 gmcharlt mmorgan: you know, upon skimming the code, I'm not seeing that there's currently a useful distinction expressed between UPDATE_MARC and UPDATE_RECORD
12:34 gmcharlt IOW, perhaps those two perms could be merged
12:35 gmcharlt (what does surprise me is that there aren't separate perms for editing bibs and editing authorities)
12:37 mmorgan UPDATE_MARC does not allow UNdeleting of records.
12:37 Dyrcona Yeah, you would think that there would be.
12:38 gmcharlt mmorgan: right - what I meant was that I haven't seen anything to explain why update_marc and update_record, as generically named permissions, are separate
12:38 * dbs seems to recall finding that UPDATE_MARC and UPDATE_RECORD were pretty much synonymous back in the oughts
12:39 gmcharlt in the case of undeleting records -- I could see an argument that there should be a distinct permssion for that
12:39 dbs Holding MARC over a fire requires UNDULATE_RECORD perm
12:41 jihpringle joined #evergreen
12:44 eeevil the reasoning for update_marc vs update_record is that updating the bre row (setting deleted=false) is different from changing the data in the marc column on that table ... not saying it's particularly strong reasoning, but, there it is
12:45 eeevil by that logic, of course, changing the source should require update_record as well.  haven't looked to see if it does, though
12:46 maryj joined #evergreen
12:51 gmcharlt eeevil: as a data point, open-ils.cat.biblio.record.marc.replace can change the source, but checks UPDATE_MARC
13:00 mmorgan I would tend to agree that undeleting a record should be a distinct permission. Sometimes copies are deleted by a staff member who intends to add a new copy or order. The staff member may not realize it's a last copy and the record deletes.
13:01 mmorgan It would be useful if the staff member could undelete the record. This staff member would not necessarily have the UPDATE_MARC permission.
13:03 jonadab I am having difficulty imagining a scenario where I would want to give someone permission to delete but not to undelete.
13:03 krvmga joined #evergreen
13:03 kmlussier Looking at mmorgan's scenario, I'm thinking it is more likely they would want to give permission to undelete but not to delete a MARC record.
13:03 krvmga when i run autogen and get the error "No bootstrap config exists.  Have you bootstrapped?
13:03 krvmga ", what has gone wrong?
13:04 krvmga what did i miss?
13:04 mmorgan yes, what kmlussier said :)
13:05 mmorgan We have the system option set to delete the bib when the last copy is deleted.
13:06 jonadab Yes, undelete but not delete permission makes more sense than the other way around.
13:09 krvmga https://bugs.launchpad.net/evergreen/+bug/960552
13:09 pinesol_green Launchpad bug 960552 in Evergreen "Cronscript.pm broke unless --sysconfdir specified during configure" (affected: 2, heat: 10) [Undecided,Fix released]
13:10 krvmga ./configure and checking Open-ILS/src/perlmods/lib/​OpenILS/Util/Cronscript.pm is enough to fix it?
13:10 krvmga or is there another way?
13:41 krvmga i just wonder why, when the fix was released in 2012, i'm still hitting the same problem. quel frustrate.
13:45 Dyrcona krvmga: You sure you did all of the steps?
13:46 Dyrcona I was trying to just install support-scripts yesterday and found the files were not remunged at make install time, only at configure.
13:46 Dyrcona Or something like that.
13:46 Dyrcona You sure didn't pull a new checkout and build without configuring or do a git reset or something like that?
13:48 krvmga Dyrcona: hmmmm....i'm going to have to check that out. i had 2.7.3 up and running when i *cough*foolishly*cough* decided to go to 2.7.4 via the upgrade path.
13:49 krvmga maybe something got missed on the way.
13:49 Dyrcona That's not foolish, that's what most people would do.
13:49 Dyrcona Well, it sounds like something was missed when building 2.7.4.
13:49 Dyrcona You got it via tarball and not git?
13:49 krvmga Dyrcona: i'm guessing you're right. i got it via tarball rather than git.
13:50 krvmga i'm just going to try it again and see how it goes.
13:50 Dyrcona Did you put it in a fresh directory or did you extract over the existing 2.7.3 code?
13:50 Dyrcona The latter might cause a problem.
13:50 krvmga i put it in a fresh directory
13:50 Dyrcona OK.
13:51 Dyrcona When I had trouble with just doing support-scripts yesterday, I just did a fresh build.
13:51 Dyrcona That resolved my issue.
13:51 krvmga it's really hot in my office now.
13:51 krvmga the sun is shining on the blinds and the building hasn't turned the heat off.
13:52 krvmga must be muddling my thinking.
13:52 Dyrcona Could be.
13:52 krvmga Dyrcona: thanks :)
13:52 Dyrcona Anyway, I'd just go through the build steps again and see if that resolves ti.
13:52 krvmga Dyrcona++
13:52 Dyrcona it
13:53 Dyrcona Maybe do a make clean first.
13:53 * krvmga sees a yellow brick road and feels a strong compulsion just to follow it to find out where it goes.
13:53 Dyrcona If you were using git I'd recommend git clean -x -f -d
13:53 krvmga i'll do the make clean
13:54 Dyrcona I'd watch out for those yellow brick roads. You never where you'll end up.
13:54 collum joined #evergreen
13:55 * krvmga is standing at the end of a road before a small brick building. Around him is a forest. There is a mailbox here.
13:56 krvmga :)
13:57 Dyrcona You are about to be eaten by a grue.
13:57 Dyrcona Oops. Wrong game. :)
13:57 krvmga lol
13:58 Dyrcona i
13:58 Dyrcona Kill grue.
13:58 Dyrcona Kill grue with what?
13:58 Dyrcona i
13:58 Dyrcona *fork *knife *spoon
13:58 Dyrcona Kill grue with spoon.
13:58 Dyrcona You are eaten by a grue.
13:59 * Dyrcona goes back to hunting library elves in his apache logs.
13:59 * collum is standing at the end of aroad before a small brick building. There's a fork, knife, and spoon on the ground.
14:00 Dyrcona heh
14:12 mglass joined #evergreen
14:18 kmlussier @dessert
14:18 * pinesol_green grabs some Chocolate Chip Cookies for kmlussier
14:20 * kmlussier has discovered that if you publicize the fact that you're driving around with cases of Girl Scout cookies in your trunk, people will start buying them in large numbers.
14:21 maryj kmlussier++ # my favorite dealer
14:21 kmlussier maryj: It does lead to a lot of shady transactions in the parking lot.
14:22 maryj :D
14:25 Dyrcona heh
14:32 jeff having once met a stranger (to me) in a parking lot downstate and exchanged a wad of cash for a pillow case that was moving around a bit, i know what you mean by the "shady" (seeming) transactions bit.
14:33 jeff but my son really likes his new ball python. :-)
14:38 kmlussier As in a snake (not a programming language)?
14:38 * kmlussier shudders
14:43 jeffdavis I've registered the Overdrive API Integration project on Launchpad: https://launchpad.net/overdrive-eg-opac
14:44 jeffdavis The LP setup is pretty minimal, but it should suffice as a place to report bugs.
14:45 jeffdavis gmcharlt: ^ may be of interest if you are looking at that code
14:45 sbrylander joined #evergreen
14:46 gmcharlt jeffdavis++
14:56 akilsdonk joined #evergreen
15:00 kmlussier jeffdavis++
15:17 mglass joined #evergreen
15:17 vlewis joined #evergreen
15:17 dreuther joined #evergreen
15:18 kmlussier @eightball is it called a frappe or a milkshake?
15:18 pinesol_green kmlussier: Unlikely.
15:19 kmlussier Hmmmm...I need to rephrase that.
15:20 kmlussier @eightball is it called a frappe?
15:20 pinesol_green kmlussier: NO!
15:21 dreuther joined #evergreen
15:21 mglass_ joined #evergreen
15:21 vlewis joined #evergreen
15:26 mmorgan Then it must be a milkshake!
15:26 Dyrcona @eightball is it called a milkshake?
15:26 pinesol_green Dyrcona: The outlook is poor.
15:29 kmlussier That settles it. It's a cabinet.
15:29 mmorgan @eightball is it called a cabinet?
15:29 pinesol_green mmorgan: Come again?
15:33 Dyrcona @eightball Are travel books serials?
15:33 pinesol_green Dyrcona: Unlikely.
15:34 Dyrcona @eightball You aren't a cataloger, are you?
15:34 pinesol_green Dyrcona: The outlook is hazy, please ask again later.
15:34 mmorgan @eightball Are you being indecisive today?
15:34 pinesol_green mmorgan: Unlikely.
15:34 * mmorgan does not agree ;-)
15:35 gmcharlt @eightball Are all eightballs liars?
15:35 pinesol_green gmcharlt: You're kidding, right?
15:35 gmcharlt @eightball Are all eightballs Cretan?
15:35 pinesol_green gmcharlt: The outlook is hazy, please ask again later.
15:36 gmcharlt not going to be pinned down today, I see!
15:56 Dyrcona Hm... Gues I can't really blame library elf, either.
15:56 Dyrcona Looks like all of their hits during our problem period happened on the same apache child process.
15:56 dbwells bshum: (or anyone else doing EG self-check) What OS/underlying software do you use for your self-check kiosks?
15:57 Dyrcona @blame eightball
15:57 pinesol_green Dyrcona: eightball is why we can never have nice things!
16:01 bshum dbwells: For awhile, we used Ubuntu and OpenKiosk; nowadays I think our tech team is using Win 7 and OpenKiosk
16:02 bshum http://openkiosk.mozdevgroup.com/
16:02 mmorgan dbwells: We have three libraries using (or soon to launch) roughly the same combination of a Windows 8 touchscreen with OpenKiosk.
16:02 bshum I've also setup openkiosk with Mac systems too for one of our schools.
16:02 Dyrcona We did have 40 different apaches active at the time, though.
16:02 dbwells bshum++ mmorgan++ # thank you
16:08 Bmagic So, I have a title level hold on something with 15 copies. I put a hold on it, the hold logic populates those 15 copies into the hold_copy_map. My copy is targeted for the one with the smallest proximity number. Let's say 24 hours go by and the hold targeter "retargets". It will pick the same copy because it has the lowest prox number
16:08 Bmagic how do we get it to pick the next copy instead of the same one with the lower prox number
16:10 Dyrcona Bmagic: Change the code.
16:10 Dyrcona There's no setting for that.
16:11 Bmagic Dyrcona: bummer
16:14 mmorgan Bmagic: Curious - for what reasons could the targeted item with the lowest proximity not be available?
16:14 Dyrcona mmorgan: Staff could be ignoring or not finishing the pull list.
16:16 Bmagic mmorgan: library is closed is another reason. We would like the system to just move on (without having to take that copy out of the map like marking it missing)
16:16 bmills joined #evergreen
16:16 mmorgan Closings is what I was wondering about. Are days closed entered when libraries are closed? There's an option not to target when a library is closed.
16:21 Dyrcona Bmagic: When a library is closed for an extended period, you can skip them for hold targeting with an org_unit setting.
16:22 Dyrcona circ.holds.target_skip_me
16:25 mmorgan I am thinking of these two org unit settings: "Target copies for a hold even if copy's circ lib is closed", "Target copies for a hold even if copy's circ lib is closed IF the circ lib is the hold's pickup lib"
16:26 mmorgan IOW, circ.holds.target_when_closed and circ.holds.target_when_closed_if_at_pickup_lib
16:27 Dyrcona The setting I posted skips the org unit for holds targeting, period.
16:28 Dyrcona It's useful if the library is closed for several weeks/months for renovations or moving or disaster recovery.
16:28 mmorgan Yes, we have had those situations, too.
16:43 Bmagic mmorgan: Dyrcona: we are familiar, however it seems that regular library hours can exclude weekends. Will the hold targeter remove their copies from the pool after the fact? Meaning: will it see that the library is currently* closed and change the hold_copy_map, and change the current_copy?
16:45 Bmagic We want the hold targeter to target a different copy after giving the current_copy's owner an ample amount of time to pull it. For whatever reason, they didn't, so, let's get a different copy from the pool
16:46 Dyrcona I do believe you will have to change the code.
16:47 Bmagic Dyrcona: Thank you. That does help me believe it or not. Holds are fun!
16:48 Dyrcona I believe I have forgotten what that word means...."fun."
16:50 Bmagic Dyrcona: to your knowledge, is there a date that we can rely on for when the current_copy was selected?
16:51 Dyrcona Don't think so, but it should not be to difficult to make the code in OpenILS/Application/Storage/Publisher/action.pm ignore the current copy when finding a new target. Though you might to allow exceptions for the time when only that 1 copy can target.
16:52 mmorgan Bmagic: Dyrcona: would the org unit setting "circ.holds.max_org_unit_target_loops" not apply to this situation? After the number of max targeting attempts is reached, would it not move on to items with higher proximity?
16:52 Bmagic mmorgan: oooo, I like this
16:53 Dyrcona Dunno. never touched it.
16:53 Bmagic mmorgan: oh, yeah, I forgot, we already tried this
16:54 Bmagic mmorgan: it would appear that the lower proximity trumps max_org_unit_target_loops
16:54 mmorgan oh, too bad :-(
16:54 Bmagic unless we need to have it set to the specific branch (we had it set at consortium level and it didn't make a difference)
16:55 Bmagic mmorgan: do you happen to know where it records the number of times a branch is selected?
16:55 mmorgan So, after the max target attempts on the items with the lower proximity was reached, what happened to the hold?
16:56 mmorgan Hmm. don't know off the top of my head. Looking..
16:56 Bmagic mmorgan: nothing happens, the system continues to target the same copy (the one with the lower prox)
16:56 Dyrcona Looks like hold_copy_targeter uses the settings.
16:58 Dyrcona Ah. Looks like it is consulted if the pickup library does not have the best copy.
16:59 chatley joined #evergreen
17:00 Dyrcona Then, I'm not entirely sure what the rest is doing and no time to dig deeper right now.
17:00 Dyrcona Catch ya'll tomorrow.
17:00 Bmagic Later!
17:00 mmorgan Bmagic: don't see where the number of targeting attempts could be recorded. We aren't currently using that setting either.
17:01 Bmagic mmorgan: weird, you would think it would need a "history" of some kind
17:01 mmorgan But I would think if the setting were being consulted, the hold would get cancelled after the max number of target attempts.
17:01 Bmagic oh canceled?
17:03 Bmagic https://bugs.launchpad.net/evergreen/+bug/1037282
17:03 pinesol_green Launchpad bug 1037282 in Evergreen "Hold un-cancel does not clear target loops " (affected: 1, heat: 6) [Undecided,Triaged]
17:03 mmorgan I thought that was the idea, but, as I mentioned, we aren't using the setting.
17:04 Bmagic mmorgan: I think you are right, in which case, it's not really what we want
17:04 mmorgan That's why we aren't using it currently, but I still would think if there are copies elsewhere, the hold should move on rather than being cancelled.
17:05 mmorgan If the setting is being consulted.
17:06 Bmagic mmorgan: oh here we go, action.unfulfilled_hold_max_loop
17:08 Bmagic mmorgan: which refers back to action.unfulfilled_hold_list which only get's rows when the hold targeter runs (not when humans force the action). And we all know that the hold targeter doesn't pick a higher prox hold
17:10 mmorgan Are you using boundaries?
17:10 Bmagic mmorgan: help me - how would I know?
17:10 MrMayor joined #evergreen
17:11 mmorgan org unit settings: "circ.hold_boundary.hard", "circ.hold_boundary.soft"
17:12 Bmagic no, neither are set
17:12 MrMayor So this may be an easy answer and I have just overlooked it. Is there an easy way (or a hard way) to change when evergreen decides to accrue fines for patrons?
17:13 Bmagic MrMayor: Do you use an action trigger to automatically mark items lost after a set amount of time overdue?
17:13 mmorgan Bmagic: ok, we don't use them either. Our system targets low proximity first, but will target higher proximity if low proximity items aren't available.
17:14 * mmorgan must dash now. Holds sure are *fun*!
17:14 mrpeters left #evergreen
17:14 Bmagic mmorgan: I think a code change could still be required to solve our issue
17:14 Bmagic later!
17:14 mmorgan left #evergreen
17:14 MrMayor mmorgan: Yes we do.
17:15 Bmagic MrMayor: What types of fines are you interested in?
17:16 MrMayor I should have been more clear. It seems evergreen accrues daily fines at 11:59 p.m. Is there a way to change that behavior?
17:18 Bmagic MrMayor: I have recently found out that those times are not exactly when the fines are applied. Those are times are "when to check again". If you are referring to the money.billing table that is.
17:20 MrMayor I see. Ideally we would like fines to be applied in the early a.m. (12:01 for instance) instead of at the end of business.
17:23 Bmagic MrMayor: The fine generator is a piece of software that runs on your linux server. It runs whenever you tell it to run, usually on a cron job. When it runs, it applies fines but the date stamp that is uses is not the same time that it runs.
17:24 MrMayor Ahh interesting.  I will have to look into this. Thank you very much
17:40 Bmagic @later tell mmorgan: So, I was wrong. My tests were using the staff action "Find another target" which as I have learned, is not the same thing as the hold targeter running. So, with the hold targeter running, it DOES pick another copy from the pool regardless of the proximity
17:40 pinesol_green Bmagic: The operation succeeded.
17:40 Bmagic @later tell Dyrcona: So, I was wrong. My tests were using the staff action "Find another target" which as I have learned, is not the same thing as the hold targeter running. So, with the hold targeter running, it DOES pick another copy from the pool regardless of the proximity
17:40 pinesol_green Bmagic: The operation succeeded.
17:58 jihpringle joined #evergreen
18:05 bbqben joined #evergreen
18:20 jihpringle joined #evergreen
19:19 bbqben joined #evergreen
20:42 jonadab Oh, MrMayor's question would be relevant for us too.  (By policy, anything that comes in before 10am counts as having come back the previous day.  Because book drop.)
21:26 akilsdonk joined #evergreen
21:55 kmlussier jonadab: We usually handle book drop checkins by backdating the checkins. There is an effective date on the checkin screen where you can set the checkin date to the previous day.
21:57 jonadab Ah, interesting.
21:57 jonadab That might could be made to work.
23:00 artunit joined #evergreen

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