Comment 3 for bug 885270

If it is an intended feature (and based on comments in IRC, I guess it is) then I argue it is a *broken* feature.

My recommendation would be to re-implement it such that each user gets their own copy of the address and each address gets a pointer to the "parent" address that it is linked to. Said pointer would be a foreign key with an auto-null on delete, to automatically break the link if the parent is deleted. Otherwise a trigger would cascade the updates to the parent address into the children. One could require that editing the "child" address requires breaking the link between the two, which would be accomplished by setting the parent link to null (and could be a single button in the patron editor, setting the null and enabling the edit boxes).

Benefits to this method include inactive addresses being able to be linked between users, which would be very handy if automatically rotating out addresses. Otherwise rotating the addresses out will break the links.

Slightly related, if you expose the address IDs to staff you would also be able to trivially add a linked address to another patron. Clone the address, set the parent. Thus allowing you to add new addresses to one account and then go add them to another by manually linking sometime after the cloning was originally done. Or to a non-cloned record, in the case of marriage for example you could link the address entries together on previously unrelated accounts.