| Time |
Nick |
Message |
| 00:55 |
|
abneiman joined #evergreen |
| 00:58 |
|
akilsdonk joined #evergreen |
| 07:28 |
|
BDorsey joined #evergreen |
| 07:51 |
|
kworstell-isl joined #evergreen |
| 07:55 |
|
rfrasur joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:55 |
Dyrcona |
Hm. cron jobs didn't run on one of the VMs, but the crontab is in place. |
| 08:56 |
|
kworstell-isl joined #evergreen |
| 08:59 |
Dyrcona |
is anacron messing things up? |
| 08:59 |
Dyrcona |
Nope. It's not installed. |
| 09:06 |
|
mantis1 joined #evergreen |
| 09:08 |
Dyrcona |
OK. cron is running and "working." I added a job to echo to a file every minute and that's getting updated. |
| 09:08 |
Dyrcona |
opensrf services are running, too. |
| 09:11 |
Dyrcona |
Disk isn't full, either. |
| 09:12 |
Dyrcona |
It looks like one of the cron jobs did not run on the other virtual machine.... |
| 09:14 |
Dyrcona |
So, it's the server where I set parallel to 1 that the cron jobs did not run, or if they did, there's no sign of it in the database or the logs. |
| 09:15 |
Dyrcona |
Caught error from 'run' method: Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.34.0/OpenILS/Application/Storage/Publisher/action.pm line 1037. |
| 09:16 |
Dyrcona |
A bunch of "Subroutine .... redefined" warnings, but in the end: /usr/local/share/perl/5.34.0/OpenILS/Application/Storage/Publisher/action.pm syntax OK |
| 09:20 |
Dyrcona |
Guess I'll have to see what's going on at line 1037. |
| 09:22 |
Dyrcona |
OK. That's coming from the fine generator looking for bookings. That means cron jobs are running just that some of my cron jobs did nothing at all. |
| 09:29 |
Dyrcona |
Is manually setting the collect and react parallel settings to 1 wrong? It looked like it was OK in the code. Should I have commented the parallel section out of the XML? |
| 09:33 |
Dyrcona |
Well, I'll check back to see if I get any hourly events after 10:00 am. I expect there to be an expiring hold or something. |
| 09:35 |
Dyrcona |
Oh, right....You can kill the action_trigger_runner.pl, but the backends will keep working on the events.... |
| 09:36 |
Dyrcona |
That relates to my parting comment yesterday that I've seen events still being processed after the a/t runner has ended. That is still a problem for my auto-renewal fix program. |
| 09:37 |
Dyrcona |
So, I started the daily runner manually and stopped it. I now see about 19,500 pending auto-renewals. This was after commenting out the parallel block. I'm not sure if that was the difference, or if it was running it manually. |
| 09:39 |
Dyrcona |
Well, I should have checked timestamps before truncating the table, but I'm pretty sure that they were from my current run. If that's the case, then it looks like NOT using a parallel collector is faster than using a parallel collector. |
| 10:00 |
Dyrcona |
Has anyone out there enabled the setting to allow Perl in templates in the database? I'm wondering if it works. I've done it with templates I've processed via the command line. (I also vaguely recall doing this once years ago, and IIRC it worked.) |
| 10:00 |
Dyrcona |
Right. The templates aren't processed in the database. They're processed by open-ils.trigger. |
| 10:01 |
Dyrcona |
OK. A/T cron jobs seem to be working now. I guess setting the parallel to 1 for collector and reactor does not work. I think that's a bug.... |
| 10:02 |
Dyrcona |
I'll play with the settings some more before filing it on Lp, though. Maybe I'm just missing something else that was going on. |
| 10:08 |
Dyrcona |
k |
| 10:13 |
sharpsie |
Dyrcona: do you have mail set up for your cron users? - that's my main way of determining problems with cron jobs |
| 10:13 |
Dyrcona |
sharpsie: These vms don't send email, and I want to keep it that way for now. |
| 10:14 |
sharpsie |
I mean internally |
| 10:14 |
sharpsie |
if the cron fails and the user has mail set up they get a message with the error |
| 10:14 |
Dyrcona |
Nope. That's not set up either. |
| 10:15 |
sharpsie |
I use mutt for that, but obviously other ways |
| 10:15 |
Dyrcona |
I'm good with that. I could see that no events were created in the database overnight. Now, events are getting created. I think it was the opensrf.xml settings for open-ils.trigger. |
| 10:16 |
Dyrcona |
yeah, I've used various programs for that. But the systems don't get email internally, either. |
| 10:16 |
sharpsie |
ah |
| 10:16 |
Dyrcona |
Which I thought was a default, but /var/mail is empty. |
| 10:17 |
sharpsie |
in my experience, if you try using "mail" (or "mutt") for an account that doesn't have it yet, the /var/mail/* directory gets created and starts receiving mail |
| 10:17 |
Dyrcona |
I thought about setting them up to send email, then setting param, recipient_email on the events, and flooding my gmail inbox. :) |
| 10:18 |
Dyrcona |
I'm OK with no mail for now. |
| 10:18 |
sharpsie |
yeah, we have some of our servers send external mail for cron, and yes it's a flood |
| 10:19 |
Dyrcona |
yeah. I would also have to make sure that the action_tigger.params, email_recipient, or whatever, works with all of our templates. It's handy for testing. |
| 10:20 |
|
smayo joined #evergreen |
| 10:20 |
Dyrcona |
We generated well over 50,000 events on Tuesday that could have sent email. |
| 10:31 |
* Dyrcona |
tries to figure out a good way to turn 2,250 lines from a spreadsheet into a SQL upsert. Yes, it has to be SQL for ... reasons. I'm not gonna do the inserts via Perl, which makes more sense than writing a program to write SQL. :) |
| 10:51 |
Dyrcona |
Ugh. ON CONFLICT ... DO UPDATE is more complicated than it needs to be.... |
| 10:54 |
Dyrcona |
And, my test data is missing some users, but OK. The syntax is all right now. |
| 10:55 |
|
BrianK joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:25 |
jeff |
fun hold quirk, probably nothing new (since ~1.2.0.4 I'm guessing): multiple outstanding holds on a title with no available copies, none have a "current copy". normal so far. check in an item, hold capture verification asks if you want to capture the item to fill a hold. say no, item is reshelving. still good/normal/expected... |
| 12:27 |
jeff |
now, patron places a new hold request on that title, new hold targets the reshelving item, "jumping the line", as it were. |
| 12:28 |
jeff |
also, at that point the "current copy" is pretty sticky. i think the only way to get the hold to relinquish its current copy is to suspend, retarget another hold, then activate the suspended hold. |
| 12:29 |
jeff |
hold capture verification is the contributing factor: otherwise the copy would have been opportunistically captured. |
| 12:29 |
Dyrcona |
Yeah, that sounds about right. :) |
| 12:31 |
Dyrcona |
Back to my template thing: I can probably do what I want without Perl, but it might be cleaner with Perl in the template. I'd like to sort the output of the AutorenewNotify template into a group that renewed and on that didn't. |
| 12:32 |
Dyrcona |
jeff: I would think there are easier ways to change the hold for that copy and vice versa. Isn't there a check-in modifier to do that? |
| 12:37 |
Dyrcona |
Now I'm wondering if creating a new event that Autorenew could kick off would make sense. One event would notify the renewed items and the other would notify those that didn't renew? Meh. That's probably too much. |
| 12:38 |
jeff |
one approach would be to have automatic renewals be something that has a worker more akin to hold retargeting, and from there create events for hooks like autorenew successful, autorenew failed, etc. |
| 12:39 |
jeff |
that would be a significant change, however. :-) |
| 12:39 |
Dyrcona |
jeff: Yeah... different hooks, and that would be even more work. |
| 12:39 |
berick |
Dyrcona: is the renewal getting stuck, the notifications, both? |
| 12:39 |
Dyrcona |
I have considered just not using action trigger for this at one point, too. |
| 12:40 |
Dyrcona |
berick: Both can get stuck, but I'm musing on a new approach. We're considering doing away with the 2-day courtesy notices, setting up renewal extensions to renew from the due date, and replacing 2-day courtesy notices with autorenew. |
| 12:41 |
Dyrcona |
Right now I'm just wondering out loud if 1 notice or two would be better. |
| 12:42 |
jeff |
Dyrcona: on the hold conversation, I don't know that retarget local holds + retarget all statuses would change the fact that this hours-old hold has the copy as its current copy. |
| 12:43 |
Dyrcona |
jeff: You are probably right. I haven't really tried retarget holds in a while. If it is already targeting a local hold, it probably won't change. |
| 12:46 |
berick |
just looking at ours.. autorenew at 3 days before + 2 day courtesy + due-today courtesy. |
| 12:46 |
Dyrcona |
My thoughts on using Perl in the template are that it might be faster to 'grep' the input into two separate lists (renewed items and not renewed items) rather than to loop through the whole list twice. |
| 12:46 |
berick |
~15k autorenew a day |
| 12:46 |
berick |
courtesy notices have obv. gone way down once we started autorenew |
| 12:46 |
Dyrcona |
yeah, we typically do about 15k autorenew per day, sometimes less (particularly on weekends) and then twice as many after a holiday weekend. |
| 12:47 |
berick |
yeah, varies quite a bit |
| 12:47 |
Dyrcona |
That's our thinking, too, that the courtesy notices would go down. I personally would like to get rid of them if we move auto-renewal earlier. |
| 12:47 |
Dyrcona |
We currently do 2-day courtesy notice, then autorenewal on due date. |
| 12:48 |
berick |
yeah if you autorenew everything, courtesy notice is redundant |
| 12:50 |
Dyrcona |
I'll make a note that you autorenew 3 days before. We might want to do that, too. Right now we're talking about 2 days because that's when we do courtesy notices. I supposed I'll set a range anyway. |
| 12:53 |
jeff |
I always liked the approach of the library that replaced/combined their courtesy notices with autorenewal notices. |
| 12:53 |
jeff |
It may have been Stompro. |
| 12:54 |
Stompro |
Yes, we did do that. |
| 12:55 |
Dyrcona |
Stompro: Do tell. How did you organize it? |
| 12:56 |
jeff |
Also, once https://bugs.launchpad.net/evergreen/+bug/1516101 or similar is released, some of the reasons for "wait until the due date to autorenew!" goes away. |
| 12:56 |
pinesol |
Launchpad bug 1516101 in Evergreen "Option to prevent renewals "too early" in the checkout cycle" [Wishlist,New] |
| 12:56 |
Stompro |
I'm proud of our template for autorenew email notices. Customizes the subject for All renewed, some renewed, none renewed, and sorts the checkouts by which ones need more attention. |
| 12:56 |
Dyrcona |
jeff: There's code in 3.10 to renew from the due date. |
| 12:57 |
jeff |
ah, that's what I was thinking of. I found 1516101 first. |
| 12:57 |
Dyrcona |
Stompro: Have you shared this template anywhere? I'm quite interested in seeing it. |
| 12:58 |
Stompro |
I'm not sure if I have, one sec and I'll share it. |
| 12:58 |
jeff |
this one: https://bugs.launchpad.net/evergreen/+bug/1891369 |
| 12:58 |
pinesol |
Launchpad bug 1891369 in Evergreen "Circulation renewals near the due date should be extended" [Wishlist,Fix released] |
| 12:58 |
Dyrcona |
jeff: Lp 1891369 |
| 12:58 |
* jeff |
nods |
| 12:58 |
Dyrcona |
ha! |
| 12:58 |
jeff |
Dyrcona++ |
| 12:59 |
Dyrcona |
jeff++ |
| 12:59 |
Dyrcona |
berick++ |
| 12:59 |
Dyrcona |
Stompro++ |
| 12:59 |
jeff |
and indeed the original bug description calls out the benefit I was mentioning: "In addition to letting patrons renew items slightly earlier in the opac without losing days, this would allow autorenewals to be run 1-2 days before items are due rather than the morning of (the current default). Then users would have more time to react to the success / failure notices." |
| 13:00 |
Dyrcona |
yeah. Should the older bug be set as a duplicate of the newer bug? |
| 13:01 |
Dyrcona |
I think yes. |
| 13:04 |
jeff |
unclear. I don't know without looking in more detail if all the goald of the original are met by th most recently mentioned one. they're certainly related. :-) |
| 13:05 |
Stompro |
We don't penalize for overdue's until some time later, so we decided that sending the courtesy notice on the due date was fine. |
| 13:05 |
Dyrcona |
Well, I marked it a duplicate because it at least gets the main things: preventing early renewal and renewing from the due date. |
| 13:05 |
Stompro |
Here is a snippet of our template. https://gitlab.com/-/snippets/2595279 |
| 13:06 |
Dyrcona |
Stompro++ That's a busy template! I think I see what I need, though. |
| 13:09 |
|
dguarrac joined #evergreen |
| 13:11 |
Dyrcona |
Stompro: Do you do a separate account expiration notice, or do you have that expiration text in all of your templates? |
| 13:13 |
Stompro |
Dyrcona, that is in all of our templates. We send out an account expiration 30 days before, but figure this provides reminders for active users. |
| 13:15 |
Dyrcona |
OK. Sounds good. Y'know, it's possible to set a template directory and have the templates pull in outside files, but it requires modifying Reactor.pm. |
| 13:15 |
Dyrcona |
i was thinking if you have something like that in all of your templates, you could put it somewhere and then INCLUDE or PROCESS as appropriate. |
| 13:16 |
Dyrcona |
I wonder if a setting for that in opensrf.xml would make a decent enhancement? Maybe something in open-ils.trigger app settings, or should it go someplace else? |
| 13:17 |
Stompro |
Interesting, maybe when I work on setting up html templates I'll look into that. That would be nice for all the branch links also. |
| 13:17 |
Dyrcona |
yeah, I first thought of it when I saw your branch links. That would be perfect fro an INCLUDE. |
| 13:19 |
mmorgan |
jeff: There were fixes to hold capture verification issues. bug 1709966, bug 1735221. Are there additional issues? |
| 13:19 |
pinesol |
Launchpad bug 1709966 in Evergreen 2.12 "webclient: items using Hold Verify fail to checkin or capture hold" [High,Fix released] https://launchpad.net/bugs/1709966 |
| 13:19 |
pinesol |
Launchpad bug 1735221 in Evergreen 3.8 "webclient: items with copy alert and hold verify fail to capture for hold" [Medium,Fix released] https://launchpad.net/bugs/1735221 |
| 13:19 |
Stompro |
Or pull that data from somewhere else, could be set in a library setting. |
| 13:19 |
mmorgan |
Stompro++ |
| 13:19 |
Stompro |
Is there a helper for grabbing library settings in templates? |
| 13:20 |
jeff |
mmorgan: I don't believe that either of those address the issue I described. |
| 13:20 |
jeff |
Unless the bug subjects and my memory are inaccurate. |
| 13:20 |
Dyrcona |
Stompro: There is a helper for library settings. |
| 13:22 |
jeff |
The underlying issue is that at time of last targeting, the pre-existing holds had no available/reshelving copies to target as their current copy (and show on a holds pull list). Once the item is checked in and the new hold is placed, that new hold sees the newly-reshelving copy and selects it as its current copy. |
| 13:22 |
Dyrcona |
Stompro: The thing I'm thinking of would require changes around line 542 of O::A::Trigger::Reactor.pm. |
| 13:22 |
Stompro |
I should switch looking up our branch pages that way... sending myself a helpdesk ticket to do that. |
| 13:23 |
Dyrcona |
Yeah. We pull links in via the lib.info_url setting. |
| 13:24 |
Dyrcona |
helpers.get_org_setting(lib.id, 'lib.info_url') |
| 13:25 |
mmorgan |
jeff: We see jumping the line for situations like new holds placed just after age hold protection expires, but I haven't seen the issue you describe related to hold capture verification. |
| 13:26 |
Stompro |
We also have some customizations for sites that have curbside pickup... I bet that could also be looked up instead of requiring template logic. |
| 13:34 |
Dyrcona |
Stompro: That is certainly worth exploring. |
| 13:35 |
Dyrcona |
I'm going to think about my idea of allowing outside templates and possibly open a Lp bug. Likely not today, though. |
| 15:04 |
|
mantis1 left #evergreen |
| 15:19 |
pinesol |
News from commits: Docs: undoing previous Global Flags table changes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8da7bce807b69ffd3d712c1858d62f2747197813> |
| 15:42 |
|
jihpringle joined #evergreen |
| 15:45 |
Stompro |
Dyrcona, I found this bug 1510595 about Action Trigger template sharing/including |
| 15:45 |
pinesol |
Launchpad bug 1510595 in Evergreen "Action Trigger may benefit from sharing templates with OPAC, etc." [Wishlist,New] https://launchpad.net/bugs/1510595 |
| 15:50 |
Dyrcona |
Stompro: Thanks for the memory jog. That discussion is not what I'm thinking of today. Plugins are nice, but they aren't going to solve your problem of identical boilerplate across most of your templates. |
| 15:52 |
Dyrcona |
It also doesn't complicate things any more than having custom filters does. The templates just have to be present on the server that run the action trigger runner for the events that need them. Everyone puts their customization in a git repo, updates the Makefiles to install their custom stuff, and installs via git, right? :) |
| 15:57 |
Dyrcona |
I have also experimented with some of this in the past. I'll have to see if I still have any of it hanging around from my MVLC days. |
| 16:21 |
Bmagic |
I'd like to know the permissions required to register a patron. I'm just getting a scrolling bar when loading the page. I've granted the EVERYTHING permission at the consoritum level, logout/login, and the registration page loads fine. So I know it's permissions. |
| 16:22 |
Bmagic |
Looking at the log when the page fails to load I'm finding a lot of lookups for permissions: EDIT_SELF_IN_CLIENT, group_application.user.staff.circ, group_application.user.staff.acq, group_application.user.staff.acq_admin, UPDATE_PATRON_ACTIVE_CARD, group_application.user.staff.cat_admin, UPDATE_PATRON_PRIMARY_CARD, group_application.user.staff.circ_admin, group_application.user.staff.admin.local_admin |
| 16:22 |
Bmagic |
So I granted all of those at the system level, the page still doesn't load |
| 16:22 |
Bmagic |
maybe those need to be at the consortium level? Or one of them... Trying that |
| 16:29 |
Bmagic |
nope, I granted all of those at the consortium level, still doesn't load the page. The browswer has an error for pcrud.search: |
| 16:29 |
Bmagic |
params => ["SCRUBBED",{"-or":[{"name":["circ.holds_behind_desk","circ.collections.exempt","opac.hold_notify","opac.default_phone","opac.default_pickup_location","opac.default_sms_carrier","opac.default_sms_notify"]},{"name":[]},{"opac_visible":"t"}]},{}] |
| 16:30 |
Bmagic |
the log shows this: open-ils.pcrud 2023-09-07 15:38:26 [ERR :4032254:oils_sql.c:2835:SCRUBBED] open-ils.pcrud: Empty IN list |
| 16:41 |
Bmagic |
I do see "name":[] |
| 16:45 |
mmorgan |
Bmagic: maybe the group_application.user permission? |
| 16:46 |
Bmagic |
I'll try that |
| 16:46 |
Bmagic |
that permission is granted already at the consortium level (inherited from the "Staff" parent group) |
| 16:52 |
Bmagic |
I have a clue. I compared the osrfsys.log file when loading the web page as and admin compared to loading the page where it fails to load as my test user. And there is a small difference in the pcrud call: |
| 16:53 |
Bmagic |
CALL: open-ils.pcrud open-ils.pcrud.search.cust.atomic "REDACTED",{"-or":[{"name":["circ.holds_behind_desk","circ.collections.exempt","opac.hold_notify","opac.default_phone","opac.default_pickup_location","opac.default_sms_carrier","opac.default_sms_notify"]},{"name":["circ.send_email_checkout_receipts"]},{"opac_visible":"t"}]},{} |
| 16:53 |
Bmagic |
^^ This is when it works |
| 16:54 |
Bmagic |
the difference is the presence of "circ.send_email_checkout_receipts" in there |
| 16:55 |
Bmagic |
when using my test staff account, the pcrud call doesn't include the email_checkout_receipt call in the pcrud call. And that's what's missing, throwing the error "Empty IN list" |
| 16:56 |
mmorgan |
Bmagic: Just to clarify, are you trying to load a blank new registration page, or load an existing user? |
| 16:56 |
Bmagic |
blank registration |
| 17:01 |
* mmorgan |
just loaded the blank registration screen successfully, and doesn't see the email_checkout_receipt in the pcrud call. |
| 17:02 |
jeff |
Bmagic: are you certain that the staff user in question has necessary work_ou / Working Location set? |
| 17:02 |
jeff |
that is the typical cause of "i can log in but I can't load the patron editor" |
| 17:02 |
Bmagic |
jeff: I check that, I added all* of the branches just in case, no change |
| 17:02 |
Bmagic |
I'm running autogen now |
| 17:02 |
jeff |
and you logged out and then back in after making that change? |
| 17:03 |
Bmagic |
right |
| 17:03 |
* mmorgan |
thought about whether the ou of the workstation can have users, but can load the reg page regardless. |
| 17:04 |
jeff |
well, next i'd suggest setting super_user = TRUE on the staff user in in question, which may well serve only as a as a large hammer to suggest that permissions aren't to blame after all. |
| 17:04 |
Bmagic |
I did give the EVERYTHING permission, and that solved it |
| 17:05 |
jeff |
and yes, mmorgan has a good point about the org unit associated with your workstation -- are you dealing with a typical org tree and single branch? |
| 17:05 |
jeff |
ohh, I see what you were saying now. |
| 17:06 |
Bmagic |
There's a definite difference in that pcrud call when I'm logged in as an admin vs. this staff user |
| 17:06 |
Bmagic |
as the staff user, the pcrud call doesn't include any params inside the "name":[] |
| 17:07 |
Bmagic |
which throws an ugly error in the browser console as well as the logs on the server |
| 17:09 |
Bmagic |
the pcrud call is "open-ils.pcrud.search.cust.atomic" which is config.usr_setting_type |
| 17:15 |
|
mmorgan left #evergreen |
| 17:33 |
|
smayo joined #evergreen |
| 19:23 |
|
jihpringle joined #evergreen |
| 20:01 |
|
brianmk joined #evergreen |
