15:02:07 #startmeeting 2023-02-14 - Developer Meeting 15:02:07 Meeting started Tue Feb 14 15:02:07 2023 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:07 The meeting name has been set to '2023_02_14___developer_meeting' 15:02:10 #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2023-02-14 15:02:16 #topic Introductions 15:02:26 #info JBoyer = Jason Boyer, EOLI 15:02:30 #info terranm = Terran McCanna, PINES 15:02:38 #info rhamby = Rogan Hamby, EOLI 15:02:43 #info mmorgan = Michele Morgan, NOBLE 15:02:44 #info tlittle = Tiffany Little, PINES 15:02:50 #info jeff = Jeff Godin, Traverse Area District Library (TADL) 15:02:53 #info berick Bill Erickson, KCLS 15:03:19 (dueling calendar entries, will be here then not then here) 15:03:30 #info abneiman = Andrea Buntz Neiman, EOLI 15:03:54 #info mantis1 = Gina Monti, Bibliomation 15:04:17 #info collum - Garry Collum, KCPL 15:04:31 #info jvwoolf = Jessica Woolford, Bibliomation 15:05:13 ok, anyone joining later should feel free to get all #info with it 15:05:23 #topic Action Items from Last Meeting 15:05:29 #info Bmagic to email the development list about a way to share common Evergreen tools with the community. 15:05:40 Bmagic, how did that turn out? 15:05:58 Who I just noticed may not be around... :) 15:06:04 I'm here 15:06:12 Bmagic++ 15:06:26 Umm, did I send an email... I think I did 15:07:23 rhamby replied, but I don't think we made a full plan 15:07:38 Yeah, looks like 2022-12-22 15:08:00 yeah, it was batted around a bit and I had thought others would chime it but it was also knocking on Christmas so ..... 15:08:17 yep, so, that's where we are 15:08:35 I went ahead and published the thing I was working on, on github 15:08:49 Which adds to the scatter 15:09:03 Looks like a wiki page collecting links to repos for interop would help at least direct people. 15:09:07 maybe resurrect the thread now that there isn't a major holiday looming? 15:09:33 IMO we should do the wiki page no matter what. some scatter is likely to occur and it is low hanging fruit. 15:10:13 Yes, I think a wiki page without a doubt. Even if it has just one link: to the final place we decide all these things go 15:10:26 rhamby++ Bmagic++ 15:10:34 Works for me. 15:10:46 #info Bmagic = Blake GH, MOBIUS 15:10:52 Bmagic, since you have a new link to add would you like to start the new page? 15:11:00 Will do! 15:11:04 Bmagic++ 15:11:07 ok, on we go 15:11:15 #info Dyrcona to review Lp 1901932 15:11:15 Launchpad bug 1901932 in Evergreen "Wish List - Enhanced Concerto dataset" [Wishlist,New] https://launchpad.net/bugs/1901932 15:11:19 Dyrcona emailed me ahead of time to let me know that he may not be here and that he hasn't had time to review that bug yet; we'll discuss it more later. 15:11:37 Looks like the Launchpad status hasn't been updated yet so we'll skip over that for this meeting 15:11:44 The main event! 15:11:51 #topic New Business 15:11:57 #info scottangel: Request for testers / feedback: LP1977554 - Add Password visibility toggle on login screens 15:12:20 Yes! Test away 15:12:30 Always good to call attention to accessibility and internationalization fixes. 15:12:35 scottangel++ 15:12:51 #info mantis/gmonti: Procedure for updating terminology in Evergreen 15:13:00 mantis2, it's all yours 15:13:06 thanks! 15:13:39 I'm going through the bitesite LP tickets for example and finding a lot of instances like these: https://bugs.launchpad.net/evergreen/+bug/1915053 15:13:39 Launchpad bug 1915053 in Evergreen "Item Tags Interface has "Copy Tag Type" as a column" [Undecided,Confirmed] 15:13:59 so basically I'm asking what would be the procedure for these big termniology changes in the system like item and copy for example 15:14:10 I don't know if individually reporting them or having something more central is the best option 15:15:13 in the past we handled them informally but if we're talking about a mass change making say 70 tickets seems clunky 15:15:37 They don't necessarily have to be individual, but reports should probably be small, limited to a single section of the client or opac. 15:16:03 I think if we have a consensus to make such a change there should be a good faith effort to list logically grouped ones into just a few tickets 15:16:04 JBoyer++ 15:16:27 Smaller patches like that are easier to test and apply, without making them too tiny or so large that we end up with a "# items" printing option sneaking through. :) 15:16:42 (again?) 15:16:49 mantis2++ 15:17:23 Any other comments before we move on? 15:17:36 Not from me! 15:17:38 thank you! 15:17:47 #info JBoyer: It may be possible to completely remove Evergreen server PCI exposure by moving to client-side Authorize.net and PayPal (and dropping PayFlowPro). 15:17:54 Can someone take an action item to verify whether it would violate any of their license agreements if the client-side integrations were to be used by the staff client? (i.e. handing a patron card to a staff member and entering it into the client. 15:18:30 I *assume* that's not a big deal, but I'd rather not find out by a library losing their stripe account or something like that. 15:20:20 I'm not clear what this is proposing. Removing all the CC code from Evergreen? 15:20:32 No, removing all of it from the server. 15:21:05 Do the transaction, but don't record stuff into money.credit_card_payment? 15:21:27 The way stripe and modern paypal and others work is that the browser where the payment is being taken communicates with the payment processor and sends the server a transaction key and what not instead of the card info 15:21:39 then the server verifies that it actually took place and applies the payment. 15:22:00 PINES only uses Stripe, so that wouldn't change, correct? 15:22:41 It would potentially change in that you could accept Stripe payments in the staff client, which you can't today. That's what I'm curious about. 15:22:49 *THAT* would be amazing 15:23:01 Would you like to read some EULAs? :D 15:23:02 Especially if staff could scan the credit cards 15:24:03 So, to reiterate what I'm saying because I left out more detail than I should have: 15:25:59 I'd like someone to investigate whether it is against the Stripe, PayPal, or Authorize.net license agreements for their JS-based in-browser payment products for staff to enter a user's card information into their system or if the intent is only the cardholder has access to their card. 15:26:30 I see 15:26:43 If that's not an issue (I don't expect it to be, really) then we could eventually move all CC processing to these JS-based processes and phase out the CC processing on-server. 15:26:49 We don't contract with Stripe at the consortial level, but I'll see if one of our libraries that uses it would be willing to share with us. 15:27:12 And for the first time that I can remember remove some dependencies, which I like very much. 15:27:59 terranm, license terms may be available on their signup / dev sites without having to have an account or anything. 15:28:09 JBoyer++ 15:28:56 Does that mean you'd like to check them out? :) (Stripe, PayPal, and Authorize.net specifically are the ones of interest, I looked and don't believe PayFlowPro has such an offering yet.) 15:29:21 I'm only going to take on Stripe, as that's the only one I'm familiar with at all. 15:29:38 That still helps. terranm++ 15:29:52 terranm++ 15:29:59 #action terranm will look at the Stripe license agreement for this 15:30:09 terranm++ 15:30:16 #action JBoyer will look over Authorize.net and PayPal license agreements. 15:30:25 I can take Authorize.net. I had a library reach out to me about it a few years ago because they offer a credit card reader through TechSoup 15:30:33 jvwoolf++ 15:30:36 you got it. 15:30:40 Ooh, credit card reader.... 15:30:51 jvwoolf++ 15:30:54 #action jvwoolf will take authorize.net rather than JBoyer 15:30:55 JBoyer++ 15:31:03 * mmorgan just snuck the lp stats onto the agenda 15:31:14 mmorgan is a ninja! 15:31:34 https://stripe.com/legal/ssa might have the relevant docs for stripe 15:31:51 rhamby++ 15:32:07 rhamby++ 15:32:53 #topic Launchpad Status 15:32:57 #info Snapshot 15:33:01 #info Open Bugs - 2937 15:33:13 #info Pullrequests - 119 15:33:13 #info Signedoff - 28 15:33:16 #info Updates Since Last Meeting 15:33:20 #info Bugs Added - 69 15:33:25 #info Pullrequest tag Added - 26 15:33:29 #info Signedoff tag Added - 9 15:33:33 #info Fix Committed - 21 15:33:38 mmorgan++ 15:33:44 Folks have been busy!! 15:34:14 Now then! 15:34:15 #info JBoyer: Who wants to build Evergreen 3.11 for Workgroups? 15:34:32 Evergreen 3.11 release team, assemble! 15:34:42 I'm interested 15:34:49 That is to say, who here wants to be on it? 15:34:53 Bmagic++ 15:35:15 BMagic++ 15:35:20 I'm familiar with the buildmaster team. I'm not familiar with Workgroups 15:35:59 https://winworldpc.com/screenshot/e280a1c2-a175-4bc5-a0c3-bf11c3a4c2ac/42015082-eae8-11e7-a562-fa163e9022f0 15:36:02 it adds new networking technologies to any underlying product 15:36:07 lol 15:36:20 JBoyer++ 15:37:17 * mmorgan is willing to help out again. 15:37:21 I never grew beyond sneakernet networking technology 15:37:34 I can try to be more involved again also. 15:38:24 So, for now JBoyer, Bmagic, and mmorgan? Want to just run with that list or should I send a nudge to the dev list to see if a fourth shakes loose? 15:38:38 sounds good. I'm stoked 15:39:01 Works for me. 15:39:05 What's the timeline for 3.11? 15:39:16 Or does the release team set that? 15:39:17 Might be nice to nudge the dev list, but this works. 15:39:22 jvwoolf: join the team and make it up as you go! 15:40:06 It's post-conference or pre-conference, I forget 15:40:11 Bmagic: I'd consider it, but I might disappear for the month of March ahead of our upgrade :) 15:40:26 Which may be really inconvenient 15:40:41 I'll email the list with the addition that if there's unexpectedly large interest I may step back. But for now, it's provisionially the three of us. 15:41:00 When our powers combine.... 15:41:10 EVERGREEN 3.11 15:41:28 And yeah, the release team will likely finalize the timeline but I expect the process to be a lot like this: "Look at 3.10 timeline, adjust for DATE(), nudge here and there, send." 15:42:05 #info As of now the 3.11 release team is JBoyer, Bmagic, and mmorgan 15:42:41 #action JBoyer will send a "Hey, Listen!" email to the dev list about interest in the 3.11 release team. 15:42:49 workgroup++ 15:42:53 Bmagic++ mmorgan++ 15:43:02 JBoyer++ # backatcha 15:43:09 Jboyer++ Bmagic++ mmorgan++ 15:43:09 JBoyer++ Bmagic++ 15:43:19 mmorgan++ 15:43:26 JBoyer++ Bmagic ++ mmorgan++ 15:43:30 I hope pinesol can keep up 15:43:41 Which brings us to the last new business item, 15:43:42 #info Bmagic: Enhanced Concerto Dataset: LP1901932 15:43:44 @jboyer++ @bmagic++ @mmorgan++ 15:43:44 tlittle: What we have here is a failure to communicate. 15:43:51 Bmagic, fire away 15:44:32 The main thing I wanted to talk about was to make it clear that my proposal for this will require the buildmaster to have a local server of Postgres for the build process to interact with 15:45:19 some new flags to the build command, passing the PG login creds will allow the Enahanced concerto set to grow with the version of Evergreen thta you build 15:45:31 I have been a bit lax in looking this over, does this essentially make the concerto sample data a pg dump 15:45:33 ? 15:46:14 no, it's a custom dump to a series of SQL files, mimicing, to some extent, what we're doing with the concerto set now 15:47:24 That's not as bad as I was thinking, but I'm not totally sold on the approach. I'll have to check it out more. 15:47:42 It's all fine and dandy until someone adds/removes columns from the database structure, and the enhanced dataset will need to move along with it. I've got it all coded to be automated, it just needs a PG server to run it's process and upgrade scripts then dump back to files 15:48:44 Which is another benefit of bringing it up here; I know Dyrcona is planning to check it out but anyone here that's comfortable with databases please feel free to check it out also. 15:48:49 it's kinda beautiful. As a side-effect, we now have the code to automate any* dataset through the procedure 15:49:04 Bmagic++ 15:49:12 Bmagic++ 15:49:47 If it's merged, the instructions here: https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 15:49:55 will need to have the new flags documented 15:50:31 Speaking of that release page, what should probably happen at some point is that it should be duplicated and updated so we can finally put 2.8 to rest. 15:50:48 Bmagic: curious if there was a reason to avoid going with concerto-style INSERTs, etc. 15:51:05 (I'd specifically like to keep the current one around) 15:51:46 berick: I wanted to code something that could accomodate any* future that Evergreen DB could go. And any* database that we wanted to make the "Enhanced Concerto Dataset" 15:52:31 Not just bibs/items/patrons. But any table and combination of tables, entangled however we wanted 15:53:28 The patch keeps the current concerto set intact, and doesn't change the way that it's installed via the standard docs 15:56:01 (I'm done) 15:56:04 Any other discussion before we all depart? 15:56:22 heh i thought the meeting was already over 15:56:25 I added another line item 15:56:34 The New Devs group has begun pulling together all of our individual notes and content from elsewhere on the wiki and from conference presentations. : 15:56:35 https://wiki.evergreen-ils.org/doku.php?id=newdevs:start 15:56:40 Side menu on the left with "WIP" on pages that are just placeholders. 15:56:46 #info terranm: New Devs Update - adding code explanations and samples to https://wiki.evergreen-ils.org/doku.php?id=newdevs:start 15:56:57 oops, I jumped the gun 15:57:19 No, I just wanted to make sure it was in the minutes and hte log. :) 15:57:26 Anybody that wants to contribute is more than welcome! 15:57:32 (minutes are mostly just the #stuff) 15:57:36 terranm++ 15:57:37 terranm++ 15:57:44 I just want to say you guys are doing an awesome job on the newdevs:start Thank you so much!!! 15:58:11 #topic Announcements 15:58:15 #info Next Meeting is March 14, 2023 at 3pm Eastern 15:58:19 #endmeeting