Hi, On Fri, Feb 28, 2025 at 4:00 PM Ian Skelskey via Evergreen-dev < [email protected]> wrote:
> *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? > > The intention is to allow members of a group of linked patrons to have an address update be done in one fell swoop by editing the address through the lead record in the group (or as is currently the case with the Angular patron registration form, any member of the group). It would also help ensure that the address of a child's account doesn't diverge from the parent/guardian's address. Reducing data entry work and ensuring consistent addresses among family members is a valid use case. Now, the feature as it exists has caused problems (and the "Patron Registration: Cloned patrons get address copy" setting exists for a reason). I think there are alternative approaches that could serve the purpose (e.g., having the patron editor offer to apply an address update to other members of a group), so I'm no partisan of the current design. However, just dropping it might come as a surprise to users. The evergreen-general mailing list will get at more people who can advise whether they use shared addresses. > > - Does anyone have that setting set to *false*? > > It's not common, but at least one of our customer systems has a library system with that setting set to false. > *3. Modify actor.usr_purge_data to Handle Shared Addresses Gracefully* > I think the intent of this is fine - and it could be done even if address sharing is left as is - but there's a detail to be worked out (and this may have contributed to this bug languishing for so long): actor.usr_address.usr links back to the patron that is intended to be the lead of the group. Consequently, if actor.usr_purge_data() is handling such a lead patron, some provision is needed to reassign actor.usr_address.usr to another member of the group (or to give up and - usefully - ask a human operator to sort out the grouped patrons). Regards, Galen -- Galen Charlton Implementation and IT Manager Equinox Open Library Initiative [email protected] https://www.equinoxOLI.org phone: 877-OPEN-ILS (673-6457) direct: 770-709-5581 <http://evergreen-ils.org>
_______________________________________________ Evergreen-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
