| Time |
Nick |
Message |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
agoben joined #evergreen |
| 07:41 |
|
JBoyer joined #evergreen |
| 07:52 |
|
ericar joined #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
sam_l joined #evergreen |
| 08:58 |
|
maryj joined #evergreen |
| 09:12 |
|
bos20k joined #evergreen |
| 09:13 |
|
mrpeters joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:31 |
jeff |
@later tell jeffdavis can you share the queries you were using to identify missing circs that should have been migrated to action.usr_circ_history? at the very least, I can see if we see similar here. |
| 09:31 |
pinesol_green |
jeff: The operation succeeded. |
| 09:32 |
Dyrcona |
This morning has been full of unexpected email questions. |
| 09:50 |
Bmagic |
kmlussier: I did not address holds, I thought about it, but I decided that just because you move an item, doesnt mean there are no more items with that part attached, therefore, the hold could still be valid |
| 09:54 |
* Dyrcona |
waits on an multi-million line insert to blow up. |
| 10:05 |
Bmagic |
@later tell kmlussier I did not address holds, I thought about it, but I decided that just because you move an item, doesnt mean there are no more items with that part attached, therefore, the hold could still be valid |
| 10:05 |
pinesol_green |
Bmagic: The operation succeeded. |
| 10:10 |
Dyrcona |
Bmagic: Maybe it should if there are no items on the previous part that could fill the hold? |
| 10:11 |
Bmagic |
Dyrcona: yes, I agree, the code could be expanded to check all of that out. However, I believe it's outside of the scope of the bug that I was solving. If everyone agrees, then I can go back and work that into the commit |
| 10:13 |
Dyrcona |
OK. Your choice sounds reasonable to me. |
| 10:16 |
|
mmorgan joined #evergreen |
| 10:17 |
Bmagic |
Evergreen lacks the ability to view non title level holds in my opinion. At least, it's hard for staff to know sometimes. Perhaps an alert message when moving an item with parts that has holds? Or even better, block the action with a report |
| 10:26 |
|
Christineb joined #evergreen |
| 10:31 |
* csharp |
returns from several days off |
| 10:31 |
csharp |
no @laters, I see :-) |
| 10:31 |
berick |
@later tell csharp we're using mysql now |
| 10:31 |
pinesol_green |
berick: The operation succeeded. |
| 10:33 |
dbs |
gmcharlt: hmm, so how much non-escaping is going on in that authority browse? Enough that 400 $a <script>alert('Bonjour!')</script> would be a problem? |
| 10:33 |
gmcharlt |
hmm, I think I'm about to find out! |
| 10:33 |
dbs |
:) |
| 10:35 |
gmcharlt |
dbs: so, initial results - pwning the staff client that way doesn't look like an immediate concern; the search string isn't emitted back to the client |
| 10:36 |
gmcharlt |
but this is the result of only a very quick and superficial check |
| 10:46 |
pinesol_green |
[evergreen|Ben Shum] LP#1554714: Set angular 1.5.5 as minimum, not exact version - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1463f35> |
| 10:47 |
|
kmlussier joined #evergreen |
| 10:49 |
kmlussier |
Bmagic: Thanks for the clarification. I won't worry about setting duplicates then. |
| 10:53 |
kmlussier |
But, now that I look at it, I don't think bug 904472 addresses moving holds. It only referred to holds because that was a symptom seen as a result of the parts problem. I'm still inclined to believe it may be addressing the same bug. |
| 10:53 |
pinesol_green |
Launchpad bug 904472 in Evergreen "Transferring items with monographic parts to a new bib record causes problems with holds placement" [Undecided,Confirmed] https://launchpad.net/bugs/904472 |
| 10:55 |
* kmlussier |
will take a look at the patch when she has tuits to see if it addresses both problems. |
| 11:03 |
Bmagic |
kmlussier: I agree, my patch should address 904472 as well |
| 11:04 |
Bmagic |
basically, it will bring the part with the item(s) between bibs. I doesn't move* the original part, it creates a new one on the destination bib (if it doesn't have one with the same label) and attaches the copy to it |
| 11:04 |
kmlussier |
Bmagic: Ok, thanks! I'll take a look at it when I get a chance. I know this bug has been a thorn in our side for a long, long time. |
| 11:05 |
Bmagic |
kmlussier: us too! |
| 11:07 |
Bmagic |
kmlussier: You hadn't logged in yet, but Dyrcona and I were talking about the holds issue. I offered an option maybe, to alert the staff when moving items with parts that have holds, and perhaps stop the operation and make the staff address the holds somehow |
| 11:08 |
Dyrcona |
My suggestion was to find holds that would be orphaned and move them with the parts, but I'm not sure how the parts are being "moved." |
| 11:08 |
* Dyrcona |
may also misunderstand the original issue. |
| 11:09 |
csharp |
berick: ha! |
| 11:09 |
kmlussier |
Well, it would be nice if we did that when moving/deleting any copy or part on a record. But that might be a separate issue. |
| 11:09 |
Bmagic |
It does seem reasonable that if you are moving the last copy that could fill that part hold, then move the hold, but it's not really in the scope of the original bug. And I believe it will explode the code a bit |
| 11:11 |
|
jwoodard joined #evergreen |
| 11:11 |
jeff |
@ana explode the code |
| 11:11 |
pinesol_green |
jeff: connect to host dev port 22: Connection refused |
| 11:11 |
jeff |
alas. |
| 11:13 |
* Dyrcona |
spent part of this morning in a mysql database used for email accounts. |
| 11:13 |
Bmagic |
mysql++ #sometimes |
| 11:14 |
dbs |
gmcharlt++ |
| 12:07 |
|
brahmina joined #evergreen |
| 12:11 |
jeffdavis |
jeff: I grabbed a list of all users who have a value for the history.circ.retention_start user setting and no entries in action.usr_circ_history, and then did a count of all circs by those users that fall within their retention period |
| 12:11 |
jeffdavis |
select count(*) from action.circulation circs join ( select a.usr, a.value, b.* from actor.usr_setting a join actor.usr b on a.usr = b.id where a.name = 'history.circ.retention_start' and a.usr not in (select distinct usr from action.usr_circ_history) ) as usrs on circs.usr = usrs.usr where circs.xact_start >= usrs.value::date; |
| 12:12 |
jeffdavis |
excluding deleted users (as I see the circ migration query does, now that I've had a closer look) drops the numbers to 1522 non-migrated circs by 354 users |
| 12:15 |
jeffdavis |
this doesn't account for any missing circ history for users who *do* have some entries in action.usr_circ_history, but to figure that out I'd need to mess with the circ chain |
| 12:16 |
jeffdavis |
and at this point it seems most likely that I'm just failing to account for something in my queries |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:45 |
Dyrcona |
jeffdavis: The date that the circ.retention started? |
| 12:46 |
Dyrcona |
Fun stuff: DBD::Pg::st execute failed: ERROR: index row size 3608 exceeds maximum 2712 for index "vhost_request_idx" |
| 12:47 |
Dyrcona |
Gonna ask about it in #postgresql, but that's what I was talking about yesterday. |
| 12:47 |
Dyrcona |
Looks like someone pasted from a review site into the search box in Evergreen. |
| 12:51 |
|
bmills joined #evergreen |
| 13:10 |
Bmagic |
Maybe I missed it but I cannot find a discussion about preventing a print dialog box during checkin. "Printer prompt" disables the Evergreen prompt, but the OS prompt is still there. Can we get Evergreen to just print without a prompt during checkin? |
| 13:12 |
jeff |
printing hold and transit slips? |
| 13:12 |
Bmagic |
yes |
| 13:13 |
jeff |
uncheck "Printer Prompt" and set the Checkin Modifier "Auto-Print Hold and Transit Slips"? |
| 13:13 |
sam_l |
You can - Checkin Modifier "Auto-Print..." yeah what Jeff said. :) |
| 13:13 |
jeff |
it can depend on your print strategy / printer settings, but that's usually sufficient when using windows print strategy. |
| 13:14 |
Bmagic |
gotcha |
| 13:14 |
jeff |
er, "mozilla print" (the default in the xul client) |
| 13:16 |
Bmagic |
there we go, thanks yall! |
| 13:44 |
|
gsams joined #evergreen |
| 14:21 |
|
rjackson_isl joined #evergreen |
| 14:59 |
Dyrcona |
email-- |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:35 |
Dyrcona |
Does changing hours of operation require an autogen.sh run? I can't remember. |
| 15:41 |
dbs |
Dyrcona: I don't think so. We change our hoo all the time programmatically and never run autogen.sh |
| 15:41 |
Dyrcona |
dbs: Thanks! |
| 15:41 |
jeff |
Hrm. |
| 15:41 |
jeff |
It might be that there is no longer a path in logs from auth token to username + workstation. |
| 15:41 |
Dyrcona |
We have libraries that close on Sundays in the summer and I'm trying to decide if adding closed dates or changing hours is the better choice. |
| 15:41 |
* jeff |
looks closer |
| 15:42 |
jeff |
I might be wrong, or looking in the wrong logs. |
| 15:42 |
JBoyer |
jeff, as of what version? |
| 15:42 |
JBoyer |
We don't use that a lot, but it has been handy before. |
| 15:43 |
jeff |
I'm noticing the change in 2.10, which (if I'm right) wouldn't be too surprising -- major auth changes. |
| 15:43 |
jeff |
But yeah, we're going to want that back. |
| 15:52 |
berick |
jeff: ugh. looks like the 'successfull login..' message was lost in 2.10 auth changes. that was certainly no intentional |
| 15:52 |
jeff |
commit 7223386 introduced the removal |
| 15:52 |
pinesol_green |
jeff: [evergreen|Bill Erickson] LP#1468422 New open-ils.auth_internal service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7223386> |
| 15:52 |
berick |
heh |
| 15:53 |
berick |
jeff: i'll push a patch to recover it. |
| 15:53 |
jeff |
berick++ |
| 15:57 |
jeff |
now to see why i have a webstaff client making so many requests to open-ils.auth.session.retrieve |
| 15:57 |
jeff |
(177746 requests and counting) |
| 15:57 |
jeff |
179077 |
| 15:58 |
jeff |
180119... :-) |
| 15:58 |
jeff |
(possibly something fixed already) |
| 16:18 |
|
jlitrell joined #evergreen |
| 16:19 |
berick |
jeff: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/login-successs-msg -- I can push a LP too if needed, but not for another hour or so. |
| 16:19 |
berick |
jeff++ # glad you found that one |
| 16:21 |
|
rlefaive joined #evergreen |
| 16:25 |
jeff |
bwahahaha.... |
| 16:30 |
jeff |
$timeout( function() { ... }, service.authtime() * 1000 + 5000 ); |
| 16:32 |
jeff |
that was half of why my clients are requesting open-ils.auth.session.retrieve over and over. |
| 16:32 |
jeff |
the other can be seen with a call to window.localStorage.getItem('eg.auth.time') |
| 16:32 |
jeff |
which returns "999999999" |
| 16:44 |
jeff |
and since $timeout wraps window.setTimeout, whose delay is stored as a 32-bit signed int by browsers "including Internet Explorer, Chrome, Safari, and Firefox", we get a whole bunch of calls to open-ils.auth.session.retrieve |
| 16:53 |
* jeff |
changes 999999999 to 57600 and tests |
| 17:09 |
|
jeffdavis joined #evergreen |
| 17:09 |
|
mmorgan1 left #evergreen |
| 17:09 |
|
jeffdavis joined #evergreen |
| 17:09 |
berick |
jeff: FYI bug 1592565 |
| 17:09 |
pinesol_green |
Launchpad bug 1592565 in Evergreen 2.10 "2.10 Login code lost key activity log message" [Undecided,New] https://launchpad.net/bugs/1592565 |
| 17:11 |
jeff |
thanks. i'll probably look-test-signoff-merge later tonight if someone doesn't beat me to it. |
| 17:11 |
jeff |
berick++ |
| 17:16 |
|
jihpringle joined #evergreen |
| 18:26 |
|
sandbergja joined #evergreen |
| 18:55 |
|
jihpringle_ joined #evergreen |
| 23:14 |
|
dcook joined #evergreen |
| 23:32 |
|
jihpringle joined #evergreen |
