Time |
Nick |
Message |
00:30 |
|
sandbergja joined #evergreen |
06:46 |
|
agoben joined #evergreen |
07:27 |
|
bos20k joined #evergreen |
07:35 |
|
rjackson_isl joined #evergreen |
08:06 |
|
Dyrcona joined #evergreen |
08:09 |
agoben |
Silly question, but it's stumping me atm: if you update the Composite Attribute Entry Definitions on coded value map, does it require a restart of services to see the changes? |
08:35 |
|
collum joined #evergreen |
08:43 |
rhamby |
agoben: no, but you'll have to reingest the affected records |
08:43 |
agoben |
rhamby++ Thanks! |
08:45 |
|
mmorgan joined #evergreen |
08:50 |
mmorgan |
agoben: I'm not positive, but you may need to reingest record attributes to see changes. |
08:53 |
agoben |
mmorgan++ thanks! |
09:11 |
|
yboston joined #evergreen |
09:14 |
|
aabbee joined #evergreen |
09:26 |
|
jvwoolf joined #evergreen |
09:32 |
|
cmalm joined #evergreen |
09:35 |
|
tlittle joined #evergreen |
09:57 |
mmorgan |
I haven't looked at this in a long time, and I think I know the answer, but there's no way to block a patron based on how many days something is overdue, right? For example, block checkout when an item is one week overdue. |
09:57 |
|
gsams joined #evergreen |
10:19 |
|
Christineb joined #evergreen |
10:31 |
Bmagic |
After inserting rows into actor.org_unit_proximity_adjustment do I have to regenerate the actor.org_unit_proximity table? Shouldn't I see the adjustment reflected in that mapping? |
10:36 |
Dyrcona |
Bmagic: IIRC, "autogen.sh -c" takes care of it. |
10:37 |
Bmagic |
Dyrcona++ |
10:44 |
miker |
has anyone run into a workstation reg loop (both ang-js and new-ang) with recent master? no console errors before the redirect that I can see, but I constantly get pushed to workstation reg on login. incognito window included. full restart (including memcached) of everything, fresh install and no angjs or ang build problems |
10:45 |
berick |
miker: i've had that happen. usually deleting any workstations in the admin page workstation selector fixes it |
10:45 |
miker |
Bmagic: you won't see the change there. the result of the calculations using prox adjustment only live in action.hold_copy_map.prox |
10:45 |
Bmagic |
miker: ah! Sweet |
10:46 |
miker |
berick: mmm... even in fresh incognito? |
10:46 |
berick |
miker: i can't say for sure, but that's where I'd start |
10:48 |
miker |
unfortunately, that didn't help |
10:49 |
berick |
miker: hm, maybe try not in incognito mode? |
10:49 |
miker |
ws is in the db, in local storage |
10:49 |
berick |
oh, or disable the Hatch extension if it's turned on but Hatch is not running on the machine |
10:50 |
miker |
well, this try was in a normal tab. removed the one ws, reg'd a new one, "use now", back to workstation reg |
10:50 |
miker |
berick: OH... bah... thanks, trying that |
10:51 |
miker |
removed from chrome, new tab ... same result :( |
10:51 |
miker |
maybe restart chrome? I'll try that |
10:53 |
miker |
nope... restart didn't help. I'll try FF |
10:54 |
mmorgan |
miker: Cookie maybe? |
10:54 |
|
yboston joined #evergreen |
10:54 |
miker |
mmorgan: they were flushed (all but local storage, for the ws values) |
10:55 |
miker |
bah, same result in firefox |
10:55 |
Bmagic |
Everyone knows the real test results come from IE |
10:56 |
miker |
IE 5, to be exact |
10:56 |
Bmagic |
"It ain't broke if it works in Internet Explorer" |
10:59 |
Bmagic |
I installed Windows 95 on a VM recently. Hilarious. IE 1.0 |
10:59 |
Dyrcona |
Pfft... It's just plain broken. |
11:00 |
Bmagic |
The days when you had to "install" TCP/IP |
11:03 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live/test.41.html#2019-08-29T11:00:49,587271975-0400 -0> |
11:04 |
Dyrcona |
Eh, well, the Internet was "new..." |
11:04 |
gmcharlt |
^ bah, humbug |
11:04 |
gmcharlt |
er, ^^^ |
11:04 |
* gmcharlt |
looks at the failure |
11:04 |
Dyrcona |
:) |
11:04 |
Dyrcona |
:( |
11:08 |
miker |
MS was all, "what's this 'IP' crap? what's wrong with IPX/SPX?" |
11:09 |
Bmagic |
haha, yeah! IPX and NetBEUI. Good times |
11:09 |
pinesol |
[evergreen|Galen Charlton] fix bad conflict resolution made merging LP#1825851 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71a8ada> |
11:10 |
Dyrcona |
miker: That *might* be your problem right there... If chunks of schema failed to create. |
11:11 |
Dyrcona |
But, that's likely not it....after taking another look at the commit diff. |
11:11 |
* Dyrcona |
goes back to hitting softballs. |
11:13 |
|
jihpringle joined #evergreen |
11:18 |
|
sandbergja joined #evergreen |
11:19 |
miker |
Dyrcona: I wish it were... |
11:27 |
|
mmorgan1 joined #evergreen |
11:27 |
|
khuckins joined #evergreen |
11:53 |
Bmagic |
well, action.hold_request_permit_test still results in a failure "config.rule_age_hold_protect.prox" - It doesn't seem that this code consults the proximity adjustment table |
11:54 |
Bmagic |
The hold rule that it choses is perfect. It's the one I created to specifically allow the two systems to lend to eachother. And it's an Allow rule. Even though it's an allow rule, the rest of the permit test code "IF hold_transit_prox > age_protect_object.prox THEN" |
11:56 |
Dyrcona |
hold_transit_prox should be calculated using proximity adjustments. If not, that's a bug. |
11:56 |
Dyrcona |
Could be your adjustment is incorrect. |
11:57 |
Bmagic |
I'm using the system to adjust to the other system. Maybe I need to install adjustment rows for each combo of branches? |
11:58 |
Dyrcona |
yeah, I think you do. |
11:58 |
Bmagic |
I still can't seem to find the reference in the SQL to the adjustment table |
12:00 |
Dyrcona |
Well, maybe it doesn't use it, which I think is a bug. |
12:01 |
Bmagic |
It sure seems like it should use it. It does* consult actor.org_unit_proximity which tells me the logic is there to decide if it's "too far" when age protected |
12:04 |
Dyrcona |
I have never really messed with it, so I am not sure what it is or isn't supposed to do. |
12:04 |
Bmagic |
As a last ditch effort, and if there is some code somewhere that I don't see is using the adjustment table, I'm installing adjustment rows for the combinations of each branch |
12:08 |
|
tlittle joined #evergreen |
12:08 |
Dyrcona |
It has been a few years since I last looked at how proximity adjustments work, so I could be wrong, but yeah, I would try branch to branch adjustements. I don't think it is aware of a hierarchy. |
12:09 |
Bmagic |
didn't work BUT I might be using the wrong columns. I'm setting these item_circ_lib,hold_pickup_lib |
12:10 |
Dyrcona |
You run autogen.sh -c after adding the new rows? |
12:10 |
Bmagic |
no, will do |
12:12 |
Bmagic |
wait, -u maybe? |
12:14 |
Dyrcona |
Maybe. I'd have to look at the script again. |
12:15 |
Bmagic |
yeah, -u |
12:15 |
Bmagic |
Refreshing proximity of org units;Successfully updated the organization proximity |
12:18 |
Bmagic |
yeah, as I suspected, didn't change the outcome of the permit test |
12:18 |
Dyrcona |
All right, my bad for giving you the wrong option... |
12:19 |
Bmagic |
at this point, I'm 99% sure that it doesn't take into account the adjustments |
12:19 |
Dyrcona |
Well, you could open a bug or you can tell the libraries that they can't share age protected items with each other. |
12:19 |
Bmagic |
:) |
12:47 |
bshum |
Probably both |
13:10 |
miker |
UPDATE: my earlier issue was ye olde "need to copy conf idl to reports idl on dev machine" ... wheee |
13:16 |
|
mmorgan joined #evergreen |
13:35 |
|
collum_ joined #evergreen |
13:35 |
|
collum__ joined #evergreen |
13:54 |
Bmagic |
bshum Dyrcona miker: bug 1841974 |
13:54 |
pinesol |
Launchpad bug 1841974 in Evergreen "action.hold_request_permit_test should consult proximity adjustments" [Undecided,New] https://launchpad.net/bugs/1841974 |
14:12 |
Bmagic |
eg/staff/cat/bucket/record/view grid settings in 3.2 do not seem to save. However, I can see that the tt2 contains persist-key="cat.bucket.record.view" and furthermore, I can see that my settings are getting saved into the server |
14:13 |
Bmagic |
but, when I load the page, the grid doesn't apply my settings |
14:19 |
|
khuckins joined #evergreen |
14:36 |
dbs |
miker: if only there was a better/more robust way to translate XML than via XML entities and mod_xmlent :/ |
14:43 |
Bmagic |
Dyrcona: the assumption that the hold would get filled by the hold targeter after the hold is overriden at placement time turns out to be false. The hold targeter also uses the "action.hold_retarget_permit_test" code |
14:53 |
mmorgan |
Bmagic: bug 1805895 |
14:53 |
pinesol |
Launchpad bug 1805895 in Evergreen 3.2 "Bucket grid configuration updates do not save" [Medium,Fix released] https://launchpad.net/bugs/1805895 |
14:54 |
Bmagic |
mmorgan++ |
15:07 |
|
mmorgan1 joined #evergreen |
15:21 |
|
yboston joined #evergreen |
15:22 |
Bmagic |
isn't it possible to purge a patron without supplying a "merge to" usr? |
15:23 |
Bmagic |
I guess select from actor.usr_delete(12345,null) ? |
15:26 |
Dyrcona |
Bmagic: Yes, and no. IF you use null, then user id of 1 is used by default. |
15:26 |
Bmagic |
Ah, I see that |
15:26 |
* Dyrcona |
isn't really here and disappears again. |
15:26 |
Bmagic |
Dyrcona++ |
15:32 |
|
khuckins joined #evergreen |
15:56 |
|
mmorgan joined #evergreen |
16:17 |
|
jvwoolf left #evergreen |
17:03 |
|
sandbergja joined #evergreen |
17:05 |
|
mmorgan left #evergreen |
20:39 |
|
sandbergja joined #evergreen |
23:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
23:43 |
|
sandbergja joined #evergreen |