Save & Clone Action Results in Pending Address

[John Amundson]

Evergreen 3.0.13
Evergreen 3.2.4

We have the following library settings set, (though I don't know how much of an impact they have on this bug):
Allow Pending Addresses: UNSET
Patron Registration: Cloned patrons get address copy: TRUE

When a patron account is saved and cloned in the web client, the resulting patron record ends up with a pending address. This does not happen in the XUL client and it didn't happen in our installation of an earlier release of 3.0.

This seems to have begun in 3.0.12 as we had no pending addresses in our database prior to our 3.0.12 upgrade. (I'm wondering if it's related to this fix: LP #1724083).

If staff try to approve the address before the account is fully created, (i.e while still on the registration screen), staff receive the following pop-up error message: Event: 1528:ACTOR_USER_ADDRESS_NOT_FOUND -> Requested address was not found. (This makes sense since the address hasn't actually been created yet). The address can be approved if the record is saved.

Save & Cloning a patron should not result in a pending address.

[Jennifer Pringle (jpringle-u)]

We're seeing this in 3.1.7

[Terran McCanna (tmccanna)]

This is still a problem in 3.4.

[Terran McCanna (tmccanna)]

This is still a problem in 3.6.1.

When Saving and Cloning, the "Approve" button appears above the address, but clicking on it gives the error: "Event: 1528:ACTOR_USER_ADDRESS_NOT_FOUND -> Requested address was not found"

You have to first save the patron, then go back and re-open it to approve the pending address.

[Josh Stompro (u-launchpad-stompro-org)]

Hello, I was trying to track this down this morning, and I wonder if the problem has to do with translating between "t" and True or rather "f" and False.

I noticed that in the clone_addr(addr) function, .valid gets set to true, while in the source address it is set to 't'. So maybe we just need some logic to deal with it there, to set pending = false. I'm not sure if we need to handle cloning a pending address... or if we can assume that if we are cloning, it doesn't need to be pending?

// copy the billing and mailing addresses into new addresses
            function clone_addr(addr) {
                var new_addr = egCore.idl.toHash(addr);
                new_addr.id = service.virt_id--;
                new_addr.usr = user.id;
                new_addr.isnew = true;
                new_addr.valid = true;
                user.addresses.push(new_addr);
                return new_addr;
            }

It looks like the
service.ingest_address function normally fixes the booleans... but doesn't get used during a clone.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

I think that is it after doing some testing.

Adding
new_addr.pending = addr.pending === 't'; to the clone_add function translates the pending string into a boolean.

I think that the city limits value may also be getting messed up during cloning since it also isn't handled... let me test that.

Josh

[Galen Charlton (gmc)]

Yeah, you've run into a quirk of IDL objects. Boolean database fields will get represented as the strings 't' or 'f'.

However, isnew, isdeleted, and ischanged are not database fields, but rather special fields that signal to egCore.pcrud.apply what action to take on a record. Those three accept Javascript truthy and falsey values.

[Josh Stompro (u-launchpad-stompro-org)]

Working branch at:
user/stompro/lp1821804_cloned_address_pending

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1821804_cloned_address_pending

It seems like the city limits issue only has to do with the display of the checkbox... even though the checkbox was unchecked, the city limits does get set to match the parent address in my testing.

Josh

[Ruth Frasur Davis (redavis)]

You are now able to approve the pending address in the patron registration screen with cloned information. I've tested this code and consent to signing off on it with my name, Ruth Frasur, and email address, <email address hidden>.

[Bill Erickson (berick)]

Merged to 3.6 and up. Thanks, All!