| Time |
Nick |
Message |
| 03:17 |
|
yar joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-04-04T04:59:06,000630798-0400 -0> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
bdljohn joined #evergreen |
| 08:26 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
bos20k joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 09:00 |
|
agoben joined #evergreen |
| 09:14 |
|
sandbergja joined #evergreen |
| 10:26 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "IDL Parse Error, except xmllint says it's OK" (12 lines) at http://paste.evergreen-ils.org/10836 |
| 10:27 |
Bmagic |
Dyrcona: stock? |
| 10:27 |
Dyrcona |
Bmagic: Not stock, but xmllint doesn't report any issues, and the error suggest a missing </class> which xmllint would catch. |
| 10:28 |
Bmagic |
which OS 18.04? |
| 10:30 |
Dyrcona |
Nope, 16.04. |
| 10:30 |
|
JBoyer joined #evergreen |
| 10:30 |
Dyrcona |
I'm reverting the IDL additions to see if that makes a difference. |
| 10:31 |
Bmagic |
My thinking is the xmllint version might* matter - or yeah, fiddle with the IDL |
| 10:33 |
Dyrcona |
Well, reverting our custom entries seems to have resolved it. Now to figure out what's wrong with our custom entries. |
| 10:34 |
Dyrcona |
This didn't happen until I upgraded this VM to 3.2.4 with our customization branches. It was working fine with 3.0 and this patch. |
| 10:34 |
Bmagic |
hmmm, that is perplexing |
| 10:35 |
Dyrcona |
Though, it is working on the training server.... |
| 10:35 |
Bmagic |
I had a similiar issue recently but in my case the issue was much more obvious |
| 10:35 |
JBoyer |
If it's ok to post the custom IDL in full I'd be curious to see it. At least there are a couple ids in the error message. :) |
| 10:35 |
* Dyrcona |
double checks that. |
| 10:37 |
Dyrcona |
Nope. Apparently, that commit is missing from our training branch. |
| 10:37 |
|
Christineb joined #evergreen |
| 10:40 |
Dyrcona |
No conflict markers... |
| 10:48 |
Dyrcona |
So, it's looking like something is botching it during installation, actually. |
| 10:50 |
Dyrcona |
I'm not sure, though what the \n means in that parser output. |
| 10:54 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagic: The full IDL" (13098 lines) at http://paste.evergreen-ils.org/10837 |
| 10:54 |
pastebot |
"JBoyer" at 64.57.241.14 pasted "Dyrcona's message reformatted" (11 lines) at http://paste.evergreen-ils.org/10838 |
| 10:55 |
JBoyer |
Just to line things up in the error message. You'll probably have to look at the plain text to see what it's doing. |
| 10:56 |
JBoyer |
Oh, no, the default view does the right thing re: monospaced fonts. |
| 11:01 |
Dyrcona |
cash_report_mimic is the only class that has \n without any ' ' between the attributes. The other classes all have a ' ' or more. |
| 11:02 |
Dyrcona |
Sounds like a bug in the XML parser. :) |
| 11:04 |
|
yboston joined #evergreen |
| 11:08 |
Dyrcona |
Yeahp. Seems to be working, now. |
| 11:09 |
Dyrcona |
Dunno if that's a bug in the parser or just one of those things. |
| 11:10 |
|
collum joined #evergreen |
| 11:11 |
Dyrcona |
And, I need to modify my websocksetd start script to redirect to /dev/null. :) |
| 11:11 |
Dyrcona |
The console messages can get in the way. |
| 11:12 |
|
sandbergja joined #evergreen |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:31 |
|
khuckins joined #evergreen |
| 12:33 |
Dyrcona |
Anyone else have the user permission editor go unresponsive on 3.2? |
| 12:34 |
mmorgan |
Dyrcona: I've seen that on 3.1, it actually behaves better for me on 3.2. |
| 12:36 |
Dyrcona |
Well, that interface looks like it lacks intelligence. It seems to update everything listed, so when you have a lot of work_ou_maps, it times out or something. |
| 12:36 |
mmorgan |
Actually, let me amend that. It behaves better on 3.1 and 3.2 for me than it did on 3.0. |
| 12:37 |
Dyrcona |
Well, I'll blame the slow VM and busy db server for now. |
| 12:46 |
Dyrcona |
Group permissions editor seems to just be broken. I tried adding a mapping and I don't even see an attempt to create a grp_perm_map entry in the logs. |
| 12:48 |
Dyrcona |
Only thing in the logs matching grp are related to opening conify/global/permission/grp_tree.hml |
| 12:50 |
mmorgan |
Dyrcona: I noticed that on a 3.3 system just this morning. Seems to be working ok on our 3.2.4 training system. |
| 12:51 |
Dyrcona |
I haven't been told its not working on our 3.2.5 training system. This machine where it's not working is a 3.2.4 test VM. We decided not to go to 3.2.5 after some performance issues with a couple of the fixes. |
| 12:53 |
Dyrcona |
So, wonder if it's "one of those things" or something that we backported, but I don't recall backporting any permissions-related things. |
| 13:00 |
Dyrcona |
Well, this explains it: POST https://jasontest.cwmars.org/osrf-http-translator 400 (Bad Request) |
| 13:02 |
Dyrcona |
I get a number of 404s for dojo.js and openils_dojo.js just opening the page. |
| 13:10 |
* Dyrcona |
tries reinstalling OpenSRF rel_3_1, just in case. |
| 13:14 |
Dyrcona |
Nope. Doesn't help after rebuilding OpenSRF and Evergreen. |
| 13:19 |
Dyrcona |
Well, it's not max_stanza_size, turns out that is 20,000,000 on this machine. |
| 13:28 |
|
yboston joined #evergreen |
| 13:29 |
Bmagic |
What's the troubleshooting steps for penalties that are not getting applied? It clearly should be getting applied. I've ran open-ils.actor.user.penalties.update on srfsh, it's not deciding that the patron needs the penalty when it clearly does |
| 13:30 |
Bmagic |
I'm going for PATRON_EXCEEDS_LOST_COUNT at a threshold of 1. But the patron only has one thing lost, so I thought maybe it needs to have a threshold lower than 1, so I tried .5. No dice |
| 13:31 |
Bmagic |
The lost item, patron home library and penalty org unit match |
| 13:32 |
Dyrcona |
Try having the patron lose another item. |
| 13:32 |
Bmagic |
:) |
| 13:32 |
bshum |
Maybe also run the recalculate patron penalty function in the DB |
| 13:33 |
Bmagic |
Oh, there is a function in the DB? I couldn't identify one |
| 13:33 |
bshum |
Isn't there? Maybe I'm making it up in my head... |
| 13:33 |
Dyrcona |
:) |
| 13:33 |
Bmagic |
oh yep actor.calculate_system_penalties |
| 13:33 |
Dyrcona |
A lot of the Perl code ends up running db functions. |
| 13:33 |
Dyrcona |
Well, a good bit of it, anyway. |
| 13:34 |
berick |
Bmagic: any chance the item has been returned and or the xact has been all paid off? |
| 13:34 |
Dyrcona |
I'm a bit vague on what the flow is supposed to be with penalties. |
| 13:34 |
Bmagic |
bshum: good call - executing that function returns the penalty that I want, however it doesn't insert it into actor.usr_standing_penalties |
| 13:35 |
bshum |
Bmagic: Are you sure they don't already have the penalty set then somewhere else? |
| 13:35 |
Bmagic |
not according to the database they don't |
| 13:35 |
Bmagic |
select * from actor.usr_standing_penalty where usr={myid} |
| 13:36 |
bshum |
Okay, just checking cause sometimes I've seen it where we had a lost penalty threshold for higher branch level |
| 13:36 |
Dyrcona |
can't argue with the database. :) |
| 13:36 |
bshum |
And that resulted in different penalties being assigned |
| 13:37 |
Bmagic |
yep, the DB function returns the rows I would expect to see in usr_standing_penalty. So, when do rows get inserted there? Not part of running the DB function? |
| 13:38 |
Dyrcona |
probably as part of the back end function. |
| 13:39 |
Bmagic |
at least on XUL, I thought that the act of opening the patron would run the calculation |
| 13:40 |
Dyrcona |
Bmagic: You don't get a permission error, do you? |
| 13:40 |
Bmagic |
not on the UI at least I don't |
| 13:40 |
Bmagic |
haven't checked the logs |
| 13:41 |
Dyrcona |
When you run it in srfsh, you've logged in and passed in the authtoken? |
| 13:41 |
Bmagic |
yep, on srfsh it works without errors |
| 13:41 |
Bmagic |
Received Data: "1" |
| 13:41 |
Dyrcona |
Did it update the patron in the db? |
| 13:41 |
Bmagic |
nope |
| 13:41 |
Bmagic |
or at least it didn't apply the penalty that I want it to |
| 13:44 |
Dyrcona |
Could be the org_unit that you're using, but the call eventually uses the db function to get the penalties to apply. |
| 13:44 |
Bmagic |
request open-ils.actor open-ils.actor.user.penalties.update "myauth", 571114 |
| 13:44 |
Bmagic |
I will say that my authtoken is workstationless |
| 13:44 |
Bmagic |
at srfsh |
| 13:45 |
Dyrcona |
Well, that may be the problem. |
| 13:45 |
Bmagic |
can I pass a workstation DB ID using the srfsh# login staff password ? |
| 13:45 |
Dyrcona |
Add the workstation and see what happens. |
| 13:46 |
Dyrcona |
login <username> <password> [type] [org_unit] [workstation] |
| 13:46 |
Dyrcona |
from srfsh help |
| 13:47 |
Bmagic |
oh, umm, what do I do for type ? "staff" ? |
| 13:47 |
Dyrcona |
you can also use the open-ils.auth.login call. |
| 13:47 |
Dyrcona |
yes. |
| 13:49 |
Bmagic |
ok, what am I doing wrong |
| 13:49 |
Bmagic |
request open-ils.auth open-ils.auth.login {"admin","password", "staff", 285, 1590} |
| 13:50 |
Dyrcona |
login admin demo123 staff BR1 BR1-N240WU |
| 13:50 |
Dyrcona |
You want the names, quotes not needed. |
| 13:51 |
Dyrcona |
srfsh# request open-ils.auth open-ils.auth.login {"username": "admin", "password": "demo123", "type": "staff", "workstation": "BR1-N240WU"} |
| 13:51 |
Dyrcona |
Both commands, copy/pasted from my pre-confernce slides. :) |
| 13:51 |
bshum |
#shameless advertising |
| 13:51 |
bshum |
Dyrcona++ |
| 13:53 |
bshum |
Just thinking out loud... is this Lost penalty for a single library branch or something? or is it a higher org tree rule? |
| 13:53 |
bshum |
And is the workstation where you're trying to trigger the penalty at the same level? |
| 13:53 |
bshum |
*location |
| 13:54 |
bshum |
Cause let's say if you had a penalty threshold set for a given library, but you were using the workstation of another library, it wouldn't necessarily trigger the penalty |
| 13:54 |
bshum |
Until someone were to retrieve it using the library where the threshold was set |
| 13:55 |
Bmagic |
holy cow, that was an ordeal to get logged with the workstation on srfsh. But once I did and ran the penalties command, it updated the DB |
| 13:55 |
Bmagic |
Dyrcona++ |
| 13:55 |
bshum |
That's one of the reasons why local based blocking rules that apply consortially is not good |
| 13:55 |
Bmagic |
bshum++ |
| 13:55 |
Bmagic |
Conclusion: refreshing the patron on the web client doesn't update the penalties |
| 13:56 |
bshum |
Was the penalty set at org unit 1 for the whole consortium or just one place? |
| 13:56 |
Bmagic |
at the system level |
| 13:56 |
bshum |
Okay, and the workstation used to look up the patron was from that system? |
| 13:56 |
Bmagic |
on the web client in my testing, I was logged in at the branch under the system where the penalty is defined |
| 13:56 |
bshum |
Hmm |
| 13:57 |
bshum |
that sounds suspicious then |
| 13:58 |
* bshum |
doesn't know enough about the web client to comment further :D |
| 13:59 |
Bmagic |
I didn't try refreshing on XUL - I should have |
| 14:00 |
* Dyrcona |
lurks for a bit. |
| 14:00 |
jeff |
makes sense. the web client doesn't *have* a refresh option for the patron, right? |
| 14:01 |
Bmagic |
cause the browser has one built in |
| 14:02 |
Bmagic |
confirmed - XUL applied the penalty |
| 14:02 |
bshum |
Running the penalty re-calc every time we retrieve a patron in web client sounds expensive |
| 14:02 |
bshum |
Maybe there needs to be a new button for forced recalc |
| 14:03 |
Bmagic |
I should have tried that before this whole conversation |
| 14:03 |
Bmagic |
The refresh button on XUL is what did it. Opening the patron did not (on XUL) |
| 14:03 |
bshum |
Right, again, why recalc every time you open a patron |
| 14:04 |
bshum |
Sounds like a fun new feature |
| 14:07 |
Bmagic |
The special button (renamed from refresh to Webby friendly terms) might be required to fix this issue. I think* the action trigger MarkItemLost will recalc the penalties at the end so that's something. |
| 14:25 |
|
ningalls_ joined #evergreen |
| 15:16 |
|
JBoyer joined #evergreen |
| 16:22 |
Bmagic |
jeff: RE: auditor table claiming to have status checked out without a matching circulation in action.circulation - Nothing in aged_circulation. also config.copy_alert_type next_status is null 100% of the rows |
| 16:29 |
jeff |
I wonder how much work it would take to make the Renew context menu option in Item Status open the Renew interface with the barcodes of the selected items. |
| 16:30 |
jeff |
Because then the receipt experience would be a bit better... |
| 16:30 |
jeff |
context is for item-present renewals where the patron isn't certain that they want to renew yet, etc. |
| 16:30 |
|
khuckins joined #evergreen |
| 16:30 |
jeff |
transaction begins with "can you check to see when this is due?" |
| 16:31 |
jeff |
Also, there doesn't seem to be a way to print a single item receipt from Item Status. |
| 16:32 |
jeff |
Bmagic: interesting! i don't remember all of the other details, but I think so far I'm stumped, barring a direct db update or copy template shenanigans. |
| 16:33 |
Bmagic |
right! I'm exporing an idea, be back shortly |
| 16:33 |
Bmagic |
exploring |
| 16:37 |
mmorgan |
Bmagic: It was possible in the xul client to change an item's status to Checked out in the editor under certain circumstances. |
| 16:37 |
Bmagic |
oh yeah? |
| 16:37 |
Bmagic |
That almost has to be it |
| 16:38 |
mmorgan |
bug 1616980 |
| 16:38 |
pinesol |
Launchpad bug 1616980 in Evergreen 2.12 "Magical statuses not so magical - possible for staff to edit items into or out of magical statuses" [Medium,Fix released] https://launchpad.net/bugs/1616980 |
| 16:38 |
Bmagic |
mmorgan++ |
| 16:39 |
Bmagic |
but it wasn't possible in 3.0+ ? |
| 16:39 |
Bmagic |
The date on this is this year and the system was on 3.0.9 |
| 16:40 |
mmorgan |
That fix was for the web client, it was never fixed in xul. |
| 16:40 |
Bmagic |
sweet! Thanks |
| 16:40 |
Bmagic |
I was about to start reading the code |
| 16:40 |
mmorgan |
bug 1695921 |
| 16:40 |
pinesol |
Launchpad bug 1695921 in Evergreen "Possible for staff to edit items into or out of magical statuses (XUL)" [Undecided,Won't fix] https://launchpad.net/bugs/1695921 |
| 16:41 |
mmorgan |
@decide read code or read launchpad |
| 16:41 |
pinesol |
mmorgan: go with read launchpad |
| 16:41 |
mmorgan |
:) |
| 16:41 |
jeff |
was status the only thing that changed, or did the edit timestamp and other bits change as well, as you'd expect from an edit operation in the client? |
| 16:41 |
Bmagic |
is it plausable that the staff switched it to checked out manually (even though the item was returned and on the shelf) - then the system marked it lost and billed the patron that last circed it? |
| 16:41 |
jeff |
i can't remember if that question was asked/answered in the previous description of the mystery. :-) |
| 16:43 |
Bmagic |
edit date changed as well as status changed time |
| 16:43 |
Bmagic |
auditor did record who did it |
| 16:48 |
jeff |
ah good. also be interesting to example copy templates for that user, as those were another way to force a status change. |
| 16:48 |
jeff |
as for your question about the system billing the previous patron who circulated the item... that would be common under a Damaged workflow, but I'm not sure that you'd end up with that for Lost. |
| 16:49 |
jeff |
gmcharlt: i just dusted off bug 1437106 to put a comment on it, containing a question for you if and when you have a moment. |
| 16:49 |
pinesol |
Launchpad bug 1437106 in Evergreen "keyboard shortcuts in the web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437106 |
| 16:50 |
* gmcharlt |
sneezes |
| 16:50 |
jeff |
:-) |
| 16:53 |
Bmagic |
Another clue here is: the item was automatically marked Lost but the patron never received the related billing. That's because the circulation wasn't open. |
| 16:53 |
jeff |
which process marked the item lost? |
| 16:54 |
mmorgan |
Bmagic: could bug 1758975 possibly be relevant? |
| 16:54 |
pinesol |
Launchpad bug 1758975 in Evergreen "Item status can be set to Lost and Paid inappropriately when closing a transaction for a Long Overdue or Lost returned item" [Medium,Confirmed] https://launchpad.net/bugs/1758975 |
| 16:54 |
Bmagic |
I was thinking that the system did the right thing by not billing the patron, because the circulation was closed |
| 16:58 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "for jeff: the Evergreen side of the experiment" (22 lines) at http://paste.evergreen-ils.org/10840 |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:08 |
jeff |
gmcharlt++ i'll keep my eyes out for the Mousetrap side, or let me know if there isn't one. Thanks! |
| 17:37 |
jeffdavis |
Are we going to have a proper dev meeting this month? I know there was an informal quasi-meeting on Tuesday... |
| 18:11 |
Dyrcona |
We usually have one at the conference, at least among the committers. |
| 18:29 |
|
jamesrf joined #evergreen |
| 18:56 |
jeffdavis |
Yeah, that makes sense. |
| 20:03 |
|
sandbergja joined #evergreen |
| 21:44 |
|
sandbergja joined #evergreen |
| 22:05 |
Dyrcona |
Oh! I'm still signed in? |
