| Time |
Nick |
Message |
| 02:15 |
|
ahelten joined #evergreen |
| 02:52 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:27 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:00 |
|
_adb joined #evergreen |
| 09:03 |
|
maryj joined #evergreen |
| 09:03 |
|
maryj_ joined #evergreen |
| 09:05 |
|
kmlussier joined #evergreen |
| 09:31 |
|
jvwoolf joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:46 |
rjackson_isl |
can someone point me to the logic that involves collection agency hooks when patron exceeds a designated thresh hold and later drops below that same value? |
| 09:47 |
rjackson_isl |
background info: branch wanted all bills forgiven for their patrons that were initiated prior to a give date - forgot to not forgive bills owed to other libraries (oops) |
| 09:48 |
rjackson_isl |
when the bills were forgiven(voided) patrons were taken out of collections |
| 09:48 |
rjackson_isl |
when the mistake was corrected (unvoiding of same set of bills) the patron accounts did not go back into collections |
| 09:51 |
bshum |
Uh, that sounds like a messy situation rjackson_isl |
| 09:51 |
rjackson_isl |
yeah - it was rather EXCITING! |
| 09:51 |
bshum |
To my recollection, there's a table for users to get added to for collections |
| 09:51 |
bshum |
And I would think that adding back bills that would force someone into collections state, would be some sort of penalty threshold |
| 09:52 |
bshum |
So refreshing a user's data or recalculating penalities might help |
| 09:53 |
bshum |
Taking users out of collections wasn't something I ever touched |
| 09:53 |
bshum |
I usually left that to the collections agency |
| 09:54 |
rjackson_isl |
bshum: I was thinkg (perhaps in error) there was a hook that the agency had to take the patron out of collections and they collection agency triggered it somehow? |
| 09:54 |
* bshum |
does not want to get involved with money |
| 09:54 |
bshum |
They do have that ability |
| 09:54 |
bshum |
Or they should |
| 09:54 |
bshum |
At least, Unique did when I worked with them |
| 09:54 |
rjackson_isl |
yeah - rjackson_isl has done some pretty dumb things in the past moeny related! |
| 09:55 |
Dyrcona |
Well, it gets complicated when you start dealing with money. |
| 09:55 |
Dyrcona |
You might think "it's only math," but you'd be mistaken. :) |
| 09:56 |
Dyrcona |
It's easy to mess up, and boy, don't people get mad when you do. :) |
| 09:56 |
rjackson_isl |
test plans and reviews are your friend in this case |
| 09:57 |
berick |
rjackson_isl: there are 2 parts, the collection agency tracker (money.collections_tracker IIRC) and penalty. the penalty can be locally cleared when the threshold goes back down, but the agency has to clear the collection_tracker entry |
| 09:58 |
rjackson_isl |
berick: in the instance currently being reviewed there is a note on the account showing it going into collections and then back out when I did the oops |
| 09:58 |
rjackson_isl |
it doesn't show going back into collections in the note when I corrected (or partially corrected) |
| 09:59 |
Dyrcona |
rjackson_isl: Yeah, my first reaction was to think that users don't just get removed from collections. That has to be done manually, but I don't know that API. |
| 09:59 |
rjackson_isl |
and the collection agency is indicating the account did not go back into collections even though it is over the thresh hold |
| 09:59 |
Dyrcona |
So, kindof what berick said. :) |
| 10:01 |
berick |
rjackson_isl: when you say a 'note', like a penalty entry under patron "messages" |
| 10:01 |
rjackson_isl |
yeah - no row in money.collections_tracker for this patron |
| 10:01 |
berick |
? |
| 10:02 |
rjackson_isl |
under the Notes entry "Patron Removed from Collections" as header with "Patron removed from collections for xxxx on 1/25/2017" in detail |
| 10:03 |
kmlussier |
agoben++ |
| 10:03 |
berick |
the only way for a patron to be removed from money.collections_tracker is for someone (i.e. the agency) to make an API call for open-ils.collections.remove_from_collections |
| 10:03 |
berick |
and there /is/ a collections API for adding patron notes too |
| 10:04 |
berick |
which may be the source of the note in question |
| 10:04 |
berick |
open-ils.collections.patron_note.create |
| 10:04 |
berick |
so the agency may remove the patron and add a note indicating as much |
| 10:04 |
rjackson_isl |
berick: so would it be up to the collection agency to re-add the patron when I did the adjustment back in January or is it because I un-voided existing bills their logic didn't pick it up? |
| 10:05 |
rjackson_isl |
(probably one for the collection agency...) |
| 10:06 |
Dyrcona |
I think the answer is, "Don't do that." :) |
| 10:06 |
berick |
rjackson_isl: yes, and it depends on how they are doing it. there are 2 APIs for finding patrons to put into collections. one is based on amount owed and one is based on the presence of a threshold penalty (PATRON_EXCEEDS_COLLECTIONS_WARNING) |
| 10:06 |
berick |
if they are using the penalty method, then the penalty has to exist on the patron beore they can go into collections |
| 10:07 |
rjackson_isl |
berick: that sounds familiar - it has been a few months since this fiasco though so my reuse of brain cells comes into play |
| 10:07 |
rjackson_isl |
berick++ bshum++ Dyrcona++ |
| 10:07 |
rjackson_isl |
tgif |
| 10:08 |
berick |
:) |
| 10:08 |
jeff |
ooh. collections talk. |
| 10:08 |
* jeff |
reads up |
| 10:08 |
jeff |
(scrolls back, whatever) |
| 10:08 |
bshum |
No jeff, don't look at the light! |
| 10:08 |
rjackson_isl |
jeff: hopefully you won't get to experince this pleasure |
| 10:09 |
jeff |
bshum: I looked at the trap, Ray. |
| 10:12 |
miker |
rjackson_isl: IIRC, there's a time threshold in the collections api as well, so it may be that the reinstated fines are too old to cause the patron to cross the threshold now... maybe |
| 10:12 |
rjackson_isl |
miker: thanks for that info as well - in this case they were pretty old! |
| 10:13 |
* miker |
sees if he can confirm. haven't looked at collections in... a long time |
| 10:13 |
jeff |
When using the older (but probably more common) "users of interest" call, the vendor does a sweep using some basic criteria, then retrieves a number of details including transaction details, and can apply all manner of logic external to Evergreen. |
| 10:13 |
rjackson_isl |
xact_start: 2015-05-xx |
| 10:15 |
jeff |
You will likely have more luck by engaging your collections vendor to help diagnose the issue, rather than trying to fix it without their involvement -- which will likely result in a restart of the collections process on their end, the library being billed freshly for each patron being submitted, a new bill (if any) being added to the patron account, etc. |
| 10:16 |
rjackson_isl |
jeff: in this case I think the library is willing to let the isue slide but wanted info on why :( |
| 10:16 |
jeff |
You probably don't want much of if any of those things to happen. |
| 10:17 |
jeff |
rjackson_isl: simplest is probably (after verifying with your vendor) "once we undid the mistake, the patron no longer met the criteria that originally put them into collections. even though they carried a qualifying balance, the transactions were now too old." |
| 10:18 |
rjackson_isl |
once again a big ++ to the Evergreen community! |
| 10:19 |
jeff |
"we've identified X patrons that were affected, and after consulting with {vendor} we think that we {can|can't} place them back into collections without a large amount of additional work", etc... :-) |
| 10:19 |
Dyrcona |
Don't mess with bills. It's a gateway to Hell. |
| 10:19 |
rjackson_isl |
yeah - either that or the other libraries involved didn't have a prosecutor involved :( |
| 10:20 |
miker |
rjackson_isl: yeah ... there are a ton of things that could be stopping patrons from falling back into collections, if that's the goal. if it's UMS you're working with, they'll be as helpful with diagnostics as they can be, I'm sure |
| 10:20 |
rjackson_isl |
mikre: I think the library is in direct contact on their side so I am going to stay out of this fight unless forced to join! |
| 10:20 |
rjackson_isl |
miker: that is... |
| 10:20 |
* Dyrcona |
shuts up and goes back to checking if his test db server has finished rebooting. |
| 10:30 |
Dyrcona |
On a somewhat related note, I've been having trouble finding patrons that return fine item details with SIP2. |
| 10:30 |
jeff |
Oh? |
| 10:30 |
Dyrcona |
I'll have to look into because apparently the code isn't doing what I think it does. |
| 10:30 |
jeff |
Before or after your format changes? |
| 10:30 |
Dyrcona |
Well, I get no patron that return anything other than 0 in the fine items count field. |
| 10:31 |
Dyrcona |
I'm dropping words again. Brain faster than the fingers. |
| 10:31 |
Dyrcona |
Maybe I should try the charged items field? |
| 10:31 |
jeff |
that's "items checked out" |
| 10:31 |
Dyrcona |
Right. |
| 10:32 |
Dyrcona |
I even ran the fine generator on my server before the last run. |
| 10:32 |
Dyrcona |
Not sure if the modifications broke something or what. |
| 10:32 |
Dyrcona |
Having a million other things to do and a vacation in between doesn't help. |
| 10:35 |
Dyrcona |
It supposedly works with contrived examples in the Concerto data, i.e. after adding a fine to a patron. |
| 10:35 |
|
jvwoolf joined #evergreen |
| 10:37 |
jeff |
there have been issues in the past with regard to some SIP code using a different mat view (old money owed summaries, iirc), and there were gotchas with auth tokens and/or multiplex personality, but i think most of the ones that would affect this have been addressed. |
| 10:38 |
jeff |
Dyrcona: i'm interested in what you find and might be able to help troubleshoot, but nothing immediately comes to mind for you to try. |
| 10:38 |
jeff |
Dyrcona: what client are you testing with, and have you checked the raw sip message either over the wire or in the server logs to verify that the client isn't obscuring / mis-parsing the fixed field in question? |
| 10:39 |
Dyrcona |
I'm using branches based on Evergreen 2.12.3 and SIPServer master with a copy of production data. |
| 10:39 |
Dyrcona |
jeff: PHPSIP2, and yes, I've dumped the raw messages. I'm not getting the results that I expect. |
| 10:40 |
Dyrcona |
If I ask for 10 fine item details, I get 10 empty fields on every patron. |
| 10:40 |
jeff |
oh, i thought you were dealing with the fixed field being 0 instead of 10. |
| 10:40 |
jeff |
the count. |
| 10:40 |
Dyrcona |
Yes, I was about to explain. :) |
| 10:41 |
Dyrcona |
I started picking patrons that owed money in blocks of ten or so in various intervals from the database. |
| 10:42 |
Dyrcona |
I then requested patron info with fine item details requesting up to 10 responses. |
| 10:42 |
Dyrcona |
That gave the results above. |
| 10:43 |
jeff |
if you don't request any details, does the summary count show a non-zero value for the patron's fine items? |
| 10:43 |
Dyrcona |
So, I switched to pulling all patrons that owe money, requesting patron info, and if fine items details was greater than 0, requesting again for that many items. |
| 10:43 |
Dyrcona |
I get 0 for every patron. |
| 10:43 |
jeff |
and at that point, they were all 0? ah. |
| 10:43 |
Dyrcona |
Even after running the fine generator. |
| 10:44 |
Dyrcona |
Since I haven't tested with unmodified code, I don't know what's broke. :) |
| 10:44 |
jeff |
if you reduce it to one patron with bills that is showing a count of 0 fine items via SIP2, if you open the patron in the staff client and Refresh them, does that then change the fine items count in SIP2? |
| 10:45 |
Dyrcona |
I haven't tried that. |
| 10:48 |
jeff |
Does the Evergreen user that the SIPServer is authenticating as have VIEW_USER_TRANSACTIONS permission at the proper ou/depth? |
| 10:48 |
jeff |
(needs to have it at the home_ou of the user you're looking up) |
| 10:50 |
|
rlefaive left #evergreen |
| 10:50 |
rjackson_isl |
followup note: found the "fix" script used and it only tried to update actor.usr_standing_penalty for existing collections warning entries - but in this case it should have done an add :( |
| 10:52 |
jeff |
rjackson_isl: I will again point out that if you just try to get the patrons eligible for collections again, and they go to collections again, you'll likely make the process worse than if you work with the collections vendor to come up with an idea for fixing the mistake. The patrons are no longer in money.collections_tracker, so even if you get the facts such so that the patrons will match the criteria to be submitted, starting the submission / collectio |
| 10:52 |
jeff |
(and i was verbose, and truncated myself) |
| 10:53 |
rjackson_isl |
jeff++ thanks for the warning I am not going to mess with this again I promise!!! |
| 10:53 |
Dyrcona |
jeff, it has VIEW_USER_FINES_SUMMARY but not VIEW_USER_TRANSACTIONS. |
| 10:53 |
jeff |
...even if you get the facts such so that the patrons will match the criteria to be submitted, starting the submission / collections process fresh is likely a Bad Idea. There isn't a way to put them "back where they were" in the collections process without involving your collections vendor and having careful coordination. |
| 10:54 |
rjackson_isl |
messing with money is a bad idea - but I was out-voted! |
| 10:54 |
jeff |
rjackson_isl: you're welcome :-) |
| 10:55 |
Dyrcona |
jeff thanks for the suggestions, I'm going to rebuild my test vm and give i another whirl. |
| 10:55 |
Dyrcona |
s/i/it/ |
| 10:56 |
jeff |
Dyrcona: it could be as simple as that, then. |
| 10:56 |
* jeff |
finds things he wants to change |
| 10:57 |
Dyrcona |
It could be as simple as changing/adding a permission. |
| 10:57 |
Dyrcona |
Actually, before I blow it all away and resintall, I'll give that a whirl. :) |
| 11:00 |
jeff |
also, if you have Evergreen logging turned up to debug, the lines matching "OILS: Patron->fine_items" will be likely helpful/instructive |
| 11:01 |
jeff |
especially if they match "OILS: Patron->fine_items() ERROR: " |
| 11:01 |
jeff |
which is just one thing that i want to fix. |
| 11:01 |
jeff |
(burying an ERROR in a DEBUG) |
| 11:02 |
jeff |
(my fault, originally) |
| 11:02 |
jeff |
I'm also wondering why I went with the history form of open-ils.actor.user.transactions.history.have_balance here. |
| 11:04 |
Dyrcona |
Dunno. :) |
| 11:05 |
Dyrcona |
I'm trying again. |
| 11:05 |
Dyrcona |
Well, after I run the fine generator again, just to be up to date. |
| 11:06 |
jeff |
Ah, because that's probably the most appropriate API call anyway. |
| 11:06 |
jeff |
(the history variant) |
| 11:06 |
jeff |
But I'll double check myself. |
| 11:09 |
jeff |
oh, and at least one of the gotchas i was thinking of is probably still present. |
| 11:10 |
jeff |
the total amount of money / balance is based on retrieve_money_open_user_summary |
| 11:10 |
jeff |
(this doesn't affect you) |
| 11:10 |
jeff |
(probably doesn't affect your current problem, that is) |
| 11:14 |
Dyrcona |
jeff: Here's the client script, if you're interested: https://pastebin.com/5jm9m2h3 |
| 11:15 |
Dyrcona |
And, I meant to add debug settings to PHPSIP2 so it can dump the messages, but I didn't get to that, yet. :) |
| 11:20 |
Dyrcona |
jeff++ Looks like it was a permissions issue. |
| 11:20 |
jeff |
Oh good! |
| 11:21 |
Dyrcona |
I'm getting out put at least. |
| 11:21 |
jeff |
Excellent. |
| 11:21 |
Dyrcona |
Until this happened: PHP Fatal error: Uncaught Exception: _parse64 failed to parse message in /home/opensrf/PHPSIP2/sip2client.class.php:562 |
| 11:23 |
Dyrcona |
Bet some field has a | in it. |
| 11:23 |
jeff |
encoding error on a title? :-) |
| 11:23 |
jeff |
heh. |
| 11:23 |
Dyrcona |
Yeah, or an encoding error. |
| 11:24 |
jeff |
oh hey, here's why this is taking a while: `Seq Scan on circulation circ` |
| 11:24 |
Dyrcona |
yeah, that might take a while. :) |
| 11:25 |
Dyrcona |
A dozen or more million rows, I'm sure. |
| 11:27 |
* jeff |
disables pager and upgrades to EXPLAIN ANALYZE for the real thing |
| 11:28 |
* Dyrcona |
has been using -P pager with psql a lot lately. |
| 11:31 |
Dyrcona |
agoben++ |
| 11:56 |
|
jihpringle joined #evergreen |
| 11:59 |
|
Christineb joined #evergreen |
| 12:07 |
|
abowling joined #evergreen |
| 12:27 |
abowling |
rjackson++ for helping with an error of omission |
| 13:05 |
* jeff |
successfully resists the urge to over-optimize a weeding report query |
| 13:05 |
jeff |
(for now!) |
| 13:58 |
|
jvwoolf left #evergreen |
| 14:39 |
|
ningalls joined #evergreen |
| 14:56 |
|
Jillianne joined #evergreen |
| 15:06 |
gmcharlt |
https://evergreen-ils.org/evergreen-2-11-7-and-2-12-4-released/ |
| 15:11 |
kmlussier |
gmcharlt++ dbwells++ Bmagic++ |
| 15:11 |
gmcharlt |
kmlussier++ |
| 15:27 |
jeff |
gmcharlt++ dbwells++ Bmagic++ kmlussier++ |
| 15:31 |
pinesol_green |
[evergreen|Galen Charlton] forward port 2.12.3-2.12.4 schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7b4349> |
| 15:56 |
|
rlefaive joined #evergreen |
| 16:15 |
jeff |
When a single library holds a given item, and someone places a hold request on that item, and only THEN is the item found to be missing (and marked as such), I don't think we have an established workflow for letting the patron know that they're not going to be getting the item. |
| 16:15 |
jeff |
Instead, the request hangs out until it comes up on somebody's "old unfilled holds" report or similar. |
| 16:16 |
jeff |
Or, in this case, a "unfulfillable holds" report. |
| 16:17 |
|
mtcarlson joined #evergreen |
| 16:20 |
mmorgan |
jeff: this happens a lot in our consortium. |
| 16:20 |
mmorgan |
Similarly, if all copies become long overdue when there are still holds to be filled. |
| 16:22 |
mmorgan |
We generate and post a "Hopeless Holds" report daily. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:44 |
abneiman |
jeff: when I was at KCPL we did a weekly "Hopeless Holds" report -- based on a version that NC Cardinal did. It let us know when the amount of targetable copies dropped to 0 (lost, missing, claimed returned, etc) on titles with holds. Interacted a little wonkily with metarecord holds, IIRC, but it got the job done. |
| 16:46 |
mmorgan |
Ours only looks at title holds, so, not perfect, but also gets the job done (mostly). |
| 16:46 |
abneiman |
jeff: see slide 22 of this presentation: https://evergreen-ils.org/wp-content/uploads/2015/11/eg16-Oops-I-accidentally-deleted-something-and-other-small-problems-bite-sized-reports-to-help-you-find-and-fix-problems-in-your-ILS.compressed.pdf |
| 16:47 |
abneiman |
the one I used was slightly different but I don't have a version of it handy right now |
| 16:59 |
|
mmorgan left #evergreen |
| 17:06 |
jeff |
mmorgan++ abneiman++ thanks. Nice to see alternate approaches. |
| 17:28 |
jeff |
We're using Jasper for reporting, so I have an SQL query that gives "unfulfillable" holds for a given library based on the hold having no matching rows in action.hold_copy_map. So far, I think I'm getting reasonable results. Some/all of these already show up on our holds/copy ratio reports, but I think we're overdue for having a report dedicated to these that people pay attention to sooner rather than later. |
| 17:30 |
abneiman |
jeff: it's definitely a customer service plus. KCPL was so small, we only had a handful (5-6) per week, but patrons (and the acquisitions librarian) really appreciated being notified. |
| 17:33 |
jeff |
And we often have the option of asking them if they'd like us to re-request through the statewide ILL system on their behalf. |
| 17:34 |
jeff |
I was interested, so I flipped a NOT EXISTS to an EXISTS in the query, and looked at old holds that have entries in action.hold_copy_map but aren't fulfilled for some reason. |
| 17:34 |
jeff |
So far, lots of suspended holds (logical) and lots of holds on "on order" copies that probably aren't ever going to become "real" copies. |
| 17:34 |
jeff |
(book cancelled, etc) |
| 17:36 |
jeff |
Not all, though... Hrm. More to look at later! |
| 17:38 |
_adb |
happy sysadmin appreciation day, everyone. i got you a cat: https://i.imgur.com/YCjGkKL.gifv |
| 17:46 |
gmcharlt |
awwwwww |
| 17:46 |
gmcharlt |
_adb++ |
| 18:25 |
|
jvwoolf joined #evergreen |
| 18:26 |
|
jvwoolf left #evergreen |
| 20:10 |
ahelten |
Question: which GUI do you use for postgresql database management? I'm not very savvy with postgresql command line so prefer a GUI for admin (like scheduling backups). I've used webmin in the past, is that still one of the better options? |
| 22:49 |
|
jvwoolf joined #evergreen |
