| Time |
Nick |
Message |
| 00:08 |
|
jeff__ joined #evergreen |
| 00:25 |
|
jeff_ joined #evergreen |
| 00:32 |
|
a1 joined #evergreen |
| 00:36 |
|
jeff__ joined #evergreen |
| 01:01 |
|
jeff__ joined #evergreen |
| 01:12 |
|
jeff__ joined #evergreen |
| 01:17 |
|
fparks joined #evergreen |
| 01:24 |
|
jeff__ joined #evergreen |
| 01:40 |
|
jeff_ joined #evergreen |
| 02:04 |
|
jeff__ joined #evergreen |
| 02:12 |
|
jeff__ joined #evergreen |
| 02:18 |
|
jeff___ joined #evergreen |
| 02:40 |
|
jeff_ joined #evergreen |
| 03:19 |
|
jeff__ joined #evergreen |
| 03:29 |
|
jeff__ joined #evergreen |
| 03:51 |
|
jeff_ joined #evergreen |
| 04:20 |
|
jeff__ joined #evergreen |
| 04:24 |
|
jeff___ joined #evergreen |
| 04:41 |
|
jeff__ joined #evergreen |
| 05:02 |
|
jeff__ joined #evergreen |
| 05:14 |
|
jeff__ joined #evergreen |
| 05:22 |
|
jeff___ joined #evergreen |
| 05:32 |
|
jeff__ joined #evergreen |
| 05:45 |
|
jeff_ joined #evergreen |
| 05:55 |
|
jeff__ joined #evergreen |
| 06:08 |
|
jeff__ joined #evergreen |
| 06:22 |
|
jeff__ joined #evergreen |
| 06:23 |
|
smyers_ joined #evergreen |
| 06:45 |
|
jeff_ joined #evergreen |
| 06:55 |
|
jeff__ joined #evergreen |
| 07:20 |
|
jeff__ joined #evergreen |
| 07:31 |
|
kmlussier joined #evergreen |
| 08:09 |
|
jeff_ joined #evergreen |
| 08:16 |
|
rjackson-isl joined #evergreen |
| 08:34 |
|
akilsdonk joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
timlaptop joined #evergreen |
| 08:59 |
|
mmorgan joined #evergreen |
| 09:03 |
|
kbeswick joined #evergreen |
| 09:08 |
|
rangi` joined #evergreen |
| 09:10 |
|
collum joined #evergreen |
| 09:11 |
|
mrpeters joined #evergreen |
| 09:12 |
|
rjackson-isl joined #evergreen |
| 09:14 |
|
jcamins joined #evergreen |
| 09:14 |
|
ericar_ joined #evergreen |
| 09:25 |
Dyrcona |
Looks like bug 1243280 slipped through the cracks because it was not targeted at 2.5. |
| 09:25 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
| 09:26 |
bshum |
Oops. |
| 09:32 |
Dyrcona |
kmlussier: If you find my development server to be slow, that is because I am running the inter authority link script on it, in parallel. I wanted to test if it could be run in parallel. |
| 09:33 |
kmlussier |
Dyrcona: Ok, thanks! Do you have the two depesz branches on there now? |
| 09:33 |
Dyrcona |
kmlussier: And, it may have other issues at the moment. I'm not sure if it is because of load or for some other reason, but I get a 500 error when testing the hostname. |
| 09:33 |
eeevil |
Dyrcona: it can be. there's no particular interlocking danger |
| 09:34 |
Dyrcona |
kmlussier: I have loaded both of them, yes. |
| 09:34 |
kmlussier |
Dyrcona: Thanks again. |
| 09:36 |
Dyrcona |
Must be something else. top reports the load as 0.00, but I can see stuff is happening. |
| 09:36 |
Dyrcona |
All the drones are running. |
| 09:38 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "My Server Error" (1 line) at http://paste.evergreen-ils.org/41 |
| 09:38 |
Dyrcona |
For those following along at home. :) |
| 09:39 |
berick |
whoa. just did "cp A B; edit B; git rm A". git status now shows "renamed A -> B". thanks, git! |
| 09:41 |
Dyrcona |
git mv A B wasn't enough work for you? |
| 09:41 |
berick |
i was just poking at something, didn't actually plan on removing the original file |
| 09:41 |
berick |
until I did, of course |
| 09:41 |
Dyrcona |
:) |
| 09:41 |
Dyrcona |
ok. if the load is 0.05, why is my server so slow? |
| 09:42 |
Dyrcona |
Must be the database server.... |
| 09:42 |
Dyrcona |
Or the disk. |
| 09:42 |
* Dyrcona |
waits. |
| 09:47 |
Dyrcona |
And autogen.sh fails with a similar message on a different line in a different file. |
| 09:47 |
* Dyrcona |
suspects what he is trying to test. |
| 09:52 |
Dyrcona |
And, bingo! Delete the database entry I added and everything works again. |
| 09:52 |
* Dyrcona |
does more research. |
| 09:55 |
|
yboston joined #evergreen |
| 10:22 |
|
smyers__ joined #evergreen |
| 10:30 |
jeff |
outages-- |
| 10:40 |
|
ericar joined #evergreen |
| 11:32 |
|
Shae joined #evergreen |
| 11:38 |
mmorgan |
Fighting with invalid patron address penalties again... |
| 11:38 |
mmorgan |
Nothing's being inserted into actor.usr_standing_penalty when I invalidate an address. Any ideas? |
| 11:51 |
tsbere |
mmorgan: Where/how are you invalidating? |
| 11:53 |
mmorgan |
In patron edit, uncheck the Valid Address? box and save. |
| 11:54 |
bshum |
I don't think that's how it engages the penalty. |
| 11:54 |
tsbere |
I don't think that triggers any code anywhere |
| 11:54 |
bshum |
That'd just set the flag in the actor.usr_address field for "valid" to FALSE |
| 11:54 |
tsbere |
If there was a "invalidate" *button* maybe, but not just changing the checkbox |
| 11:56 |
mmorgan |
This was working before upgrade/ database refresh of the system. |
| 11:56 |
mmorgan |
After some tweaking: http://evergreen-ils.org/irc_logs/evergreen/2013-10/%23evergreen.25-Fri-2013.log |
| 11:58 |
|
afterl joined #evergreen |
| 11:58 |
mmorgan |
Just reread this myself. I think I may have found my oversight... |
| 12:03 |
|
remingtron joined #evergreen |
| 12:05 |
mmorgan |
working now. The ou setting definitely helps :-[ |
| 12:05 |
kmlussier |
heh |
| 12:07 |
|
ktomita_ joined #evergreen |
| 12:08 |
bshum |
Well I learned something new now |
| 12:08 |
bshum |
I didn't know that was even possible. |
| 12:08 |
bshum |
mmorgan++ jeff++ |
| 12:09 |
mmorgan |
jeff++ indeed! |
| 12:37 |
tsbere |
So, we have complaints that the item_type labels next to the icons in the catalog don't match our search box. So I wrote a fix. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/search_label_icons |
| 12:37 |
tsbere |
Does anyone think that is a horrible idea/implementation? |
| 12:38 |
kmlussier |
tsbere: I think bshum had mentioned something similar here the other day. |
| 12:39 |
bshum |
Yeah, tsbere's implementation is better than what I hacked together on the fly. |
| 12:39 |
* tsbere |
has already been talking to bshum about it |
| 12:39 |
kmlussier |
+1 to the idea. Can't comment on the implementation. |
| 12:39 |
bshum |
Our catalogers still aren't fully happy with the search_label, but I can see where keeping it consistent with what's in the search box makes sense. |
| 12:39 |
bshum |
Happy in the sense that our search_label for "Language material" is "Book" but it could actually be a newspaper, or magazine. |
| 12:40 |
bshum |
But that's a label problem |
| 12:40 |
bshum |
Though, for good measure.... MARC-- |
| 12:40 |
tsbere |
@karma Though, for good measure.... MARC |
| 12:40 |
pinesol_green |
tsbere: Though, for good measure.... MARC has neutral karma. |
| 12:40 |
kmlussier |
It still won't match what's in the search box for my other two consortia because they are using search filter groups. But it's still a big improvement since our default labels are just awful. |
| 12:41 |
* tsbere |
is happy that it isn't grabbing the entire "line" when doing karma like it used to |
| 12:41 |
bshum |
kmlussier: Well, that's customized |
| 12:41 |
bshum |
kmlussier: Out of the box Evergreen uses the search_label :) |
| 12:41 |
kmlussier |
bshum: Sure, I'm not complaining. |
| 12:41 |
bshum |
So for stock, I think tsbere's approach actually makes the most sense anyways |
| 12:42 |
bshum |
tsbere: Yeah I think it stopped doing that when we borrowed the karma module that someone else had updated with tweaks to prevent that. |
| 12:42 |
kmlussier |
Nor am I suggesting that it accommodate search filter groups since I don't think that would be possible until we get the MVF development done. |
| 12:42 |
kmlussier |
IF we get the MVF development done. |
| 12:43 |
bshum |
In the short term, I think I'm also +1 to tsbere's approach. |
| 12:44 |
csharp |
@praise tsbere |
| 12:44 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of tsbere |
| 12:44 |
eeevil |
+1, excepting that it makes i18n more difficult (coded-value is more stable, so can be translated at the TT level; search-value is more likely to be changed by configuration, and i18n isn't applied in the patch (and can't be, without a lot of extra work)) |
| 12:45 |
tsbere |
eeevil: Can I counter-argue that the existing usage doesn't appear to get translated anyway? |
| 12:45 |
dbs |
I was just looking at the i18n ramifications, yeah :/ |
| 12:46 |
dbs |
tsbere: you can |
| 12:46 |
bshum |
So this is where we need to bring up the stuff paxed was working on before we bashed all of it around |
| 12:46 |
eeevil |
tsbere: you can, sure |
| 12:46 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/491712 |
| 12:46 |
pinesol_green |
Launchpad bug 491712 in Evergreen "ALT text for format icons on search results page is always in English" (affected: 2, heat: 10) [Medium,Incomplete] |
| 12:46 |
bshum |
Which includes his work in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/paxed/lp491712 |
| 12:47 |
bshum |
But he did note that he wasn't really happy with it. |
| 12:48 |
eeevil |
the same could work fine for ccvm.label (or however it's spelled) |
| 12:48 |
paxed |
it was a quick hack to get it to translate |
| 12:49 |
eeevil |
but I was actually thinking of just: l(coded_value); |
| 12:49 |
paxed |
coded_value? |
| 12:50 |
paxed |
l() needs a static string, or it won't be picked up by the translation scripts |
| 12:50 |
eeevil |
and then translate the (stable-ish) value elsewhere... but, the combination of tsbere's and paxed's work (adjusted appropriately for field names, etc) would be the best of both |
| 12:50 |
eeevil |
paxed: doh, of course... nevermind me |
| 12:50 |
eeevil |
but the combination would still stand as a solution |
| 12:50 |
tsbere |
paxed: Does coded_value_selector get the translated values already (aka, does the search box get them)? |
| 12:52 |
paxed |
hm. i think so, but i'm not 100% sure |
| 12:53 |
* tsbere |
may have an idea for after lunch if the answer is "yes" |
| 13:02 |
|
brent_sage joined #evergreen |
| 13:24 |
|
DPearl1 joined #evergreen |
| 13:41 |
|
ktomita joined #evergreen |
| 13:42 |
Dyrcona |
I s'pose I have another blog topic. |
| 13:43 |
|
smyers__ joined #evergreen |
| 13:58 |
tsbere |
eeevil/paxed/dbs: How about http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/translated_icon_labels ? |
| 14:03 |
|
remingtron_ joined #evergreen |
| 14:03 |
|
stevenyvr2 joined #evergreen |
| 14:03 |
|
remingtron__ joined #evergreen |
| 14:17 |
|
RoganH joined #evergreen |
| 14:18 |
eeevil |
tsbere: eyeballing that, it looks pretty reasonable |
| 14:22 |
|
mrpeters left #evergreen |
| 14:29 |
|
remingtron_ joined #evergreen |
| 14:32 |
pinesol_green |
[evergreen|Angela Kilsdonk] New documentation for 2.5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5cdbb36> |
| 14:34 |
|
kbutler joined #evergreen |
| 14:55 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation for Sorting Billing Columns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46768f1> |
| 15:03 |
|
kbeswick joined #evergreen |
| 15:05 |
|
mllewellyn joined #evergreen |
| 15:17 |
csharp |
okay here's something to test... do a catalog search for something in the staff client and click "Place Hold". The Submit button is greyed out (since it now cares whether a barcode is entered). Click Place this hold for me and the button remains greyed out, but if you switch the radio button back to Place hold for patron by barcode, then back to Place this hold for me, the Submit button is activated |
| 15:17 |
csharp |
this is on 2.5-rc1 actually (need to upgrade to 2.5.1 when we get a chance) |
| 15:17 |
bshum |
csharp: Yeah that bug is fixed in 2.5.1 |
| 15:17 |
csharp |
oh? |
| 15:18 |
bshum |
Or at least I think it is |
| 15:18 |
bshum |
I think I merged something from Callender to fix that |
| 15:18 |
* csharp |
searches for a bug report |
| 15:18 |
dbwells |
https://bugs.launchpad.net/evergreen/+bug/1251424 |
| 15:18 |
pinesol_green |
Launchpad bug 1251424 in Evergreen 2.4 "In the staff client, the submit hold button is not activating when placing hold" (affected: 1, heat: 6) [Low,Fix released] |
| 15:19 |
bshum |
That's it |
| 15:19 |
csharp |
bshum++ dbwells++ |
| 15:19 |
bshum |
dbwells++ thanks |
| 15:19 |
dbwells |
np |
| 15:20 |
bshum |
csharp: Future 2.5.2 will have a fix for the email notification part of that GUI too |
| 15:20 |
csharp |
oh good |
| 15:20 |
bshum |
If the staff account didn't have an email account, it kind of sticks and doesn't update to show the patron's email |
| 15:20 |
csharp |
ah |
| 15:20 |
bshum |
The fix is in master |
| 15:20 |
bshum |
And rel_2_5 |
| 15:22 |
bshum |
csharp: https://bugs.launchpad.net/evergreen/+bug/1259231 for good measure |
| 15:22 |
pinesol_green |
Launchpad bug 1259231 in Evergreen "No email address message stuck in staff client" (affected: 1, heat: 6) [Medium,Fix committed] |
| 15:23 |
tsbere |
twas a simple fix |
| 15:23 |
bshum |
I think the only other issue at fault with the place hold GUI in the staff client is the unresolved problems with pickup library. |
| 15:23 |
bshum |
That's been something pondered since 2.4 or so |
| 15:23 |
tsbere |
bshum: Wait, what problem with pickup library? |
| 15:23 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1167541 |
| 15:23 |
pinesol_green |
Launchpad bug 1167541 in Evergreen 2.4 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" (affected: 6, heat: 34) [Medium,Confirmed] |
| 15:23 |
bshum |
It's if they haven't selected a specific pickup library via settings |
| 15:24 |
bshum |
Some folks have differing ideas about where the pickup defaults to |
| 15:24 |
tsbere |
I thought that was desired. After all, they are standing in front of you. :P |
| 15:24 |
tsbere |
(in theory) |
| 15:24 |
bshum |
Kind of what I think now too. But just noting the bug exists |
| 15:24 |
bshum |
*bug ticket |
| 15:25 |
|
yboston joined #evergreen |
| 15:27 |
csharp |
Callender's patch did the trick |
| 15:29 |
bshum |
Good to know 2.5.1 will be safe to use then ;) |
| 15:29 |
bshum |
Callender++ |
| 15:38 |
Dyrcona |
Confirmed, eh... Sounds more like Opinion to me. :) |
| 15:38 |
Dyrcona |
YAOUS! |
| 15:39 |
Dyrcona |
That fixes everything, well that and $1.2 million. ;) |
| 15:40 |
gmcharlt |
Dyrcona: and yet, nobody ever thinks to turn on the boolean YAOUS "Enable patron happiness" |
| 15:41 |
bshum |
I would have thought to look for that as a global flag. But you're right gmcharlt, should be per-library choice :) |
| 15:41 |
Dyrcona |
gmcharlt: It's a NO-OP anyway. |
| 15:42 |
Dyrcona |
Sometimes, I think the answer to bugs like that should be, "Too bad. That's how it works." |
| 15:42 |
tsbere |
wait, that isn't a user setting? After all, you can't make EVERYONE happy to begin with... |
| 15:46 |
|
kmlussier joined #evergreen |
| 15:50 |
bshum |
It's early, but has anyone considered post-conference hacking or other activities up in Boston next year? Or will folks be rushing off to Code4Lib? :P |
| 15:51 |
Dyrcona |
bshum++ # Reminding me that I need to reserve a room. |
| 15:51 |
bshum |
Yeah that's what I'm looking into now |
| 15:52 |
bshum |
Trying to decide if staying the extra Saturday night is valuable or not. Looks like we have to call it in if so. |
| 15:52 |
bshum |
Past conferences, I know we often have some tendency to lurk about |
| 15:53 |
Dyrcona |
I'd have to run it by my boss since we're so close, but I wouldn't mind staying over the Saturday night if there was something planned. |
| 15:54 |
|
smyers__ joined #evergreen |
| 16:00 |
|
artunit joined #evergreen |
| 16:01 |
bshum |
Something to think about I guess. |
| 16:17 |
jeff |
hooray for backup connectivity. |
| 16:19 |
* dbs |
has booked a hotel for Saturday night, fwiw |
| 16:21 |
|
kmlussier joined #evergreen |
| 16:22 |
bshum |
Cool, I just did too. |
| 16:22 |
bshum |
Though it took me like 3 tries by phone. The connection kind of sucked. |
| 16:23 |
* dbs |
still needs to phone to book at the conf hotel for the Saturday night though, right now he's a hop, skip and a jump away on Saturday night |
| 16:26 |
jeff |
primary internet connection showing only 55% packet loss now |
| 16:29 |
kmlussier |
dbs: I just got some numbers from the hotel yesteday and there are still rooms available Satuday. Which pleasantly surprised me because I didn't think we had reserved any room blocks for that day. |
| 16:32 |
dbs |
yay! |
| 16:36 |
eeevil |
jeff: the glass is cracked and the packets are dribbling all over the floor.... what a mess! |
| 16:38 |
|
DPearl joined #evergreen |
| 16:39 |
* Dyrcona |
is trying to decide if he'll take the train and whether or not he'll stay over Saturday night. |
| 16:50 |
jeff |
trains++ |
| 16:51 |
bshum |
"from now on, can't we just take the train?" |
| 16:52 |
|
ktomita_ joined #evergreen |
| 16:53 |
Dyrcona |
Well, "the train" for me would be about a half-hour ride into Boston and then 15 minutes to Kendall Square. |
| 16:55 |
Dyrcona |
Ok. It's more like a 50-minute ride on the train. |
| 16:56 |
* kmlussier |
is hoping to take the train. |
| 16:56 |
kmlussier |
If I don't have too much stuff to carry. |
| 16:59 |
berick |
hmm, 16hr train ride from raleigh. not bad, until you realize there is a 7-hour layover between rains. :( |
| 16:59 |
berick |
i.e. 23 hour train ride |
| 17:15 |
|
mmorgan left #evergreen |
| 17:26 |
|
dcook joined #evergreen |
| 18:12 |
|
ktomita joined #evergreen |
| 18:24 |
|
dcook joined #evergreen |
| 19:18 |
|
Dyrcona joined #evergreen |
| 19:27 |
|
afterl left #evergreen |
| 19:45 |
|
stevenyvr2 left #evergreen |
| 21:22 |
|
kmlussier joined #evergreen |
| 21:33 |
|
Dyrcona joined #evergreen |
| 23:07 |
|
jboyer_isl joined #evergreen |
| 23:23 |
|
mtate joined #evergreen |
| 23:25 |
|
ningalls joined #evergreen |
