| 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 |
