If an individual contact is sharing the address of an organization contact and they submit a civi-integrated webform with a different primary address (the form exposes the individual contact's primary address with NO sharing specified), it updates the primary address information in the individual contact's record, but leaves the Shared Address fields enabled. So looking in Civi, it shows that the individual contact is sharing the address of the organization contact, but the address information is different. And then if you go to edit that individual contact record in Civi and save it (no change to any address info), the address reverts to the organization's address, assumed because the sharing tie is still there. When I defined and tested the form, I was expecting the sharing to be completely removed.

I think it's just a matter of setting the master_id to NULL on the address record.

Comments

jaymcgraw’s picture

One more comment to this. I guess you'd only want it to disconnect it from a shared address IF the submitted address information changed. If not, the shared address connection should remain in place.

colemanw’s picture

I seem to remember an issue with setting this value to null with the API -- key constraint failed or something. Maybe I'm wrong and it will work... worth a try.

jimurl’s picture

I just verified that this also happens with D6 version- the contacts address is changed, but the master_id (link to the Master address ID) is still pointed to the other contact's address ID.

colemanw’s picture

Yay, it worked. Something got fixed in the API, because now if I pass in the string 'null' it will delete the master id and "unshare" the address.
My approach is to always set master id to null, except in the case where nothing has changed, then the address won't be updated at all. This should give a little performance boost as well, as I've implemented the "skip if same" check for all location data.

I've committed this to the latest -dev, which is the soon-to-be-released version 2.4 -- note that this version is not compatible with CiviCRM prior to 4.1, and you should only upgrade to it if you have already upgraded Civi. You'll also need to run update.php. Webform_civicrm 2.4 contains numerous other improvements, so please help me test it so we can get it released!

colemanw’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.