| Time |
Nick |
Message |
| 07:00 |
|
collum joined #evergreen |
| 08:47 |
|
mantis joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:16 |
* Dyrcona |
ponders a later from mmorgan that doesn't seem to be related to anything that I've monologued about lately. |
| 09:37 |
Dyrcona |
I've noticed that some items don't get courtesy/autorenewals, but this looks normal. |
| 09:39 |
Dyrcona |
I found 23 this morning that looks like they should have autorenewed last night, but they were all created yesterday. They mostly have 2 day or 1 day circ durations, except for 1 that is 7 days and another that's 21 days. I can only assume that staff entered the due date manually on the latter 2. |
| 09:39 |
Dyrcona |
By, "should have autorenewed last night," I really mean "should have autorenewed yesterday because they have a due data of tomorrow." |
| 09:40 |
Dyrcona |
Due Data & Diligence |
| 09:43 |
Dyrcona |
I think I'll check those same circulations tomorrow to see what happens to them today. |
| 09:46 |
ACSpike[Work] |
Sorry in advance for asking the wrong question of the wrong people in the wrong place. :-) Our instance of Evergreen was updated last Thursday. I've got a python script running on a cron job that creates patrons. After the update it fails. I did the bad thing and hard coded the fields instead of parsing the IDL file. I noticed that the IDL file in the update adds a field in the au class. But even after adding that field, I still get a |
| 09:46 |
ACSpike[Work] |
n error `can't call method "id" on an undefined value at ....../OpenILS/Application/Actor.pm line 792.` I looked up line 792 in the public git repo, but the lines don't match. Is there something else obvious I can check before I ask for help from our vendor? |
| 09:51 |
Dyrcona |
ACSpike[Work]: For the line number, you need to make sure you're looking at your running copy of the Evergreen code. What's on the lines will vary by Evergreen release and you may have local changes or patches. |
| 09:51 |
Dyrcona |
For the Python script, I'd probably have to see the code, but if you're trying to push array objects into the Evergreen backend, I'd recommend creating a field mapper class that can parse the IDL and set the object fields in the correct order. |
| 09:52 |
Dyrcona |
I've not done it with Python, but I have done it with PHP. |
| 09:58 |
Dyrcona |
And, why is my local copy of the PHP repo missing the source code files? |
| 09:59 |
Dyrcona |
hrm... "something" deleted the files... |
| 10:00 |
ACSpike[Work] |
I actually have the identical tool written in both PHP and python because I need the capabilities in two different places |
| 10:01 |
ACSpike[Work] |
Yes, I expect our vendor has added something ontop |
| 10:02 |
berick |
ACSpike[Work]: is the line this? my $p = $e->retrieve_actor_user($patron->id); |
| 10:02 |
ACSpike[Work] |
I can't see it :-) |
| 10:03 |
berick |
ah |
| 10:03 |
berick |
if that's it, it suggests you are calling the open-ils.actor.patron.update without a value for the patron object, thing that follows the authtoken |
| 10:04 |
Dyrcona |
berick++ |
| 10:04 |
Dyrcona |
I was thinking the object was malformed, but it's just not there. |
| 10:07 |
|
dguarrac joined #evergreen |
| 10:08 |
|
sandbergja joined #evergreen |
| 10:09 |
Dyrcona |
Looking at my PHP code again tempts me to implement something similar in C++. |
| 10:16 |
jeff |
ACSpike[Work]: if you can share a copy of the code or a sanitized copy of the HTTP request, that might help. |
| 10:22 |
Dyrcona |
ACSpike[Work]: I'll make the repo public. I haven't touched it in over a year. It's usable but not close to finished. |
| 10:23 |
Dyrcona |
ACSpike[Work]: https://github.com/Dyrcona/PHPEvergreenClient |
| 10:24 |
Dyrcona |
You probably want to look at https://github.com/Dyrcona/PHPEvergreenClient/blob/wip/src/Evergreen/Fieldmapper.php and https://github.com/Dyrcona/PHPEvergreenClient/blob/wip/src/Evergreen/ObjectModel.php |
| 10:46 |
* Dyrcona |
should probably add some examples of using that code to the repository. |
| 10:51 |
|
sandbergja joined #evergreen |
| 11:05 |
ACSpike[Work] |
Sorry, meeting. |
| 11:08 |
ACSpike[Work] |
This code was working on Wednesday. Update on Thursday. Then not working. So I must have been passing the right thing prior to Thursday. I think I fixed the datamodel. Maybe the API changed a little? |
| 11:08 |
ACSpike[Work] |
What parts of the HTTP request should I sanatize out? |
| 11:11 |
berick |
ACSpike[Work]: another option is the 'id' value within the patron object you are passing is not valid / does not exist in the database |
| 11:12 |
Dyrcona |
That could mean the fields are not aligned properly if you're passing an array object, and that would point to the IDL changing. |
| 11:12 |
ACSpike[Work] |
berick: I'm creating new patrons. |
| 11:12 |
berick |
or the ->isnew value is not what you expect |
| 11:12 |
Dyrcona |
Ah... |
| 11:13 |
berick |
yeah, what Dyrcona said... if things are not aligned properly |
| 11:13 |
ACSpike[Work] |
Yeah, I added the Parent/Guardian Email before Name Keywords this morning |
| 11:13 |
Dyrcona |
Those isnew, isdeleted fields are tricky. They get tacked on the end, no? |
| 11:13 |
ACSpike[Work] |
Yes |
| 11:13 |
ACSpike[Work] |
I guess maybe it is still misaligned somehow |
| 11:15 |
Dyrcona |
Yeah. My Fieldmapper pushes isnew, ischanged, and isdeleted on the end of the array in that order. It worked when I tried it last year. |
| 11:16 |
ACSpike[Work] |
I think I should pull an existing patron and compare against the array I would send to create that same patron anew |
| 11:22 |
ACSpike[Work] |
This is my bare bones python module https://gist.github.com/acspike/90c6f2045ba89afa0814d94d7f8e8257 . Please be gentle. |
| 11:25 |
sandbergja |
ACSpike that looks super nice actually -- did you mention what Evergreen versions you upgraded from and to? |
| 11:26 |
Dyrcona |
Yeah, I was going to say it looks OK if the field indexes are correct. |
| 11:26 |
sandbergja |
ACSpike[Work] rather |
| 11:27 |
ACSpike[Work] |
I didn't. I'm not sure what we were at prior, but if I log in and look now I think it said 3.13.9. https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=eed61e5ac2505b06f0ea02aaa946364cb2e9d4df;hb=refs/heads/tags/rel_3_13_9#l792 But the lines don't line up. I'd guess because of vendor applied patches. |
| 11:27 |
ACSpike[Work] |
Or I'm completely off on the version |
| 11:28 |
ACSpike[Work] |
Our library is part of a larger consortium with library IT people, and I'm just a non-library IT person. So I really know rather little about what's going on. |
| 11:34 |
Dyrcona |
ACSpike[Work]: You should be able to get the Evergreen version with this call 'open-ils.actor', 'opensrf.open-ils.system.ils_version' with no arguments. The service in the front doesn't matter so long as it is a valid service. |
| 11:34 |
jeff |
one thing that happens when your IDL array positions shift and your client is either hardcoded or using a cached copy of the IDL: the canonical isnew, ischanged, isdeleted will be misaligned also. In the staff client, that can manifest as things like "USERNAME_EXISTS errors when trying to save a patron", because the client sets what it thinks is the "ischanged" field, but the server interprets it as |
| 11:34 |
jeff |
"isnew", and tries to create a (conflicting) patron instead of updating an existing patron. |
| 11:34 |
jeff |
sorry, typed half of that before going afk, returned and finished. :-) |
| 11:40 |
Dyrcona |
If you're serious about programming Evergreen in this manner, I highly recommend implementing a field mapper that can parse the IDL. You can get the IDL from https://[host]/reports/fm_IDL.xml |
| 11:40 |
jeff |
ACSpike[Work]: if your au class in the IDL has 74 fields (positions 0 through 73), then your isnew, ischanged, and isdeleted would be positions 74, 75, and 76. At a quick glance at the Python in your gist above, those look correct. |
| 11:47 |
jeff |
ACSpike[Work]: it doesn't quite look like those vars at the top of your Python are used in the code you shared. it looks like the create_patron function is using hardcoded arrays. if you haven't adjusted those, that's where I'd look next. |
| 11:49 |
ACSpike[Work] |
jeff: I do hardcode the array for creation and I use the indices for updates in another file. |
| 11:52 |
ACSpike[Work] |
Whenever I do an update, I always pull a fleshed user |
| 11:53 |
ACSpike[Work] |
Comparing the array I generate to create and the fleshed user I pull, I'm seeing some differences. Still trying to figure out what might be significant. |
| 11:53 |
ACSpike[Work] |
and meld just crashed on me |
| 12:04 |
jeff |
counting array values in your gist, it looks like the patron dict in the create_patron function, starting around line 181, aligns as isnew: None, ischanged: TRUE. If you're trying to create a user, that's probably going to fail, possibly in the way you're seeing. |
| 12:04 |
jeff |
it's also possible I've counted incorrectly. perils of this approach. :-) |
| 12:06 |
jeff |
I also recommend an approach that makes use of the IDL to do this more automatically, but that's a larger change than what you're looking for right now! |
| 12:10 |
ACSpike[Work] |
Yes, I know I _should_ use the IDL. I just thought I could get away with the lazy way longer than I did. |
| 12:10 |
ACSpike[Work] |
It kinda looks like I'm adding an additional none somewhere, which I think it what you are saying too. |
| 12:13 |
ACSpike[Work] |
That did it. I screwed up adding my None and added two. |
| 12:13 |
ACSpike[Work] |
Sorry for the trouble. |
| 12:15 |
ACSpike[Work] |
I guess I'll move writing a field mapper up my list. :-) |
| 12:16 |
jeff |
Or keep your eyes open, there might be something useful to you soonish. |
| 12:17 |
jeff |
And don't feel bad: you aren't the only one, and likely also not in the running for "getting away with this lazy approach longest" :-) |
| 12:17 |
|
jvwoolf joined #evergreen |
| 12:36 |
Bmagic |
ACSpike[Work]: Evergreen has an external patron loader now: https://docs.evergreen-ils.org/docs/latest/development/support_scripts.html#patron_loader - you might be able to get inspiration from that code too |
| 12:38 |
|
jvwoolf joined #evergreen |
| 12:43 |
|
mmorgan joined #evergreen |
| 12:49 |
mmorgan |
Dyrcona: Sorry, my later, from earlier, was intended for Bmagic in response to his question: http://irc.evergreen-ils.org/evergreen/2025-04-22#i_577033 |
| 12:50 |
mmorgan |
Bmagic: I haven't tried this, but maybe if you set the user_setting_type.reg_default to TRUE for the circ.send_email_chekout_receipts type, that would do the trick? |
| 12:50 |
Bmagic |
mmorgan++ # interesting! I'll try it |
| 12:52 |
ACSpike[Work] |
Thanks for the help! |
| 13:10 |
jeff |
the sample invocation in the docs for that tool leaves me wondering how many swim caps have been left at the desk... |
| 13:52 |
Bmagic |
jeff++ |
| 14:01 |
|
mmorgan joined #evergreen |
| 14:09 |
|
mmorgan1 joined #evergreen |
| 15:28 |
|
mantis left #evergreen |
| 16:32 |
|
jvwoolf left #evergreen |
| 16:52 |
|
mmorgan1 joined #evergreen |
| 16:53 |
|
mmorgan1 left #evergreen |
| 22:42 |
|
Christineb joined #evergreen |
