| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:10 |
|
rjackson_isl_ joined #evergreen |
| 07:36 |
|
agoben joined #evergreen |
| 07:49 |
|
derekz joined #evergreen |
| 07:54 |
JBoyer |
A fun game to play: open the same file in 2 different tabs on 2 different machines (one to edit, one for reference); make some edits in one tab, some edits in the other tab, wonder why nothing works as expected. |
| 07:59 |
|
rlefaive joined #evergreen |
| 08:39 |
|
rlefaive joined #evergreen |
| 08:41 |
|
ngf42 joined #evergreen |
| 09:05 |
|
bos20k joined #evergreen |
| 09:17 |
|
Dyrcona joined #evergreen |
| 09:19 |
csharp |
so glad bug 1745499 has been reported - just got a ticket about item barcode upload "not doing anything" after having to manually manage crazy server load during the period where they were testing uploads over and over |
| 09:19 |
pinesol_green |
Launchpad bug 1745499 in Evergreen "Web client: Barcode file upload inflates pcrud drone count" [Undecided,Confirmed] https://launchpad.net/bugs/1745499 |
| 09:19 |
csharp |
berick++ # fix for patron bucket upload |
| 09:25 |
|
kmlussier joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:52 |
berick |
csharp++ # bug 1745610 |
| 09:52 |
pinesol_green |
Launchpad bug 1745610 in Evergreen "deprecate legacy hold_targeter.pl in favor of new one" [Wishlist,New] https://launchpad.net/bugs/1745610 |
| 09:52 |
berick |
been meanging to do that |
| 09:52 |
berick |
and to take spelling lessons |
| 10:44 |
|
jvwoolf joined #evergreen |
| 10:50 |
|
Christineb joined #evergreen |
| 10:54 |
rhamby |
berick: spelling is oberrated |
| 10:56 |
* csharp |
is always amused when he sees mod_speling |
| 11:00 |
Bmagic |
Anyone here know if it's possible to change the number of "last few circulations" ? |
| 11:03 |
csharp |
I thought that was a YAOUS, but I haven't looked in a while |
| 11:03 |
Bmagic |
hmm, I looked but maybe I didn't use the right search |
| 11:06 |
Bmagic |
"Number of Retrievable Recent Patrons" |
| 11:07 |
csharp |
circ.item_checkout_history.max? |
| 11:07 |
Bmagic |
that sounds right! |
| 11:07 |
Bmagic |
csharp++ |
| 11:08 |
Bmagic |
without that setting, it seems like the default is 4? |
| 11:09 |
csharp |
maxHistory = set['circ.item_checkout_history.max'] || 4; |
| 11:09 |
csharp |
yep |
| 11:09 |
csharp |
(web client) |
| 11:09 |
Bmagic |
thank you for looking that up! |
| 11:09 |
Bmagic |
csharp++ |
| 11:09 |
csharp |
happy to help! |
| 11:26 |
|
rlefaive joined #evergreen |
| 12:11 |
|
jvwoolf joined #evergreen |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:15 |
Bmagic |
A library thinking about migrating wanted to know if it were possible to remove access because there was a situation where the director received a subpoena |
| 12:17 |
berick |
Bmagic: can you clarify "remove access" ? |
| 12:19 |
Bmagic |
the "show last few circs" feature |
| 12:20 |
Bmagic |
The director wants to be able to tell the officials that the library doesn't have access to the information |
| 12:20 |
|
rlefaive joined #evergreen |
| 12:21 |
Bmagic |
At least that is the way I understand the scenario. It's long passed but the library is wary of it now. |
| 12:28 |
|
khuckins joined #evergreen |
| 12:42 |
|
jvwoolf joined #evergreen |
| 12:49 |
jeffdavis |
Bmagic: In that situation the library would have been better off aggressively aging circs I think. Even if you limit what the last few circs function shows, the data still exists. |
| 12:50 |
Bmagic |
jeffdavis: I agree, it's all a mirage |
| 12:51 |
Bmagic |
In theory we could restore from backups and still get the information after the circs were aged..... etc, etc |
| 12:52 |
berick |
presumably you don't keep every backup forever, though |
| 12:53 |
|
rlefaive joined #evergreen |
| 13:35 |
|
Dyrcona joined #evergreen |
| 14:04 |
|
kmlussier joined #evergreen |
| 14:10 |
|
jvwoolf joined #evergreen |
| 14:58 |
|
jvwoolf joined #evergreen |
| 15:22 |
eby |
Curious how people are handling retargeting across multiple locations with new items. Are most having the catalogers retarget the holds on a record after adding the new items? I notice the checkin modifiers seem to only do local holds for the retargeting when workstation is scoped to the branch. |
| 15:23 |
|
rlefaive joined #evergreen |
| 15:31 |
kmlussier |
eby: I'm pretty sure our libraries typically use the checkin modifiers. Since we use age protection on most of our items, the targeter would most likely pick would only pick up on local holds anyway. |
| 15:32 |
kmlussier |
Sigh...I shouldn't type this late on a Friday afternoon. |
| 15:35 |
eby |
yeah i'm trying to retarget holds at all locations |
| 15:37 |
kmlussier |
eby: Before the checkin modifier was added to the client, I believe the suggested procedure was to manually retarget the hold that was next in line. |
| 15:38 |
* kmlussier |
is looking at old pre-checkin modifier documentation - http://docs.evergreen-ils.org/1.6/draft/html/Addingholdings.html |
| 15:38 |
eby |
ok thanks. that seems to be the case still if you want it beyond local holds |
| 15:39 |
eby |
we are doing true fifo so aren't doing any of the local preference in filling |
| 15:39 |
kmlussier |
eby: Or wait 24 hours. But that's not ideal. |
| 15:39 |
eby |
playing around with the retargetting period in the cron but wondered if someone else had their own workaround |
| 15:40 |
|
Dyrcona joined #evergreen |
| 15:40 |
|
khuckins joined #evergreen |
| 15:46 |
kmlussier |
eby: hmmm...Bmagic was talking in here recently about playing around with some of the flags on the new hold targeter, possibly as a way to address the same issue? But I might be misremembering. |
| 15:46 |
Bmagic |
yes! We love the new targeter |
| 15:46 |
Bmagic |
we are running two cron jobs |
| 15:47 |
* eby |
is listening |
| 15:47 |
Bmagic |
getting the syntax |
| 15:47 |
Bmagic |
1 2 * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter_v2.pl --osrf-config $SRF_CORE |
| 15:47 |
Bmagic |
*/30 7-20 * * * . ~/.bashrc && $EG_BIN_DIR/hold_targeter_v2.pl --osrf-config $SRF_CORE --retarget-interval '2 days' --soft-retarget-interval '30 minutes' |
| 15:48 |
Bmagic |
The first one there is the nightly and the second one is every 30 minutes during the day |
| 15:48 |
Bmagic |
The first one is pretty straight forward |
| 15:48 |
eby |
what are the differences of soft retarget vs normal? |
| 15:49 |
Bmagic |
The second uses some of the new flags in order to catch newly cataloged items and only pay attention to those holds that do not have a copy targeted |
| 15:50 |
Bmagic |
the retarget interval is greater than the nightly retarget interval (1 day vs. 2 days) - therefore the 30 minute retargeter doesn't touch stuff with a prev_check_time < 2 days |
| 15:51 |
Bmagic |
from the release notes: |
| 15:51 |
Bmagic |
"How soft-targeting works: * Update hold copy maps for all affected holds * Holds with viable targets (on the pull list) are otherwise left alone. * Holds without viable targets are retargeted in the usual manner." |
| 15:53 |
Bmagic |
The feedback from the libraries is positive. Now if we could just do something about the 100 hold query limit upon checkin with age based protection...... |
| 15:53 |
eby |
so holds with with potential copy would still be updated in that case but not ones that have a barcode assigned to be pulled |
| 15:53 |
Bmagic |
eby: right, the 30 minute job just looks at holds that havn't received a copy |
| 15:54 |
Bmagic |
havn't/haven't |
| 15:59 |
eby |
thanks Bmagic . we will give those a whirl |
| 16:00 |
Bmagic |
eby: cool! Love to hear about the results |
| 16:01 |
kmlussier |
Bmagic++ |
| 16:01 |
Bmagic |
berick++ |
| 16:05 |
kmlussier |
berick++ indeed |
| 16:17 |
|
glen joined #evergreen |
| 16:18 |
|
rlefaive joined #evergreen |
| 16:46 |
|
rlefaive joined #evergreen |
| 16:52 |
|
derekz left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
