ContactMechPurposeType bad design

[Adam Heath-2]

There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
BILLING_LOCATION, etc.  Why can't that just be PRIMARY, BILLING, etc?

[Cimballi-2]

Not sure about the original idea, but from my point of view this helps
to know what kind of contact mech is behind the purpose type.
For example, if you have a party and you want to get its primary email
contact mech, you search for PRIMARY_EMAIL and you know you will have
only emails (well, if you didn't mess up everything... :-).
If it was only PRIMARY, it could be any kind of contact mech, you
would then have to go through the list to retrieve the contact mech of
type email.

Maybe another solution would be to have hierarchical types, so you
would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
would return PRIMARY and PRIMARY_EMAIL.

HTH,

Cimballi


On Mon, Feb 1, 2010 at 4:23 PM, Adam Heath <[hidden email]> wrote:
> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
> BILLING_LOCATION, etc.  Why can't that just be PRIMARY, BILLING, etc?
>

[Adam Heath-2]

Cimballi wrote:
> Not sure about the original idea, but from my point of view this helps
> to know what kind of contact mech is behind the purpose type.
> For example, if you have a party and you want to get its primary email
> contact mech, you search for PRIMARY_EMAIL and you know you will have
> only emails (well, if you didn't mess up everything... :-).
> If it was only PRIMARY, it could be any kind of contact mech, you
> would then have to go through the list to retrieve the contact mech of
> type email.

There is a view to handle that.

>
> Maybe another solution would be to have hierarchical types, so you
> would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
> would return PRIMARY and PRIMARY_EMAIL.

PRIMARY_EMAIL and PRIMARY_LOCATION are not normalized.  You know it is
already an EMAIL_ADDRESS or a POSTAL_ADDRESS, by looking at the
associated ContactMech.contactMechTypeId field.

[Malin Nicolas]

Cimballi a écrit :
> Not sure about the original idea, but from my point of view this helps
> to know what kind of contact mech is behind the purpose type.
> For example, if you have a party and you want to get its primary email
> contact mech, you search for PRIMARY_EMAIL and you know you will have
> only emails (well, if you didn't mess up everything... :-).
> If it was only PRIMARY, it could be any kind of contact mech, you
> would then have to go through the list to retrieve the contact mech of
> type email.
>  
You right if you want find information from ContactMechPurposeType but
the Type information is also present on ContactMech by contactMechTypeId
and you can find this with entityview

> Maybe another solution would be to have hierarchical types, so you
> would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
> would return PRIMARY and PRIMARY_EMAIL.
>
> HTH,
>
> Cimballi
>
>
> On Mon, Feb 1, 2010 at 4:23 PM, Adam Heath <[hidden email]> wrote:
>  
>> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
>> BILLING_LOCATION, etc.  Why can't that just be PRIMARY, BILLING, etc?
>>
>>    

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[hans_bakker]

If we change that and can still select a "primary email" then that
sounds pretty good...however isn't this often used in the system?

On Mon, 2010-02-01 at 15:23 -0600, Adam Heath wrote:
> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
> BILLING_LOCATION, etc.  Why can't that just be PRIMARY, BILLING, etc?
--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Ruth Hoffman-2]

Hi Hans:
Yes, this is used in other places.
What exactly do you mean by "change"?
Regards,
Ruth

Hans Bakker wrote:
> If we change that and can still select a "primary email" then that
> sounds pretty good...however isn't this often used in the system?
>
> On Mon, 2010-02-01 at 15:23 -0600, Adam Heath wrote:
>  
>> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
>> BILLING_LOCATION, etc.  Why can't that just be PRIMARY, BILLING, etc?
>>