Thank you David.
We could replace ContactMechLink with ContactMechAssoc/
ContactMechAssocType and add a few types like "RELATED_TO" and
"ALTERNATE_OF" (or similar).
In this way we could setup something like:
FirstPostalAddress -RELATED_TO-> FirstPhoneNumber
^
|
ALTERNATE_OF
|
SecondPostalAddress -RELATED_TO-> SecondPhoneNumber
...
Is it a good idea?
Jacopo
On Oct 11, 2009, at 8:14 PM, David E Jones wrote:
The usual approach so far has been to associate both contact mechs
to the OrderItemShipGroup or whatever. If I understand right what
you are going for is to allow a user to associate them in advance
instead of having to select both on checkout/etc.
I like the ContactMechLink idea a lot better than the Facility idea.
I think you're right that ContactMechLink isn't used, and probably
hasn't ever been updated from the original data model from the Data
Model Resource Book. So yeah, updating and using ContactMechLink
would be my vote.
-David
On Oct 10, 2009, at 4:56 AM, Jacopo Cappellato wrote:
Hi all,
what is the best way to divide into groups the contact mechanisms
of a party.
For example:
a party may have one primary postal address and phone number, plus
a series of alternative postal addresses each with its own phone
number.
Using the PartyContactMechPurpose entity we can define the postal
addresses as "SHIPPING_LOCATION" and, for the primary postal
address we can use also the "PRIMARY_LOCATION"; for the phones we
can use the "PHONE_SHIPPING" purpose and for the phone associated
to the primary postal address we could also use the "PRIMARY_PHONE".
The problem is that, with the above setup, there is no way to
specify, for example, that the phone number #3 is associated with
the postal address #3... I would just end up with a set of
alternative phone numbers and an independent set of alternative
postal addresses.
I know that we could define a facility for each alternative address
(and the contact mechs will be associated to it), but for ecommerce
customers this seems a bit too complex.
I have seen the entity ContactMechLink that could be a good way to
link together a postal address with a phone number, but the entity
is not currently used and it seems not based on ofbiz conventions.
Any hints?
Jacopo
