in short you said what I said, or intended to get across. have to sort through the commits to answer you about 9.04. if you have eclipse or want to learn svn line commands you can find the history of the ECA'a mentioned in the log.
========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Matt Warnock sent the following on 5/25/2010 3:29 PM: > Not sure I fully understand your comment, BJ. It seems to me that we > can't assume that updating one (Postal) address updates any or all other > matching addresses as well. > > The CC address is a billing address that is sometimes transmitted with > payment requests, and probably has to match the info your bank has for > you, or CC payments may be rejected. That address may or may not change > with the invoice address, or any other address. Certainly any change > there needs to be made with caution. > > Shouldn't an address change here simply link the new address (or an > existing one, if appropriate) to the contact mechanism "general > correspondence", "invoice/payment" or whatever? Why would it need to > lookup or verify EFT addresses at all? And shouldn't NameOnAccount be in > a separate entity from the address anyway? Or am I reading Silverston > wrong? > > Seems like usually (e.g. for partys, groups, etc), we take the approach > of <find> first, or <create> as necessary, then <link> with a relation, > in this case contact_mech. Here we throw up an edit screen and collect > a contact purpose and address, which is maybe rolling the <find> and > <link> together? > > What changed since 9.04? I would expect this part of the code to be > pretty stable. >
