| Time |
Nick |
Message |
| 00:27 |
pinesol_green |
[evergreen|Cesar Velez] LP#1710405 - remove Modify + Use Edits buttons in z3950 overlay - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bfd5b2f> |
| 02:12 |
|
gsams_ joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
JBoyer joined #evergreen |
| 07:27 |
|
rjackson_isl joined #evergreen |
| 08:11 |
|
kmlussier joined #evergreen |
| 08:13 |
|
rlefaive joined #evergreen |
| 08:14 |
|
agoben joined #evergreen |
| 08:16 |
kmlussier |
LP timeouts already? |
| 08:16 |
|
jvwoolf joined #evergreen |
| 08:18 |
|
jvwoolf1 joined #evergreen |
| 08:20 |
|
krvmga joined #evergreen |
| 08:25 |
rhamby |
kmlussier: it wanted to get an early start |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:38 |
|
rlefaive joined #evergreen |
| 08:51 |
|
rlefaive joined #evergreen |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
yboston joined #evergreen |
| 09:59 |
|
bos20k joined #evergreen |
| 10:07 |
|
terran joined #evergreen |
| 10:17 |
Bmagic |
berick: Is it possible that the new hold targeter is not respecting age based hold protection? We have many hold rules that look like are suddenly allowing patrons to get items that are age protected accross systems. |
| 10:18 |
Bmagic |
accross/across |
| 10:18 |
terran |
In the "not sure if it's just me" category - in our 3.0.2 test server, when I print a list of current bills, it's only printing circ bills and not grocery. Don't see this problem on our 3.0.0 test server. |
| 10:19 |
terran |
Does anyone have a moment to test this on their 3.0.2 server? |
| 10:19 |
Bmagic |
terran: sure |
| 10:19 |
Bmagic |
let me see if I can dig up a patron with both types |
| 10:19 |
terran |
Bmagic: Thanks! |
| 10:20 |
Bmagic |
terran: did csharp ask you to confirm another scenario that I mentioned to him yesterday? |
| 10:20 |
terran |
Bmagic: no, but he's been in meetings all morning and I've barely seen him yet |
| 10:21 |
Bmagic |
it's easy - can you confirm that the patron hold notification preferences simply do not show up in Webby and clearly are there in XUL? |
| 10:21 |
Bmagic |
when editing a patron |
| 10:21 |
terran |
Bmagic: Sure, I'll check |
| 10:23 |
berick |
Bmagic: age protect is handled in the DB hold permit test. that stuff didn't change with the new targeter. |
| 10:25 |
terran |
Bmagic: The first account I checked has Email and SMS checked and it shows up in both My Account and the web client. I'll create a new test account and check it. |
| 10:25 |
Bmagic |
terran: interesting.... |
| 10:25 |
Bmagic |
berick: darn, I was hoping it would be explained easily.... |
| 10:26 |
Bmagic |
berick: I suppose it's possible that no one noticed this flaw in our hold rules until now... |
| 10:29 |
JBoyer |
Bmagic, I'm not sure what you're seeing, but I don't think the age protection value in the hold rules has anything to do with items actually having age protection. I thought that was checked in perl after a holds rule was chosen. |
| 10:30 |
terran |
Bmagic: I created a new account and left email and phone checked by default. Tested in OPAC and it was fine. Edited in web client and the settings still appeared. Made changes in OPAC. Changes showed up in web client. |
| 10:31 |
terran |
Bmagic: I recall seeing a lot of problems with this type of thing in 2.12. |
| 10:31 |
JBoyer |
You don't have a custom .tt2 for the patron editor do you? I think half (or more) of the fix for that was in the template. |
| 10:32 |
kmlussier |
Yes, what JBoyer sounds vaguely familiar. Age protection needs to be applied at the copy level. |
| 10:34 |
Bmagic |
terran: thanks for checking that, maybe it is just me. JBoyer: it sounds like this was a problem in the past? And perhaps I have some old tt2 files..... weird. I will have to investigate |
| 10:35 |
Bmagic |
terran: still digging up the scenario on the billing print |
| 10:37 |
JBoyer |
Just a possibility. I know that hold notifications should be working in 3.0 though, because I was involved in fixing them. :) (and just verified on my 3.0.2-ish production system) |
| 10:38 |
Bmagic |
terran: confirmed, it does not include the non circulation bills |
| 10:38 |
kmlussier |
terran: Yes, I can confirm it too. |
| 10:39 |
terran |
Bmagic++ and kmlussier++ I'll create a new bug |
| 10:39 |
Bmagic |
terran: if I only check the box for the grocery bill and print that, I get blank between header and footer |
| 10:45 |
terran |
Ack, meeting time. I'll file the bug report as soon as this is over. |
| 10:48 |
Dyrcona |
Bmagic: You're asking about the item_age field in the hold_matrix_matchpoint. |
| 10:48 |
Bmagic |
Dyrcona: yes |
| 10:48 |
Dyrcona |
Bmagic: That's not for aged hold protection. |
| 10:48 |
Bmagic |
it's called "copy age hold protection rule" |
| 10:49 |
Dyrcona |
Where is it called that? |
| 10:49 |
Dyrcona |
That's not what it does, exactly. |
| 10:49 |
Dyrcona |
If you're going to use age protection you do that on the copy as kmlussier said earlier. |
| 10:49 |
Bmagic |
I happen to be looking at XUL. It's the name of the column next to active in the giant dojo grid |
| 10:50 |
Dyrcona |
Well, that name is misleading in my opinion. |
| 10:50 |
JBoyer |
There are both, item_age (does what it says on the tin) and age_hold_protect_rule which is for something else. |
| 10:50 |
Bmagic |
it's the label also when editing the rule |
| 10:51 |
Dyrcona |
The field has a default weight of 0, which means it almost never applies. |
| 10:51 |
Bmagic |
I am referring to age_hold_protect_rule - the options correlate with the options that we have for age based hold protection |
| 10:51 |
kmlussier |
What exactly does that field do in the hold matrix? I don't think I ever figured out the answer to that question when we stumbled across this issue years ago. |
| 10:52 |
Bmagic |
I am not referring to item age, sorry I misunderstood. I am definitely not referring to item age |
| 10:52 |
* mmorgan |
thought that field in the hold matrix allowed for different circ rules for items with those values. Never have used or tested it, though. |
| 10:52 |
Dyrcona |
Basically, it prevents a given matrix matchpoint from applying to an item less than that age. |
| 10:52 |
JBoyer |
And the comments light the way. It's not for matching, it's for returning. There's a comment in 110.hold_matrix_matchpoint about not being sure someone wanting to remove it from acp. The intent (if not the result) is that a matching row with a non-null age_hold_protect_rule would apply that rule to the copies even if their age rule is null. |
| 10:53 |
Dyrcona |
Basically, it makes no sense. :) |
| 10:54 |
JBoyer |
I don't know if that part is actually hooked up anywhere, as that has to happen elsewhere. |
| 10:54 |
Dyrcona |
It is hooked up in the function that pulls out matchpoints. |
| 10:54 |
Dyrcona |
Line 187 in 110.hold_matrix.sql |
| 10:55 |
JBoyer |
Yeah, I mean the "apply this rule even if the copy has no age protection" part of it. |
| 10:55 |
* kmlussier |
can't keep all of these search bugs straight. |
| 10:55 |
Dyrcona |
It's applied even if the copy does. |
| 10:56 |
JBoyer |
Dyrcona, Ah, I think Bmagic and kmlussier are talking about age_hold_protect_rule. That's the thing I don't think is hooked up the way the comments say. |
| 10:56 |
JBoyer |
I also think we've all been talking past each other for a couple minutes since it takes so long to bang out these responses. :) |
| 10:56 |
Dyrcona |
Well, Bmagic was talking about the hold matrix specifically. |
| 10:56 |
Dyrcona |
If the age hold protect rule shows up in the matrix grid, that's a bug. |
| 10:57 |
Dyrcona |
I'm assuming item_age is mislabeled in the grid, but I never use the gird, nor have I ever used item_age. |
| 10:57 |
JBoyer |
Check out line 58 of that file. It's not a match point, it's a return value. |
| 10:58 |
Dyrcona |
Oh, I see. |
| 10:58 |
JBoyer |
and no, item_age isn't mislabled, there was just some confusion earlier. |
| 10:58 |
Dyrcona |
I never specifically configured that in matchpoints because it isn't used in matchpoints. |
| 10:58 |
JBoyer |
Bmagic, to summarize, are you trying to apply hold protection rules through the hold matrix, or something else? |
| 10:59 |
Dyrcona |
The age_hold_protect rules are used after the fact to remove copies form the list, IIRC. |
| 10:59 |
Bmagic |
we are finding that age protected items are filling holds with pickup locations outside of the item's system |
| 10:59 |
Dyrcona |
That field should be removed from the matrix since it is not used by the function. |
| 10:59 |
Bmagic |
we thought that wasn't supposed to happen |
| 11:00 |
JBoyer |
Dyrcona, it's a return value. I would think it's supposed to be used outside the function. (I just don't know if it is.) |
| 11:00 |
kmlussier |
miker: For bug 1730758, did you want to address the issue I mentioned in comment #10 in the bug or should it be handled through a separate bug? I was thinking it might be easier to handle it all in one upgrade script. |
| 11:00 |
Dyrcona |
It's not, but that depends on settings and the age of the item and what rule applies. |
| 11:00 |
pinesol_green |
Launchpad bug 1730758 in Evergreen "biblio.record_entry.vis_attr_vector not updated upon adding a locate URI" [Medium,Confirmed] https://launchpad.net/bugs/1730758 |
| 11:00 |
mmorgan |
Bmagic: Have you checked that the values in config.rule_age_hold_protect.prox are correct? |
| 11:00 |
Dyrcona |
holds-- |
| 11:00 |
Bmagic |
mmorgan: yes, they are correct - value is 2 |
| 11:01 |
* mmorgan |
nods |
| 11:02 |
mmorgan |
And all the copies in question have an age_hold protection rule set, and that the rule has not expired based on the created date (or active date)? |
| 11:02 |
Bmagic |
when running the hold permit test, I find that it's matching a rule with a null value for age_hold_protect_rule - which means "copies with anything in this column" ? |
| 11:03 |
Dyrcona |
Bmagic: I've never filled in that field in the matrix and age hold protection has always worked as I expected it to. |
| 11:03 |
Dyrcona |
I honestly don't think the field in the matrix is used, but I need to do some archeology to be certain. |
| 11:03 |
Bmagic |
We have rules in place for each of our systems that explicitly permit holds from items anywhere in the consortium to patrons in each of the systems. One rule per system. |
| 11:04 |
JBoyer |
Bmagic, nope. age_protect_rule isn't used to match in the holds matrix, it's (intended to be) used to apply age protection to copies that don't have it. I assume so you can do more complicated things with keeping holds from going from one place to another. |
| 11:05 |
Bmagic |
JBoyer: that is what we thought! And that is the way the system had been behaving. It's been disallowing items with age protection from filling holds outside of the proximity specified in config.rule_age_hold_protection. But recently that isn't working |
| 11:06 |
Bmagic |
So, back to my original question, since we are using the hold targeter v2, I was wondering if it had anything to do with that |
| 11:06 |
Bmagic |
berick says no because v2 didn't change any of the SQL logic |
| 11:06 |
JBoyer |
I doubt it, because we've been using it since it was released. (we would definitely hear about that...) |
| 11:07 |
JBoyer |
I was going to ask though, is it targeting things on the shelf it shouldn't, or did someone return a copy somewhere that tried to use it for a hold that wouldn't normally be allowed? |
| 11:14 |
Bmagic |
JBoyer: I believe the scenario that I am looking at had the copies on a pull list. So copies on the shelf |
| 11:16 |
Bmagic |
JBoyer: just confirmed that my templates are stock, so I'm back to searching for the issue on those checkboxes |
| 11:18 |
Bmagic |
JBoyer: aha, refreshing caused those checkboxes to populate, perhaps we have another timeout issue? |
| 11:24 |
|
Christineb joined #evergreen |
| 11:41 |
Bmagic |
terran: it seems that those notification preferences randomly are not populated, if you ever see them non-checked when they should be, perform a browser refresh page and violla |
| 11:43 |
Bmagic |
JBoyer: just to be clear, when performing a hold permit test with the SQL funciton, it should pass and provide the matching rule even with age based hold protection on the copy because that logic happens in perl? |
| 11:45 |
JBoyer |
Yeah, that way you can see if the hold is even possible. Just finding a matching row doesn't mean you've targeted a copy. |
| 11:45 |
JBoyer |
(or that you've found a copy to target, rather.) |
| 11:51 |
|
khuckins joined #evergreen |
| 11:59 |
berick |
Bmagic: JBoyer: the copy age protect test happens in the in-db function too |
| 12:00 |
Bmagic |
berick: which function should I be testing with? |
| 12:00 |
berick |
action.hold_request_permit_test and action.hold_retarget_permit_test |
| 12:01 |
Bmagic |
the one that should be denying this copy with age protection to this patron |
| 12:01 |
terran |
Bmagic: Thanks for confirming the bill printing problem, bug reported at: https://bugs.launchpad.net/evergreen/+bug/1742194 |
| 12:01 |
pinesol_green |
Launchpad bug 1742194 in Evergreen "Web Client: Print Current Bills only prints circ not grocery" [Undecided,New] |
| 12:01 |
Bmagic |
berick: when creating the hold, the system decides weather or not to insert the row in action.hold_request by using these rules. Once the row is created, the rules are no longer referred to? |
| 12:02 |
berick |
Bmagic: that's not true |
| 12:02 |
berick |
age protect and other filters, etc. are checked every time a copy is put onto the pull list or captured during checkin. |
| 12:02 |
Bmagic |
I'm (re)learning |
| 12:03 |
berick |
if a copy is on the pull list, action.hold_retarget_permit_test returned success=true |
| 12:03 |
Bmagic |
alright, I will run this scenario through |
| 12:04 |
terran |
Bmagic: re notification preferences: weird, I will keep my eyes open for that problem. |
| 12:05 |
miker |
kmlussier: was in a meeting ... I can look at the comment #10 thing quickly and see if it's trival |
| 12:05 |
Bmagic |
terran: along those same lines, we find that the transit slips print the wrong stuff until you print it a second time |
| 12:06 |
terran |
Bmagic: I saw your report on that, but we haven't seen that happen in testing yet either. It may be that we see both of these after we are in production next week. |
| 12:06 |
Bmagic |
terran: it's tough to find because it doesn't happen always |
| 12:06 |
krvmga |
we have an item in our catalog that includes both a CD and a DVD. is there any way for us to display both icons for this in the catalog? |
| 12:07 |
Bmagic |
I am finding a common theme, where refreshing the screen corrects the issue |
| 12:07 |
Bmagic |
krvmga: I believe so, You will need to define two 007's in the MARC |
| 12:08 |
Bmagic |
one for the CD and one for the DVD |
| 12:09 |
krvmga |
yes, the record type for the DVD is g and the music CD is j |
| 12:09 |
krvmga |
I added the 007 field for the CD and the record already had an 006 field for the sound recording type but the system is not picking up the codes for the CD. |
| 12:10 |
terran |
Bmagic: so it may be caching data? I have noticed when making changes to print templates and spine label templates, it doesn't always recognize the changes right away. |
| 12:10 |
Bmagic |
terran: I think it's a race condition |
| 12:11 |
terran |
Bmagic: Ah, that would explain why it doesn't always happen |
| 12:11 |
Bmagic |
terran: where the UI is ready to show but the data isn't. Like this one |
| 12:11 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1642036 |
| 12:11 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] |
| 12:14 |
terran |
Bmagic: FWIW, we have your patch on our test server and it's been working there, but we don't have it in production yet. |
| 12:15 |
Bmagic |
I think bug 1642036, bug 1740537, bug 1361258 might have some of the same underlying causes |
| 12:15 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] https://launchpad.net/bugs/1642036 |
| 12:15 |
pinesol_green |
Launchpad bug 1740537 in Evergreen "Web client: Transit slip printing with wrong information" [Undecided,New] https://launchpad.net/bugs/1740537 |
| 12:15 |
pinesol_green |
Launchpad bug 1361258 in Evergreen "Patron registration form does not set notification preferences" [Undecided,Confirmed] https://launchpad.net/bugs/1361258 |
| 12:16 |
Bmagic |
terran: that patch for group member details? I think gmcharlt is right and the patch I have there isn't the answer. The right path to take would be using the angular timeout chain. |
| 12:16 |
|
rlefaive joined #evergreen |
| 12:17 |
terran |
Bmagic: That makes sense. However, if it's not fixed this week, we'll roll out with your patch until a fix is ready. |
| 12:18 |
Bmagic |
terran: right on. that patch should make the issue occur less :). We could wrap the code in 10 more loops and it would occur even more less frequently! |
| 12:18 |
Bmagic |
I love saying more less |
| 12:20 |
terran |
:D |
| 12:23 |
Bmagic |
krvmg: example http://missourievergreen.org/eg/opac/record/2039680 |
| 12:23 |
Bmagic |
krvmga ^^ |
| 12:23 |
kmlussier |
terran: Your upgrade is this weekend? |
| 12:25 |
krvmga |
Bmagic++ |
| 12:30 |
terran |
kmlussier: Yes |
| 12:30 |
kmlussier |
terran: Best wishes with the upgrade! I hope it goes well! |
| 12:32 |
terran |
kmlussier: Thanks! There are still a few things we're concerned about, but with the exception of cataloging, we're fairly optimistic. |
| 12:34 |
kmlussier |
miker++ # Continued work on search bugs! |
| 12:45 |
miker |
kmlussier: not sure if you saw it, but there's yet another update to 1730758. you can apply the 2-line sql in the comment rather than rebuilding everything and source vis cache changes should work as expected now |
| 12:45 |
Bmagic |
terran: if it goes anything like ours, you will be fine! It was pretty seemless. |
| 12:45 |
kmlussier |
miker: Thanks! |
| 12:48 |
terran |
Bmagic: Good! |
| 12:50 |
Bmagic |
anyone else out there find rows in money.materialized_billable_xact_summary where id not in(select id from money.grocery) ? |
| 12:51 |
Bmagic |
I have 9815175 rows |
| 12:51 |
JBoyer |
Those would be from action.circulation. |
| 12:52 |
Bmagic |
oh oops, I mean to look at money.billable_xact |
| 12:52 |
JBoyer |
(money.grocery and action.circulation share the same serial function for their ids.) |
| 12:53 |
Bmagic |
JBoyer: right, I was comparing the wrong tables. money.billable_xact should have a row that accounts for rows in action.circulation and money.grocery |
| 12:53 |
Bmagic |
and money.materialized_billable_xact_summary for that matter |
| 12:54 |
JBoyer |
Oh, if you're seeing ids that aren't in either table they're probably in action.aged_circulation then. |
| 12:56 |
Bmagic |
good point |
| 13:01 |
JBoyer |
That all said, we do have 32 rows in money.billable_xact that don't exist in any of those 3 tables. Huh. |
| 13:04 |
|
kmlussier joined #evergreen |
| 13:07 |
Dyrcona |
Well, there are ways you could insert into money.billable_xact itself. |
| 13:08 |
Dyrcona |
In the database, at least. |
| 13:11 |
|
jihpringle joined #evergreen |
| 13:24 |
|
rlefaive joined #evergreen |
| 13:33 |
|
jwoodard joined #evergreen |
| 13:40 |
* phasefx |
is going to suppress the flagging of those lovefield offline DB errors for now on the live tester |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:21 |
kipd |
Potentially silly question. I needed to literally make a one character change in Application/Circ/HoldNotify.pm and run make again and will run make install. I need to restart OpenSRF and the Apache instances for that to take effect, right? |
| 15:23 |
Bmagic |
berick: It might help if I use the right item ID. Now I am getting "config.rule_age_hold_protect.prox" |
| 15:28 |
Dyrcona |
kipd: You can do --restart-all with osrf_control and restart apache, or you can do --stop-services then --start-services, and I don't think you have to restart apache. |
| 15:29 |
kipd |
Sounds good, thanks. |
| 15:29 |
berick |
Bmagic: that's what I would expect to see |
| 15:30 |
Dyrcona |
Changing Holds.pm, you may just need to restart circ and hold_targeter services. |
| 15:30 |
Bmagic |
berick: I do have a row in theauditor.action_hold_request_history table that tells me that this copy was in fact targeted. Now I am looking to see if that copy was age protected at that time or if was added later |
| 15:32 |
Bmagic |
darn. The answer is: yes, it was age protected on Jan 5th |
| 15:33 |
Bmagic |
age_protect column has been set since it was cataloged |
| 15:36 |
Bmagic |
I think it captured during a checkin and not on the pull list. Considering that it was cataloged 5 days ago. |
| 15:37 |
jeff |
haven't been following, so it might not matter or might have already been checked, but since you're question age hold protection and have auditing enabled for ahr, have you verified that the pickup location of the hold has remained constant? |
| 15:53 |
|
jvwoolf joined #evergreen |
| 16:25 |
Bmagic |
jeff: yes, remained the same |
| 16:26 |
Bmagic |
right now my theory is that the workstation that checked the item in is mistakenly registered to the foreign branch.... |
| 16:26 |
Bmagic |
I'm not sure that is technically possible with the staff login accounts that they have there, but hey, one can hope! |
| 16:29 |
Dyrcona |
Bmagic: You can check that theory by looking at checkin_lib for the circulation of that item. |
| 16:29 |
Bmagic |
there isn't a circulation |
| 16:30 |
Bmagic |
it's a newly cataloged item checkin |
| 16:30 |
Dyrcona |
Oh. I see... Someone checked it in just to trap a hold, did they? |
| 16:30 |
Bmagic |
I think the routine is to checkin after the cataloging is done in order to change the status and capture any holds. Which is what it did, but it captured a hold for a patron that shouldn't be allowed to have it for 6 months |
| 16:30 |
Dyrcona |
If that was mentioned before, I missed it. I stopped paying attention after a while. :) |
| 16:31 |
Dyrcona |
Yeah, that's pretty standard. |
| 16:31 |
Bmagic |
except the part about the hold for the pickup location > 2 proximity |
| 16:31 |
Dyrcona |
The check in of new items, I mean. The age hold protection failing is not standard. |
| 16:32 |
Dyrcona |
I don't think there are ways for staff to force a copy onto a hold. |
| 16:33 |
Dyrcona |
Have you checked the logs or do you not have enough information to find the checkin in the logs? |
| 16:33 |
Bmagic |
I had that thought but I figured they have been rotated out by now.... but I suppose I could double check that |
| 16:33 |
Dyrcona |
Should be a check in message that would tell you the workstation. |
| 16:33 |
Dyrcona |
Well, depends on how long you're keeping logs, etc.... |
| 16:34 |
Dyrcona |
And, now that I think about it, the message in the logs may not be that useful.... |
| 16:35 |
|
mmorgan joined #evergreen |
| 16:36 |
* Dyrcona |
looks for a sample in the current syslog and watches reams of text scroll by. :) |
| 16:38 |
Dyrcona |
Rats. I just see stuff like AUTHKEY, HASH(0x....) |
| 16:38 |
berick |
has printing to Hatch from iframes come up yet? i feel like it must have. e.g. the Print Worksheet link in the ACQ UI. I'm sure there are catalog examples too. |
| 16:38 |
berick |
Dyrcona: you can determine the workstation from the authkey |
| 16:38 |
Dyrcona |
berick++ That is true! |
| 16:48 |
Bmagic |
Dyrcona: auditor.asset_copy_history never shows it going in-transit.... |
| 16:49 |
Bmagic |
and no rows in action.transit_copy |
| 16:54 |
Bmagic |
oh, I think I see. It WAS a pull list situation and never captured. Details details |
| 16:58 |
Dyrcona |
Well, I'm going to give up pretending that I know how holds work. :) |
| 17:01 |
Dyrcona |
Catch everyone tomorrow. |
| 17:01 |
mmorgan |
Bmagic: Forced hold by any chance? |
| 17:01 |
Bmagic |
mmorgan: no |
| 17:05 |
* mmorgan |
needs to run, but wonders if Bmagic's age hold protection goes by create_date or active_date, and wonders what those values are for the copy. |
| 17:05 |
Bmagic |
berick: Dyrcona: ha! I found the lines in the hold targeter log where it "targeter: [hold 1004507] exiting => successfully targeted copy 3533553" |
| 17:08 |
|
mmorgan left #evergreen |
| 17:09 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "Hold targeter choosing age base protected item" (46 lines) at http://paste.evergreen-ils.org/965 |
| 17:10 |
Bmagic |
there are some warning leading up to the action.hold_retarget_permit_test |
| 17:13 |
Bmagic |
it looks like the targeter received empty values for the proximity in the hold_copy_map? |
| 17:13 |
Bmagic |
looking at the database today, I find that those columns are non-null but I don't have an easy way of seeing the state of that table on 2018-01-05 11:20:30 |
| 17:15 |
Bmagic |
furthermore, if I execute select * from action.hold_request_permit_test(163,163,3533553,177136,177136) - it fails! But somehow it succeeded on that day at that time. I guess I can chalk it up to computer voodoo |
| 17:19 |
berick |
Bmagic: those warnings suggest the hold_copy_map contained no proximity data for the copy. |
| 17:19 |
berick |
that lack of data could have affected the age protect calculation in the permit call |
| 17:19 |
Bmagic |
that must have been the reason |
| 17:19 |
Bmagic |
so, the step that fleshes that table was messed up on this day |
| 17:20 |
Bmagic |
select * from action.hold_copy_map where proximity is null returns two rows right now..... |
| 17:24 |
Bmagic |
looking at the function action.hold_request_regen_copy_maps - I find that it doesn't insert proximity |
| 17:24 |
berick |
Bmagic: trigger on hold_copy_map |
| 17:25 |
Bmagic |
ah |
| 17:26 |
csharp |
autogen.sh on the server running the hold targeter? (pretty sure that needs to happen, right?) |
| 17:26 |
Bmagic |
I am concluding that action.hold_copy_calculated_proximity sometimes returns null |
| 17:26 |
csharp |
Bmagic: we have no rows from the query you just posted, fyi |
| 17:27 |
Bmagic |
how does autogen matter when executing SQL proceedures/triggers? |
| 17:27 |
Bmagic |
csharp: which one? lol, are you replacing those ID numbers with relavent ones in your data? |
| 17:28 |
csharp |
select * from action.hold_copy_map where proximity is null |
| 17:28 |
Bmagic |
relavent/relevant |
| 17:28 |
csharp |
Bmagic: I was looking at osrfsys.log.4.gz:[2018-01-05 11:20:30] open-ils.hold-targeter [WARN:2034:Application.pm:624:1515171602322802] open-ils.hold-targeter.target: Use of uninitialized value $prox in hash element at /usr/local/share/perl/5.22.1/OpenILS/Utils/HoldTargeter.pm line 665. |
| 17:28 |
Bmagic |
oh yes! thanks for checking that. Getting null proximity has got to be a problem |
| 17:29 |
Bmagic |
somehow between now and then, the hold targeter started getting proximity results from that trigger and everything is just fine.... |
| 17:29 |
csharp |
and that is solved by autogen.sh (or at least it used to be :-/) |
| 17:30 |
* csharp |
never has completely unwound what autogen.sh does enough to know where it needs to be run |
| 17:30 |
Bmagic |
no kidding.... I think I recently ran autogen on that server where I hadn't before then, but I wonder how I still have two rows with null values for proximity |
| 17:31 |
Bmagic |
I think I can explain those null rows. The associated holds are captured and the hold targeter isn't refreshing the hold copy map |
| 17:31 |
csharp |
perl -MOpenILS::Utils::Configure -e "OpenILS::Utils::Configure::org_tree_proximity();" |
| 17:31 |
csharp |
it does that^ |
| 17:32 |
berick |
autogen may be needed there if it's a new org unit |
| 17:33 |
berick |
it creates the org-to-org proximity values |
| 17:47 |
Bmagic |
we certainly add new org units and rerun autogen afterwards. But I do believe that I neglect the utility server sometimes |
| 17:49 |
Bmagic |
I have to ask though, the org units in question for this particular case are old* and should have rows in the proximity table already, also, running autogen updates the database and therefore the utility server should have access to the values regardless of which machine ran it? |
| 17:55 |
berick |
right, you only have to run autogen once to update the org proximity table |
| 17:55 |
berick |
beware there is an autogen flag to do the proximity updates, though |
| 17:56 |
berick |
and yes if the orgs are old and already had proximities, the org-to-org proximities may not be the cause of the problem. |
| 17:56 |
berick |
just guessing, but could be an issue with proximity adjusment configuration |
| 18:20 |
Bmagic |
That system does have an adjustment set... More on this when I get back to it Thursday. |
| 18:20 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
rlefaive joined #evergreen |
| 18:43 |
miker |
autogen.sh -u should no longer be needed. a trigger should be handling that |
| 18:43 |
* miker |
disappears |
| 18:47 |
|
dbwells_ joined #evergreen |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13d0596> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2, part deux - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d63b81f> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Bib visibility tests get OR'd - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=979d0c2> |
