Time |
Nick |
Message |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:21 |
|
rjackson_isl_hom joined #evergreen |
07:27 |
|
agoben joined #evergreen |
07:41 |
|
Dyrcona joined #evergreen |
08:00 |
|
mantis joined #evergreen |
08:04 |
|
collum joined #evergreen |
08:29 |
|
alynn26 joined #evergreen |
08:36 |
|
mmorgan joined #evergreen |
09:49 |
|
alynn26_away joined #evergreen |
10:12 |
|
mmorgan1 joined #evergreen |
10:21 |
berick |
would appreciate an eye on these 3.5 release notes updates: |
10:21 |
berick |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/3.5-release-notes-adds |
10:23 |
berick |
just want to confirm the process is just 1. copy to main file 2. delete original specific file. |
10:25 |
gmcharlt_ |
yeah, that's the process I follow |
10:29 |
berick |
thanks gmcharlt_ |
10:29 |
|
tlittle joined #evergreen |
10:42 |
|
mmorgan1 joined #evergreen |
10:43 |
miker |
berick: just a head's up, I'm pushing up a branch that I think we should get into 3.5 to save the sanity of admins re angular: we really mustn't let browers cache angular's index.html, lets updates not show up to clients |
10:43 |
miker |
I'm working on release notes for that right now, as it happens :) |
10:48 |
berick |
miker: agreed, sounds good |
10:57 |
miker |
berick: https://bugs.launchpad.net/evergreen/+bug/1883267 ... and I suppose it should be backported as far as angular is in regular use. 3.4 at least, I guess |
10:57 |
pinesol |
Launchpad bug 1883267 in Evergreen "Angular index.html needs to never be cached" [High,New] |
10:58 |
miker |
(I put the release note in Architecture for lack of a better idea on location...) |
10:58 |
miker |
obv, move as you (or whoever) sees fit |
11:01 |
berick |
miker: thanks, looking now |
11:08 |
|
kenstir joined #evergreen |
11:37 |
pinesol |
[evergreen|Mike Rylander] LP#1883267: Never cache Angular index.html - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=298c581> |
11:37 |
pinesol |
[evergreen|Mike Rylander] LP#1883267: Adding release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=da0e2e3> |
11:37 |
pinesol |
[evergreen|Bill Erickson] LP1883267 Minor release note tweaks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2bf71af> |
11:45 |
pinesol |
[evergreen|Bill Erickson] 3.5 Post-Beta Release Notes Additions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=35fca97> |
12:12 |
|
nfBurton joined #evergreen |
12:16 |
nfBurton |
Is there a script I can run to update blocks on patron accounts? We want to raise the fine limit and retroactively remove blocks |
12:17 |
|
abowling1 joined #evergreen |
12:18 |
berick |
nfBurton: there's an API call you can use open-ils.actor.user.penalties.update -- but i'm not aware of any scripts that automate calling it |
12:18 |
berick |
it updates 1 patron per call |
12:21 |
nfBurton |
If I remove the entries in actor.usr_standing_penalty, will that remove the block |
12:21 |
* mmorgan |
was just about to suggest that. |
12:21 |
mmorgan |
That will remove the block. |
12:22 |
nfBurton |
Ok awesome. |
12:25 |
|
jihpringle joined #evergreen |
12:29 |
|
nfBurton71 joined #evergreen |
12:36 |
|
mmorgan1 joined #evergreen |
12:38 |
|
mmorgan2 joined #evergreen |
12:57 |
|
dbwells_ joined #evergreen |
12:58 |
|
jihpringle joined #evergreen |
13:51 |
mantis |
Thanks to everyone who participated in presenting and planning for the conference! It was mentioned that the community would like some volunteers for the Hack Away. I'm not sure who to get in contact with to offer my time. |
13:53 |
berick |
rhamby: ^-- |
13:53 |
mantis |
rhamby: I thought it would be you but wasn't entirely sure! |
14:00 |
csharp |
mantis++ |
14:46 |
rhamby |
mantis: yep feel free to drop me an email rhamby at equinoxinitiative.org |
14:47 |
rhamby |
berick++ for pinging me |
14:54 |
|
jihpringle joined #evergreen |
15:08 |
|
mantis joined #evergreen |
15:14 |
mmorgan |
If a hold that's ready for pickup, and has generated a pickup email gets retargeted and recaptured, will a second email be generated? My testing says yes, unless my testing is flawed. |
15:18 |
jeff |
yes, I believe you are correct. |
15:18 |
jeff |
though if the existing A/T events were pending they may BOTH be run. |
15:19 |
jeff |
(say, if you had disabled notifications by disabling cron jobs for a time) |
15:19 |
mmorgan |
Ok, good! That was the answer I wanted. |
15:19 |
mmorgan |
I'm thinking of original events that completed months ago. |
15:20 |
jeff |
reset / "Find Another Target" on an hold won't touch any events that may exist, but the action of the hold going "on shelf / ready for pickup" will happily autocreate any relevant hold.available events. |
15:21 |
jeff |
it can get confusing if you disabled notifications, some items were captured for holds and events were created, and then you reset the holds and re-captured them, now there are two events... though grouping may mean that the duplicates go away, i haven't checked. |
15:24 |
mmorgan |
jeff++ |
15:24 |
mmorgan |
Thanks! |
15:25 |
Dyrcona |
jeff: Events won't be created if the event definitions were disabled. I know, we did this. |
15:25 |
|
mantis joined #evergreen |
15:25 |
jeff |
one of the things we did was threw on-shelf holds back into transit from the pickup lib to the pickup lib, then staff could scan items at their own pace to trigger notifications, since the new notifications are "please call to schedule a time to get these via curbside" |
15:26 |
jeff |
Dyrcona: correct. if the defs are disabled, the events will not be created. i was talking about "disabling notifications" by disabling cron jobs. |
15:26 |
jeff |
(where the events would be created but stay pending until cron jobs were re-enabled) |
15:26 |
Dyrcona |
Ah, well, OK. |
15:28 |
Dyrcona |
Good to clarify. |
15:28 |
jeff |
Yes! |
15:28 |
jeff |
:-) |
15:29 |
|
mantis left #evergreen |
15:30 |
Dyrcona |
FWIW: We deactivated the event definitions in the database and left the cron jobs alone. Now, we're cloning hold notification events for individual libraries that request it. |
15:33 |
mmorgan |
We did the same. |
15:37 |
|
jihpringle joined #evergreen |
15:42 |
jeff |
something i was just looking at was what happens when you have active event defs at multiple depths: if BR1 and SYS1 both define an event for hold.available, do both event defs each result in an event being created? |
15:42 |
jeff |
my current thought on looking at things was "yes, you get two events", but I hadn't finished looking or tested yet. |
15:43 |
csharp |
make your configure more colorful with "./configure --prefix=/openils --sysconfdir=/openils/conf | lolcat" |
15:47 |
Dyrcona |
jeff: Yes, it looks like you get two events. |
15:50 |
Dyrcona |
But, with something like hold notifications, you get multiple events (1 per hold) anyway, and only 1 email. I'm not sure how that works with different events, though. You'll probably have two emails or texts sent. |
15:51 |
Dyrcona |
I should be more clear: multiple entries in the action_trigger.events table for the same event def for multiple holds, then with two different definitions at different depths, you'll get events for each definition if the owner org_units overlap. |
15:51 |
Dyrcona |
The latter will probably lead to multiple emails and texts being sent. |
15:53 |
Dyrcona |
Our plan is to deactivate all of the event definitions for the individual libraries when (if) we reactivate the event definition owned by the consortium. |
16:20 |
|
jihpringle joined #evergreen |
17:09 |
|
mmorgan left #evergreen |
17:30 |
|
jihpringle joined #evergreen |
18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
21:20 |
|
mrisher_ joined #evergreen |
22:25 |
|
dbwells joined #evergreen |
22:43 |
|
jeffdavis joined #evergreen |
23:05 |
|
jeffdavis joined #evergreen |
23:20 |
|
jamesrf joined #evergreen |
23:20 |
|
eby joined #evergreen |
23:47 |
|
eby joined #evergreen |