| Time |
Nick |
Message |
| 02:22 |
pinesol_green |
[evergreen|Jeff Davis] LP#1314827: On login, don't allow referer-based redirect to external site - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fcf4628> |
| 04:28 |
|
vanya joined #evergreen |
| 04:33 |
vanya |
gmcharlt : Hi! I was trying to work on Bug #978040, and I was wondering if you could tell me what files in the code to look up regarding that. I was a little lost. |
| 04:33 |
pinesol_green |
Launchpad bug 978040 in Evergreen "No result found search for patron by database id results in return to wrong interface" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/978040 |
| 04:40 |
vanya |
I have been trying to run the evergreen client, but when I enter hostname as "localhost", it gives me the status "500: Internal server error", and there is a warning that says "Workstation not yet configured for the specified server" |
| 04:40 |
vanya |
Can someone tell me what I'm doing wrong? |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:49 |
csharp |
vanya: you should be able to see more details about the error in /openils/var/log/osrfsys.log (assuming you haven't changed anything about OpenSRF logging) |
| 07:58 |
|
eeevil joined #evergreen |
| 07:58 |
|
mtate joined #evergreen |
| 07:58 |
vanya |
csharp : Hello! Thank you! I will do it right away. |
| 08:00 |
vanya |
Also, do you have any idea which files in the code I should check, if I'm working on bug #978040 ? |
| 08:00 |
pinesol_green |
Launchpad bug 978040 in Evergreen "No result found search for patron by database id results in return to wrong interface" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/978040 |
| 08:00 |
vanya |
The description of the bug doesn't tell much |
| 08:01 |
|
akilsdonk joined #evergreen |
| 08:02 |
|
Callender joined #evergreen |
| 08:03 |
|
graced joined #evergreen |
| 08:04 |
|
phasefx joined #evergreen |
| 08:27 |
|
mdriscoll1 joined #evergreen |
| 08:28 |
|
tspindler1 joined #evergreen |
| 08:28 |
|
StephenGWills joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
kmlussier joined #evergreen |
| 09:08 |
|
ericar joined #evergreen |
| 09:20 |
|
kmlussier left #evergreen |
| 09:20 |
|
kmlussier joined #evergreen |
| 09:39 |
jeff |
neat. haven't seen that before, or at least not in a while. select Patrons in the Permission Groups admin interface, select "New Child", background flashes red, no new group created. |
| 09:44 |
mmorgan |
Hmm. Already have one called "New Group"? |
| 09:45 |
|
vrani_ joined #evergreen |
| 09:46 |
jeff |
mmorgan: oh hey, look at that! |
| 09:48 |
mmorgan |
funny what can grow on one's permission group tree :) |
| 09:51 |
|
yboston joined #evergreen |
| 09:53 |
|
mllewellyn joined #evergreen |
| 10:23 |
dbs |
mmorgan++ |
| 10:36 |
jeff |
yup, and based on the id of the New Group, it's been hanging out for a while. |
| 10:37 |
berick |
let the dev meeting attendance cage match between eeevil and ldw begin. mon at 3pm or tues at 2pm. |
| 10:38 |
berick |
anyone who has not responded (that might break the tie), please go forth.. http://doodle.com/5zautb9brzfknsxx |
| 10:39 |
kmlussier |
FWIW, when there was a toss-up, I used to try picking the date when the most core committers could attend. Not sure it was the right thing to do, but it helped me make decisions. :) |
| 10:39 |
berick |
kmlussier: sounds perfectly logical |
| 10:39 |
kmlussier |
Trying to get people to break the tie works too. Or sometimes it makes the problem worse. :) |
| 10:39 |
berick |
heh |
| 10:40 |
berick |
by that metric, we're looking at tues at 2pm.. going once |
| 10:43 |
dbwells |
I responded, but it didn't change the situation, sorry. Or, you're welcome ;) |
| 10:43 |
berick |
heh |
| 10:49 |
|
krvmga joined #evergreen |
| 10:55 |
jeff |
hrm. i think i can break that tie. |
| 11:08 |
yboston |
eeevil: are you available to talk about Sequoia for a moment? |
| 11:16 |
|
sandbergja joined #evergreen |
| 11:31 |
|
siddhism joined #evergreen |
| 11:37 |
siddhism |
#evince |
| 11:39 |
|
siddhism left #evergreen |
| 11:55 |
kmlussier |
ldw: I noticed you assigned yourself to bug 996029 several months ago. Is it something you're still working on or should I set it back to unassigned? |
| 11:55 |
pinesol_green |
Launchpad bug 996029 in Evergreen "Totals in funds do not round to two decimal places when prorating is used" (affected: 4, heat: 20) [Medium,Confirmed] https://launchpad.net/bugs/996029 - Assigned to Liam Whalen (whalen-ld) |
| 11:55 |
kmlussier |
Of course, there will be much rejoicing in the land if you are indeed working on it. :) |
| 12:10 |
|
nhilton joined #evergreen |
| 12:30 |
|
jihpringle joined #evergreen |
| 12:34 |
|
tspindler1 left #evergreen |
| 12:40 |
|
tspindler joined #evergreen |
| 12:54 |
dbs |
jeff: So it was a New Child on the New Group's block? |
| 12:55 |
|
tspindler left #evergreen |
| 13:06 |
jeff |
*cringe* |
| 13:06 |
jeff |
dbs++ |
| 13:23 |
|
Canepa joined #evergreen |
| 13:25 |
dbs |
I really should have gone with something like, "Check the CSS: you might find that there's a New Group called "New Child" on the display:block" |
| 14:38 |
|
vanya joined #evergreen |
| 14:38 |
berick |
kmlussier: gracias |
| 14:38 |
kmlussier |
eeevil: Did you all kick webby? I appear to be getting search results. :) |
| 14:39 |
* kmlussier |
is keeping her fingers crossed. |
| 14:43 |
phasefx |
kmlussier: yes, I believe it was kicked |
| 14:43 |
kmlussier |
phasefx: Thanks! |
| 14:44 |
phasefx |
you're welcome :) |
| 14:46 |
|
vlewis joined #evergreen |
| 14:55 |
kmlussier |
Something to ponder before I go back to web client testing. This record - https://bark.cwmars.org/eg/opac/record/948727 - is not retrieved in any keyword searches, either in the public catalog or staff client. |
| 14:56 |
kmlussier |
If it were just the public catalog, I would think it was a problem with subfield 9 or OPAC visibility. |
| 14:56 |
kmlussier |
We forced a reingest on the record, and it does have an entry in the metabib keyword table. |
| 14:56 |
kmlussier |
Is there anything else we should be looking at? |
| 14:57 |
|
jboyer-laptaupe joined #evergreen |
| 15:03 |
ldw |
kmlussier: It is not something I am working on currently. Please set it back to unassigned. It is still in my mind though, so I will get back to it. I will reassign myself when I am back on that job. |
| 15:03 |
kmlussier |
ldw: Thanks! |
| 15:06 |
mmorgan |
kmlussier: maybe check if there is an entry for that record in metabib.record_attr? lp 1091885 might be relevant. |
| 15:06 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1091885 |
| 15:07 |
mmorgan |
we had some records not represented in that table and they were not searchable. |
| 15:07 |
kmlussier |
mmorgan: Ah, thanks! I knew this problem sounded familiar. |
| 15:08 |
mmorgan |
That table's purpose is still a mysery to me, though :-( |
| 15:10 |
tsbere |
mmorgan: record_attr stores a lot of things used for search and icon type stuff so that the MARC doesn't have to be parsed all the time. |
| 15:12 |
mmorgan |
ah, ok. So what populates that table and what causes things to go missing from it? |
| 15:20 |
|
vrani_ joined #evergreen |
| 15:24 |
jeff |
ingest populates it. manual deletion from the table can remove from it. there was at one time a problem where reingest (of a non-new record) would not re-populate if there were zero rows (due to manual deletion from the table, or possibly due to some other not-at-that-time identified reason) |
| 15:26 |
csharp |
kmlussier: your "non-retrieval by keyword" issue rings a bell - if you remind me, I can ask Elaine about it next week |
| 15:27 |
kmlussier |
csharp: OK, thanks! |
| 15:30 |
tsbere |
jeff/mmorgan: Deleting a bib record, when you don't have the flag to keep deleted bibs searchable set (or available), will remove from the record_attr table as well. |
| 15:30 |
jeff |
the irc log linked from bug 1091885 is not formatted as nicely as some of our newer logs, but it does have a number of additional comments/details, as well as sql to identify affected bibs. some guy named "jeff" said a bunch of things. |
| 15:30 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1091885 |
| 15:30 |
mmorgan |
jeff++ |
| 15:31 |
jeff |
tsbere: right! under normal circumstances the rows are created on bib undeletion, too. |
| 15:32 |
tsbere |
jeff: Actually, I think there was (is?) a bug in that department. We had to clean up undeleted records for that issue every so often... |
| 15:41 |
kmlussier |
Thanks all! C/W MARS just reported back that it does indeed appear to be the issue identified in bug 1091885 |
| 15:41 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1091885 |
| 15:41 |
kmlussier |
mmorgan++ |
| 15:42 |
csharp |
yeah - that sounds like what we hit |
| 15:43 |
csharp |
mmorgan++ |
| 15:43 |
mmorgan |
jeff++ #lots of good info in that irc log |
| 15:51 |
kmlussier |
hmmmm |
| 15:51 |
jeff |
hrm. ever have those times when you wonder if you're over-using recursive CTEs? :P |
| 15:51 |
kmlussier |
I followed up on the discussion we had here a few months back on loading times for the patron registration screen. http://irc.evergreen-ils.org/evergreen/2014-07-30#i_114377 |
| 15:52 |
jeff |
hey, that came up in private conversation the other day. |
| 15:52 |
* kmlussier |
googles recursive cte. :) |
| 15:52 |
jeff |
kmlussier++ for saving me from digging up the irc log for that time |
| 15:52 |
kmlussier |
Well, I just did some timed tests. |
| 15:53 |
kmlussier |
I used a 2.7 client on webby and then tried it in a browser. |
| 15:53 |
kmlussier |
The first load is very slow, in both, but it's a bit better in a web browser. |
| 15:53 |
kmlussier |
Then, in both environments, the load time improves. But I consistently found it took 4 seconds to load a patron in the editor in the xul client. It took 6 seconds in the browser. |
| 15:54 |
* kmlussier |
used an actual timer this time, not counting on her fingers. :) |
| 16:03 |
|
Canepa joined #evergreen |
| 16:04 |
kmlussier |
Anywho, I'll just re-state the concern I has back then about moving our libraries to something that is still loading slowly or, in this case, is loading a little more slowly. |
| 16:09 |
|
artunit joined #evergreen |
| 16:10 |
kmlussier |
Since it's Friday, I'll move on to happier performance-related topics. I'm guessing we no longer need the cap for patron search results because a) the user has the ability to select the option of up to 100 results b) we have paging and c) we won't kill the server by retrieving the 100 results that can be displayed on one screen? |
| 16:15 |
|
Canepa joined #evergreen |
| 16:15 |
dbs |
6 seconds? Good lord. |
| 16:16 |
* dbs |
doesn't have much more to contribute right now :( |
| 16:16 |
kmlussier |
dbs: That's okay. I'll take a 'good lord.' |
| 16:17 |
gmcharlt |
kmlussier++ # data |
| 16:23 |
|
Sally joined #evergreen |
| 16:27 |
|
Canepa_ joined #evergreen |
| 16:42 |
jeff |
action.circulation and actor.usr_activity have plenty of "last time this patron interacted with us" data. there's also actor.usr.last_update_time and actor.usr.create_date (if they've no other activity, that may be the only date you get). i suppose action.hold_request is another source of dates/data... anyone have other ideas offhand? |
| 16:42 |
jeff |
context being not for any kind of forensic trail, just a gathering of data to come up with a "most recent activity of almost any kind" date. |
| 16:43 |
jeff |
i covered the ones i care about for this specific task, but it got me wondering as more of a thought experiment. |
| 16:43 |
jeff |
adding an item to a list is usually going to involve an opac login first, but of course with long-lasting tokens that could be days apart. |
| 16:46 |
|
StephenGWills left #evergreen |
| 17:02 |
|
mdriscoll1 left #evergreen |
| 17:02 |
kmlussier |
jeff: I can't think of much else. Maybe paying a bill in the OPAC if they are using a long-lasting auth token? |
| 17:15 |
jeff |
sure, or paying a bill in person. |
| 17:16 |
jeff |
if they came in and only paid the bill, or paid over the phone, if there was no other activity or no account changes... i don't know if last_xact updated via that method will result in last_update_time being bumped also. worth checking. |
| 17:18 |
kmlussier |
Webby must have been updated while it was kicked. Awesome! I'm seeing a lot of fixes. :) |
| 17:20 |
jeff |
heh |
| 17:25 |
|
mmorgan left #evergreen |
| 17:42 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
tsbere |
jeff: On action.circulation, that can be much *less* useful when you are aging circs.....and as far as I know, "circulated an item" doesn't really show up anywhere else. For good reasons. |
| 18:09 |
|
Canepa joined #evergreen |
| 18:15 |
|
Canepa_ joined #evergreen |
| 18:20 |
|
Canepa joined #evergreen |
| 18:53 |
|
vanya joined #evergreen |
| 19:15 |
|
kmlussier joined #evergreen |
| 19:34 |
|
sbrylander joined #evergreen |
| 19:38 |
|
Canepa_ joined #evergreen |
| 19:51 |
|
sarabee joined #evergreen |
| 20:23 |
|
sbrylander joined #evergreen |
| 21:04 |
|
nhilton joined #evergreen |
| 22:40 |
|
dbwells_ joined #evergreen |
| 22:45 |
|
jventuro_ joined #evergreen |
| 22:46 |
|
phasefx_ joined #evergreen |
