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/doku.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/doku.php?id=dev:3.4:feedback_fest_1 |
15:21 |
gmcharlt |
#info So did Bug Squashing Week - https://wiki.evergreen-ils.org/doku.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/evergreen/2019/evergreen.2019-06-04-15.00.html |
15:58 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2019/evergreen.2019-06-04-15.00.txt |
15:58 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/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 |