| Time |
Nick |
Message |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:57 |
|
_adb joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:18 |
Bmagic |
Has anyone "turned off" bib editing while 3rd party vendors perform authority on the DB? If so, which method? I was considering permissions and/or DB table rule |
| 09:19 |
Bmagic |
JBoyer: might as well have the option if it's not too much trouble |
| 09:20 |
|
yboston joined #evergreen |
| 09:27 |
Dyrcona |
Bmagic: I've never done that and we do authority loads every quarter, and I still have to send last quarter's file.... |
| 09:27 |
Dyrcona |
IOW: I don't think it is necessary, really. |
| 09:28 |
|
dbwells joined #evergreen |
| 09:28 |
|
JBoyer joined #evergreen |
| 09:42 |
|
kmlussier joined #evergreen |
| 09:48 |
kmlussier |
Happy Friday #evergreen! |
| 09:48 |
kmlussier |
@coffee [someone] |
| 09:48 |
* pinesol_green |
brews and pours a cup of Kenya Ndiara, and sends it sliding down the bar to phasefx |
| 09:48 |
kmlussier |
@tea [someone] |
| 09:48 |
* pinesol_green |
brews and pours a pot of Greenfield Estate Ceylon Black Tea, and sends it sliding down the bar to berick (http://ratetea.com/tea/arbor-teas/greenfield-ceylon-black-tea/4363/) |
| 09:49 |
mmorgan |
kmlussier: Happy Friday!! |
| 09:50 |
jeff |
happy friday! |
| 10:00 |
csharp |
hmm - my custom reporter sources are not showing up in the web client's reporter UI |
| 10:00 |
csharp |
they're in the fieldmapper and show in the XUL client fine |
| 10:03 |
JBoyer |
Bmagic, we used permissions, though only for the initial (full db) update. Since then we just send whatever, whenever. |
| 10:04 |
|
jvwoolf joined #evergreen |
| 10:05 |
csharp |
berick: following up on yesterday's issue, here's an activity log entry for entering the Surveys UI within a patron record: |
| 10:05 |
csharp |
2017-10-27 06:32:26 my-head osrf_websocket_translator: [ACT:10355:./osrf_websocket_translator.c:769:15091002841035520] [<REDACTED IP>] [] open-ils.pcrud open-ils.pcrud.search.asvr "<REDACTED AUTHTOKEN>", {"usr":"1175852"}, {"flesh":4,"flesh_fields":{"asvr":["question","survey","answer"],"asv":["responses","questions"],"asvq":["responses","question"]}} |
| 10:06 |
csharp |
and then, for at least 20+ hours, I can see perm checks in the logs for each action.survey_response row |
| 10:06 |
csharp |
(in the postgres logs) |
| 10:07 |
csharp |
exhausting pcrud drones everywhere and leading to jabber layer errors |
| 10:38 |
|
sandbergja joined #evergreen |
| 10:41 |
jeff |
hah! is it fetching the answers for the user, but then fleshing the question for those answers, and then the answers for those questions? |
| 10:42 |
csharp |
jeff: I don't know :-( - if there's a way to confirm that with logs, I can search |
| 10:43 |
csharp |
I just learned that the XUL client calls 'open-ils.circ.survey.response.retrieve' rather than using pcrud, which explains why this wasn't an issue there |
| 10:58 |
* csharp |
tries to learn what "flesh: 4" means in practice |
| 11:00 |
Dyrcona |
csharp: It means you're fleshing up to 4 levels deep. |
| 11:01 |
Dyrcona |
I can't think of anything that would go that deep off the top of my head, but it is OK to set that value higher than you actually use. |
| 11:01 |
Dyrcona |
If you get it too low, I think it stops looking and you don't get all the data you wanted. |
| 11:01 |
Dyrcona |
Say, you're going from acp -> acn -> bre, that's a flesh depth of 2. |
| 11:03 |
Dyrcona |
I don't think the 1st one counts, but it has been a while since I've written code to do a flesh, so I might be off by 1. :) |
| 11:04 |
csharp |
ah - makes sense - thank you |
| 11:06 |
Dyrcona |
Some of that fleshing in the log you pasted earlier looks redundant to me, but I don't know if the fields with the same names all point to the same things or not. |
| 11:07 |
Dyrcona |
No, it's not redundant. You'd need to specify everything you want fleshed in the object. |
| 11:08 |
Dyrcona |
There might be a better way to get all of that data together, though. |
| 11:08 |
csharp |
I'm going to dig a little deeper into which actual asvr rows are being checked - if jeff is right, it's probably the voter registration question, which should have at least one response from every user ever |
| 11:09 |
Dyrcona |
Also, I think pcrud is going to check permissions on every call. I'm not sure what it does with fleshing. |
| 11:10 |
Dyrcona |
From what you describe, it sounds like it is checking for every fleshed row, too. |
| 11:12 |
jeff |
asv = survey, asvq = survey questions, asvr = survey responses (answers). |
| 11:13 |
Dyrcona |
yes. |
| 11:13 |
Dyrcona |
:) |
| 11:13 |
jeff |
er, no. |
| 11:13 |
Dyrcona |
No? |
| 11:13 |
jeff |
asvr is response, not answer. there's answers also. |
| 11:13 |
Dyrcona |
Ah, details.... :) |
| 11:13 |
Dyrcona |
Always another layer of indirection. :) |
| 11:14 |
jeff |
i think the fleshing arguments are causing a problem with anything but a trivial/empty dataset. it looks like it's searching for all responses for a single user, and requesting that the question, survey, and answer be fleshed. |
| 11:14 |
Dyrcona |
Yes, that is what that is doing. |
| 11:15 |
jeff |
problem is that for every question (asvq) it's also asking that all responses be fleshed. |
| 11:15 |
jeff |
or am i misreading? |
| 11:15 |
Dyrcona |
And it's starting from responses, since that's the object method used. |
| 11:16 |
Dyrcona |
The "responses" in asvq could probably be dropped. In hindsight, I'm probably wrong about that not being redundant. |
| 11:16 |
csharp |
I was just thinking that |
| 11:17 |
Dyrcona |
And in asv for that matter, assuming they are the same as the asvr object retrieved in the first place. |
| 11:17 |
csharp |
(dropping 'responses' might fix it) |
| 11:17 |
jeff |
also "asvq":["responses","question"] looks wrong because action.survey_question.question is TEXT, not an id pointing to an object that can be fleshed. |
| 11:17 |
Dyrcona |
Right, nothing there to flesh, then. |
| 11:18 |
Dyrcona |
So drop asvq from flesh_fields entirely. |
| 11:18 |
csharp |
e2ee72f2 |
| 11:18 |
pinesol_green |
csharp: [evergreen|Kyle Huckins] LP#1511358 Patron Survey Interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2ee72f> |
| 11:18 |
csharp |
bug 1511358 |
| 11:18 |
pinesol_green |
Launchpad bug 1511358 in Evergreen "webclient: Surveys are not accessible from patron account" [Medium,Fix released] https://launchpad.net/bugs/1511358 |
| 11:20 |
Dyrcona |
csharp: You know how to write a small Perl program to make those calls? If so, that would be a good way to test changes to that code. |
| 11:21 |
csharp |
Dyrcona: I don't, unfortunately :-/ |
| 11:25 |
Dyrcona |
I can paste something for you in a bit. Got something else to do right now. |
| 11:25 |
csharp |
Dyrcona: that would be great! - thank you |
| 11:33 |
* JBoyer |
throws shade at pcrud when open-ils.circ.survey.response.retrieve exists. |
| 11:37 |
Dyrcona |
Nothing wrong with pcrud, though it might not be the optimal choice in this case. |
| 11:37 |
JBoyer |
Perhaps "pcrud use when..." would have been more accurate. |
| 11:38 |
Dyrcona |
JBoyer s'alright. Don't sweat it. :) |
| 11:40 |
jeff |
csharp: is there a followup feature where the ability to answer surveys is added, or is that just not a thing yet? |
| 11:40 |
* jeff |
looks |
| 11:43 |
csharp |
jeff: I think they're answered in the patron editor, but I'm not sure |
| 11:44 |
csharp |
yeah - at the bottom of the patron editor |
| 11:44 |
|
jvwoolf joined #evergreen |
| 11:44 |
jeff |
helps if i remember to start the survey. |
| 11:45 |
csharp |
jeff: and I think a quirk of surveys is that you have to start them the next day (i.e., not today) |
| 12:09 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "For csharp: pcrud script." (55 lines) at http://paste.evergreen-ils.org/908 |
| 12:12 |
Dyrcona |
And, that was an obvious edit of a script I wrote earlier this week to test something in open-ils.reporter. |
| 12:12 |
csharp |
Dyrcona++ # will test :-) |
| 12:13 |
Dyrcona |
I would have changed the $reporter variable to $request if I'd noticed. :) |
| 12:14 |
Dyrcona |
I haven't run that script, either, so beware typos. |
| 12:14 |
jeff |
confirmed in webby, it's fleshing far too much. |
| 12:15 |
Dyrcona |
Grr.... |
| 12:15 |
* Dyrcona |
let's it go. |
| 12:15 |
Dyrcona |
I mistyped in channel. What's new? :) |
| 12:15 |
csharp |
@praise Dyrcona |
| 12:15 |
* pinesol_green |
And Dyrcona raised the report up on high, saying O Lord, bless this thy circ report, that with it thou mayst blow thine enemies to tiny bits, in thy mercy. |
| 12:15 |
Dyrcona |
s/reporter/session/ in that script. |
| 12:16 |
Dyrcona |
If it bothers you... if not....who cares? :) |
| 12:17 |
csharp |
no prob ;-) |
| 12:20 |
Dyrcona |
I recommend running that on a utility server. |
| 12:21 |
|
khuckins joined #evergreen |
| 12:23 |
jeff |
i'm wondering how it went on for 20+ hours. |
| 12:23 |
* jeff |
muses and mutters a little more quietly |
| 12:29 |
Bmagic |
Anyone have troubles with libraries billing one another for lost items? There is a situation that I can't think of a solution for. Library A invoices B for X items. B pays A. Then, using the same report, A generates a report and bills B for some of the same items because the patrons haven't paid B yet |
| 12:30 |
jeff |
the flesh options on that call should be changed, and there may be some assumptions in the js and/or template for survey display that need adjusting. |
| 12:31 |
jeff |
csharp: when surveys are present in the user editor, should they always be empty response-wise, so that staff can ask the patron over and over each time they are in the editor? |
| 12:31 |
jeff |
csharp: or should the previous values show there in the editor? |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:48 |
pinesol_green |
[evergreen|Jeanette Lundgren] docs: LP1717583 add details about aged circulation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b5d42fe> |
| 12:53 |
Dyrcona |
Bmagic: Why are libraries billing libraries? Shouldn't that only involve patrons and the library that owned the item? |
| 12:53 |
|
khuckins_ joined #evergreen |
| 12:54 |
Bmagic |
its when Library A lends Library B the item, and Library B's patron loses it. Library B's patron is suppose to pay it but weather or not, Library B owes Library A |
| 12:55 |
Dyrcona |
Bmagic: No. Library B's patron owes for the lost item. Whom they owe is a question of policy and not a technical one. |
| 12:55 |
Bmagic |
Library B can't be expected to wait for the patron to pay, so Library B just invoices A at regular intervals, and there isn't a way to flag the bill as having been paid to the remote Library other than maybe Patron Alert |
| 12:56 |
Bmagic |
Dyrcona: the policy is that the patron owes the owning library, but they only inneract with their home library. |
| 12:57 |
Dyrcona |
That's a policy issue, and not a technical issue in Evergreen. If you you want to make changes to the code to help facilitate that policy, patches are welcome. :P |
| 12:57 |
Bmagic |
I'm not jumping to code at this stage, just trying to put some feelers out and see how others might handle it |
| 12:59 |
Dyrcona |
We don't. |
| 12:59 |
Dyrcona |
Our libraries don't bill each other for things that other libraries' patrons have lost, AFAIK. |
| 12:59 |
mmorgan |
In our consortium, the patron owes the owning library for the lost item, but the owning library doesn't get the money until the patron actually pays. |
| 13:00 |
Dyrcona |
My knee-jerk reaction is to tell them to stop doing that. |
| 13:00 |
Dyrcona |
Yeah, what mmorgan said. :) |
| 13:01 |
mmorgan |
If the patron never pays, the owning library has the right to expect payment from the lending library, though often they do not pursue it. |
| 13:01 |
mmorgan |
Generally, when the owning library receives payment, the transaction is closed, so it would no longer appear on any reports. |
| 13:05 |
mmorgan |
Bmagic: You could potentially do something on the patron record when Library A pays Library B. Library A could close the transaction and add their own billing to the patron record to recoup the $. Seems labor intensive, though. |
| 13:05 |
Bmagic |
that's a good idea |
| 13:06 |
Bmagic |
thanks! I will bring it up at the meeting |
| 13:06 |
Dyrcona |
I'd recommend asking them to find another way to resolve this. |
| 13:07 |
Bmagic |
I agree with you Dyrcona |
| 13:36 |
|
khuckins__ joined #evergreen |
| 13:59 |
jeff |
there are days when i think i'm getting better at using jq, and there are days when i just give in and supplement what i know with a blunt usage of grep. |
| 14:02 |
csharp |
jeff: empty in the user editor - unfortunately there's no "we've already answered this so don't ask again" feature |
| 14:19 |
csharp |
btw, the lack of such a feature means that required surveys require an answer every time you edit and save the record |
| 14:19 |
csharp |
but that's a bug report for another day |
| 15:02 |
csharp |
I was just thinking about the fact that concerto doesn't approximate "real" |
| 15:02 |
csharp |
or realistic data scale |
| 15:03 |
csharp |
I think it would be beneficial to host a more realistic dataset somewhere that people can download for testing larger things |
| 15:03 |
jeff |
*nod* |
| 15:04 |
* csharp |
isn't expressing himself well |
| 15:04 |
jeff |
and/or generators. |
| 15:04 |
csharp |
anyway - keep concerto around for basic proof of concept, but when doing testing for signoffs, require the larger dataset |
| 15:04 |
csharp |
just thinking out loud |
| 15:05 |
* mmorgan |
agrees. Many times production level data makes all the difference. |
| 15:06 |
Dyrcona |
Yeah. It does. |
| 15:08 |
kmlussier |
csharp: There are several projects that I will only test using something closer to production data. For example, the recent 3.0 search work was tested against a much larger dataset. |
| 15:08 |
kmlussier |
Testing search against Concerto is never a good idea. |
| 15:08 |
csharp |
kmlussier: that's good to hear |
| 15:09 |
csharp |
well, I'm very happy we test extensively before go-live |
| 15:09 |
csharp |
this probably would have brought us to our knees on day one |
| 15:10 |
csharp |
fwiw, the offending code is also in 2.12 - which tells me that not many are using the web client in production yet |
| 15:10 |
kmlussier |
csharp: Maybe, but do you have a good sense of how many people are using surveys? |
| 15:11 |
csharp |
kmlussier: everyone in PINES uses surveys - we require it to record voter registration |
| 15:12 |
Dyrcona |
You can register to vote at the library? |
| 15:12 |
csharp |
and it's a legal requirement, so every patron since 2006 should have an entry |
| 15:12 |
Dyrcona |
I'm not surprised... OK. I am surprised that you have to record if someone is registered to vote or not. |
| 15:12 |
csharp |
Dyrcona: yeah - it's legally required for Georgia libraries to offer voter registration when registering for a card/address update/etc. |
| 15:13 |
Dyrcona |
Oh, that isn't so surprising, in that case. I was imagining something else. |
| 15:13 |
csharp |
it's an agreement with the Georgia Secretary of State's office that we record it in Evergreen rather than requiring paper copies |
| 15:13 |
* Dyrcona |
needs a break. |
| 15:14 |
* Dyrcona |
takes that break. |
| 15:14 |
kmlussier |
csharp: Yeah, I remember hearing that about using surveys for voter registration. |
| 15:20 |
|
Jillianne joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:45 |
|
jvwoolf left #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:32 |
|
finnx1 joined #evergreen |
| 21:36 |
|
finnx1 left #evergreen |
