Evergreen ILS Website

IRC log for #evergreen, 2019-06-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:32 jamesrf joined #evergreen
03:23 jamesrf joined #evergreen
03:43 jamesrf joined #evergreen
03:56 timo75 joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
05:28 jamesrf joined #evergreen
06:14 JasonEDN joined #evergreen
07:11 rjackson_isl joined #evergreen
07:22 agoben joined #evergreen
07:33 jamesrf joined #evergreen
07:34 JasonEDN1 joined #evergreen
07:58 JasonEDN joined #evergreen
08:04 JasonEDN1 joined #evergreen
08:17 bos20k joined #evergreen
08:49 mmorgan joined #evergreen
08:56 tlittle joined #evergreen
08:58 Christineb joined #evergreen
09:13 yar joined #evergreen
09:18 Dyrcona joined #evergreen
09:22 yboston joined #evergreen
09:40 bos20k Hello.  Working with a 3.1.11 database, when I do this - UPDATE actor.org_unit_setting SET value = '^.{12}' WHERE id = 965;
09:40 bos20k I get this - ERROR:  new row for relation "org_unit_setting" violates check constraint "aous_must_be_json"
09:40 bos20k DETAIL:  Failing row contains (965, 1, global.password_regex, ^.{12}).
09:40 Dyrcona bos20k: Put double quotes inside your single quotes.
09:41 Dyrcona A JSON string is always quoted.
09:41 bos20k Will try.  Thanks.
09:42 Dyrcona I'm also pretty sure that setting value will bite you if it is what I think it is.
09:42 bos20k Looking to try minimum password length of 12 in a test system.
09:42 Dyrcona That's not minimum, that's exactly 12, IIRC.
09:43 Dyrcona And, it's not the setting I thought it was. :)
09:43 Dyrcona I should have paid more attention to the DETAIL line... :)
09:44 Dyrcona If you want minimum of 12, add a comma after the 12 inside the braces.
09:44 Dyrcona "^.{12,}"
09:45 bos20k Hmmm.  You seem to be right as to how the regex is interpreted.  My reading of the regex is that it needs to start with at least twelve characters.  This same regex works elsewhere to require strings of at least twelve characters.
09:45 Dyrcona Though, I guess it would still work since there's no terminal anchor.
09:45 bos20k I'll try the comma.
09:45 bos20k It doesn't work for this OU setting but works in Perl.
09:45 bos20k Without the comma that is.
09:45 Dyrcona You're right, I was mentally making it into this: "^.{12}$"
09:46 Dyrcona I believe that setting ends up being given to Perl. I don't think it is used in the database, but I could be wrong.
09:47 Dyrcona There are subtle differences between various regex libraries, particularly when it comes to braces.
09:48 bos20k Yes, it works with the comma for the OU setting.  Must be lib difference you mentioned.  Thanks!
09:48 Dyrcona Some require the comma or they say it is malformed.
09:48 Dyrcona You're welcome.
09:51 sandbergja joined #evergreen
10:16 Dyrcona joined #evergreen
10:29 khuckins joined #evergreen
10:42 sandbergja joined #evergreen
10:54 jamesrf joined #evergreen
11:17 yboston joined #evergreen
11:37 jihpringle joined #evergreen
11:43 sandbergja joined #evergreen
11:45 _sandbergja joined #evergreen
11:50 aabbee joined #evergreen
12:36 phasefx berick: hey man, I'm re-using the eg2 <eg-holds-grid> in another interface and want to change up the columns that are visible by default.  Would it be best for me to make something like [defaultVisible]="[name1,name2,..]" or is there something already there I'm overlooking?  Another option might be to allow the passing of <eg-grid-column> elements to overlay the internal ones, but that seems scary to me at the moment.  What do you think?
12:40 phasefx hrmm, I guess a defaultVisible would be more suitable for the base eg-grid
12:41 phasefx ha, and there is a showFields
12:41 phasefx thanks rubber duck :)
12:47 mmorgan rubberduck++
12:50 phasefx not sure of the best way to pass it through, but I'm getting closer
13:42 littlet joined #evergreen
13:44 aabbee joined #evergreen
13:59 yboston joined #evergreen
14:26 khuckins joined #evergreen
14:34 collum joined #evergreen
14:49 sandbergja joined #evergreen
14:50 gmcharlt 10-minute warning for the development meeting
15:00 gmcharlt and here we go
15:00 gmcharlt #startmeeting Development Meeting, 4 June 2019
15:00 pinesol Meeting started Tue Jun  4 15:00:25 2019 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00 pinesol Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00 Topic for #evergreen is now  (Meeting topic: Development Meeting, 4 June 2019)
15:00 pinesol The meeting name has been set to 'development_meeting__4_june_2019'
15:00 gmcharlt #info Agenda is https://wiki.evergreen-ils.org/do​ku.php?id=dev:meetings:2019-06-04
15:00 gmcharlt #topic Introductions
15:00 Topic for #evergreen is now Introductions (Meeting topic: Development Meeting, 4 June 2019)
15:00 gmcharlt #info gmcharlt = Galen Charlton, Equinox, 3.4 RM
15:00 JBoyer #info JBoyer = Jason Boyer
15:01 sandbergja #info sandbergja = Jane Sandberg, Linn-Benton Community College
15:01 rhamby #info rhamby = Rogan Hamby
15:01 jeff #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:01 dbs #info dbs = Dan Scott, Laurentian University
15:01 remingtron #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:01 dbwells #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:01 Dyrcona #info Dyrcona = Jason Stephenson, CW MARS
15:03 gmcharlt #topic Action items from previous meetings
15:03 Topic for #evergreen is now Action items from previous meetings (Meeting topic: Development Meeting, 4 June 2019)
15:03 gmcharlt so, dbwells, you had a couple
15:03 gmcharlt any updates?
15:03 dbwells Sure
15:04 dbwells First, some progress was made on getting Syrup working on modern Ubuntu/Python 3.
15:04 dbwells It is far enough along that an interface now loads and displays generic object strings.
15:04 miker #info miker = Mike Rylander, EOLI
15:05 dbwells One significant hurdle we have backburnered is regarding a Z39.50 Python module which has no working Python 3 version.
15:06 dbwells I don't have a good idea how that fits yet in the big picture, and whether we'll need to shepherd that along or replace it outright.
15:06 dbwells As far as buildmaster call, I decided to delay that until 3.1 is done in a few more months.
15:07 dbwells Since I was RM for two of our three supported releases, and made particular committments regarding 3.1 support, the time wasn't quite right yet to step back, I think.  But, soon :)
15:07 gmcharlt does that negate a desire for additional help?
15:08 dbwells Yes, I think for now we are good.  I expect to look for more help around late August.
15:08 gmcharlt ok
15:08 dbwells That said, the door is always open, of course.
15:09 gmcharlt w.r.t. the OpenSRF Python binding, do you have a sense yet about whether you are willing to assume reponsibility, or is it too early yet?
15:10 yboston joined #evergreen
15:11 dbwells Our first priority is getting it working with Syrup, and I think that goal is shared by others in the community.  I would likely need help implementing some of the newer OpenSRF features from scratch.
15:12 gmcharlt ok
15:12 gmcharlt I think "assuming responsiblity"  here is more about willingness to drive, not writing the patches singlehandedly
15:13 gmcharlt I can help with respect to some of the new features, but do not promise idiomatic Python3 code
15:13 dbs I hope to be able to contribute some time to making at least the existing OpenSRF Python functionality available in Python 3, starting around August
15:13 gmcharlt dbs++
15:13 JBoyer dbwells++
15:13 JBoyer dbs++
15:14 gmcharlt #info dbwells has started work on porting Syrup to Python 3; one blocker is updating a z3950 module that doesnt' yet have a python3 equivalent
15:14 gmcharlt #info some initial additional promises of assistance for the python3 OpenSRF binding have been made
15:15 gmcharlt #info Call for additional buildmaster to be deferred until closer to August
15:15 gmcharlt as far my action item is concerned
15:15 gmcharlt I expect to drop a patch for that in a couple weeks
15:15 gmcharlt so
15:15 gmcharlt #action gmcharlt will work on upgrading ng-bootstrap past 3.3.0 for 3.4; will also evalulate whether that might be a safe backport to 3.3.x
15:15 gmcharlt moving on
15:15 gmcharlt #topic OpenSRF release
15:15 Topic for #evergreen is now OpenSRF release (Meeting topic: Development Meeting, 4 June 2019)
15:16 gmcharlt #action gmcharlt will cut OpenSRF bugfixes releases on 7 June
15:17 gmcharlt mostly just to accumulate bugfixes
15:17 gmcharlt I'm also looking at bug 1824181 and bug 1824184
15:17 pinesol Launchpad bug 1824181 in OpenSRF "Allow first argument to logger to be string or subroutine" [Undecided,New] https://launchpad.net/bugs/1824181
15:17 pinesol Launchpad bug 1824184 in OpenSRF "Change potentially slow log statements to subroutines" [Undecided,New] https://launchpad.net/bugs/1824184
15:17 gmcharlt particularly with an eye towards seeing if they can be safely backported to 3.1.x
15:18 gmcharlt any questions or other OpenSRF thoughts?
15:18 * miker begs for tuits...
15:18 miker for opensrf
15:19 * gmcharlt tosses a tuit into the air
15:19 gmcharlt miker: where are you specifically hoping it will land?
15:20 miker gmcharlt: c-side improvements to chunking, and parameter streaming ... but those are both too big for 6/7
15:20 miker I think
15:20 gmcharlt yeah, I think so as well
15:20 * miker watches tuit fall through the sewer grate, lost forever
15:20 gmcharlt I'm viewing the 6/7 releases as bugfixing anyway
15:21 gmcharlt ok, moving on
15:21 gmcharlt #topic Evergreen update
15:21 Topic for #evergreen is now Evergreen update (Meeting topic: Development Meeting, 4 June 2019)
15:21 gmcharlt #info Feedback Fest #1 happened - https://wiki.evergreen-ils.org/do​ku.php?id=dev:3.4:feedback_fest_1
15:21 gmcharlt #info So did Bug Squashing Week - https://wiki.evergreen-ils.org/dok​u.php?id=dev:bug_squashing:2019-05
15:22 gmcharlt one thing I'm particularly curious about is feedback for, well, Feedback Fest
15:22 gmcharlt specifically, whether any changes to its format or structure should be contemplated for the second one
15:23 Dyrcona Seems like it was a good bit of work for you, gmcharlt.
15:25 gmcharlt Dyrcona: yeah, as I expected
15:25 Dyrcona From my point of view, I'd say it was useful and the overlap with bug squashing week seemed to simplify things.
15:25 Dyrcona Well, do you have any ideas for improvements, since you did the bulk of the work?
15:25 gmcharlt but the only part I found particularly problematic was the lack of a decent API in LP, but that's hardly news
15:27 Dyrcona Yeah, the API used to work, then didn't, but it was never that great to work with. It may be working again depending on Ubuntu release or Python version. I haven't tried it in a few years.
15:27 gmcharlt the main thing I'm thinking of doing differently for the second fest is buttonholing all of the committers earlier in the process to hopefully get a bit more evenness of the patch review work
15:27 gmcharlt I will note that compared to the two I ran for 3.0, the first 3.4 fest was the most productive yet
15:28 gmcharlt we just had/have a much bigger backlog of PRs w/o SOs
15:28 khuckins joined #evergreen
15:28 JBoyer I don't have much to add, but I will say that having the two weeks overlap does seem like a good idea that worked well, as the people that participate in one may or may not be able to in the other, but the two projects do support each other.
15:29 * gmcharlt makes notes
15:29 gmcharlt moving up
15:29 gmcharlt *on
15:29 gmcharlt #topic Hatch update
15:29 Topic for #evergreen is now Hatch update (Meeting topic: Development Meeting, 4 June 2019)
15:29 gmcharlt any updates on Hatch?
15:30 JBoyer None here.
15:31 gmcharlt ok
15:31 gmcharlt #topic Bug discussion
15:31 Topic for #evergreen is now Bug discussion (Meeting topic: Development Meeting, 4 June 2019)
15:31 gmcharlt so one with the needsdiscussion tag I'd like to highlight is bug 1778414
15:31 pinesol Launchpad bug 1778414 in Evergreen "The catalog menu should include Item Status" [Undecided,Confirmed] https://launchpad.net/bugs/1778414 - Assigned to Meg Stroup (mstroup)
15:32 gmcharlt which basically boils down to if, and under what circumstances, we want to allow duplicate menu entries in the staff interface
15:32 jeff It would be good to get a new Hatch build out there, especially with regard to the Oracle license changes. To the best of my understanding, the only Hatch that works well with OpenJDK is not available on the download page yet.
15:33 gmcharlt JBoyer: any obstacle to ^^ that folks can help with?
15:34 JBoyer To my knowledge all that's really needed is testing. berick has a branch available to build your own windows installer with all of the new openjdk bits
15:34 JBoyer (looping up lp)
15:35 JBoyer Ah, bug 1830391 and there's also a pre-built installer to test.
15:35 pinesol Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] https://launchpad.net/bugs/1830391
15:36 JBoyer being an omnibus bug including Eg patches for one of the issues addressed might make it slightly more work to test, but if anyone wants to sign off on what they can test I'm sure it would help.
15:37 gmcharlt #info Call for testers for Hatch ombnibus bug 1830391 (https://bugs.launchpad.net/evergreen/+bug/1830391)
15:37 pinesol Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New]
15:37 jeff Once it has signoff and is committed / etc, how does the installer generally make it to the download page for Hatch? Ad hoc at the moment?
15:38 gmcharlt I believe ad hoc
15:38 JBoyer Yeah, I believe so far berick has built the releases and shipped them to the web team as needed.
15:38 jeff Works for me! Thanks, and sorry for rewinding the topic. :-)
15:38 gmcharlt no worries
15:38 gmcharlt so bug to bug 1778414, he said, redundantly
15:38 pinesol Launchpad bug 1778414 in Evergreen "The catalog menu should include Item Status" [Undecided,Confirmed] https://launchpad.net/bugs/1778414 - Assigned to Meg Stroup (mstroup)
15:38 gmcharlt *back to
15:39 gmcharlt I don't personally have a strong feeling either way, but do think we should come up with a consistent policy
15:40 miker opinion: if we consider each menu as the lauching point for all of what a particular class of staff member needs to do (generally speaking), I think the duplication is fine
15:40 gmcharlt (I do have a stronger feeling that if we do run with having duplicate menu items, that we give each instance the same label unless there's a complelling reason to refer to a given action/page by multiple naems)
15:40 miker if we consider the menus like windows application menu bars, not so much
15:40 JBoyer I think as long as it's in the menus and any link to the same route always has the same name I'm +1 to it. Since you can't have multiple menus open at once it shouldn't be especially confusing.
15:41 miker IOW, they're not really like File, Edit, Settings, Tools
15:41 sandbergja miker: the cataloger here (who originally prompted this bug) saw them as windows application menu bars
15:41 dbwells gmcharlt++ # linking to Nielson Norman Group discussions
15:41 sandbergja and saw Item Status as being misplaced
15:42 miker but Circ Staff, Cat Staff, Acq Staff
15:42 miker sandbergja: ah, so you'd propose /moving/ it?
15:42 jeff "Circulation -> Item Status" and "Search -> Search for Copies by Barcode" both lead to the same ("cat" app) url, /eg/staff/cat/item/search
15:42 sandbergja miker: I'd prefer either moving or duplicating it, since it is such a key part of cat workflows
15:43 * JBoyer isn't especially fond of calling anything where you enter a direct identifier a "search"
15:43 sandbergja But, to be fair, I have only talked to cat folks about it, not circ folks. :-)
15:43 miker JBoyer: boy howdy...
15:43 miker sandbergja: yeah, I get the feeling it's pretty key to circ folks, too
15:43 miker for item-in-hand work
15:43 JBoyer miker, I mean, I did add back "search for patrons by barcode" to our search menu, I just didn't like it. ;)
15:44 gmcharlt JBoyer: we can only search for things... never find them ;)
15:44 sandbergja I am definitely in favor of having some more established principles for the menus
15:44 JBoyer gmcharlt++
15:45 dbwells I think as long as we are having task specific menus, duplication is inevitable to fully support those tasks/workflows.  Other systems use object specfic workflows (i.e. a Patron menu, an Item menu, a Record menu, etc.), but we don't have that :)
15:45 miker anyway, +1 to duplicating item status (specifically) and letting the thunderdome decide on others in the future
15:45 JBoyer I think we're all pointing in vaguely the same direction (duplication is fine in menus, try to always use the same name, Search is ... search.) Does that sum it up?
15:45 Dyrcona I'm inclined to not change it and tell people to customize it locally. I can see it getting out of hand if everybody wants all kinds of commands duplicated. At some point, duplication ends up being unhelpful.
15:46 gmcharlt so, since I'm not seeing a big cry for no duplication... how about this as a principle: "Menus in the Evergreen staff interface serve as an entry point to the functionality most used by various classes of library staff, and as such, duplication of menu items between menus is permitted provided that the same page/function has the same name in each copy."
15:46 dbwells +1 to duplicating this one, +1 to making labels the same
15:48 miker (we may just have to carry the search->copies-by-barcode as a wart)
15:48 gmcharlt Dyrcona: FWIW, I'm not much in favor of encouraging tweaks to staff templates or (even worse) Angular HTML. If there ends up being a strong desire for customization of staff menus, it would be more work, but I'd propose doing database-driven menus
15:48 JBoyer While I'm fine with Dyrcona's warning to not do this frivolously, the reason this is coming up is that the XUL client did have it in both places (with different names)
15:49 * phasefx is glad he was vetoed long ago on having an extra set of menus that started with the nouns Item, Bib, etc.
15:50 Dyrcona I agree that if duplication is going to happen, then the names and functions should be the same.
15:50 JBoyer phasefx, extra might have been over the top, but maybe instead? The world may never know. ;) (Or we may, depending on how annoyed / relieved Wf users are when they switch, heh.)
15:50 * phasefx was thinking Circ, Cat, etc. at the top, and Item, Bib, etc. at the bottom near the status bar ;)
15:51 phasefx I'm +1 gmcharlt's stated principle, fwiw
15:51 miker phasefx: like a software mullet: verbs at the top, nouns on the floor
15:52 miker ;)
15:52 phasefx and picture buttons in the middle
15:52 JBoyer I'm also +1 to gmcharlt's proposed principal.
15:53 miker +1 as well
15:54 gmcharlt ok, I've updated the bug
15:54 jeff eliminate menus. series of RPN style buttons. first, select BARCODE, then select ITEM...
15:54 gmcharlt we have six minutes -are there any other bugs or other topics folks want to bring up?
15:55 gmcharlt jeff: HP can have that so long as they sponsor Evergreen with all their money
15:55 phasefx live search box for all functionality
15:56 gmcharlt phasefx: all of Google's money for that one
15:57 gmcharlt any other last minute topics?
15:58 * gmcharlt now gives each of you two free minutes to use as you see fit
15:58 gmcharlt #endmeeting
15:58 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
15:58 pinesol Meeting ended Tue Jun  4 15:58:23 2019 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:58 pinesol Minutes:        http://evergreen-ils.org/meetings/evergr​een/2019/evergreen.2019-06-04-15.00.html
15:58 pinesol Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2019/evergreen.2019-06-04-15.00.txt
15:58 pinesol Log:            http://evergreen-ils.org/meetings/evergree​n/2019/evergreen.2019-06-04-15.00.log.html
15:58 dbwells gmcharlt++
15:58 dbs gmcharlt++
15:58 JBoyer gmcharlt++
15:58 remingtron gmcharlt++
15:58 rhamby gmcharlt++
15:59 Dyrcona gmcharlt++
16:00 miker gmcharlt++
16:29 yboston joined #evergreen
17:11 mmorgan left #evergreen
17:25 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:37 yar joined #evergreen
21:04 dwgreen joined #evergreen
21:22 sandbergja joined #evergreen
22:24 yar joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat