| Time |
Nick |
Message |
| 00:56 |
|
akilsdonk joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:02 |
|
edoceo joined #evergreen |
| 07:14 |
|
hopkinsju joined #evergreen |
| 07:15 |
|
jeff__ joined #evergreen |
| 07:20 |
|
b_bonner_ joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
akilsdonk joined #evergreen |
| 08:19 |
|
graced joined #evergreen |
| 08:20 |
|
ericar joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:33 |
|
kshitij joined #evergreen |
| 08:34 |
|
mrpeters joined #evergreen |
| 08:35 |
|
kshitij left #evergreen |
| 08:48 |
|
gmcharlt joined #evergreen |
| 09:01 |
|
maryj joined #evergreen |
| 09:05 |
|
abowling joined #evergreen |
| 09:08 |
|
julialima_ joined #evergreen |
| 09:09 |
|
mmorgan joined #evergreen |
| 09:13 |
|
sarabee joined #evergreen |
| 09:34 |
|
RoganH joined #evergreen |
| 09:41 |
|
ericar_ joined #evergreen |
| 10:02 |
bshum |
RoganH++ |
| 10:06 |
dbwells |
Good morning, all. Last Wednesday for the OPW project we talked a lot about buttons, today we want to talk at least a little about tables. |
| 10:07 |
dbwells |
Here is a mockup julialima_ has developed for us of some proposed style changes for client tables. It also shows (roughly) the same table in the current design for reference: http://www.calvin.edu/library/images/table_mockup.png |
| 10:11 |
|
yboston joined #evergreen |
| 10:11 |
dbwells |
We are certainly interested in overall reactions, but can also take some time to point out some of the differences once people have had a chance to look it over. |
| 10:19 |
dbwells |
It seems we are light on opinions this morning :) julialima_ and I will be around until 11:00am, but we'll also send this same concept to the list for discussion. |
| 10:19 |
* jeff |
grins |
| 10:21 |
jeff |
both the old and the new lack a "last page" button, which may simply be due to underlying bits -- say, the expense of calculating the last page, etc. |
| 10:21 |
jeff |
but the new has "Page 1/1" and still lacks a "last page" button. |
| 10:22 |
jeff |
anything intentional/noteworthy there, or am i reading too much into it? |
| 10:23 |
dbwells |
jeff: Yes, I think you're reading too much into it :) |
| 10:23 |
jeff |
I do like the removal of "total paid", but mostly because it can be confusing when the bulk of the "paid" is "Forgive" payments. :-) |
| 10:25 |
jeff |
But sorry, I forgot to state my overall reaction: looks like a nice improvement! |
| 10:26 |
dbwells |
Sorry, I know the tables aren't perfectly analogous, but that's really just chance. The project is focused on the style elements. |
| 10:26 |
mmorgan |
Do I see that "Actions" has turned into that "stack" in the upper right? |
| 10:27 |
jeff |
"hamburger menu" is the term I've seen most often, and that's started to see use around here. :-) |
| 10:27 |
dbwells |
mmorgan: yes, that is one concept we've been exploring. |
| 10:28 |
jeff |
dbwells: are the column picker and actions both under the hamburger menu? |
| 10:28 |
mmorgan |
That was my next question :) |
| 10:29 |
dbwells |
jeff: julialima_ might be able to answer that better, but that is how I understood it. It would be a submenu in there, I think. |
| 10:29 |
jeff |
(realizing that it's a mockup, and that neither are likely actually in existence under the hamburger...) |
| 10:32 |
julialima_ |
jeff and mmorgan: Yes, it will display the same options |
| 10:33 |
dbwells |
I think it is a sensible compromise, but maybe others would argue that column configuration is a first class action deserving it's own widget. |
| 10:34 |
jeff |
julialima_: thanks! |
| 10:34 |
julialima_ |
I even eliminate columns options, and perhaps would present in a separate popup. Of course it is debatable.https://raw.githubusercontent.com/JuliaLima/OPWInternship/master/tables-01.png |
| 10:34 |
jeff |
dbwells: That was my initial thought (regarding column-picker "demotion"), but perhaps that's just an argument for finding ways to make the need for the column picker less frequent. |
| 10:36 |
jeff |
(three ideas there would be: 1) reasonable defaults, 2) default->org->workstation/user prefs hierarchy/overrides/whatever 3) easier access to more columns for a given row) |
| 10:36 |
mmorgan |
IMO, column config is far less used than Actions, so having it tucked in the hamburger makes sense to me. |
| 10:37 |
dbwells |
julialima_'s second pic there doesn't actually show the actions yet, but they would be in there above the column stuff. |
| 10:38 |
gmcharlt |
jeff: one thing I'm doing in my own webstaff dev is actively picking reasonable default columns for tables |
| 10:38 |
gmcharlt |
but just to toss something out: if anybody wants to send me their (customized) column configurations, that's data I'm willing to look at |
| 10:39 |
jeff |
gmcharlt: yay! and the fact that work has been done to fix the old xul-client issue of "ahr columns are ahr columns, no matter the surrounding context" also has helped. |
| 10:40 |
jeff |
when viewing holds on a patron's account, you're far less likely to find the patron name a helpful bit of info, but seeing patron last/first/alias is helpful when viewing holdshelf at a library. |
| 10:40 |
jeff |
similar, very little reason to see the title/author on each hold when viewing holds on a title, but that info is relevant when looking at holds on a patron account or browsing the holdshelf. :-) |
| 10:41 |
gmcharlt |
Shut down the Department of Redudancy Department! |
| 10:42 |
jeff |
something else i find myself doing (and have no idea if it's something others do often) is adding a column when i'm interested in only a single additional field on a single row -- a faster way to see full details for a given row (some interfaces already have this) would avoid the column picker dance there also. |
| 10:42 |
* mmorgan |
agrees with jeff. Better defaults would be a huge improvement and make customization less of a requirement. As things are now, customization is essentially required. |
| 10:43 |
dbwells |
gmcharlt: Thanks for that offer. I really hope you get some responses, as that kind of feedback will make a huge difference in overall OOTB usability, in my opinion. |
| 10:43 |
dbwells |
It sounds like we are all of similar opinion :) |
| 10:43 |
* mmorgan |
would be willing to share tree_column files. How would gmcharlt like them shared? |
| 10:45 |
gmcharlt |
mmorgan: email is fine, or put up a zipfile on a public webserver and post the link |
| 10:45 |
mmorgan |
ok, will gather up some files. |
| 10:47 |
mmorgan |
Back to the navigation in the mockup - would anyone else prefer to see the forward/back last/first page arrows just to the left of the hamburger rather than where they are now? |
| 10:50 |
gmcharlt |
I'm neutral on that question |
| 10:51 |
gmcharlt |
I like the styling in general, but one thing that bothers me a bit is the potential for very common actions to end up hidden under the hamburger |
| 10:51 |
gmcharlt |
(as it were) |
| 10:52 |
dbwells |
gmcharlt: I agree. How do you feel about dedicated buttons in the title bar for the most common actions? |
| 10:53 |
gmcharlt |
dbwells: that seems reasonable; that, or an action bar below the title bar |
| 10:55 |
dbwells |
gmcharlt: that's a good idea and very useful feedback, thanks! |
| 10:56 |
mmorgan |
If individual actions turn into dedicated buttons, I'd favor the action bar concept rather than adding them to the title bar. |
| 10:57 |
mmorgan |
Maybe pie in the sky, but an option to expand the hamburger into an action bar? |
| 10:58 |
|
ericar_ joined #evergreen |
| 10:58 |
dbwells |
mmorgan: Yes, maybe pie in the sky, but still an excellent idea. |
| 10:59 |
gmcharlt |
that may be an achievable piece of pie (making no promises though), as each item on an action bar and/or the hamburger menu would still just be a menu item |
| 10:59 |
gmcharlt |
the common ones would just be decorated differently to indicate that they should get priority in the display |
| 10:59 |
dbwells |
I think the ideal style will allow for various levels of progressive expansion/compression based on interface need and user preference. |
| 11:00 |
dbwells |
That seems to be what we're describing, I think. |
| 11:01 |
dbwells |
The initial goal will need to be a middle ground of sorts, but with our eye still on that pie :) |
| 11:03 |
eeevil |
we do have an analog to the idea of an actions bar right now, actually. the billing history interface (IIRC) has buttons left-justified on the same row as the pagination and actions bar |
| 11:04 |
eeevil |
or, maybe the top-level billing interface? |
| 11:04 |
dbwells |
eeevil: Yes, I know what you are talking about. |
| 11:05 |
dbwells |
The billing interface in general has been our primary focus, as it is a rich set of screens with a lot of good ideas. |
| 11:05 |
eeevil |
anyway, we can move those elements around easily in the grid widget template. I think someone could come close to julialima_'s mockup today just by doing that much |
| 11:05 |
gmcharlt |
indeed |
| 11:06 |
eeevil |
(that someone is not me right this moment, though ... TUITS!) |
| 11:09 |
gmcharlt |
$a Tuits $x Dearth $y 2015 |
| 11:11 |
dbwells |
Well, it's past 11:00am so I need to retreat. Thanks all, once again, for the feedback. We're doing our best to identify and codify existing ideas, then trying to apply them to various places in the client and see what works most broadly. |
| 11:12 |
jeff |
julialima_++ dbwells++ |
| 11:13 |
mmorgan |
julialima_++ dbwells++ |
| 11:13 |
julialima_ |
Thank you all :) |
| 11:29 |
|
nhilton joined #evergreen |
| 11:48 |
|
bmills joined #evergreen |
| 12:07 |
|
vlewis joined #evergreen |
| 12:13 |
|
maryj joined #evergreen |
| 12:31 |
Dyrcona |
Head Up: I just ran the 0905 upgrade script and it ended with a rollback. Details to follow. |
| 12:33 |
Dyrcona |
ERROR: cannot ALTER TABLE "record_entry" because it |
| 12:33 |
Dyrcona |
has pending trigger events |
| 12:33 |
bshum |
Bleh |
| 12:33 |
Dyrcona |
I'll make a fix and post it to Launchpad. |
| 12:33 |
Dyrcona |
After lunch. |
| 12:34 |
bshum |
Dyrcona++ # thanks for testing that in your system. |
| 12:55 |
|
nhilton joined #evergreen |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:10 |
|
chatley_ joined #evergreen |
| 13:11 |
|
buzzy joined #evergreen |
| 13:18 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 13:18 |
pinesol_green |
[evergreen|Josh Stompro] LP#1390138: Another update for install/update docs - added make install - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0d739da> |
| 13:18 |
pinesol_green |
[evergreen|Josh Stompro] LP#1390138: Updating Upgrade and Install docs for 2.7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c7bd0b> |
| 13:18 |
pinesol_green |
[evergreen|Josh Stompro] LP#1390138: Updating Upgrade and Install docs for 2.7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b671b65> |
| 13:18 |
pinesol_green |
[evergreen|Ben Shum] LP#1390138: Remove references to Ubuntu Lucid Lynx 10.04 as this is not supported - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7331f82> |
| 13:18 |
pinesol_green |
[evergreen|Ben Shum] LP#1390138: Clarify 2.6-2.7 upgrade path - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1dc77fa> |
| 13:19 |
|
collum joined #evergreen |
| 13:19 |
bshum |
Stompro++ # I did some light rebasing to get things all squared away |
| 13:19 |
bshum |
But thanks for your contribution on getting us upgrade docs |
| 13:19 |
bshum |
For 2.7 |
| 13:20 |
bshum |
When the docs are rebuilt overnight (and we actually cut and release 2.7.3) I'll go ahead and update the downloads page on the main Evergreen site accordingly. |
| 13:23 |
|
jwoodard joined #evergreen |
| 13:27 |
|
maryj joined #evergreen |
| 13:27 |
|
nhilton joined #evergreen |
| 13:28 |
|
dMiller_ joined #evergreen |
| 13:41 |
|
mglass joined #evergreen |
| 13:46 |
|
bmills joined #evergreen |
| 13:48 |
pinesol_green |
[evergreen|Bill Erickson] LP#1261777 repair cloned addr owner link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f48b1bc> |
| 13:50 |
bshum |
Alrighty, that's that. Just waiting for Dyrcona's results from https://bugs.launchpad.net/evergreen/+bug/1418164 and then I think we're in ready shape to cut 2.7.3 today. |
| 13:50 |
pinesol_green |
Launchpad bug 1418164 in Evergreen "0905.schema.use_current_normalize_heading.sql fails with SQl Error" (affected: 1, heat: 6) [Undecided,New] |
| 13:58 |
kmlussier |
@dessert bshum |
| 13:58 |
* pinesol_green |
grabs some coffee frappes for bshum |
| 13:59 |
bshum |
Coffee? Bleh |
| 13:59 |
kmlussier |
Brrrrr...way too cold for coffee frappes. |
| 13:59 |
|
kbutler joined #evergreen |
| 13:59 |
kmlussier |
Even though I just had one a few nights ago. :) |
| 14:01 |
|
nhilton_ joined #evergreen |
| 14:02 |
|
graced joined #evergreen |
| 14:09 |
tsbere |
I invite others to decide how important this is: https://bugs.launchpad.net/evergreen/+bug/1418177 |
| 14:09 |
pinesol_green |
Launchpad bug 1418177 in Evergreen "Part Holds ignore boundaries after placement" (affected: 1, heat: 6) [Undecided,New] |
| 14:09 |
tsbere |
MVLC doesn't use boundaries, so I don't see it as that important. I just happened to run into it when looking for a solution to a different issue. |
| 14:09 |
|
nhilton joined #evergreen |
| 14:12 |
kmlussier |
I'm guessing it's important to those sites using boundaries. |
| 14:13 |
|
mrpeters left #evergreen |
| 14:15 |
tsbere |
kmlussier: At least I saw it as important enough to test and post to launchpad, right? |
| 14:27 |
|
krvmga joined #evergreen |
| 14:36 |
bshum |
Dyrcona++ |
| 14:38 |
|
mrpeters joined #evergreen |
| 14:40 |
bshum |
Okay, off to cut 2.7.3 |
| 14:41 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1418164: Fix 0905.schema.user_currnet_normalize_heading.sql. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c9ee432> |
| 14:45 |
Stompro |
bshum++, thanks for fixing up the upgrade docs and committing them. |
| 14:52 |
bshum |
dbwells: So I think that when we make the upgrade scripts for 2.7.3 and 2.6.5, it's a matter of moving the last bits of ALTER TABLE out of the transaction body. Kind of like how Dyrcona repaired 0905 in master. |
| 14:52 |
Dyrcona |
That feeling you get when you notice typos in your commit message when you read the commit email..... |
| 14:52 |
bshum |
Just something to watch out for, I haven't done that sort of editing for a version-upgrade script in a long time. |
| 14:53 |
dbwells |
bshum: If we're including a bigger reingest step anyway (full or metabib.reingest_metabib_field_entries style), we don't need that last chunk of 905 at all, I think. |
| 14:54 |
dbwells |
bshum: nevermind, this is authority stuff |
| 14:54 |
dbwells |
sorry |
| 14:54 |
Dyrcona |
dbwells: I think the triggers were dropped to speed things up, but I'm just guessing. |
| 14:55 |
dbwells |
Dyrcona: I am sure you are right. |
| 14:55 |
bshum |
dbwells: Ah right, I forgot about the reingest step. Should I just add verbiage for that at the end of the upgrade script? |
| 14:55 |
Dyrcona |
Problem is FK relationships are triggers, and you can't always drop those. |
| 14:59 |
dbwells |
Dyrcona: I think for similar problems in the past we've also had some success doing "SET CONSTRAINTS ALL IMMEDIATE;" in the transaction before altering the table; |
| 15:03 |
dbwells |
bshum: I'm planning to steal stuff from the bottom of the 2.5.0 upgrade script. Let me whip up a paste and see what you think. |
| 15:03 |
bshum |
dbwells: Sounds good. I'll finish editing my working branch and then manually tweak the tarball with the final changes for the upgrade scripts then. |
| 15:06 |
|
mrpeters left #evergreen |
| 15:08 |
bshum |
dbwells: Maybe more the variant at the end of the 2.6.0 script is better |
| 15:10 |
bshum |
Oh, funny, the 2.5 to 2.6.0 upgrade script does the same thing with the authority table triggers. |
| 15:10 |
bshum |
Puts them outside the COMMIT main transaction body |
| 15:10 |
bshum |
Guess we're repeating history there, heh |
| 15:10 |
bshum |
Again. |
| 15:10 |
dbwells |
bshum: Is metabib.reingest_metabib_field_entries not enough? I need to check to remember what exactly it does and doesn't do. |
| 15:11 |
bshum |
dbwells: I'm unsure. |
| 15:15 |
dbwells |
It's not the right piece. |
| 15:18 |
dbwells |
I think we need metabib.reingest_record_attributes() in this case. Let me see if I can test it out a bit. |
| 15:26 |
dbwells |
bshum: based on my testing, SELECT metabib.reingest_record_attributes(id); is sufficient for this situation. Paste forthcoming... |
| 15:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "Partial Reingest Addendum For Upgrade Script" (24 lines) at http://paste.evergreen-ils.org/30 |
| 15:35 |
Dyrcona |
Is there a test script floating around to see if Python is working correctly with Evergreen? |
| 15:35 |
Dyrcona |
I did --enable-python 'cause I eventually want to see if I can get constrictor working. |
| 15:35 |
bshum |
dbwells++ |
| 15:35 |
bshum |
I'll tack that on and get the tarball finished to push up to the website |
| 15:36 |
* Dyrcona |
decides to look at constrictor in the mean time. |
| 15:38 |
jeff |
Dyrcona: there's osrfsh.py -- that's a start. |
| 15:38 |
Dyrcona |
jeff: yeah. I just tried srfsh.py and that worked. |
| 15:39 |
jeff |
er, yeah. i was about to verify that filename but went with what came to mind first because i figured you'd get the point. :-) |
| 15:40 |
Dyrcona |
There's also opensrf.py for managing python services. |
| 15:41 |
Dyrcona |
It lists nothing available when I ask it, as I expect. |
| 15:42 |
Dyrcona |
I also found this: http://wiki.evergreen-ils.org/doku.php?id=opensrf:python |
| 15:45 |
dbs |
Dyrcona: I'm still using Python to do all of our LDAP auto-create users from LDAP stuff |
| 15:45 |
Dyrcona |
dbs: Cool. |
| 15:46 |
Dyrcona |
I assume the <plugins> entry goes inside the <srfsh> block in .srfsh.xml. |
| 15:46 |
Dyrcona |
Or, is that even necessary? |
| 15:48 |
dbs |
I don't use srfsh.py, sorry |
| 15:49 |
Dyrcona |
Well srfsh.py worked without the link or the configuration, so that's why I asked. |
| 15:49 |
Dyrcona |
I imagine that wiki page may be out of date. |
| 15:49 |
dbs |
That untrustworthy dbs guy wrote it 6 years ago, so maybe |
| 15:50 |
dbs |
And it looks... unfinished |
| 15:52 |
Dyrcona |
I assume that I could enable python on a utility server and run python scripts on that server against a production server without python enabled, and the python scripts would still work. |
| 15:52 |
dbs |
Yep |
| 15:52 |
Dyrcona |
Cool. |
| 15:53 |
|
vlewis_ joined #evergreen |
| 15:54 |
Dyrcona |
I was going to try Java again, too, but decided not to deal with that today. |
| 16:05 |
Dyrcona |
I would say that wiki page is out of date. |
| 16:05 |
Dyrcona |
Python packages get installed to /usr/local/lib/python2.7/dist-packages/ or equivalent these days. |
| 16:07 |
bshum |
Okay, 2.7.3 is up |
| 16:07 |
bshum |
Tomorrow after the docs server updates, I'll add the link to the upgrades chapter too. |
| 16:07 |
Dyrcona |
bshum++ |
| 16:13 |
pinesol_green |
[evergreen|Ben Shum] Forward-port 2.7.2-2.7.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ef6f4b> |
| 16:13 |
bshum |
After the whole tagging in OpenSRF experience, going back to these fake tags and branches feels more annoying :) |
| 16:14 |
bshum |
Just saying. |
| 16:15 |
|
jboyer-isl joined #evergreen |
| 16:16 |
gmcharlt |
bshum++ # tilting at those hashtag windmills |
| 16:16 |
bshum |
Bring back evgils I say. I'm tired of all these unrelated tweets :( |
| 16:24 |
Dyrcona |
@love git tag |
| 16:24 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona loves git tag. |
| 16:24 |
jboyer-isl |
#evergreenopensourceintegratedlibrarysystem - still leaves 116 characters. |
| 16:24 |
* Dyrcona |
has visions of guis writting in PyQT, linking to PyUNO to produce odt and ods documents. |
| 16:25 |
Dyrcona |
"Writting? Really, fingers?" |
| 16:27 |
bshum |
Heh |
| 16:58 |
kmlussier |
Have a nice night #evergreen! |
| 16:59 |
kmlussier |
And +1 to evgils. I'm also tired of those beer drinkers and e-girls hiijacking our hashtag. :) |
| 17:18 |
|
mmorgan left #evergreen |
| 17:28 |
|
mdriscoll left #evergreen |
| 17:36 |
* berick |
wonders if anyone is going to be sticking around in Hood River Saturday evening after the conference. |
| 18:34 |
bshum |
berick: We will be. |
| 18:34 |
bshum |
"We" being a contingent from Biblio |
| 18:35 |
bshum |
Easier to fly home early Sunday morning. |
| 18:35 |
bshum |
Otherwise getting back east tends to suck |
| 18:59 |
eeevil |
berick: so, I'm getting doubled pcrud commits from .update() in the pcrud.js ng service ... thoughts? |
| 20:25 |
|
bmills joined #evergreen |
| 22:14 |
|
bmills joined #evergreen |
| 23:13 |
|
nhilton joined #evergreen |
