| Time |
Nick |
Message |
| 01:09 |
|
sandbergja joined #evergreen |
| 03:07 |
|
sandbergja joined #evergreen |
| 03:11 |
|
sandbergja joined #evergreen |
| 03:17 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:53 |
|
agoben joined #evergreen |
| 07:22 |
|
rjackson_isl_hom joined #evergreen |
| 07:59 |
|
rfrasur joined #evergreen |
| 08:02 |
|
alynn26 joined #evergreen |
| 08:03 |
|
rfrasur_ joined #evergreen |
| 08:08 |
|
rfrasur__ joined #evergreen |
| 08:13 |
|
rfrasur_ joined #evergreen |
| 08:18 |
|
rfrasur__ joined #evergreen |
| 08:23 |
|
rfrasur_ joined #evergreen |
| 08:28 |
|
rfrasur__ joined #evergreen |
| 08:38 |
|
rfrasur_ joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mantis1 joined #evergreen |
| 08:43 |
|
rfrasur__ joined #evergreen |
| 08:48 |
|
rfrasur_ joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:53 |
* Dyrcona |
wishes that Lp had an edit button for comments. I forgot to mention something. I guess I'll add another comment. |
| 08:55 |
alynn26 |
Dyrcona, your not the only one. |
| 10:04 |
|
jvwoolf joined #evergreen |
| 10:41 |
|
sandbergja joined #evergreen |
| 10:54 |
Bmagic |
Anyone handled "too many failed login attempts" for sip users? There was a different issue causing the auth failure, and now that it's resolved, the account is blocked for now. What's the best way to reset the "faield" attempts for certain accounts. Is that held in memcache? |
| 10:57 |
berick |
Bmagic: yes, that's in memcache |
| 10:58 |
Bmagic |
self check machines seem to never stop, so, I would imagine that the affected accounts would never get unblocked? |
| 11:00 |
berick |
the block times out eventually |
| 11:00 |
berick |
so if they have the correct password post-timeout, it will start working again |
| 11:01 |
Bmagic |
ok, so the "90" from "block_time" clause will fix it? That timer doesn't get reset as they continue to hammer openils.auth ? |
| 11:01 |
|
nfBurton joined #evergreen |
| 11:02 |
berick |
Bmagic: now i'm not sure |
| 11:03 |
berick |
if they continue w/ the wrong password it might keep resetting the timeout |
| 11:04 |
Bmagic |
haha, well, the threshold was "90" - that's minutes? |
| 11:04 |
berick |
pretty sure that's seconds |
| 11:12 |
Bmagic |
I've attempted to change the values in the open-ils.auth <block_time> and <block_count>, then osrf_control --restart --localhost --service open-ils.auth |
| 11:12 |
berick |
Bmagic: you'll have to restart opensrf.settings as well |
| 11:12 |
berick |
1st |
| 11:12 |
Bmagic |
ah! |
| 11:17 |
Bmagic |
berick++ # working now! |
| 11:34 |
|
nfBurton joined #evergreen |
| 12:59 |
|
nfBurton joined #evergreen |
| 13:21 |
|
rfrasur joined #evergreen |
| 13:28 |
|
rfrasur_ joined #evergreen |
| 14:22 |
mmorgan |
Question about adjusted proximity for holds. Does adjusted proximity only come into play with opportunistic capture? Does it play any part at all in targeting and pull lists? |
| 14:26 |
berick |
mmorgan: proximity is used in targeting for the pull list |
| 14:29 |
mmorgan |
berick: Thanks. But now I realize that likely won't be a solution to my problem, which is this: |
| 14:29 |
berick |
... if you are not using circ.holds.max_org_unit_target_loops |
| 14:29 |
mmorgan |
A system has 3 branches, but only one is serving patrons. They want holds for pickup at the main branch to show on pull lists at the other branches, but not holds for the whole consortium. |
| 14:30 |
mmorgan |
We're not using circ.holds.max_org_unit_target_loops, for the record |
| 14:31 |
mmorgan |
The branches are already closest to each other proximity-wise, so adjusting proximity to make them closer would likely change nothing. |
| 14:32 |
Dyrcona |
mmorgan: Add hold matrix matchpoints. |
| 14:32 |
mmorgan |
We're using closed dates and the ou settings to only target when closed when pickup library matches item circ library. But that doesn't work for the branch case. |
| 14:33 |
mmorgan |
Dyrcona: Add hold matrix matchpoints to make the branch items not holdable anywhere else? |
| 14:33 |
Dyrcona |
Yes. |
| 14:34 |
Dyrcona |
It's not fun; it's not pretty, but it will work. |
| 14:35 |
alynn26 |
Mmorgan, that is what we are doing |
| 14:35 |
alynn26 |
pain to keep up with, but it works |
| 14:36 |
mmorgan |
Ok, sounds promising, and maybe not that bad to configure. I think I can just make one rule for each branch with transit range of system (?) |
| 14:37 |
* mmorgan |
will give it a try |
| 14:37 |
mmorgan |
berick++ Dyrcona++ alynn26++ |
| 14:49 |
|
mrisher joined #evergreen |
| 14:54 |
mmorgan |
One rule for each branch setting transit range to system seems to have done the trick :-D |
| 14:54 |
Dyrcona |
mmorgan++ # Glad it was that easy. |
| 14:55 |
mmorgan |
Me too! Don't know why it never occurred to me, we have a few hold rules that use the transit range. |
| 14:58 |
alynn26 |
Since I have to configure this for about 128 different libraries I scripted this update. |
| 15:12 |
Dyrcona |
Yeah, it depends a lot on how the matchpoints are set up. |
| 15:31 |
|
mantis1 left #evergreen |
| 16:14 |
|
sandbergja joined #evergreen |
| 16:29 |
pinesol |
[evergreen|Shula Link] LP1848573: Added nice labels to Open-ILS\examples\fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a2bd6a> |
| 16:29 |
pinesol |
[evergreen|Jane Sandberg] LP1848573: follow-up: minor changes to IDL labels for the ccs class - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=433059d> |
| 17:17 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:54 |
|
sandbergja joined #evergreen |
| 20:44 |
|
sandbergja joined #evergreen |
| 21:04 |
|
sandbergja joined #evergreen |
| 21:39 |
|
sandbergja joined #evergreen |
