February 2025 - Evergreen-dev

Proposal for a Comprehensive Fix to Shared Address Issues in Evergreen
by Ian Skelskey 28 Feb '25

28 Feb '25

Dear Evergreen Developers, While executing a patron purge initiative at Bibliomation, I encountered an issue related to shared addresses that prevented some deletions from completing. I was able to work around the issue, but I believe a more permanent fix should be implemented to prevent similar problems in the future. I decided to share this as an email because it's a bit long and is easier to read with some shiny formatting that isn't possible on Launchpad. The root cause, as outlined in Bug #885270 <https://bugs.launchpad.net/evergreen/+bug/885270>, is that cloned patrons historically shared the same address row in the database. When attempting to delete a patron whose address is still referenced by another user, the process fails. Over the years, multiple solutions have been introduced to mitigate this issue, but they remain somewhat fragmented and the bug ticket remains open. *Summary of Fixes Implemented So Far* 1. *Library Setting: "Cloned patrons get address copy"* - When enabled, this setting ensures newly cloned patrons receive a separate address entry rather than sharing the original. - However, this only prevents new instances of the issue and does not fix pre-existing shared addresses. 2. *fix_addresses.sql <https://bugs.launchpad.net/evergreen/+bug/885270/+attachment/4112365/+files…> Script (shared by Jason Boyer)* - This script untangles shared addresses by duplicating them, ensuring each patron has a unique address entry. - It serves as a one-time fix for existing shared addresses but does not enforce consistent behavior moving forward. 3. *Address Deletion Failure* - The actor.usr_purge_data function currently attempts to delete all addresses linked to a user, which fails if the address is still referenced elsewhere. - A fail-safe could be added to prevent deletion if the address is still associated with another patron. *Proposed Next Steps**1. Make Cloning Behavior Consistent* - Remove the "Cloned patrons get address copy" setting and enforce the creation of separate address entries for all cloned patrons by default. - No use case seems to require shared addresses, and maintaining this setting prolongs potential inconsistencies. - Can anyone think of a use case where shared addresses would be helpful? - Does anyone have that setting set to *false*? *2. Database Migration Fix* - The fix_addresses.sql script should be incorporated into a future database upgrade process to automatically separate any remaining shared addresses. *3. Modify actor.usr_purge_data to Handle Shared Addresses Gracefully* - Instead of failing outright when trying to delete a shared address, modify the function to ensure the address is not deleted if still referenced. A log message can be added to report any cases where the issue persists. - SELECT COUNT(*) INTO shared_address_count FROM actor.usr u WHERE (u.mailing_address = actor.usr_address.id OR u.billing_address = actor.usr_address.id) AND u.id != src_usr; IF shared_address_count > 0 THEN RAISE NOTICE 'Address shared by another patron, not deleting address for user %', src_usr; ELSE DELETE FROM actor.usr_address WHERE usr = src_usr; END IF; - This adjustment ensures the deletion process continues rather than throwing an error while preserving shared addresses when necessary. *Next Steps & Feedback* Would the community support moving forward with this approach? If there’s consensus, I’d be happy to contribute toward implementing these updates. Looking forward to your thoughts! -- Best regards, *Ian Skelskey* *Evergreen Systems Specialist* *Bibliomation Inc.* 203-577-4070 <+12035774070> ext. 108

3 2

Re: [Eg-newdevs] Proposal: new angular components should be standalone
by Mike Rylander 28 Feb '25

28 Feb '25

I also agree with Galen's framing. Standalone components will definitely make the simple generic components easier to use, I think, but NgModules will still be useful for encapsulation in some important cases. Thanks, all! -- Mike Rylander Research and Development Manager Equinox Open Library Initiative 1-877-OPEN-ILS (673-6457) work: miker(a)equinoxOLI.org personal: mrylander(a)gmail.com https://equinoxOLI.org On Thu, Feb 27, 2025 at 5:26 PM Jane Sandberg via Eg-newdevs <eg-newdevs(a)list.evergreen-ils.org> wrote: > > +1 from me to Galen's formulation! Thanks for the discussion so far, Galen and Ruth! > > El jue, 27 feb 2025 a la(s) 1:02 p.m., Galen Charlton (gmc(a)equinoxoli.org) escribió: >> >> Hi, >> >> On Thu, Feb 27, 2025 at 9:10 AM Jane Sandberg via Eg-newdevs <eg-newdevs(a)list.evergreen-ils.org> wrote: >> > But my proposal is that after a certain date TBD, if you create a new component, please make it standalone. >> >> I think this is too strong at present until we collectively get more experience with standalone components. While the standalone model does look useful - and of course, in the long run it does not pay for us to try to buck what's a very clear trend in Angular's evolution - we do have several sets of closely-linked components where keeping them bundled in an NgModule may still make sense (e.g., eg-grid). I fear that - for now - setting an absolute requirement that new components be standalone may reduce flexibility and create an implicit expectation that we _must_ perform (and pay for in various ways) what would be a large refactoring of the existing NgModule-based app. >> >> Consequently, I would propose a different formulation in two parts: >> >> * Writing new Angular components as standalone is both permitted and encouraged >> * After more time has passed and we have more experience with wrestling with the management of dependencies for standalone components, we'll reevaluate whether a stricter mandate is warranted. >> >> By the way, I found this piece an interesting exploration of the opportunities and tradeoffs: https://borstch.com/blog/development/angulars-ngmodules-vs-standalone-compo… >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Implementation and IT Manager >> Equinox Open Library Initiative >> gmc(a)equinoxOLI.org >> https://www.equinoxOLI.org >> phone: 877-OPEN-ILS (673-6457) >> direct: 770-709-5581 > > _______________________________________________ > Eg-newdevs mailing list > Eg-newdevs(a)list.evergreen-ils.org > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs

1 0

Re: [Evergreen-general] Git server Reboot
by Terran McCanna 28 Feb '25

28 Feb '25

Thanks for the alert! On Fri, Feb 28, 2025 at 9:49 AM Jason Stephenson via Evergreen-general < evergreen-general(a)list.evergreen-ils.org> wrote: > Hi, all. > > The Evergreen git server will be rebooted at 4:30 PM EST (21:30 UTC, > 1:30 PM PST) today. It should be down for no more than 5 minutes. > > Sorry for the lack of much advance warning, but we don't have a > coordinated schedule for these things. (Perhaps we should but we're all > volunteers here.) > > Cheers, > Jason Stephenson > _______________________________________________ > Evergreen-general mailing list > Evergreen-general(a)list.evergreen-ils.org > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >

1 0