| Time |
Nick |
Message |
| 04:22 |
|
Stompro joined #evergreen |
| 04:43 |
|
StomproJ joined #evergreen |
| 04:55 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:00 |
|
StomproJosh joined #evergreen |
| 07:21 |
|
graced joined #evergreen |
| 07:40 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
jboyer-isl joined #evergreen |
| 08:05 |
|
julialima_ joined #evergreen |
| 08:05 |
kmlussier |
Good morning #evergreen! |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:25 |
|
mrpeters joined #evergreen |
| 08:34 |
|
mtate joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:36 |
|
ericar joined #evergreen |
| 08:39 |
|
Shae joined #evergreen |
| 08:44 |
|
maryj joined #evergreen |
| 08:44 |
* csharp |
thaws fingers enough to wish kmlussier a good morning in return |
| 08:45 |
csharp |
@weather 30033 |
| 08:45 |
pinesol_green |
csharp: The current temperature in Leafmore, Decatur, Georgia is 19.2°F (8:42 AM EST on February 20, 2015). Conditions: Overcast. Humidity: 47%. Dew Point: 3.2°F. Windchill: 19.4°F. Pressure: 30.47 in 1032 hPa (Rising). Winter Weather Advisory in effect from 8 PM this evening to 1 PM EST Saturday... |
| 08:46 |
tsbere |
@weather 01845 |
| 08:46 |
pinesol_green |
tsbere: The current temperature in WB1CHU, Lawrence, Massachusetts is 7.0°F (8:46 AM EST on February 20, 2015). Conditions: Clear. Humidity: 56%. Dew Point: -5.8°F. Windchill: -0.4°F. Pressure: 29.86 in 1011 hPa (Rising). Wind Chill Advisory in effect until 10 am EST this morning... |
| 08:47 |
kmlussier |
csharp: 19.2? I would be wearing my shorts and flip flops! :) |
| 08:47 |
kmlussier |
@weather 02771 |
| 08:47 |
pinesol_green |
kmlussier: The current temperature in Rumford, East Providence, Rhode Island is 5.5°F (8:40 AM EST on February 20, 2015). Conditions: Partly Cloudy. Humidity: 55%. Dew Point: -7.6°F. Windchill: -5.8°F. Pressure: 29.97 in 1015 hPa (Rising). Wind Chill Advisory in effect until 10 am EST this morning... |
| 08:47 |
jcamins |
csharp: that sounds really nice. |
| 08:48 |
jcamins |
@wunder 11375 |
| 08:48 |
pinesol_green |
jcamins: The current temperature in Meadow Lake, New York, New York is 3.7°F (8:15 AM EST on February 20, 2015). Conditions: Clear. Humidity: 45%. Dew Point: -13.0°F. Windchill: -11.2°F. Pressure: 30.18 in 1022 hPa (Rising). Wind Chill Advisory in effect until 10 am EST this morning... |
| 08:48 |
kmlussier |
It's colder here than where tsbere is? That just seems wrong. |
| 08:49 |
tsbere |
kmlussier: You aren't that far away from me. |
| 08:49 |
kmlussier |
tsbere: True, but, still, we're usually a few degrees warmer here. |
| 08:49 |
tsbere |
meh |
| 08:50 |
kmlussier |
jcamins: You win for now, but I'm sure when dbs arrives, he'll have us all beat. :) |
| 08:51 |
dbwells |
@weather 49546 |
| 08:51 |
pinesol_green |
dbwells: The current temperature in Timber Canyon, Ada, Michigan is -7.2°F (8:51 AM EST on February 20, 2015). Conditions: Mostly Cloudy. Humidity: 83%. Dew Point: -11.2°F. Windchill: -7.6°F. Pressure: 30.36 in 1028 hPa (Falling). Wind Chill Advisory in effect until 10 am EST this morning... |
| 08:52 |
jboyer-isl |
@weather 47274 |
| 08:52 |
pinesol_green |
jboyer-isl: The current temperature in Vallonia, Vallonia, Indiana is -8.5°F (8:40 AM EST on February 20, 2015). Conditions: Clear. Humidity: 76%. Dew Point: -14.8°F. Windchill: -7.6°F. Pressure: 30.40 in 1029 hPa (Rising). Wind Chill Advisory in effect until 11 am EST this morning... |
| 08:52 |
jboyer-isl |
Vallonia? It’s a wonder any of my mail ever arrives. |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
krvmga joined #evergreen |
| 09:10 |
|
mdriscoll joined #evergreen |
| 09:14 |
csharp |
whoa |
| 09:15 |
Dyrcona |
Whee, doggies! |
| 09:16 |
csharp |
we under a WINTER WEATHER ADVISORY which means we may get snow/sleet/freezing rain tonight before the temperature climbs into the mid-50s tomorrow |
| 09:16 |
rjackson_isl |
supposed to do similar hee - minus the climb into the 50s :-( |
| 09:17 |
Dyrcona |
I think we're expecting another blizzard Sunday night. |
| 09:17 |
Dyrcona |
Wouldn't be Sunday without one. |
| 09:17 |
kmlussier |
dbwells: Thanks for the info on multiple stat cats. That's good news! |
| 09:18 |
Dyrcona |
issa and NCIPServer have had that feature from the start. ;) |
| 09:19 |
Dyrcona |
phasefx: Still want to make issa the new staff client? |
| 09:20 |
Dyrcona |
I think a number of my members' staff still pine for GEAC and "green screen" terminals. |
| 09:20 |
Dyrcona |
Anyway, back to the weather report. |
| 09:20 |
phasefx |
Dyrcona: my original unrealistic dream was for there to be a plethora of staff clients :) so sure |
| 09:21 |
Dyrcona |
phasefx: I've considered messing with stuff in Qt, Java, Python/Qt, LibreOffice, you name it, for custom clients to do certain things. |
| 09:21 |
Dyrcona |
Like something to make it simpler for our staff to mess with circ and hold matrices or library settings, etc. |
| 09:22 |
Dyrcona |
We have some custom functions for making circ and hold matrix entries that anyone could use with a gui. |
| 09:22 |
Dyrcona |
Add it to our paramters spread sheet as a form, hook it up to the database via LibreOffice, and bingo! |
| 09:22 |
Dyrcona |
'Course I'm the only one who really uses LibreOffice in the office. |
| 09:22 |
csharp |
in other news, I'm trying to figure what has been applying a stop_fines reason of 'LONGOVERDUE' to our circulations before we began using the longoverdue feature in October |
| 09:23 |
Dyrcona |
csharp: I think a staff person may be able to do that through an oversight in the code. |
| 09:23 |
csharp |
oh! |
| 09:23 |
Dyrcona |
Someone should file a Launchpad bug if there isn't one. |
| 09:23 |
Dyrcona |
I think tsbere noticed it before I did. |
| 09:24 |
Dyrcona |
I think that's the status, it may be a different one. |
| 09:24 |
csharp |
do you know how it's done from the UI? |
| 09:25 |
Dyrcona |
I think it just appears in the list of statuses in edit item attributes when it shouldn't. |
| 09:25 |
tsbere |
csharp: It isn't a "magic" status in the item editor |
| 09:25 |
Dyrcona |
There's a list it failed to get added to that prevents it showing up there. |
| 09:25 |
Dyrcona |
Or, what tsbere said. :) |
| 09:28 |
mmorgan |
but csharp said stop_fines, not item status. Changing a status wouldn't set a stop_fines, would it? |
| 09:28 |
Dyrcona |
Well, that's true. |
| 09:29 |
Dyrcona |
Also, I'm not sure off the top of my head if that happened to long overdue or lost and paid. |
| 09:29 |
csharp |
Dyrcona: tsbere: okay - yeah we found that issue before we went live with the longoverdue feature and added it to the magic statuses as a PINES customization |
| 09:29 |
csharp |
and, no, that doesn't do anything to circs |
| 09:29 |
Dyrcona |
stop_fines is likely a trigger. |
| 09:30 |
csharp |
or maybe it is/was? |
| 09:30 |
Dyrcona |
Unless staff can monkey with it, but I don't think they can. |
| 09:30 |
tsbere |
Perhaps someone turned on the A/T event def, if library staff are allowed to monkey with those? |
| 09:31 |
|
yboston joined #evergreen |
| 09:31 |
csharp |
well, the only thing that could have triggered that stop_fines is a subroutine in action.pm named 'mark_longoverdue' |
| 09:31 |
csharp |
this was all pre-longoverdue-as-a-feature |
| 09:31 |
csharp |
like 2012 and before |
| 09:32 |
csharp |
and nothing else in the code calls that subroutine |
| 09:32 |
dbs |
jonadab: of course the auto-generated images are "just" something scripted, but they support different images for different formats (e.g. CDs, books, journals, scores, maps, etc), and they have something working now and we have nothing. |
| 09:33 |
dbs |
Everything is easy in theory. Making it actually happen is the hard part. Boy howdy would it be nice to have a feature like that as part of stock evergreen, instead of 404s a-plenty. |
| 09:33 |
csharp |
anyway - this is a new rabbit hole I found while trying to create a reports template to deal with the fact that paid-for longoverdue items still show on patron accounts with no indication that they have been paid already |
| 09:34 |
Dyrcona |
csharp: that seems unpossible. |
| 09:34 |
csharp |
yeah, that's what I think too |
| 09:34 |
Dyrcona |
but there it is, so I really can't say. |
| 09:35 |
csharp |
right - all I have is the fact that there are hundreds of pre-longoverdue "LONGOVERDUE" circs and it's complicating my approach to the report :-/ |
| 09:35 |
* csharp |
may batch change them all to MAXFINES or something |
| 09:36 |
csharp |
but I wanted to understand how they got there before doing anything about them |
| 09:38 |
Dyrcona |
Do they all have the same stop fines date? |
| 09:38 |
csharp |
I've been saying for years that working in PINES is like trying to declutter a hoarder's house where every closet you open causes a big pile of problems to fall on top of you |
| 09:38 |
csharp |
Dyrcona: nope - dates are all over and began in 2006 |
| 09:38 |
Dyrcona |
Same here, only a smaller house with fewer closets. |
| 09:39 |
Dyrcona |
Something could have changed the stop_fines without change the dates, possibly via SQL. |
| 09:40 |
csharp |
hmm |
| 09:40 |
Dyrcona |
There's also a constraint on stop_fines, at least in current systems: circulation_stop_fines_check |
| 09:40 |
Dyrcona |
I'd look to see if you have that constraint on action.circulation. |
| 09:41 |
Dyrcona |
Today, it should allow LONGOVERDUE, but I don't know if it existed in 2006 or what it did back then if it did exist. |
| 09:41 |
csharp |
I'll look into it |
| 09:41 |
dbs |
UToronto uses an "in-house application" to generate the cover images: http://journal.code4lib.org/articles/9195#ref8 |
| 09:42 |
* dbs |
will poke them |
| 09:42 |
Dyrcona |
While I see the utility in automatically generated cover images, I know our members would complain that it's the "wrong" cover. We get enough of those complaints already. :) |
| 09:42 |
* mmorgan |
thinks longoverdue existed a while back, but maybe in a different form. The Items Out screen always referred to "Longoverdue" until it was recently changed to "Other/Special Circulations" |
| 09:43 |
Dyrcona |
I think Equinox added it as an actual stop_fines and copy status in 2013. |
| 09:44 |
csharp |
mmorgan: yeah, some of the architecture for "longoverdue" was developed early on |
| 09:44 |
csharp |
but it was never in a finished form until summer 2013 |
| 09:47 |
gmcharlt |
dbs: I'll be putting 1423585 through its paces today -- just want to double-check that you don't have anything pending that you were planning to add to the branch today |
| 09:49 |
dbs |
gmcharlt: I'm all done, AFAIK |
| 09:49 |
gmcharlt |
dbs: thanks |
| 09:50 |
csharp |
ah - I think I figured it out |
| 09:50 |
csharp |
$circ->stop_fines_time('now') unless $circ->stop_fines_time; |
| 09:51 |
dbs |
message sent to the UofT folks re cover-art generating stuff |
| 09:51 |
csharp |
so if there was already a stop_fines_time, don't update it |
| 09:51 |
dbs |
gmcharlt++ |
| 09:51 |
csharp |
okay, that appears to be sorted then |
| 10:56 |
Dyrcona |
I have all these scraps of paper with encryption keys written on them. None of them are labeled so I don't know which are for what any more. |
| 10:58 |
jeff |
at least you have significantly reduced your search space. |
| 10:59 |
Dyrcona |
:) |
| 11:00 |
mmorgan |
Dyrcona: You're just practicing good security measures :) |
| 11:01 |
jboyer-isl |
A fun game: decryption software that destroys the file in question after 4 failed attempts, you have 5 keys to try. |
| 11:01 |
Dyrcona |
jboyer-isl++ |
| 11:02 |
Dyrcona |
You have an 80% chance of success, which is pretty good, though. |
| 11:03 |
jeff |
"software" that "destroys the file" is a pretty low hurdle, though. |
| 11:03 |
jeff |
an HSM, however... |
| 11:04 |
jboyer-isl |
jeff: I can’t tell if you are referring to how easy it is to make a copy and try again in that situation, or the fact that given enough time all software destroys all files. |
| 11:06 |
|
vlewis joined #evergreen |
| 11:06 |
jeff |
i was going for the former -- easy to make a copy. :-) |
| 11:06 |
jeff |
but on a long enough timeline... |
| 11:07 |
jeff |
software, hardware... the files are doomed! DOOMED! |
| 11:07 |
jeff |
incidentally, I unloaded a delivery of Commodore 64 hardware and software last night. I'm interested to see if it can be coaxed into operation, but I'm not expecting much. |
| 11:08 |
|
BigRig_ joined #evergreen |
| 11:08 |
Dyrcona |
I'm pretty sure the stuff on the cassettes for my old Vic-20 is beyond use. The Vic-20 itself.....I haven't tried in over 2 decades. |
| 11:10 |
jeff |
I imaged a bunch of old floppy diskettes back in 2003 or so. Several were no longer readable. Most/all of those copies are now lost due to another series of hardware failures. |
| 11:10 |
jeff |
I make more copies now. |
| 11:10 |
Dyrcona |
I'm my own worst enemy when it comes to files. |
| 11:10 |
Dyrcona |
I deleted the wrong files the other day. |
| 11:10 |
jeff |
Mostly it was "interesting" stuff vs "important" stuff. |
| 11:10 |
Dyrcona |
Fortunately, I make daily backups. |
| 11:11 |
Dyrcona |
I don't have anything truly important that I don't use on a regular basis. |
| 11:11 |
* jeff |
nods |
| 11:15 |
|
artunit joined #evergreen |
| 11:16 |
Dyrcona |
I am going to dig out some old CD-Rs and DVD-Rs this weekend. |
| 11:16 |
Dyrcona |
I swear I wrote a recursive directory traversal function in C over a decade ago, and it will probably be on one of those. |
| 11:16 |
jeff |
heh |
| 11:16 |
Dyrcona |
It doesn't look like it is on any of my current backups. |
| 11:16 |
|
BigRig joined #evergreen |
| 11:17 |
Dyrcona |
I'm working on a program at home to monitor files on our server and to initiate an off-site backup when anything changes. |
| 11:19 |
jcamins |
Dyrcona: wouldn't it be faster to write a new recursive directory traversal function in C than to find it in your backups? |
| 11:21 |
Dyrcona |
jcamins: Maybe, maybe not. |
| 11:21 |
Dyrcona |
It might even have been in Perl, but I'm pretty sure that I did both. |
| 11:21 |
Dyrcona |
I'll probably end up spending Saturday afternoon looking at most of the old stuff on the CDs. |
| 11:22 |
* kmlussier |
is perplexed |
| 11:23 |
Dyrcona |
kmlussier: About...? |
| 11:23 |
kmlussier |
The mkurl in working/user/kmlussier/lp1423922-place-another-hold-link is stripping query, qtype, locg parameters from the URL. |
| 11:23 |
kmlussier |
mkurl(ctx.opac_root _ '/place_hold', {}, stop_parms |
| 11:24 |
kmlussier |
Which I wouldn't have expected based on my previous use of mkurl |
| 11:24 |
kmlussier |
I feel like I'm missing something obvious |
| 11:25 |
* Dyrcona |
looks at the macro again. |
| 11:26 |
Dyrcona |
I recently used it and it didn't strip any of that stuff. I think it may be the arguments you are using. |
| 11:26 |
Dyrcona |
It may be that they are already gone. |
| 11:26 |
dbwells |
Good morning all. We're a bit short on time this morning for various reasons, but our OPW intern julialima_ is here for the next 25-30 minutes, and we'd like to ask a question or two. |
| 11:27 |
kmlussier |
Dyrcona: They still appear in the URL on the page where the link appears. The only parameters that are maintained are hold_type and hold_target. |
| 11:28 |
julialima_ |
Hello to all! Our concern is about action buttons requiring selections in, for example, tables. These buttons should be disable when nothing is selected, or hide completely (e.g. Gmail)? |
| 11:28 |
Dyrcona |
kmlussier: You're clearing whatever is in stop_parms. |
| 11:29 |
kmlussier |
Dyrcona: Yeah, I checked to see what was being cleared there. Hold on... |
| 11:30 |
bshum |
Hmm |
| 11:30 |
tsbere |
kmlussier: If stop_parms isn't an array it will clear a lot more too. I don't see where it is being set in that tree, though. |
| 11:30 |
kmlussier |
From body.tt2 - stop_parms = ['expand','cnoffset','copy_offset','copy_limit']; |
| 11:30 |
bshum |
julialima_: Is there any recommendation with that sort of behavior? I could see it being helpful to see the options regardless, but if they're not doing anything, I can see why hiding them is also okay? |
| 11:31 |
Dyrcona |
julialima_: I don't have a preference so long as the behavior is consistent. I'm used to seeing things disabled, but not showing them is the new trend, particularly on web apps. |
| 11:31 |
tsbere |
kmlussier: place_hold_result.tt2 doesn't include body.tt2, as far as I can tell. |
| 11:32 |
* kmlussier |
prefers disabled but is also curious about standard recommendations. |
| 11:32 |
kmlussier |
tsbere: Ah! that makes sense. OK, I can work with that. |
| 11:32 |
jonadab |
IMO, the space should at least be reserved (visibility: hidden, not display: none) so the layout doesn't change when something is selected. |
| 11:32 |
* kmlussier |
needs to move on to something else first. |
| 11:32 |
dbwells |
Thanks, all. Yes, we see both sides, and each has certain benefits. |
| 11:33 |
bshum |
+1 to jonadab's point |
| 11:33 |
Dyrcona |
I agree with jonadab if they are hidden. |
| 11:34 |
dbwells |
I think I somewhat prefer disabled, since that's been typical behavior for a long time, but as bshum points out, "newer" designs are using hiding more often. |
| 11:35 |
bshum |
Well, Dyrcona said it, but sure :) |
| 11:36 |
dbwells |
right, sorry :) |
| 11:36 |
jonadab |
Yeah, disabled would be reasonable too, I think. |
| 11:37 |
dbwells |
It would of course be really nice if there were bona fide studies which answered things like this, but they are awfully hard to find, probably in part because designing and running such studies is also really difficult. |
| 11:37 |
jonadab |
Either way *somebody* is going to be confused. |
| 11:37 |
jonadab |
But that is unavoidable. |
| 11:37 |
julialima_ |
Both option, I think, may have the same "problem": only when something is selected buttons will be enable or only when something is selected buttons will be shown |
| 11:38 |
jonadab |
Right, the question is whether its more confusing to see buttons and not be able to use them, or to look for buttons and not see them. |
| 11:40 |
dbwells |
One idea julialima_ had to help mitigate the issue altogether is to specify that tables should by default have the first row selected on load. What might be potential drawbacks of doing so, and do they outweigh the benefits? |
| 11:40 |
* bshum |
isn't sure he likes the idea of pre-selecting a row entry. |
| 11:41 |
Dyrcona |
Well, I'm not sure anything should be selected automatically, unless there is a reason to do so because of the data. |
| 11:41 |
kmlussier |
If the move to hiding actions is primarily driven by higher use of mobile, I think we should be cautious about moving in that direction because I think the majority of client use will continue to be in a non-mobile environment. |
| 11:41 |
* kmlussier |
agrees with bshum and Dyrcona |
| 11:41 |
kmlussier |
If something is pre-selected, staff will probably spend a lot of clicks deselecting those rows. |
| 11:42 |
Dyrcona |
Or, more typically, won't notice and will do something that they didn't mean to do. |
| 11:43 |
dbwells |
I think it would be selected in the "non-sticky" way, so there wouldn't be any extra clicks to unselect it. |
| 11:43 |
bshum |
Kind of like how billing works. Where there's that setting to decide whether we select every billing (to pay them) or have them all deselected (and staff are forced to pick and choose which bills to pay) |
| 11:43 |
bshum |
Staff/library/consortial preference on that particular example. |
| 11:44 |
dbwells |
That is, you could just click on the row you wanted to change the selection. The current web client works this way, though it isn't obvious from the display. |
| 11:45 |
jeff |
planning to use /c |
| 11:45 |
jeff |
er. |
| 11:45 |
jeff |
no idea where that first part came from -- sorry :-) |
| 11:48 |
julialima_ |
I know that if we try to solve something we can damage another thing, so the point is to decide which option (disable or hidden) is the best, or if there is another way to solve this |
| 11:49 |
dbwells |
Actually, it really wouldn't be terrible to relegate general first-row selection to being a possible setting. Then you get pick your poison :) |
| 11:52 |
kmlussier |
What are the perceived benefits of automatic first-row selection. |
| 11:52 |
kmlussier |
? |
| 11:53 |
|
BigRig joined #evergreen |
| 11:53 |
kmlussier |
I'm trying to think of interfaces where that approach would work well. |
| 11:53 |
jonadab |
Well, then you'd be able to see the buttons right away, *and* they'd do *something*. But it might not be something useful. |
| 11:53 |
dbwells |
The benefit would be that all the action buttons would be visible/active, so you would know what you could do without fumbling. |
| 11:53 |
jonadab |
So interface discoverability, yeah. |
| 11:54 |
jonadab |
Still not sure it's really ideal to have the first row autoselect though, because it might very well not be what you'd want to act on. |
| 11:54 |
jonadab |
Dunno. |
| 11:55 |
dbwells |
The devil's advocate response is that if you do want to act on the first row, then having it selected is a bonus, and if you don't clicking anywhere but the check mark on another row will deselect the first one anyway. |
| 11:56 |
dbwells |
We know it is atypical, and for that reason the safe choice would be to not do it, and that's probably where we'll end up. |
| 11:57 |
dbwells |
But if we take all the typical choices, we won't make anything better, either :) |
| 11:57 |
Dyrcona |
Buttons that are visible and won't do anything, should be clearly disabled. Otherwise staff will be frustrated clicking a button that does nothing, though it looks like it should. |
| 11:58 |
dbwells |
Defintely. |
| 11:58 |
Dyrcona |
Unless, like an old version of KIRC, it pops up a dialog saying "Danger, Captain! Dork at the helm!" |
| 12:00 |
dbwells |
The more subtle problem is that some users might not realize what they need to do to get the button to work. The "Pay Bill" part of the billing interface is a poster child for this problem, but as bshum pointed out, we actually have an option already just for that case. |
| 12:00 |
|
RoganH joined #evergreen |
| 12:00 |
mmorgan |
Regarding having a row selected by default, that would be useful when your table contains just ONE row. |
| 12:01 |
tsbere |
Can we make disabled buttons have hover text? Hover over the disabled "Pay Bill" button and it tells you that you need to select a bill and enter a payment amount type deal? |
| 12:01 |
Dyrcona |
Well, I think that points to larger problems with that interface. After all, why should a bill be selected to accept a payment? |
| 12:01 |
* bshum |
likes hover tips |
| 12:03 |
* Dyrcona |
resist the Monty Python reference. |
| 12:04 |
Dyrcona |
That's an example of an interface that makes you think about what you're doing. |
| 12:04 |
dbwells |
Boy, time goes fast. julialima_ has another obligation to get to. Thanks again to all who spoke up. You all make valid points, so please remember that we're just trying to push at the boundaries a bit. |
| 12:04 |
Dyrcona |
Yep. Good questions. |
| 12:06 |
dbwells |
P.S. Hover tips are great, except for touch users. And that's a good pattern for most design choices, "[ABC] is great! (except for [XYZ])" ;) |
| 12:06 |
julialima_ |
Thank you all! any idea that comes to you is welcome :) |
| 12:07 |
|
mtate joined #evergreen |
| 12:08 |
Dyrcona |
Well, the question becomes do you do things differently in the staff client versus the OPAC, and if you do something different when it looks like the user is on a mobile device? |
| 12:09 |
kmlussier |
dbwells/julialima_: Thanks for making us think! |
| 12:09 |
Dyrcona |
Then there's designing for mobile first vs. designing only for mobile and let the rest sort it out. |
| 12:09 |
* kmlussier |
also agrees with mmorgan to automatically select when there is just one result. |
| 12:12 |
|
julialima_ joined #evergreen |
| 12:13 |
berick |
dbwells: heads up for latest comment in bug 1198465 |
| 12:13 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 15, heat: 70) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:15 |
Dyrcona |
Well, another comment was added. :) |
| 12:16 |
berick |
thanks, dbwells |
| 12:16 |
berick |
er, Dyrcona |
| 12:16 |
berick |
tab-complete-- |
| 12:16 |
Dyrcona |
I think that bug is evidence we need to do something serious with respect to billing and circulation code. |
| 12:16 |
Dyrcona |
heh. |
| 12:16 |
* kmlussier |
hits submit on a GSoC application |
| 12:16 |
Dyrcona |
S'OK. I kinda deserve it for giving someone else credit for remingtron's work the other day. |
| 12:17 |
Dyrcona |
I mean all the effort that has been poured into it, and we're not really much closer to a solution than when it all started. |
| 12:17 |
|
RoganH joined #evergreen |
| 12:22 |
|
julialima_ left #evergreen |
| 12:25 |
|
gmcharlt joined #evergreen |
| 12:32 |
dbwells |
berick: thanks for the fix. Not too sure where that line came from, but this code has been through the ringer so many times, I can't be surprised. |
| 12:34 |
dbwells |
berick: I am perfectly fine with the transaction change you are suggesting. |
| 12:36 |
bshum |
kmlussier++ |
| 12:36 |
berick |
dbwells: cool. I just pushed it :) |
| 12:36 |
bshum |
kmlussier: I'll upload a logo for Evergreen to Melange |
| 12:37 |
kmlussier |
bshum: Ah, thanks. I saw that, but then I got distracted by other things |
| 12:37 |
kmlussier |
@blame other things |
| 12:37 |
pinesol_green |
kmlussier: everything was going great until other things came along |
| 12:38 |
dbwells |
berick: rolled in some other fixes too, I see. Thanks! berick++ |
| 12:39 |
Dyrcona |
That the _rebase branch that I loaded yesterday? |
| 12:39 |
berick |
collab/dbwells/1198465_cstore_fines_gen_rebase |
| 12:39 |
kmlussier |
Befoere I go off to play with the message center, I'm sending along a link to our 2015 GSoC page in case anybody has feedback. http://evergreen-ils.org/dokuwiki/doku.php?id=dev:summer_of_coding_ideas |
| 12:39 |
berick |
that the right one? |
| 12:40 |
kmlussier |
Especially Dyrcona and dbs since their names are listed on the page. |
| 12:40 |
Dyrcona |
berick: *I* think that is the latest one, yeah. |
| 12:41 |
berick |
cool |
| 12:41 |
* berick |
steps away for a few |
| 12:41 |
* dbwells |
also steps away for a bit (lunch!) |
| 12:43 |
jeff |
Jan 14: "I have put in a request for user credentials for you to use during your development, both patron and library admin. I will send them to you once I receive them." |
| 12:43 |
jeff |
It's almost as if they don't WANT people to make any use of their API. |
| 12:43 |
jeff |
"Yes, we have an API! Buy our stuff!" |
| 12:43 |
jeff |
"Oh, you want to USE the API?" |
| 12:44 |
Dyrcona |
kmlussier: It looks good to me. |
| 12:44 |
kmlussier |
Dyrcona: Thanks for looking it over! |
| 12:46 |
Dyrcona |
kmlussier: I think there will be some JavaScript required on the Awesome Box integration, at least to add a checkin modifier and communicate with the backend. |
| 12:47 |
kmlussier |
Dyrcona: OK, I've added it |
| 12:55 |
Dyrcona |
kmlussier: If you're still looking, I installed berick's changes to dbwells' cstore_fine_gen_rebase branch on my development server just now. |
| 12:56 |
kmlussier |
kmlussier: Thank you! |
| 12:57 |
|
BigRig_ joined #evergreen |
| 13:01 |
|
bmills joined #evergreen |
| 13:14 |
|
dbs joined #evergreen |
| 13:30 |
kmlussier |
eeevil++ gmcharlt++ |
| 13:30 |
kmlussier |
The action/trigger based messages seem to be working now. |
| 13:31 |
kmlussier |
Of course, I need to remind myself to wait for the delay. I almost filed a bug report saying they still weren't working. ;) |
| 13:32 |
berick |
kmlussier: let me know when you wrap up your testing. |
| 13:32 |
berick |
i'll do a final sweep and merge |
| 13:32 |
kmlussier |
berick: Will do |
| 13:33 |
* berick |
thinks this is a cool feature |
| 13:33 |
kmlussier |
Me too! :) |
| 13:47 |
gmcharlt |
kmlussier: yeah, I dropped the A/T delay down to 10 seconds in the test database :) |
| 13:47 |
kmlussier |
Apparently I was a bit impatient. :) |
| 13:55 |
jonadab |
Hmm... for current git Evergreen, is it recommended to upgrade to Apache 2.4, if the OS comes with 2.2 (e.g., wheezy)? |
| 13:56 |
csharp |
jonadab: nope |
| 13:57 |
jonadab |
Hmm.. ok, I will have another look at the relevant configuration, then, I must have done something not right. |
| 13:57 |
Dyrcona |
Even with git, it is easier to stick with what comes with your distro. |
| 13:57 |
csharp |
jonadab: well, make sure you're not using the 2.4 config on 2.2 ;-) |
| 13:57 |
jonadab |
Well, yes, clearly. |
| 13:57 |
Dyrcona |
Or vice versa. |
| 13:57 |
Dyrcona |
;) |
| 13:59 |
Dyrcona |
Sounds to me like they arrived at the destination and were not properly checked in and then sent back. |
| 13:59 |
Dyrcona |
With one of them having the bonus of somehow being checked in to get a transit to go home, but not to fill the hold for the original transit. |
| 13:59 |
Dyrcona |
oops. wrong tab. |
| 13:59 |
Dyrcona |
:) |
| 14:01 |
tsbere |
For context: MVLC has two copies in transit twice (no dest_recv_time). Once with the same source/dest/hold set, the other going *both ways* between two OUs. >_> |
| 14:02 |
jcamins |
tsbere: sounds to me like a book on quantum mechanics got entangled in the postal system! |
| 14:26 |
csharp |
tsbere: we see that occasionally too |
| 15:11 |
dbwells |
berick: can't wait to see that patch, as I'm not having luck finding the bug |
| 15:13 |
Dyrcona |
dbwells: It's probably not in your modifications. |
| 15:36 |
berick |
dbwells: thar she blows |
| 15:38 |
dbwells |
berick: ahhhh |
| 15:44 |
berick |
ok, good, that fixes the lost issue I had |
| 15:49 |
Dyrcona |
Looks like that would do it as far as sorting goes. |
| 15:53 |
dbwells |
berick: I can confirm both the bug and fix. berick++ |
| 15:53 |
jeff |
does this branch still try to "pay" bills out of order, or has it moved away from that? |
| 15:53 |
jeff |
an early version tried to "pay" (when simulating/checking) "larger" bills first |
| 15:54 |
dbwells |
The branch being tested right now doesn't try to do anything at all, it is strictly refactoring. |
| 15:54 |
jeff |
ah! i had lost context. thanks! |
| 15:55 |
jeff |
(checking in from a service desk with numerous distractions, i still have my coat on -- thanks for indulging a silly question) |
| 15:55 |
dbwells |
No problem, it is confusing, and who has time to read the 77 comments therein. |
| 15:58 |
kmlussier |
berick: I've finished up testing the message center for today. Sign-offs are forthcoming. |
| 15:58 |
berick |
kmlussier++ |
| 16:01 |
berick |
dbwells: Dyrcona: what's the situation w/ bug 1198465 -- if the fine-gen branch is merged, is the rest basically ready to go? or does that all need more testing, sign-off's, etc.? |
| 16:01 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 15, heat: 70) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 16:02 |
Dyrcona |
I'll let dbwells answer that. It's bascially all his now. |
| 16:02 |
berick |
*wistfully* it's more machine than man now |
| 16:03 |
kmlussier |
berick: There was still a bug with that branch the last time I tested that was supposed to be fixed by the fine-gen branch. I'm guessing it should be checked to see if it really is fixed. |
| 16:04 |
dbwells |
berick: I would need to rebase again, then testing and sign-offs still needed, too. And yes, the branch as it now exists is twisted, and evil. |
| 16:04 |
berick |
heh |
| 16:04 |
|
artunit joined #evergreen |
| 16:05 |
kmlussier |
The bug that needed to be fixed was related to generating new overdue fines on a lost checkin. The way I do my testing is very manual and requires that I do it over a few days to check that scenario. Not sure if you all have fancier ways of testing it. |
| 16:05 |
berick |
so, i really like the fine-gen changes. i think that will help a lot. i'm ready to sign off on those (and maybe do some squashing) unless there are any objections. |
| 16:06 |
dbwells |
berick: the goal in separating out the cstore part was to make it easier to test, so hopefully that will be worth it. I'll rebase the other stuff to that latest branch and see how far off we are from at least having working code again. |
| 16:06 |
berick |
dbwells: let me add sign-off's and squash and push another branch before you rebase. cool? |
| 16:07 |
dbwells |
sure, thanks |
| 16:11 |
Dyrcona |
Billing is twisted and evil, but it's what we got for now. |
| 16:23 |
berick |
dbwells: pushed. it's rebased to master |
| 16:30 |
kmlussier |
Is there any chance bug 1210541 will make it in for 2.8? We're really looking forward to it. :) |
| 16:30 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 16:52 |
* berick |
calls 0910 and 0911 |
| 16:53 |
gmcharlt |
emergency! emergency! |
| 16:53 |
berick |
haha |
| 16:53 |
berick |
gmcharlt++ |
| 16:53 |
berick |
the folks at 0910 talked me down |
| 16:54 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 16:54 |
pinesol_green |
[evergreen|Dan Wells] LP#1198465 Allow null fields to stay null in to_fieldmapper() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14de2b0> |
| 16:54 |
pinesol_green |
[evergreen|Dan Wells] LP#1198465 Recombine generate_fines() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d2a885> |
| 16:54 |
pinesol_green |
[evergreen|Dan Wells] LP#1198465 Move fine generation into CircCommon - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=38fab92> |
| 16:54 |
pinesol_green |
[evergreen|Dan Wells] LP#1198465 Restore skipping of lost-returned overdue generation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=170f947> |
| 16:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#1198465 CircCommon fine generator repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=389820b> |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:06 |
berick |
broke new record here.. 7 degrees over night. |
| 17:06 |
berick |
that ain't right |
| 17:06 |
pinesol_green |
Showing latest 5 of 20 commits to Evergreen... |
| 17:06 |
pinesol_green |
[evergreen|Mike Rylander] LP#1410369: Teach EventGroup how to process messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5357bfb> |
| 17:06 |
pinesol_green |
[evergreen|Mike Rylander] LP#1410369: Pull message title from the environment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db8b96c> |
| 17:06 |
pinesol_green |
[evergreen|Galen Charlton] LP#1410369: fix thinko in auml IDL - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67ceee7> |
| 17:06 |
pinesol_green |
[evergreen|Galen Charlton] LP#1410369: fix (old) thinko in A/T environment builder - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=874f870> |
| 17:06 |
pinesol_green |
[evergreen|Bill Erickson] LP#1410369 stamping TPAC message center DB upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2135221> |
| 17:06 |
berick |
(i'm sure we're not the only ones) |
| 17:07 |
kmlussier |
berick: We've been breaking other types of records up here. |
| 17:07 |
berick |
kmlussier: most vertical feet of frozen liquid? |
| 17:08 |
berick |
second only to one of jupiter's moons |
| 17:08 |
kmlussier |
berick: At one time? Yes |
| 17:15 |
|
mmorgan left #evergreen |
| 17:21 |
|
Christineb joined #evergreen |
| 17:24 |
|
dkyle1 left #evergreen |
| 17:28 |
pinesol_green |
[evergreen|Christine Morgan] LP1413721: Styling for sms Text Call Number page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33a682d> |
| 17:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1413721: Adding release notes entry for styling on SMS screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b9ababa> |
| 17:44 |
|
jihpringle joined #evergreen |
| 17:51 |
* kmlussier |
shakes her first at mkurl |
| 17:51 |
kmlussier |
fist, even |
| 17:55 |
|
buzzy joined #evergreen |
| 18:14 |
|
dbwells joined #evergreen |
| 18:14 |
bmills |
hi everyone. i was curious if anyone has had any issues getting their billing receipt templates to sum correctly? we're using <span style="display: none;" sum="total">%balance_owed%</span> (for the line item) and <span sumout="total" fixed="2"></span> for the total in the footer. The bills sum up correctly provided that all the values in %balance_owed% are > 1. When bills include amounts less than a dollar they sum up as if the decimal point wasn't there |
| 18:36 |
|
Arlene joined #evergreen |
| 18:36 |
Arlene |
hi kmlussier |
| 18:37 |
kmlussier |
Arlene: Hi! |
| 18:38 |
Arlene |
please i wish to know is evergreen is doing outreachy this year |
| 18:38 |
Arlene |
sorry for the typos |
| 18:40 |
kmlussier |
Arlene: I don't think we can, but we have applied for GSoC. |
| 18:40 |
kmlussier |
We only have a few volunteers who have stepped up to mentor, so I don't think we could properly support two separate intern projects at the same time. |
| 18:40 |
Arlene |
Gsoc is cool but difficult for us to get in |
| 18:42 |
Arlene |
i guess i will have to try my luck with the boys. |
| 18:42 |
kmlussier |
Arlene: Well, we typically do the same selection process whether it is GSoC or Outreachy. |
| 18:43 |
kmlussier |
I think the big thing is if we see you reaching out to the community during the application period, if you get a patch in, etc., it will help your application look good. :) |
| 18:44 |
Arlene |
Thanks for the tip. I think i have to start working now to get familiar with the codebase. |
| 18:44 |
kmlussier |
Arlene: Have you seen our GSoC page yet? It has a lot of tips for getting started. |
| 18:44 |
Arlene |
is there a link to some projects that will feature at gsoc 2015? |
| 18:44 |
kmlussier |
Actually, I think you've already looked at the OPW page, so they are very similar. |
| 18:45 |
kmlussier |
Arlene: There are just two at the moment. They both are ones that were part of OPW for the last round. |
| 18:45 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=dev:summer_of_coding_ideas |
| 18:46 |
Arlene |
actually im very interested in the project to convert dojo code to angular |
| 18:46 |
Arlene |
wondering if if will come for Gsoc |
| 18:47 |
kmlussier |
Arlene: I think the problem is finding a mentor to take charge of that project. We're a fairly small community, so finding a mentor to take charge of it would be difficult. |
| 18:48 |
kmlussier |
Having said that, I know there is a lot of interest in the community to have that kind of work done. |
| 18:49 |
Arlene |
the community needs to grow. what of past gsoc students? can't they mentor? |
| 18:50 |
Arlene |
i really think students should continue commiting to evergreen even after Gsoc |
| 18:51 |
Arlene |
thats if there are really passionate about the evergreen project |
| 18:51 |
kmlussier |
Arlene: Yes, and we would love to see that. :) |
| 18:51 |
kmlussier |
Because we certainly are very passionate about the project. |
| 18:52 |
Arlene |
they could even become mentors for us the new students. |
| 18:53 |
Arlene |
Thankx for the tips kmlussier |
| 18:53 |
kmlussier |
Arlene: Well, it's something I can certainly bring up with the devs. With GSoC, I do know you can submit a proposal for your own idea. But I really would want to make sure you had good mentor support for the project. |
| 18:53 |
kmlussier |
Arlene: Thanks for checking in! |
| 18:54 |
Arlene |
hope i can always get back to you while im reading through the wikis |
| 18:56 |
|
akilsdonk joined #evergreen |
| 20:08 |
* kmlussier |
raises her arms in triumph over mkurl |
| 20:23 |
|
bmills joined #evergreen |
| 20:24 |
gmcharlt |
kmlussier++ |
| 20:41 |
bshum |
kmlussier++ |
| 21:35 |
pinesol_green |
[evergreen|Dan Scott] LP#1423585 Add Open Graph Protocol markup to TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=efd0c1f> |
| 21:35 |
pinesol_green |
[evergreen|Galen Charlton] LP#1423585: add release notes entry - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=580afa1> |
| 21:37 |
|
bbqben joined #evergreen |
| 22:05 |
|
dcook joined #evergreen |
| 22:30 |
kmlussier |
Before I head out for the rest of weekend, I'm going to issue one last plea for bug 1210541. Looks like it's the only remaning new feature with a signedoff tag that hasn't been merged yet. |
| 22:30 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
