| Time |
Nick |
Message |
| 00:18 |
|
DPearl1 joined #evergreen |
| 00:23 |
|
atlas__ joined #evergreen |
| 00:39 |
|
atlas__ joined #evergreen |
| 00:50 |
|
atlas___ joined #evergreen |
| 00:53 |
|
AliceR joined #evergreen |
| 00:55 |
|
atlas__ joined #evergreen |
| 05:33 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:23 |
|
b_bonner joined #evergreen |
| 07:23 |
|
mnsri_ joined #evergreen |
| 07:24 |
|
mtcarlson_away joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:23 |
|
akilsdonk joined #evergreen |
| 08:25 |
|
tspindler joined #evergreen |
| 08:56 |
|
Shae joined #evergreen |
| 09:08 |
|
mrpeters joined #evergreen |
| 09:15 |
|
krvmga joined #evergreen |
| 09:31 |
|
RoganH joined #evergreen |
| 09:34 |
|
ericar joined #evergreen |
| 09:39 |
|
sarabee joined #evergreen |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:54 |
kmlussier |
Good morning #evergreen! |
| 10:02 |
bshum |
Oh man, I remember https://bugs.launchpad.net/bugs/1018011 |
| 10:02 |
pinesol_green |
Launchpad bug 1018011 in Evergreen "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 5, heat: 24) [Medium,Confirmed] |
| 10:02 |
bshum |
It's the reason we're still only doing reshelving once nightly now. |
| 10:02 |
bshum |
That's an old one |
| 10:02 |
|
atlas__ joined #evergreen |
| 10:04 |
RoganH |
I have a solution. Abandon technology, go back to cards in the back of books. :) |
| 10:17 |
Bmagic |
haha |
| 10:17 |
bshum |
RoganH: I remember going to start library school because I "hated computers" and wanted to "work with books" |
| 10:18 |
bshum |
So there are days :D |
| 10:19 |
Bmagic |
bshum: looking at the reshelving code, I see that it's a simple update query. The pg planner selects all of the affected rows and then goes through them. When the select returns tons, the loop can take many seconds if not minutes, durning that time, one of the selected items could be checked out |
| 10:20 |
Bmagic |
bshum: I was thinking that the solution could be simple: perform the select in perl limit 1, update, select the next one. Instead of letting the DB do it |
| 10:21 |
dbs |
< berick> kmlussier: i've been using this one lately, which is my script, but fully automated: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
| 10:21 |
kmlussier |
dbs: Thanks! I added the link to the OPW page yesterday. I think. |
| 10:22 |
berick |
yeah, that's the one I told kmlussier to use |
| 10:22 |
berick |
'tis the easiest |
| 10:27 |
dbs |
Heh, sorry, accidental paste |
| 10:27 |
dbs |
berick: does that set up websockets et al for webby dev too? |
| 10:28 |
* dbs |
still isn't used to the integrated button/clickpad on new thinkpads :/ |
| 10:28 |
berick |
dbs: not yet |
| 10:29 |
|
StephenGWills joined #evergreen |
| 10:41 |
|
mllewellyn joined #evergreen |
| 11:00 |
bshum |
dbwells: In the past, did you just copy the version-upgrade scripts into the necessary branches to make point releases? |
| 11:00 |
bshum |
I'm thinking through the process. Probably won't get to it till much, much later though. |
| 11:02 |
bshum |
For 2.7.1, I think I need to grab the 2.6-2.7.0 script into rel_2_7 and then issue a new make_release to get 2.7.0-2.7.1 |
| 11:02 |
eeevil |
Bmagic: it's not quite so simple as moving the reshelving outside the db. it would use orders of magnitude more CPU (and ram and network bandwidth), and take longer still. but, unless there are literal robots scooting around the library reshelving items the moment they are checked in, I'm not sure that there's really a point in running reshelving more than once in a 24 hour period |
| 11:03 |
Bmagic |
eeevil: so the solution is to run the reshelver during a "less active time" (at night) ? |
| 11:03 |
bshum |
berick: I think you mentioned something about the web client and make_release last time. Some flag I need to use to compile it so that it's part of the generated tarball? |
| 11:04 |
berick |
bshum: yeah, it's in the LP. lemme find it.. |
| 11:05 |
eeevil |
Bmagic: yes. it was always meant to be an off-hours batch process. running it constantly was not what it was designed for. but still, do you have a situation where books are really reshelved constantly and immediately throughout the day? that's the real question |
| 11:05 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1350350 |
| 11:05 |
pinesol_green |
Launchpad bug 1350350 in Evergreen "browser client build/install process improvements" (affected: 1, heat: 8) [Undecided,New] |
| 11:05 |
eeevil |
because, if so, then a development-based solution might be warranted. but, if not, then ... probably not |
| 11:06 |
berick |
bshum: -c, but you also need to do the 4 additional steps in advance (if you haven't already) |
| 11:07 |
kmlussier |
eeevil: We have lots of libraries, particularly our smaller ones, that reshelve books very quickly. |
| 11:07 |
bshum |
berick++ # thanks! I'll poke at it some and see where it leads me. |
| 11:08 |
eeevil |
kmlussier: like a "more pages than patrons" situation? ;) [reads back ... actually not trying to be snarky there... sorry if it sounds like that] |
| 11:09 |
eeevil |
kmlussier: so, in those cases, does it cause a lot of wasted time for patrons or staff when the item status isn't flipped quickly? |
| 11:09 |
kmlussier |
eeevil: No, it didn't sound snarky at all. |
| 11:10 |
hopkinsju |
Without a formal survey I can't say, but in our implementation discussions and through working help desk issues I'm pretty sure that many, many of our libraries do reshelving throughout the day. |
| 11:10 |
kmlussier |
tspindler may have more details, but I know there are some libraries (maybe just a few) that prefer not to have a reshelving status at all. I don't know if it causes wasted time, but maybe a bit of confusion? |
| 11:10 |
bshum |
Do I check the cart or the shelf? Or the book drop? Or the back room? |
| 11:11 |
hopkinsju |
I wouldn't think they had books reshelved in less than (and again, I'm just guessing here) 2 hours, but I think many of our libraries would complain if their books weren't available for 24 hours. |
| 11:11 |
kmlussier |
If it's in the book drop, I don't imagine it would have been scanned and put into reshelving yet. ;) |
| 11:11 |
eeevil |
bshum: I'd always check the shelf first, but I understand what you mean. my point is, does it /actually/ cause a problem, as opposed to /could/ it (because, yes, it certainly /could/) |
| 11:12 |
bshum |
kmlussier: well, maybe not if there's automated material handlers involved. |
| 11:12 |
bshum |
But I digress. |
| 11:12 |
eeevil |
hopkinsju: the reshelving status is the moral equiv of "Available" ... there is no functional difference between them for, say, filtering in the opac or hold targetting |
| 11:13 |
eeevil |
hopkinsju: so, the items /are/ "Available", they just say "but you might have to check the cart if it's not on the shelf" |
| 11:13 |
tsbere |
I suppose if you don't want it to say "Reshelving" you could just go edit the label to say "Available". Then you get two numeric statuses with the same label. :P |
| 11:13 |
bshum |
Fwiw, we changed the name of that status to "Recently returned" and then generally promised 24 hour turnover to make them "available" |
| 11:13 |
eeevil |
tsbere: indeed. some have done that, I think |
| 11:14 |
hopkinsju |
eeevil: From my perspective I do agree, but the libraries may not. Having said what I just did - I think a full half our libraries do not have a setting for reshelving interval and so are already on the 24h cycle. |
| 11:14 |
bshum |
So I often feel it's a matter of interpretation. |
| 11:14 |
hopkinsju |
I agree bshum |
| 11:15 |
eeevil |
hopkinsju: what I mean is, the label is the only difference. they can disagree with the label, but they can't disagree with the functional fact -- it's the same other than the label |
| 11:15 |
eeevil |
and, as tsbere mentioned, they can change the label, certainly |
| 11:16 |
hopkinsju |
eeevil: I completely agree with you that functionally the item is available. I think the question that the status helps answer is "should I bother going to check the shelves for this item?" |
| 11:17 |
hopkinsju |
And I also agree that a label change may be the easiest solution. We will have to pitch the options to our libraries I think. |
| 11:17 |
eeevil |
but(!), I can imagine a few things that don't try to misuse the existing code (because, see: LP bugs ... ;) ) and would help in these situations |
| 11:17 |
eeevil |
1) A/T reactor to flip the status. that's basically a bite-size bug for anyone familiar with A/T |
| 11:17 |
hopkinsju |
"Reshelving" says to me "It's not on the shelf" whereas "Recently returned" says "Maybe check the shelf?" |
| 11:18 |
jeff |
unless you're going to have pages scan books at the point in time when they are placed on the shelf, you're going to need to approximate the phase between those two states. |
| 11:18 |
bshum |
Plausible denial. "I have no recollection, Senator." |
| 11:18 |
eeevil |
2) a cron'd process that uses MultiSession to implement a map-reduce status-flipper that targets specific libraries (which is exactly what A/T does, but you could skip the overhead of the A/T events infrastructure if you want to write more new code) |
| 11:19 |
kmlussier |
I guess my question is why bother having the OU setting to set a reshelving interval if most Evergreen sites are going to need to fall back on the 24-hour reshelving interval anyway? |
| 11:19 |
hopkinsju |
kmlussier++ |
| 11:19 |
hopkinsju |
kmlussier: Maybe someone thought there weren't enough settings? |
| 11:19 |
kmlussier |
It's like a carrot that gets dangled in front of a new Evergreen site and then gets snatched away. |
| 11:19 |
eeevil |
kmlussier: the intent of the setting was to allow /longer/ reshelving times |
| 11:19 |
eeevil |
not short :) |
| 11:19 |
hopkinsju |
haha |
| 11:20 |
kmlussier |
eeevil: Heh. I didn't realize there were libraries that took longer than 24 horus to reshelve. :D |
| 11:20 |
eeevil |
many moons ago, some PINES libraries would reshelve on Mon/Wed/Fri |
| 11:20 |
eeevil |
or, they were only open a few days a week |
| 11:20 |
eeevil |
(think: st. simon's island) |
| 11:21 |
eeevil |
and they reshelved weekly or so |
| 11:21 |
jeff |
when open, books go from "checked in" to "back on the shelf" pretty quickly at most/all of our locations. i know other libraries that is not the case for reasons unknown to me. we had a library once talk about how they reduced time from checkin to shelf to "only two days". |
| 11:21 |
jeff |
so yes, some libraries take >24h to reshelve |
| 11:21 |
kmlussier |
Maybe the description for the setting should say "2 days" "1 week" instead of "1 day" "6 hours." |
| 11:21 |
eeevil |
anyway. there was a method to the madness. and the batch reshelver is not a good tool for mid-day flipping. so, if we need mid-day, we need something new |
| 11:25 |
kmlussier |
eeevil: Thanks for the background on the setting. It's helpful. |
| 11:25 |
eeevil |
good! :) (and I agree on the description change) |
| 11:26 |
|
vlewis joined #evergreen |
| 11:28 |
tsbere |
Looking at the reshelving complete code, I think the "fix" for allowing it to run mid-day and not screw things up may actually be a single line of code. <_< Not sure how to *test* it though. |
| 11:29 |
hopkinsju |
tsbere: Can you put your idea into a paste? We may be able to help test it. |
| 11:31 |
tsbere |
hopkinsju: I was thinking just drop it into a working branch you could cherry-pick from. |
| 11:31 |
tsbere |
(and attaching said branch to the launchpad bug) |
| 11:32 |
Bmagic |
tsbere: sounds good to me |
| 11:33 |
hopkinsju |
Great! tsbere++ |
| 11:34 |
hopkinsju |
eeevil++ |
| 11:37 |
tsbere |
Bmagic/hopkinsju/anyone else that cares: https://bugs.launchpad.net/evergreen/+bug/1018011/comments/5 |
| 11:37 |
pinesol_green |
Launchpad bug 1018011 in Evergreen "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 5, heat: 24) [Medium,Confirmed] |
| 11:38 |
Bmagic |
tsbere: aha! that does seem like it could work |
| 11:39 |
Bmagic |
making the update statement check the status upon update |
| 11:39 |
|
sandbergja joined #evergreen |
| 11:41 |
eeevil |
transaction isolation would have to be increased to serializable for that to be The(tm) fix. but, depending on the plan generated, it's possible it could make the error less likely to happen |
| 11:41 |
eeevil |
certainly worth a try for folks hitting the issue a lot |
| 11:42 |
eeevil |
but, beware, in the case where it "fixes" things, it will very likely also lengthen the time write-locks are held on specific copies |
| 11:43 |
tsbere |
eeevil: I am not entirely sure it will make things lock longer, but I could be wrong. The majority of the "wait" time on that script appears to be the subselect, and I didn't make that a "FOR UPDATE" select that creates locks. Once the select returns the updates themselves are going to lock either way... |
| 11:44 |
tsbere |
(and said lack of locking on the subselect is one reason why the problem exists, I think) |
| 11:47 |
eeevil |
tsbere: the subselect can be run as a nested loop, with updates happening during the whole time. If Pg thinks that it will not be Abe to filter many rows with the new clause, then exactly that may happen. All depends on stats and settings |
| 11:48 |
eeevil |
Able. Autocorrect... |
| 11:50 |
* tsbere |
watched locks with and without the status = 7 checks and didn't see any noticable difference in them, but didn't exactly do an overly complete job of watching either and wasn't on a production-level system data-wise |
| 11:51 |
dbwells |
bshum: I would typically branch rel_2_x_x from rel_2_x, do the release stuff, then forward-port the upgrade file back to rel_2_x and master (eventually). Then all the scripts are already in rel_2_x for the next point release. Does that answer your question? |
| 11:53 |
eeevil |
My bigger point is that the current reshelver has an intended purpose, and IMO we should consider that when looking for a solution that is outside that original intent. I'm 100% for code reuse, but I think this might be stretching it, in this specific case... But, testing will tell |
| 11:55 |
tsbere |
eeevil: I am all for "new code for the new intent" or even "more efficient/targeted code for this intent" (only doing short-term reshelving when open, for example) - I am also all for calling it a bug that the reshelving complete code can, regardless of when or how often it is run, change the status of something *not* in reshelving at update time. |
| 12:04 |
|
sal_ joined #evergreen |
| 12:05 |
eeevil |
fair enough. in practice, of course, it /only/ happens during open hours, but yes, it's a fair point |
| 12:11 |
|
sandbergja joined #evergreen |
| 12:24 |
|
nhilton joined #evergreen |
| 12:32 |
yboston |
hopkinsju+++ for offering to host sandboxes |
| 12:33 |
hopkinsju |
Glad to be a part of something so successful! |
| 12:47 |
|
AliceR joined #evergreen |
| 13:01 |
gmcharlt |
Evergreen web team meeting starting... NOW! |
| 13:01 |
gmcharlt |
#startmeeting Evergreen web team meeting, 15 October 2014 |
| 13:01 |
pinesol_green |
Meeting started Wed Oct 15 13:01:16 2014 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 13:01 |
pinesol_green |
The meeting name has been set to 'evergreen_web_team_meeting__15_october_2014' |
| 13:01 |
gmcharlt |
#info Agenda is http://wiki.evergreen-ils.org/doku.php?id=webteam:meetings:agenda:2014-10-15 |
| 13:01 |
gmcharlt |
#topic Introductions |
| 13:01 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:01 |
gmcharlt |
#info Galen Charlton, ESI |
| 13:02 |
RoganH |
#info Rogan Hamby, SCLENDS |
| 13:02 |
kmlussier |
Could be a quiet meeting |
| 13:02 |
gmcharlt |
bshum sent his apologies |
| 13:03 |
gmcharlt |
#topic Action Items From Previous meetings |
| 13:03 |
gmcharlt |
I think it's been a quiet past couple months, but to go them... |
| 13:03 |
|
mjingle joined #evergreen |
| 13:03 |
gmcharlt |
kmlussier: any news on gather pages from previous conferences? |
| 13:04 |
kmlussier |
I've got nothing |
| 13:05 |
kmlussier |
Sorry, I promise I'll try for next month. |
| 13:05 |
gmcharlt |
no problem |
| 13:05 |
gmcharlt |
#action (carry-over) kmlussier to create pages with handouts, schedule, logo etc. from the previous conference (as material is/becomes available) |
| 13:06 |
gmcharlt |
#info The WP Job Manager plugin is now available on the main website |
| 13:07 |
kmlussier |
gmcharlt++ |
| 13:07 |
gmcharlt |
at the moment, the submission form is available at http://evergreen-ils.org/post-a-job/ |
| 13:07 |
RoganH |
gmcharlt++ |
| 13:07 |
kmlussier |
gmcharlt: Where will the listing show up? |
| 13:07 |
gmcharlt |
RoganH: I recalled that we discussed this the other day... do you want to put it through its paces a bit before we make an announcement? |
| 13:08 |
RoganH |
Yeah, let me play with it for a couple of days. |
| 13:08 |
gmcharlt |
kmlussier: very creatively... http://evergreen-ils.org/jobs/ |
| 13:08 |
RoganH |
I'll do some test posts, deletions, etc... |
| 13:08 |
gmcharlt |
RoganH: it also exposes a jobs dashboard |
| 13:08 |
gmcharlt |
http://evergreen-ils.org/job-dashboard/ |
| 13:08 |
kmlussier |
When you've run it through its paces, I would like to share the link with OPW. As OPW sponsors, I think we get a benefit of having our jobs page listed on their site. |
| 13:08 |
gmcharlt |
great |
| 13:10 |
gmcharlt |
RoganH: and there are also settings available via the admin interface |
| 13:10 |
RoganH |
gmcharlt: I'm looking at those now. |
| 13:10 |
gmcharlt |
ok, so one of the related action items was putting out a call for somebody to curate the job listsings |
| 13:11 |
RoganH |
I had offered to do that last time. |
| 13:11 |
RoganH |
I think the action item got made before I chimed in. |
| 13:11 |
gmcharlt |
ah, OK |
| 13:11 |
kmlussier |
Yes, I was just looking at the log. RoganH is correct. |
| 13:11 |
gmcharlt |
then accept this shiny new ball |
| 13:11 |
RoganH |
shiny ball received |
| 13:11 |
gmcharlt |
RoganH++ |
| 13:12 |
kmlussier |
RoganH++ |
| 13:12 |
gmcharlt |
so, noting a couple action items for myself |
| 13:12 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate/assist with dbs to move the planet |
| 13:12 |
gmcharlt |
#action gmcharlt with work with DIG to get a test VM for doc-building set up |
| 13:13 |
kmlussier |
gmcharlt++ |
| 13:13 |
RoganH |
gmcharlt++ |
| 13:13 |
gmcharlt |
next up, the FAQs... |
| 13:13 |
gmcharlt |
phasefx: anything to report? |
| 13:15 |
gmcharlt |
#action gmcharlt will ping phasefx about the FAQs |
| 13:15 |
|
sal_ joined #evergreen |
| 13:15 |
gmcharlt |
#action (carry-over) gdunbar will proceed with the redesign of the downloads page |
| 13:15 |
kmlussier |
Does graced need help with that? |
| 13:16 |
gmcharlt |
if you're offerring ... you know where to find her ;) |
| 13:16 |
|
AliceR joined #evergreen |
| 13:16 |
gmcharlt |
also, tuits are tight at the moment |
| 13:16 |
kmlussier |
I'm offering and will follow up with Grace. |
| 13:16 |
gmcharlt |
kmlussier++ |
| 13:17 |
gmcharlt |
#action gmcharlt will follow up with ericar re libraries roster and LP instructions page |
| 13:18 |
gmcharlt |
#info Child theme is in place |
| 13:18 |
gmcharlt |
#action gmcharlt will tweak the "learn more" buttons shortly |
| 13:18 |
gmcharlt |
and bshum mentioned that he has some tweaks he wants to do |
| 13:19 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate with the EOB regarding the trademark policy page |
| 13:19 |
gmcharlt |
and, I believe that covers all of the past action items |
| 13:19 |
gmcharlt |
#topic New business |
| 13:20 |
gmcharlt |
so, now that EG2015 is confirmed, I'll ping Buzzy again about starting the conference web pages |
| 13:20 |
kmlussier |
gmcharlt: I'll be working with the conference team on their web site too. |
| 13:21 |
gmcharlt |
great |
| 13:21 |
gmcharlt |
and to clarify, planning of EG2015 is still in progress |
| 13:22 |
gmcharlt |
RoganH: kmlussier: any other new business to bring up? |
| 13:23 |
RoganH |
Not really. At some point I'd like to revisit the Evergreen location listing pages and do some new things with it but I don't have the bandwidth right now. |
| 13:23 |
kmlussier |
I sent an e-mail last month about my revised Getting Started page. |
| 13:24 |
RoganH |
kmlussier: I thought it looked good. |
| 13:24 |
|
julialima joined #evergreen |
| 13:24 |
kmlussier |
So if it looks good to everyone else, I could use it to replace the current Getting Started page. I just haven't had the tuits yet. |
| 13:25 |
kmlussier |
I think RoganH was the only person who gave feedback. |
| 13:25 |
kmlussier |
There are also a couple of other items I would like to add, but they're not necessary before making the page live. |
| 13:25 |
gmcharlt |
kmlussier: +1 to your going for it when you get the time |
| 13:25 |
|
kitteh_ joined #evergreen |
| 13:25 |
RoganH |
+1 |
| 13:26 |
gmcharlt |
#action kmlussier will apply the updates she's suggested to the Getting Started page |
| 13:27 |
kmlussier |
Actually, Getting Involved page. Sorry, I'm a little distracted today. http://evergreen-ils.org/involvement/ |
| 13:27 |
gmcharlt |
no problems |
| 13:30 |
gmcharlt |
OK, looking at the website tasks spreadsheet, I think we've mostly discussed all of the current ones |
| 13:30 |
gmcharlt |
bshum is still poking at the IRC logs |
| 13:31 |
gmcharlt |
any other topics to discuss today? |
| 13:32 |
RoganH |
Nope, not from me. |
| 13:32 |
kmlussier |
Nothing from me. |
| 13:32 |
gmcharlt |
OK, thanks everybody! |
| 13:32 |
gmcharlt |
#endmeeting |
| 13:32 |
pinesol_green |
Meeting ended Wed Oct 15 13:32:51 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 13:32 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-10-15-13.01.html |
| 13:32 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-10-15-13.01.txt |
| 13:32 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-10-15-13.01.log.html |
| 13:35 |
kmlussier |
gmcharlt / RoganH: How does the "Get Involved" menu look now? I put a bunch of the links that previously displayed there as a submenu under communications. |
| 13:37 |
RoganH |
kmlussier: like the mailing list and irc links? |
| 13:37 |
kmlussier |
Yes, exactly. If it was something that the communications page links to, then I put it under communications rather than having them all stay at the same level. |
| 13:38 |
RoganH |
For me they're acting as popups when I mouse over the drop down option. |
| 13:38 |
RoganH |
I think it's convenient. |
| 13:45 |
kmlussier |
RoganH: Yes, that's what it's doing for me too. Anyway, I'm happy to change it back to the old way if people don't find it convenient, but it made sense to me when I was moving "Communicate" down from being the main landing page. |
| 13:52 |
|
jihpringle joined #evergreen |
| 13:53 |
gmcharlt |
kmlussier: looks good to me |
| 13:53 |
kmlussier |
Well, then, it sounds like a unanimous vote of approval from today's web team. :) |
| 14:01 |
|
StephenGWills left #evergreen |
| 14:03 |
|
nhilton_ joined #evergreen |
| 14:35 |
|
mjingle joined #evergreen |
| 14:48 |
|
Sato joined #evergreen |
| 14:52 |
|
mrpeters1 joined #evergreen |
| 14:53 |
|
ningalls joined #evergreen |
| 14:55 |
|
Callender_ joined #evergreen |
| 14:56 |
|
Shae joined #evergreen |
| 14:56 |
|
ningalls1 joined #evergreen |
| 14:57 |
|
jeff__ joined #evergreen |
| 14:59 |
|
pastebot joined #evergreen |
| 14:59 |
|
mllewellyn joined #evergreen |
| 14:59 |
|
artunit joined #evergreen |
| 15:01 |
|
nhilton joined #evergreen |
| 15:03 |
|
pmurray joined #evergreen |
| 15:03 |
|
pmurray joined #evergreen |
| 15:19 |
gsams |
kmlussier: From an outside perspective, I'm really liking the direction the web team has taken the site. In case you wanted some outside input. |
| 15:20 |
gsams |
seeing where it came from and looking at it today, I really appreciate the effort that was put into it. |
| 15:20 |
kmlussier |
gsams: Thanks! Most of the credit goes to gmcharlt and bshum. :) |
| 15:21 |
gsams |
gmcharly++ |
| 15:21 |
gsams |
bshum++ |
| 15:21 |
gsams |
kmlussier++ |
| 15:21 |
gsams |
lol |
| 15:21 |
gmcharlt |
I was going to say most of the credit belongs to bshum and kmlussier |
| 15:21 |
|
mjingle joined #evergreen |
| 15:21 |
gsams |
gmcharlt++ |
| 15:21 |
kmlussier |
I like gmcharly. gmcharlt - you should change your nick. :) |
| 15:23 |
gmcharlt |
heh |
| 15:27 |
jeff |
in some default irc client configurations, gm<tab> completes to Good Morning |
| 15:28 |
jeff |
so for a period of time i would address gmcharlt by typing gm<tab>^W^Wgmc<tab>, which is still one keystroke less than just typing "gmcharlt: " |
| 15:29 |
* kmlussier |
chuckles |
| 15:32 |
csharp |
good morning good morning good morning-uh |
| 15:33 |
|
kmlussier left #evergreen |
| 15:33 |
|
kmlussier joined #evergreen |
| 15:36 |
Bmagic |
lol |
| 15:44 |
|
atlas__ joined #evergreen |
| 16:01 |
|
nhilton joined #evergreen |
| 16:17 |
|
jwoodard joined #evergreen |
| 16:31 |
|
tspindler left #evergreen |
| 16:34 |
kmlussier |
berick: I like the way you sometimes utilized line numbers in the web client to provide a one-click way to access a patron record or more details on a bill. A nice little usability/workflow improvmenet. |
| 16:40 |
berick |
kmlussier: oh, good. when a grid has those links, the same action is accessible via dbl-click |
| 16:41 |
kmlussier |
Nice! |
| 16:41 |
jeff |
berick++ |
| 16:42 |
berick |
it's baked in to the grid, so we add those anywhere it makes sense to. |
| 16:43 |
berick |
@later tell julialima sorry I missed you earlier. feel free to ask questions in #evergreen, too. lots of people around can help. |
| 16:43 |
pinesol_green |
berick: The operation succeeded. |
| 16:44 |
kmlussier |
I was thinking item status might be another good place to add it as we continue to tweak the web client. If you're in list view, it would bring you to the detail view of the item. |
| 16:44 |
berick |
yeah, that seems like a clear win |
| 16:44 |
jeff |
some things don't seem to load as i would expect if i open a new tab and paste the url. one example: https://webby.evergreencatalog.com/eg/staff/circ/patron/1463/bill/1259 |
| 16:45 |
jeff |
hrm. worked on second attempt. |
| 16:45 |
berick |
hep |
| 16:45 |
berick |
er, yep |
| 16:45 |
kmlussier |
jeff: I've found that it works on refresh. |
| 16:45 |
kmlussier |
I was curious as to why it doesn't load on the first try. |
| 16:45 |
berick |
i noticed that happening when prepping for my SEREC talk |
| 16:45 |
berick |
i have a (vague) hunch that it's somehow related to using the compressed JS, since that never happened to me befure |
| 16:45 |
berick |
before |
| 16:46 |
berick |
somehow causing a timing issue |
| 16:47 |
kmlussier |
I know we were aiming for feature parity here, but I wouldn't have been heartbroken if the "Transfer All Title Holds" had been "overlooked" in the move to the web client. :) |
| 16:47 |
* berick |
recalls a recent conversation about that |
| 16:47 |
kmlussier |
Yup. http://markmail.org/message/jsrbhxlwr2dshglv |
| 16:49 |
|
nhilton_ joined #evergreen |
| 16:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1261486 Action/trigger aggregator script repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7c3267> |
| 17:03 |
|
kmlussier left #evergreen |
| 17:04 |
|
kmlussier joined #evergreen |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:45 |
gmcharlt |
dokuwiki updated to current stable version |
| 19:10 |
|
maggieWCL joined #evergreen |
| 19:13 |
|
kmlussier joined #evergreen |
| 19:16 |
|
maggieWCL joined #evergreen |
| 20:15 |
|
atlas__ joined #evergreen |
| 21:56 |
|
hbrennan joined #evergreen |
| 22:37 |
|
akilsdonk joined #evergreen |
| 22:47 |
|
artunit joined #evergreen |
| 23:28 |
jeff |
gmcharlt++ |
| 23:29 |
bshum |
gmcharlt++ |
| 23:37 |
|
akilsdonk joined #evergreen |
| 23:58 |
|
AliceR joined #evergreen |
