| Time |
Nick |
Message |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
BigRig_ joined #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 08:07 |
|
collum joined #evergreen |
| 08:16 |
|
mrpeters joined #evergreen |
| 08:34 |
csharp |
ok - I'm trying to decide if this is a bug or a feature and whether it deserves a launchpad report.... |
| 08:35 |
csharp |
current behavior is that if a patron pays for a lost item, it drops off the lower "alternate" window on the Items Out screen |
| 08:36 |
csharp |
however, if a patron pays for a longoverdue item, that circ is still being displayed on the lower window of Items Out |
| 08:36 |
csharp |
and that's confusing our circ staff |
| 08:36 |
|
graced joined #evergreen |
| 08:38 |
csharp |
the settings berick created in http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a0ee19f899f038594fea496c2032b9fbeaffa63d do not affect this behavior |
| 08:38 |
pinesol_green |
[evergreen|Bill Erickson] LP 1212456 customize items out display - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a0ee19f> |
| 08:38 |
csharp |
because those settings only care about whether an item is checked in and still owes fines |
| 08:48 |
kmlussier |
csharp: Does the "leave transaction open when long overdue balance equals zero" OU setting affect whether it displays? |
| 08:50 |
csharp |
kmlussier: no difference, no |
| 08:51 |
csharp |
and we don't want to close those transactions (we don |
| 08:51 |
csharp |
't have that setting on for lost either) |
| 08:53 |
kmlussier |
Hmmm...ok. I had been thinking that's what removed it from that window for lost items, but I could be misremembering. |
| 08:55 |
bshum |
csharp: What is the setting set to for longoverdue? |
| 08:56 |
bshum |
And/or lost |
| 08:56 |
csharp |
bshum: unset, but when I set it to False and paid for another LO item, it still displayed |
| 08:56 |
csharp |
unset for lost too |
| 08:56 |
eeevil |
csharp: the short version (of the original reasoning) is that longoverdue is still overdue (though specially marked), and not the same as lost |
| 08:56 |
csharp |
and lost drops off |
| 08:57 |
csharp |
eeevil: that makes sense - Elaine and I were just having the same discussion here |
| 08:58 |
csharp |
however, staff are confused because 1) it doesn't act like Lost and 2) they apply a payment and nothing visually changes from their point of view, which is making them think it's a "glitch" |
| 08:58 |
bshum |
csharp: aren't the settings you linked to numerical values? |
| 08:58 |
bshum |
Or are we talking about other settings |
| 08:58 |
csharp |
bshum: oh - sorry - I was referring to the setting kmlussier asked about |
| 08:59 |
csharp |
bshum: we're unset for the customized views, so that would be default behavior too |
| 09:01 |
csharp |
kmlussier: bshum: eeevil: thanks for the input/interest - I think that gives me enough to go on |
| 09:14 |
jboyer-isl |
csharp, I remember looking into this when I made some changes to how claims returned items are displayed. The default logic behind both claims ret and longoverdue is that they display in that list until they’re checked in, regardless of bills. The reasoning (as I understand it) being that they claimed it was reutned but it still hasn’t been found. |
| 09:15 |
|
abowling joined #evergreen |
| 09:15 |
|
julialima_ joined #evergreen |
| 09:16 |
jboyer-isl |
For instance, here you’re allowed to claim you’ve returned 3 things before it’s time to pull out your checkbook. It helps to always have the list of items claimed returned in that case. |
| 09:21 |
dbwells |
Good morning all. The OPW group is just starting phase two of our project, where we hope to focus on "controls", so we're looking for input (no pun intended :) ). |
| 09:22 |
dbwells |
Our first topic of consideration is that of buttons. |
| 09:22 |
julialima_ |
Good morning! |
| 09:23 |
kmlussier |
Good morning julialima_ |
| 09:24 |
dbwells |
I'd like to say a few things about where we are, then we'll probably mostly listen and occasionally prod to see what others think. |
| 09:25 |
dbwells |
Right now, the web staff client is using Bootstrap for most of its styles. Here's some info on Bootstrap buttons: http://getbootstrap.com/css/#buttons |
| 09:26 |
dbwells |
Another place we've been looking for inspiration is Google's recent design guide, so here is Google's current take on buttons: http://www.google.com/design/spec/components/buttons.html# |
| 09:27 |
dbwells |
Now, they are not worlds apart, but there are some important distinctions. |
| 09:29 |
dbwells |
We'd love to hear some overall reactions or comments about these styles. We're also eager to consider other button styles/features if there is something else out there which does things even better. |
| 09:33 |
jboyer-isl |
The strongest feeling I have about buttons is that “flat” buttons are a terrible idea. Borders on buttons or underlined links are the way to go there. |
| 09:34 |
jboyer-isl |
And I guess a shadow counts as a border in that case. |
| 09:35 |
dbwells |
jboyer-isl: Are you specifically referring to Google's "flat" button version? |
| 09:35 |
jboyer-isl |
And Apple’s, yes. |
| 09:35 |
dbwells |
Not as familiar with Apple's, but ok :) |
| 09:35 |
jboyer-isl |
They’re the same. ;) |
| 09:37 |
* gmcharlt |
tends to agree with jboyer-isl |
| 09:37 |
dbwells |
I'm not saying this in support, but I think the idea is that there are certain instances (e.g. a dialog box) where position and context are enough to tell you something is a "button" so the additional styling is a distraction. |
| 09:40 |
dbwells |
I've personally not made up my mind about it, but it's an interesting concept, and when I look at the examples, it isn't without merit. |
| 09:41 |
|
ningalls joined #evergreen |
| 09:41 |
jboyer-isl |
That is the idea, but I think it requires a level of pattern matching that I don’t think most users care to apply. There’s another convention as to which side is ok vs. cancel (or safety vs data loss) that I don’t think even fairly advanced users can remember off hand. |
| 09:42 |
phasefx |
yuo can raed tihs bceuase of ohter cleus <- but having more information for your brain to process is not necessarily a distraction |
| 09:42 |
jboyer-isl |
I’m certainly no fan of the Windows 3.1 days where the border could take up 15% of the space, don’t get me wrong. |
| 09:48 |
julialima_ |
I think they maybe work better on a touch device, but I also consider this type of buttons can be confusing. I don´t think the web staff client is suitable for this type of resource by the amount of information handling, but I do not rule out the possibility of trying it if necessary |
| 09:49 |
dbwells |
So, on Google's guide page linked above, looking at the Do/Don't "Travel stream" example, does anyone agree with Google that the raised buttons here are more "heavy" than necessary? |
| 09:50 |
dbwells |
It's about a third of the way down the page. |
| 09:50 |
|
pmurray_away joined #evergreen |
| 09:52 |
phasefx |
dbwells: I don't have a strong opinion there, but I think I'm used to what Google is doing, and I'm very adaptable. Presumably they've done actual user testing (I'd pretty much bet on it) |
| 09:52 |
dbwells |
I'm presuming that as well. |
| 09:53 |
phasefx |
I think the words being verbs and all caps invite them to be interpreted as actions |
| 09:53 |
dbwells |
But even with zillions of dollars, there is always going to be a certain subjectivity to really subtle design choices which is hard to measure, so I'm not going to go all in on Google, either :) |
| 09:54 |
phasefx |
something like Actions for this Record would probably be horrible there :) |
| 09:54 |
|
pmurray joined #evergreen |
| 09:55 |
phasefx |
dbwells: and also potential bureaucratic craziness/bias |
| 09:55 |
|
Shae joined #evergreen |
| 09:55 |
phasefx |
I doubt any company is purely rational and numbers driven |
| 09:55 |
jboyer-isl |
My issue with that example (took me a while to find it) is they are comparing completely flat with raised. There’s a level in between, which is just the color border, no shadow. That’s the one I’d prefer in that situation. |
| 09:56 |
jboyer-isl |
phasefx: Google may be as close as can be on that front. (Que stories about the 47 shades of blue A/B testing, etc.) |
| 09:56 |
phasefx |
mmm |
| 09:57 |
gmcharlt |
I also think we can't dismiss that firms like Google, while I do believe that they can and do more actual UX testing... are also under a marketing impetus to refresh their look periodically |
| 09:57 |
phasefx |
as opposed to Yahoo with the CEO changing colors at the last minute :) |
| 10:00 |
dbwells |
jboyer-isl: So do you think you would generally support the idea of a "lighter" button style for cases where button-ness is easily identifiable from context, but a "heavier" style when you need a button to stand out due to placement or generally screen busy-ness? |
| 10:01 |
dbwells |
That question is for everyone else too, of course. |
| 10:01 |
jboyer-isl |
gmcharlt: True. End users don’t see the back-end changes, just UI. Not as much an issue for specialty software (ILSs!) |
| 10:03 |
jboyer-isl |
dbwells: Yes. I don’t have anything against multiple styles (so long as there are well defined guidelines on their use, i.e. why does this button look X, but that one Y?) My issue is specifically flat style, because it only uses placement and occasionally color. |
| 10:03 |
gmcharlt |
dbwells: yes, although I might turn it around: a general not-to-heavy button style for most buttons, and a less commonly-used one for when the button should get special emphasis |
| 10:05 |
dbwells |
Thanks, I think these are good clarifications. I also share concerns about applicability guidelines, so we don't end up with "use this style when it /feels/ like you should" |
| 10:05 |
phasefx |
does the orange in that example mean thats a default action if you're in an environment where you can press enter? |
| 10:05 |
|
jwoodard joined #evergreen |
| 10:06 |
dbwells |
phasefx: I think that's the idea. |
| 10:06 |
* phasefx |
has been using android x86 in a vm lately, and misses some keyboard/mouse niceties |
| 10:07 |
dbwells |
The default or most likely choices are generally on the right, likely due to general right-thumbedness. |
| 10:08 |
dbwells |
It does seem a little odd when you combine that with left alignment. |
| 10:09 |
dbwells |
Design is always a compromise of some kind; you just can't win em all. |
| 10:09 |
phasefx |
maybe the image is "Correct use of flat buttons.*" * - Incorrect use of alignment :) |
| 10:17 |
* phasefx |
knows good keyboard support has always been a goal for Evergreen's staff client, and so much design these days is catering to keyboardless devices |
| 10:22 |
eeevil |
just my opinion, but I think google-style flat buttons are a non-starter for a web UI ... I think break from normal "web page" expectations most users have, and their use on google pages has been painful for me to adjust to. See: the new Drive interfaces, and Inbox. on mobile, they're mostly OK, but there are different assumptions there, IMO |
| 10:23 |
eeevil |
I like the raised ones fine, but I also like the bootstrap buttons a lot |
| 10:24 |
* kmlussier |
chimes in to say good keyboard support is critical for the client. |
| 10:27 |
collum |
kmlussier++ |
| 10:29 |
dbwells |
Thank again to everyone for the input. Changing the subject a little, how do we feel about all caps vs mixed case on the buttons? Assuming we could overcome technical hurdles (I know there have been concerns about foreign character support in past uses of all caps), do we like it as a style choice? It seems meant as a visual cue to stand out from surrounding content. |
| 10:32 |
collum |
Mixed case with an easy option to change to all caps via CSS. |
| 10:32 |
jboyer-isl |
I DO NOT CARE FOR ALL THE SHOUTING. Also, I find the “shape” of mixed case easier on the eyes. |
| 10:32 |
eeevil |
I don't think it's necessary (or more usable) if the buttons are visually deliniated. and, to my eye, it looks like yelling to have ALL CAPS sprinkled on the screen. that said ... heh... what collum beat me to ;) |
| 10:32 |
* phasefx |
agrees on use CSS for it if done at all |
| 10:32 |
jboyer-isl |
And as collum mentions, if a location would like to make them all caps, that’s an easy customization |
| 10:34 |
eeevil |
super easy, actually, for current web staff code: #btn { text-transform: uppercase; } |
| 10:34 |
julialima_ |
Caps in buttons are somewhat "violent" I think |
| 10:35 |
graced |
julialima_++ I agree |
| 10:36 |
dbwells |
To help explain why it's often done, another advantage is that all caps is generally the same height, and also generally lacks decenders. This makes it much easier to vertically align in a consistent way. It is easy for mixed case buttons to look "off" depending on the text content. |
| 10:39 |
eeevil |
dbwells: it seems that would apply primarily to the flat-style buttons, yes? |
| 10:39 |
dbwells |
It also can lend things a certain "industrial" quality. For instance, looking at my stereo, every control is labeled in all caps. I've never noticed or even thought about it, because so many things are labeled that way. |
| 10:40 |
* kmlussier |
agrees with julialima_ |
| 10:42 |
dbwells |
Again, I'm not trying to support one side or the other, just trying to represent the "other" side. We're obviously a very conservative bunch :) |
| 10:43 |
* phasefx |
burns dbwells in effigy :) |
| 10:44 |
eeevil |
dbwells: the role of "devil's advocate" is very important ... please don't take my comments as an attack on /you/ :) |
| 10:46 |
dbwells |
It's also funny how thinking about things can be different than actually experiencing them. For instance, many of us have seen and clicked the button a huge number of times, but can anyone tell me (without looking) whether Gmail's compose button is all caps? As you might guess from the conversation, it is, but I'd be lying if I said I ever really noticed or cared, or that it ever seemed wrong. |
| 10:47 |
phasefx |
in Inbox it's a + sign in the lower right.. I keep looking for it |
| 10:48 |
phasefx |
so they obviously don't have everything right in my case, n=1 :) |
| 10:49 |
dbwells |
Yeah, I should have specified, the browser version. That whole plus-sign thing on mobile is a pretty dramatic gamble of a UI choice, that's for sure :) |
| 10:49 |
phasefx |
the browser version of INbox as well |
| 10:50 |
dbwells |
ah, ok. I'm still on the old-school Gmail. |
| 10:51 |
|
julialima_ left #evergreen |
| 10:51 |
* phasefx |
uses Inbox for personal, Gmail for work, so there's some dissonance there keeping me from adapting in this case :) |
| 10:51 |
dbwells |
eeevil: no worries. I understand the risks :) |
| 10:52 |
|
julialima_ joined #evergreen |
| 10:54 |
dbwells |
So Google almost certainly put the "action button" in the lower right for thumb's sake, then tries to carry the idea to the desktop, where lower right is not exactly a historically sensible place to put important things. Again, a pretty big gamble in my eyes, and another good example of why design is all about compromise. |
| 10:56 |
dbwells |
From my perspective, Google's putting cross-device consistency above 20 or 30 years of desktop GUI history. An interesting decision, and I wish them luck! |
| 10:56 |
phasefx |
does Google say anything about multiple or single entry points for a given action or workflow? |
| 10:58 |
phasefx |
or anyone else for that matter? |
| 10:58 |
dbwells |
I'm not sure if they address that directly, but I haven't read the whole guide straight through. |
| 10:59 |
dbwells |
You're thinking like both a "compose" button and the plus button? |
| 11:01 |
phasefx |
well, not something so obviously redundant. Early on in EG history, i had a mock staff client that had the normal menu bar along the top that we see now, but an extra menu bar along the bottom that was centered around nouns, like Items and Patrons. No one liked it, but since then I've been hearing different opinions on the notion of multiple ways to do something in EG |
| 11:02 |
phasefx |
one example might be the dedicated interface for scanning in a patron barcode vs entering a barcode in the patron search interface |
| 11:03 |
phasefx |
or Retrieve Record by TCN in a staff client menu vs using Advanced Search to do it in the embedded OPAC |
| 11:03 |
phasefx |
so maybe some obvious redundancies as well :) |
| 11:04 |
dbwells |
phasefx: If it's any consolation concerning your mock client, I really like that idea :) Having not seen it (obviously), I still think I know exactly what you were going for, at least in spirit. |
| 11:04 |
phasefx |
dbwells: but we're programmers ;) a subset of the population |
| 11:09 |
dbwells |
phasefx: In general, these questions are really great. It's pretty obvious (despite your programmer goggles) that you've giving UI design a lot of thought. It's probably outside the scope of the guide project, but we should find a way to talk through these ideas more over the next few months. |
| 11:16 |
dbwells |
Well, thanks again to everyone who chimed in. This is very valuable feedback. |
| 11:20 |
phasefx |
opw++ |
| 11:20 |
julialima_ |
I join Dan, thank you all! |
| 11:20 |
dbwells |
I think we'll try to bring up similar topics in channel weekly, as it's a lot to take in and digest. |
| 11:23 |
kmlussier |
I have a question about search relevance. My understanding is that an exact match on a search term is a little weightier in terms of relevancy than a match on a stemmed term. Is my understanding correct? |
| 11:23 |
kmlussier |
In looking at the 2.4 release notes on search changes, it seems like this is the case. http://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_4.html#_opac |
| 11:25 |
|
sarabee joined #evergreen |
| 11:26 |
|
sandbergja joined #evergreen |
| 11:26 |
|
Stompro joined #evergreen |
| 11:28 |
|
neutral joined #evergreen |
| 11:33 |
|
bmills joined #evergreen |
| 11:41 |
|
b_bonner joined #evergreen |
| 11:41 |
|
mnsri_away joined #evergreen |
| 11:41 |
|
rashma_away joined #evergreen |
| 11:50 |
* bshum |
hates snow days/closed dates/backdating schenanigans and explanations. |
| 11:52 |
csharp |
bshum: right there with you |
| 11:52 |
bshum |
I feel like I end up having the same conversations every year during this time of winter. :) |
| 11:53 |
csharp |
bshum: if voiding fines is an issue, I have a (fairly crude) bash script that does the job: http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=batch_void_fines.sh;h=eb84c27b09b03e92275c1447e765d4ad93e4cb8e;hb=HEAD |
| 11:53 |
|
Jake___ joined #evergreen |
| 11:54 |
Jake___ |
Hello, just a quick question. Is the Evergreen staff client okay to use with Windows 8? |
| 11:54 |
csharp |
Jake___: sure - it installs and runs fine |
| 11:54 |
bshum |
Jake___: Shouldn't be a problem, I'm using the client on Win 8.1 right now. |
| 11:54 |
bshum |
You might have to tell it to allow if Microsoft complains when you a) download it, b) try to install it. |
| 11:54 |
bshum |
Since the OS might not recognize its authenticity. |
| 11:55 |
Jake___ |
Oh awesome! Thanks! Expanding on that, when the free upgrade to Windows 10 happens do you think it should still work fine? Speculatively, of course. |
| 11:55 |
csharp |
Jake___: probably |
| 11:56 |
bshum |
I think mrpeters was experimenting with the Win10 preview and had good things to say on it. But I don't anticipate any big woes there. |
| 11:56 |
csharp |
hopefully we'll be closer to a browser based client by the time Windows 10 is in common usage, though |
| 11:56 |
mrpeters |
it was working fine |
| 11:56 |
bshum |
mrpeters++ |
| 11:56 |
mrpeters |
i used it for a day to test our standalone debs for Evergreen |
| 11:56 |
bshum |
Testing the future. |
| 11:56 |
mrpeters |
win 10 is going to be pretty solid i think |
| 11:56 |
mrpeters |
may get me to upgrade from win 7 |
| 11:57 |
Jake___ |
Thats great to hear |
| 11:57 |
Jake___ |
Thank you all for the answers! You're awesome! Now I got to get back to work! Bye! |
| 12:01 |
bshum |
csharp: Interesting script. Requires heavy modifications before we could use it :) |
| 12:02 |
bshum |
Stuff like the backup schema and the branch/system name checking I guess are unique to you |
| 12:02 |
bshum |
Though quite fun |
| 12:02 |
bshum |
csharp++ # thanks for sharing, maybe I'll play with it more later. |
| 12:02 |
csharp |
yeah |
| 12:03 |
csharp |
bshum: happy to assist, I'd like the script better if it were tied into the actual opensrf calls, but it was done under pressure and I had to use the tools I knew |
| 12:04 |
bshum |
csharp: I used to do more stuff via SQL back in the day. |
| 12:04 |
csharp |
pressure = nearly every PINES system wanting specific dates' fines voided |
| 12:04 |
bshum |
But nowadays we just tell libs to backdate more liberally. |
| 12:10 |
|
nhilton joined #evergreen |
| 12:10 |
|
buzzy joined #evergreen |
| 12:13 |
|
bmills1 joined #evergreen |
| 12:13 |
|
bmills1 joined #evergreen |
| 12:23 |
|
mmorgan joined #evergreen |
| 12:25 |
gmcharlt |
to avoid a potential race condition, I'd appreciate eyes on bug 1415572 soonish |
| 12:25 |
pinesol_green |
Launchpad bug 1415572 in Evergreen 2.7 "outdated version of authority.normalize_heading can be present in certain upgraded databases" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1415572 |
| 12:28 |
jboyer-isl |
mrpeters, I meant to ask earlier: were you going to take care of the Mac clients for the web team? I didn’t want to duplicate any efforts, but I didn’t know if you were helping out that one location or building each release’s clients. |
| 12:30 |
mrpeters |
I offered to, but didnt really hear any resounding response to start posting them on the website so I haven't yet. |
| 12:31 |
|
nhilton_ joined #evergreen |
| 12:32 |
jboyer-isl |
It would probably help, but I think that the people that need it most either track SITKA or build their own so we don’t know how big a group it is. |
| 12:33 |
mrpeters |
yeah, i dont know either. plus, do we want to offer support for them? i can't commit to supporting them |
| 12:34 |
|
mmorgan joined #evergreen |
| 12:35 |
jboyer-isl |
It would definitely be a “at your own risk” thing. |
| 12:36 |
gmcharlt |
"up to and including coming to the library one day and finding the collection reshelved in order of descreasing size..." ;) |
| 12:36 |
jboyer-isl |
Do not taunt Evergreen Staff Client. |
| 12:37 |
gmcharlt |
heh |
| 12:37 |
gmcharlt |
but from the webteam POV, it's not a big deal to provide credentials and place to upload the clients and a WP login for updating the downloads page |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:38 |
gmcharlt |
just need somebody to contact me or bshum when they're ready to say go |
| 12:38 |
mrpeters |
i'd probably need someone to tell me when one is needed, and then i'd upload the file and let someone update the downloads page when they update the rest of the clients |
| 12:38 |
gmcharlt |
and for that matter... I'm happen to simply be sent the clients, and I can put them in place |
| 12:59 |
csharp |
gmcharlt: testing your fix now |
| 12:59 |
gmcharlt |
csharp: did you all run into the issue? |
| 12:59 |
* csharp |
recalls running into NOHEADING several months ago |
| 12:59 |
gmcharlt |
snap |
| 12:59 |
csharp |
yeah, but I don't recall the details |
| 13:00 |
csharp |
we have ~9000 affected auth record entries |
| 13:00 |
csharp |
I think I was researching see from/also tracings and saw many records with NOHEADING |
| 13:01 |
csharp |
yep: http://irc.evergreen-ils.org/evergreen/2014-12-12#i_144668 |
| 13:01 |
csharp |
looks like yboston was affected too |
| 13:02 |
gmcharlt |
#startmeeting Web Team Meeting, 2015-01-28 |
| 13:02 |
pinesol_green |
Meeting started Wed Jan 28 13:02:26 2015 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:02 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 13:02 |
pinesol_green |
The meeting name has been set to 'web_team_meeting__2015_01_28' |
| 13:02 |
gmcharlt |
#info Agenda is http://wiki.evergreen-ils.org/doku.php?id=webteam:meetings:agenda:2015-01-28 |
| 13:02 |
gmcharlt |
#topic Roll call |
| 13:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 13:05 |
kmlussier |
Sorry, I wasn't paying attention. |
| 13:05 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:05 |
gmcharlt |
:) |
| 13:06 |
kmlussier |
Small meeting? :) |
| 13:06 |
gmcharlt |
appears so... |
| 13:06 |
gmcharlt |
#topic Updates |
| 13:06 |
gmcharlt |
#action gmcharlt will install (or verify that it was installed) the libc6 fixes for the "GHOST" vulnerability today on the evergreen-ils.org boxes |
| 13:08 |
gmcharlt |
#action after ALA Midwinter, gmcharlt will get the documentation test VM provisioned |
| 13:08 |
gmcharlt |
kmlussier: any quick updates from you? |
| 13:08 |
kmlussier |
gmcharlt: No, I haven't done anything for the web site this month. |
| 13:08 |
gmcharlt |
I saw that ericar has sent out a query about updated the roster |
| 13:09 |
gmcharlt |
I believe she's on the road today, though |
| 13:10 |
gmcharlt |
kmlussier: any topics/queries you'd like to bring up? |
| 13:10 |
gmcharlt |
actually, here's another from me |
| 13:11 |
kmlussier |
Nothing that I can think of. |
| 13:11 |
gmcharlt |
#info There's discussion about one or more folks building Mac staff clients; the web team has extended an offer to assist with mechanics of getting them on the webserver for download |
| 13:11 |
gmcharlt |
kmlussier: in that case, I'm inclined to carry every else to February |
| 13:12 |
gmcharlt |
and send scheduling ninjas to track people down to attend the February meeting :) |
| 13:13 |
gmcharlt |
kmlussier: thanks! |
| 13:13 |
gmcharlt |
#endmeeting |
| 13:13 |
pinesol_green |
Meeting ended Wed Jan 28 13:13:22 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 13:13 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-28-13.02.html |
| 13:13 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-28-13.02.txt |
| 13:13 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-28-13.02.log.html |
| 13:13 |
kmlussier |
gmcharlt++ |
| 13:13 |
kmlussier |
Shortest meeting ever |
| 13:19 |
tsbere |
kmlussier: I disagree! Comes close, though. |
| 13:24 |
dbwells |
fits on one screen for me, that's pretty impressive |
| 13:26 |
kmlussier |
tsbere: I want to see proof of this other, shorter meeting you speak of. |
| 13:27 |
tsbere |
kmlussier: I believe the shortest *I* have ever been involved with went "Ok, who's here?" *raise my hand* "Ok, our rules state we need more people than this to accomplish anything. I move we thus leave everything until we can actually vote on stuff." *I voice agreement* "Ok then, meeting over." - Total elapsed time was about a minute and a half. |
| 13:28 |
kmlussier |
I would argue that since there wasn't a quorum, the meeting didn't actually take place. ;) |
| 13:28 |
csharp |
one_screenful_meetings++ |
| 13:29 |
tsbere |
kmlussier: Ah, but to discuss things we didn't need a quorum. Just to actually vote on stuff. Our decision was more along the lines of "why discuss things if we can't vote on them anyway?" :P |
| 13:29 |
csharp |
#vote ulitmate power to the web team: Yes |
| 13:30 |
csharp |
er.. ultimate power, even |
| 13:30 |
csharp |
gmcharlt: I tested your branch - signoff branch on the way |
| 13:31 |
bshum |
For fun, http://evergreen-ils.org/irc_logs/evergreen/2011-07/%23evergreen.08-Fri-2011.log was when I thought I had the shortest meeting ever for the community meetings (back when we were doing those). The timestamps put it at14 minutes. So yes, that meeting I missed was shorter :) |
| 13:31 |
bshum |
gmcharlt: Apologies for missing things, I was stuck talking while retrieving my lunch :( |
| 13:32 |
|
vlewis joined #evergreen |
| 13:35 |
gmcharlt |
bshum: no worries |
| 13:39 |
kmlussier |
Ah. I do miss community meetings. |
| 13:40 |
|
kbutler joined #evergreen |
| 13:42 |
bshum |
kmlussier: Do you? Do you really? :) |
| 13:43 |
kmlussier |
I do. Every once in a while, I talk about scheduling them. But then I get distracted by something else. But I think it's good to bring the community together between conferences to talk about stuff. |
| 13:51 |
|
nhilton joined #evergreen |
| 14:18 |
|
edoceo joined #evergreen |
| 15:12 |
gmcharlt |
there will be a brief website outage in five minutes for security updates |
| 15:23 |
gmcharlt |
maintenance complete |
| 15:28 |
gmcharlt |
now performance similar maintenance on the git server |
| 15:33 |
gmcharlt |
maintenance complete |
| 15:37 |
jeff |
gmcharlt++ |
| 15:37 |
|
sarabee joined #evergreen |
| 15:39 |
jboyer-isl |
gmcharlt++ |
| 15:39 |
jboyer-isl |
security_bugs— |
| 15:39 |
jboyer-isl |
security_bugs-- |
| 15:40 |
jboyer-isl |
really, now. you autocorrect that, but not my spelling. |
| 15:42 |
kmlussier |
autocorrect-- |
| 15:44 |
gmcharlt |
the em-dashes are coming to take their rightful place! |
| 16:11 |
|
jwoodard joined #evergreen |
| 16:16 |
Bmagic |
can anyone think of a reason that the fine generator would ignore the grace period and go ahead and start applying fines at the due_date? Or do I have it wrong? When the action.circulation row is created, does the due_date include the grace? |
| 16:20 |
jboyer-isl |
Bmagic: due_date doesn’t include grace day, but I think if you keep an item past the grace period the fines are backdated until the due date. Are you seeing people with fines before the grace period is over? |
| 16:20 |
Bmagic |
jboyer-isl: that's it, the billing_ts date is NOT the real time when the fine generator applied the fine |
| 16:22 |
jboyer-isl |
I imagine the reasoning goes that it would be confusing if you had 2-3 billings for the same date, when 1-2 of them were actually for past dates. |
| 16:26 |
Bmagic |
joboyer-isl: understandable. In my development machine, I manually edited my circ to have a due_date of now(). then noticed that the fine generated, did in fact wait 15 minutes. When it finally fired, the date on billing_ts was equal to the circulation due_date+'1 hour' which is the checkout period duration |
| 16:28 |
Bmagic |
I found it strange that the billing_ts was not exactly equal to the due_date+grace period |
| 16:37 |
jboyer-isl |
Are grace periods actually multiples of the circ duration? So a grace period of 1 for a checkout of 1 hour, you only get a grace hour. does that match up with what you’re seeing? |
| 16:40 |
Bmagic |
jboyer-isl: it's 1 hour checkout, with 15 minutes grace, 2 dollars per hour over |
| 16:41 |
Bmagic |
jboyer-isl: so, the first fine will trigger at the 1 hour 15 minute mark, and it will set the billing_ts= due_date+duration (I think) at least that is what I saw in devel |
| 16:43 |
bshum |
Bmagic: billing_ts is the next time before a check occurs I think? Meaning wait till then before applying the next fine via the generator script. |
| 16:43 |
bshum |
Not the actual moment when the billing occurs |
| 16:43 |
Bmagic |
bshum: with that logic, then we don't know when the fine was applied from the DB columns |
| 16:43 |
bshum |
Bmagic: I believe that is correct. |
| 16:44 |
Bmagic |
bshum: It's exactly what I am seeing in practice |
| 16:44 |
bshum |
Yes, exactly |
| 16:44 |
* bshum |
had to relook at the table |
| 16:44 |
bshum |
billing_ts is only the time for the script to wait till applying the next fine |
| 16:45 |
bshum |
It doesn't specify when the billing is actually applied. |
| 16:49 |
|
mrpeters left #evergreen |
| 16:52 |
|
dMiller_ joined #evergreen |
| 16:57 |
* phasefx |
forgot he had mapped ils.org to git.evergreen-ils.org in his hosts file, so was pleasently surprised when a gmail butchered git link still worked when clicked |
| 17:10 |
Bmagic |
bshum: jboyer-isl: some interesting things have come from these queries. For example, I have a query that shows me everyones fines on transactions that were overdue. This query shows me that nobody received a fine inside of the grace period. However, those that did get a fine after the grace period received double SOMETIMES. I wonder.... |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
Bmagic |
due date= "2014-09-18 15:33:53-05" checkin time = "2014-09-18 16:00:13.952411-05" which means they were late by "00:26:20.952411" and they received 2 fines at 2 dollars each. The circulation is using a rule that says "2 dollars per hour". So why oh why did this xact get slapped with 2 hours worth of fees |
| 17:20 |
Bmagic |
The stop_fines_time = "2014-09-18 16:00:13.952411-05" and yet it received a fine dated "2014-09-18 17:33:53-05" |
| 18:13 |
|
dreuther joined #evergreen |
| 18:17 |
|
bmills joined #evergreen |
| 18:40 |
|
dbwells joined #evergreen |
| 21:50 |
|
BigRig joined #evergreen |
| 23:32 |
|
abowling left #evergreen |
