Wish List: Copy more fields when using save & clone

Bug #1857353 reported by Terran McCanna
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Wishlist
Unassigned

Bug Description

Since thepatron Save & Clone option is typically used when adding children accounts from a parent's account, our libraries request that the phone number and email address are copied from the parent account when cloning. Our staff feel that it would be more efficient to delete/modify phone numbers and email addresses from the child accounts that have different info than it is to re-enter or copy and paste all of the phone numbers and email addresses that are the same.

Tags: patron
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

If anyone wants to adjust which fields get cloned locally, there is a list of which fields to clone at
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/circ/patron/regctl.js;hb=HEAD#l989

I'm on an old version, so I'm not sure if this still applies to the newest interfaces.

I just tried adding
'email',
'alert_message',
'guardian',
'family_name',

and those worked fine.

It looks like the user permission profile was intended to be cloned, but wasn't changed after the line was copied from a different function.

if (user.profile) user.profile = egCore.env.pgt.map[user.profile];
should be
if (clone_user.profile()) user.profile = egCore.env.pgt.map[clone_user.profile()];

I'm looking into how the patron preferences and stat cats can be cloned.
Josh

Revision history for this message
Terran McCanna (tmccanna) wrote :

Oh cool, thanks!

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I've been attempting to allow the users settings to be cloned also... but I'm running into the fact that normally a user's settings are loaded via the "open-ils.actor.patron.settings.retrieve" call, which seems to automatically convert "true" "false" into booleans instead of leaving as strings. The values are run through JSON2perl.

The cloned user data is loaded via a single call to "open-ils.actor.user.fleshed.retrieve" which does not seem to have the values run through JSON2perl.

So I'm not sure if the correct way to do this is to add in some manually handling, look for "true" and "false" strings and change to boolean when cloning the data.

Or maybe remove the "settings" field from the call to retrieve the clone user, and then call the "open-ils.actor.patron.settings.retrieve" afterwards to fill in the settings data for the cloned user.

Another issue that I found is that applying the new patron defaults, in relation to extract_hold_notify overwrite the hold notify settings when cloning users. So that will need to be adjusted so the hold notify settings can get cloned.

Josh

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Josh,

A few thoughts on user settings:

1. I'm not entirely sure that I agree that they should be cloned. Maybe it should be determined by YAOUS?

2. There are a couple of perl2JSON methods where the JSON2perl method comes from: OpenSRF::Utils::JSON.

3. I'm pretty sure that if you have actor.usr_setting (aus) objects, you can update the user or use the backend/CStore methods without having to worry about converting them. Have you tried this and it failed?

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hello Jason, thanks for the feedback.

1. I agree that probably not everyone would want this. The majority of our use of clone user is for families that are signing up with a single form, that sets notification and other preferences for all the users. So we would want the hold notification and the opt-in settings to match. Same for the stat cat entries, we only have one, which would be the same for each cloned user. But I know that the use of the user stat cats varies widely. So maybe two settings, one for the stat cat data, and one for the registration visible user settings.

2. Understood. Looks like the OpenSRF::Utils::JSON versions are the ones being used in both retrieving and setting the users settings for the patron registration form currently.
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;hb=3eeaacf4ac3be6abd10596aec83ad0ea2309a272#l315

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;hb=3eeaacf4ac3be6abd10596aec83ad0ea2309a272#l97

3. I think the problem that I'm running into is that the form controls, the checkboxes in particular expect a boolean value. The aus objects return the values as json encoded I believe.

Normally the registration/edit form loads and saves the settings values with calls to open-ils.actor.patron.settings.retrieve and open-ils.actor.patron.settings.update. So I don't think the regctl.js updates the user settings using Cstore methods. I'm not sure I want to re-write how the data is saved... I just want to populate the forms user settings values with the data from the cloned user.

Maybe I'm missing a simple method to do what JSON2perl does in javascript? Should I be using something like JSON.parse() on the aus.value to perform the same conversion as the OpenSRF::Utils::JSON->JSON2perl does?

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Yep, I was missing something simple, running the aus value data through JSON.parse() seems to work.

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Here is a commit that enables cloning the user settings, stat cats and permission group on our 3.3 system.
https://gitlab.com/LARL/evergreen-larl/-/commit/9a817928000bb8ad150c112e9f572fab6e0576b9

Here is a commit that adds email and alert message fields also.
https://gitlab.com/LARL/evergreen-larl/-/commit/68bb2b43a5ce6c6378ef33a23859f9ef91ef3f74

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote (last edit ):

This also resolves the fact that it isn't possible to use the registration default value in the opac.hold_notify user setting type to customize which of the notification checkboxes get checked by default for new patrons.

Because
extract_hold_notify(); gets run before set_new_patron_defaults(prs);, the default settings for opac.hold_notify are overwritten by the settings in the set_new_patron_defaults function. Which hardcode the settings to phone:true, email:true, sms:false.

Maybe that should be it's own bug? So it doesn't have to wait for the cloning fixes to get enhanced with org unit settings.

Josh

Revision history for this message
Terran McCanna (tmccanna) wrote :

Noting comment from bug 1981857 to add email and ID as well.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.