15:02:05 #startmeeting 2021-07-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-07-13 15:02:05 Meeting started Tue Jul 13 15:02:05 2021 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:05 The meeting name has been set to '2021_07_13___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2021_07_13' 15:02:22 #info abowling = Adam Bowling, Emerald Data Networks 15:02:36 oh, hi, but more annoying. 15:02:49 #topic Introductions 15:02:51 #info Dyrcona = Jason Stephenson, CW MARS 15:03:05 #info terranm = Terran McCanna, PINES 15:03:06 abowling is ahead of the game, and I am also behind. 15:03:09 #info jeff = Jeff Godin, Traverse Area District Library (TADL) 15:03:10 #info alynn26 is Lynn Floyd, Evergreen Indiana 15:03:13 #info phasefx = Jason Etheridge, Equinox 15:03:15 #info JBoyer = Jason Boyer, Equinox 15:03:19 #info mmorgan = Michele Morgan, NOBLE 15:03:22 #info gmcharlt = Galen Charlton, Equinox 15:03:23 #info berick = Bill Erickson, KCLS 15:03:30 I know, but Ohai is a place name, and I looked it up this morning because I mistakenly thought that was what the O in OMC stood for. 15:03:37 #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) 15:03:44 #info collum = Garry Collum, KCPL 15:03:46 The O is actually for Otara. 15:03:55 JBoyer, broken clock... 15:04:42 And anyone else joining in later feel free to sprinkle infos at the appropriate time. 15:04:49 #topic Action Items from Last Meeting 15:05:17 #info JBoyer will for-really-this-time work with csharp to update mailman settings and make an announcement to the lists ahead of time 15:05:27 We for-really did it, finally! 15:06:05 JBoyer++ csharp_++ 15:06:08 I don't expect it to be a significant change for anyone, but if you ever had DMARC rejections in the past or made a change in the future that would have caused such, you're welcome. 15:06:15 JBoyer++ csharp_++ 15:06:27 JBoyer++ csharp_++ 15:07:45 Everything under release info is still just placeholders, so I'm going hop on down to new business unless someone is eager to spring a surprise on us. 15:07:55 #info sandbergja is Jane Sandberg, LBCC (making lunch, so I'll be here and there) 15:08:21 #topic New Business 15:08:42 #topic Offer official staff interface support for (modern) Edge? 15:09:12 JBoyer: when we're done discussion Edge, I do have a couple 3.8 things to call out 15:09:37 gmcharlt and I were discussing this earlier today, with current Edge being nothing but Chromium with some MS paint, should we offer official support for it? 15:10:25 We have had users using it. 15:10:30 was about to ask 15:10:57 alynn26: any of them also happening to be shoehorning Hatch into Edge as well? 15:11:09 nope, they are not. 15:11:23 #info miker = Mike Rylander, EOLI 15:11:27 I use it to talk to Evergreen also, though Hatch support is likely 1) missing, and 2), not that difficult to add. 15:12:26 Microsoft actually publishes .debs of Edge, so assuming that it has a headless mode, theoretically it could be folded into the Angular tests if somebody were sufficiently eager 15:12:53 gmcharlt: huh, didn't know they made debs 15:13:29 that simplifies some things 15:13:57 For Hatch I suspect they learned their lesson with old Edge's ridiculous extension mechanism and won't likely stray far from Chromium, though if we want Hatch on the Edge Extension store that's one more place to publish it. 15:16:20 maybe we could limit this some and say just the Angular bits? maybe that's implied.. 15:16:47 having the starting point be support-but-not-Hatch-yet seems like it would be OK 15:16:57 I don't mind trying to add Edge support to the Angular testing setup, though it will likely be optional so running --developer doesn't end up installing 4, 5, or 6 browsers in future. 15:17:42 berick: that is, if I'm understanding your question correctly. If Edge somehow breaks on the Dojo or AngularJS stuff, fixing that may be more than we awnt to tackle 15:17:54 berick, do you mean no Hatch yet, or even more limited than that somehow? 15:18:19 i mean what gmcharlt said. fixing stuff that's being actively replaced is not best use of time 15:18:45 Makes sense. 15:18:46 +1 to "no fixing stuff that's being actively replaced" 15:19:14 +1 15:19:28 Unless Chrome 92 breaks dojo overnight, heh. 15:19:54 yep, if it's broke in Chrome that is another issue. 15:21:01 certainly. 15:21:19 * berick tries installing hatch 15:21:44 I think this will be a desirable feature since it means one less thing to install 15:21:52 I think if the answer to "Is Edge supported?" is "It's complicated" due to Hatch, Dojo, AngJS etc, we effectively don't support Edge. 15:21:52 so it sounds like we're defining a second tier of support 15:21:54 i.e., 15:22:32 Chrome, Firefox: we fix any breakage around Angular, AngularJS, and Dojo unless impossible 15:23:22 Edge: we fix any breakage around Angular for versions supported by Angular (https://angular.io/guide/browser-support), but make no definite guarantee about maintianence for AngularJS and Dojo bits 15:23:57 and as far as Hatch goes... TBD based on the ease of using the existing extension and publishing it in the Edge store 15:24:21 sounds like a reasonable summary of what I think the concensus so far is. 15:24:23 (all of that said, not particularly expecting any Dojo or AngularJS issues) 15:24:32 * jeff nods 15:24:49 I'd be hesitant to tell a library they can use Edge under those conditions tbh. 15:25:26 it sounds like there has been some light testing of the current code in Edge. 15:25:36 yeah, and production use 15:25:44 The staff that use Edge know we do not support it. but use it anyway. Have not found any issues with Edge with the AngularJS or Dojo parts. 15:25:52 I understand the desire not to allow it to cause us any additional support burden, but as I understand it, neither Google or MS make many changes to the core rendering bits of Chromium, it's mostly the (pardon), chrome and syncing backends that are different. I don't see a situation where we have a compatibililty problem with Edge that we wouldn't have with Chrome within days. 15:25:56 if Edge weren't Chromium-plus-stuff, I think it would be a bigger lift 15:26:34 I think the hesitency in this discussion to claim full support is mostly stemming from the fact that very few here have tested the staff interfaces in Edge. 15:26:51 * mmorgan would be interested to know why Edge is preferred by those who are currently using it. 15:27:06 It's already there. 15:27:22 And if you're an IT department, it's more easily controlled with group policy. 15:27:23 "exchanging Google telemetry for Microsoft telemetry!" 15:27:25 mmorgan: central admin of IT resources, probably. less for them to have to support 15:27:30 That is it. JBoyer hit it on the head. 15:27:49 * mmorgan nods Edge is kinda pushy, too. 15:27:59 "more easily controlled with group policy" is thankfully becoming less of a valid claim. 15:28:22 Sure, I believe Chrome(-ium?) and even FF have GP templates these days. 15:28:37 indeed 15:28:40 There are. I've used them in the past 15:29:25 but if you're a MS shop with a very strict notion of avoding "foreign" software... hey, at least Edge is lightyears ahead of IE in terms of compatibility issues, at least for now 15:30:18 embrace, extend, ... ignore my zealotry :) 15:31:26 it also sounds like there are two potentially data-gathering tasks 15:31:47 1. a couple people taking it upon themselves to run through the staff interfaces with Edge 15:32:17 2. and a quick feasibility check of the current Hatch extension on Edge 15:32:33 Hatch is working :) 15:32:45 berick++ 15:32:48 berick++ 15:32:52 edge + hatch on linux that is 15:33:07 berick: OK, you have 123.5 seconds to exercise the staff interface ;) 15:33:11 I can track down the reg info for Windows in that case. 15:33:38 this would mean modifying the Hatch windows installer as well to deploy the manifest file 15:34:21 That's what I meant, I'm not going to try installing on Windows until *after* the meeting. ;) 15:34:41 (Since I'm on a Mac right now, anyway) 15:35:32 alynn26: do you know if anybody has successfully used offline circ with Edge? 15:35:39 Since berick knocked out #2 already, is anyone interested in taking an action item on exercising the staff client in Edge? Hatch is not necessary, but offline would be. 15:36:17 No, not offline circ on edge. Testing edge on Windows 10 now. 15:37:23 To be clear, I don't mean anyone needs to try to knock out a client test right now, I know personally that it works fine for everything I've done in it, but there are a lot of things I don't touch. 15:38:54 Or I will poke at it. 15:39:27 #action JBoyer will exercise the staff client in a current release of Edge and report back in August 15:39:52 JBoyer++ 15:39:57 #action JBoyer will look at adding Edge on Windows support to the Hatch installer 15:40:33 Any other Edge discussion before we move on? 15:41:12 in summary, until further research is complete: Chrome or Firefox recommended, Edge if you're... Brave. 15:41:23 (ducks) 15:41:27 heh 15:41:31 +1 15:41:34 Hey-o, 15:41:56 But yeah, Brave users are on their own for now. :P 15:42:07 yes. 15:43:14 Ok, moving on to 15:43:17 #topic Feedback for New Features Under Development 15:43:38 gmcharlt, I assume your 3.8 question is about bug 1904036? 15:43:38 Launchpad bug 1904036 in Evergreen "Port patron interfaces to Angular (search, checkout, etc.)" [Wishlist,New] https://launchpad.net/bugs/1904036 15:43:51 i added that one 15:44:08 JBoyer: yeah, mine was more of a general heads up about a bunch of big features for which we need testing 15:44:15 :( 15:44:35 seeking feedback on trying to add it to 3.8 as experimental 15:44:44 1904036 is definitely one of them, but there's also 15:44:53 - the volume/copy editor Mark Angular 15:44:59 - berick's PO/LI/SL stuff 15:45:09 - the acquisitions administration work 15:45:09 if it's disabled, it's essentially not there, but it does add quite a few angular updates (that could potentially be extracted out to their own bugs, of course) 15:45:26 - as well as remaining Angular staff catalog regressions 15:45:42 and yeah, as berick says, a ton of updates to core Angular components across all of these branches 15:46:07 so generally speaking - here's my plea/call for folks to adopt some of these branches and exercise them 15:46:36 berick and I will also be coordinating some stuff to make Angular PO/SL/LI + Angular acq admin coexist cleanly 15:46:48 (they're already 97% there, but there are a couple mege conflicts to sort out) 15:47:03 so, that's my pitch; back to berick for more on Angular patron interfaces 15:47:38 that's pretty much it, just wanted to propose we include it in the 3.8 pile-o-angular 15:48:11 gmcharlt: i can def. poke the acq admin branch as part of our merge management 15:48:53 berick++ 15:49:00 I'm +1 to getting the patron interface in, especially since it can be disabled. There will always be something that's not caught until real users see something, if they can go back and forth for a release that's a big help 15:49:21 +1 for patron interface 15:50:07 +1 for the ability to go back and forth between new and old interfaces 15:51:14 I'm curious about getting us up to Angular 12 15:51:42 I wonder if we could get the big angular stuff merged early in the cycle, so y'all don't have to go back and update your branches 15:51:57 and then upgrade angular later in the cycle? 15:52:36 sandbergja: that would be my pref 15:52:49 i could also see the argument for updating to ang 12 directly after 3.8 15:53:15 but I haven't looked yet to see what's involved in the update. might be simpler 15:53:18 er, simple 15:53:19 I was about to ask if there was anything in A12 that would be especially useful for 3.8 or if it could wait 15:53:42 (Not that "not falling behind" isn't useful, mind.) 15:54:14 berick: I played around with Angular 11 or 12 a while back; impression I got is that it's going to be bigger than normal 15:54:26 gmcharlt: gotcha 15:54:27 e.g., lint will drastrically change 15:54:57 but to sandbergja's point, I'm all in favor of getting the bigger Angular bits in sooner rather than later 15:55:05 +1 15:55:07 +1 15:55:32 +1 15:57:05 quick question re: acq po/li/sl angular UI's 15:57:18 i want to make them optional without affecting the existing search interfaces 15:57:42 should I just put links on the top of the (e.g.) PO page pointing to its Ang counterpart? 15:57:48 not sure how else people will find them 15:57:52 without search 15:58:36 berick: my gut reaction: experimental nav menus for the new interfaces + a library or workstation setting to control whether links from the search interface bounce the user from search rsesults to either the old or new interface 15:59:34 +1 to experimental nav menus 15:59:44 gmcharlt: not sure what the nav menus would looke like, though, since search is the only real entry point 16:00:29 maybe if the setting is on, the search UI will present 2 links -- could get crouded 16:00:49 we don't have menu nesting (yet?), but maybe something like 16:00:55 checkbox next to search input field that determines if the links open in new/old UI? 16:01:25 (checkbox, dropdown/select, what-have-you) 16:01:56 Acquistions => Experimental => Create Purchase Order (for anything that would be an entry point other than search) 16:02:46 ah, right, ok i guess there are some top-level pages 16:02:47 and maybe a "Acquisitions Preferences" on acq search similar to catalog preferences for the WS setting about where to link search results to 16:02:52 berick: There is an Acquisitions interest group tomorrow for potential input 16:03:09 links in new/old to view in old/new and a setting to determine default might be good also. 16:03:16 and possibly all of that wrapped in a library setting or a global flag to let administraors hide the experimental stuff outright 16:03:52 jeff: i kind of like the checkbox option since it allows access to both 16:04:07 I like the idea of being able to use the new UI without having to make a conscious decision of "new UI or old UI?" each time you perform an operation. 16:04:36 sticky checkbox, just on the search page 16:04:54 but being able to access the old UI's is critical, i think 16:05:06 Agreed 16:05:23 yes. otherwise the first time you run into an issue, you'll completely stop using the new UI. :-) 16:05:42 ok, i'll synthesize some of this and post it in the LP 16:05:45 thanks for all the input 16:05:49 berick++ 16:06:02 mmorgan: if you hear anything of note, let me know! 16:06:10 not sure I can make tomorrow's acq meeting 16:06:44 Ok, if there are no other questions or comments we can go about the rest of our days (and start testing Angular branches! ;) ) 16:06:48 berick: I'll be demoing the acq admin interfaces there tomorrow, and would be happy to relay any questions you care to feed me 16:07:01 berick: Will share this with my colleague who will be attending that meeting. 16:07:15 is it 2pm eastern? 16:07:22 3 pm 16:07:29 Yep, 3 16:07:50 ok, will try to come, may be late 16:09:00 ok 16:09:04 #topic Announcements 16:09:09 #info Next Meeting is August 10, 2021 16:09:27 Looking forward to getting some good stuff in 3.8! 16:09:33 #endmeeting