Weird way to manage the CreditCard.cardType field

[Jacopo Cappellato]

Is there a reason for hardcoding the credit card types in the following
template:

http://svn.apache.org/repos/asf/ofbiz/trunk/framework/common/webcommon/includes/cctypes.ftl

?

Why not getting the values from the Enumeration entity (we already have
value for credit card types, with enumTypeId="CREDIT_CARD_TYPE")?

Also, I've noticed that in the CreditCard.cardType field, instead of
storing the Enumeration.enumId field (e.g. CCT_VISA) we store the
Enumeration.enumCode field (e.g. "Visa")

Jacopo

[Vince Clark]

I agree. The only reason for this AFAIK is to give granular control for what CC's are available on a website.

It would be better to set it on the store payment settings.

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: [hidden email]
Sent: Monday, December 10, 2007 10:39:26 AM (GMT-0700) America/Denver
Subject: Weird way to manage the CreditCard.cardType field

Is there a reason for hardcoding the credit card types in the following
template:

http://svn.apache.org/repos/asf/ofbiz/trunk/framework/common/webcommon/includes/cctypes.ftl 

?

Why not getting the values from the Enumeration entity (we already have
value for credit card types, with enumTypeId="CREDIT_CARD_TYPE")?

Also, I've noticed that in the CreditCard.cardType field, instead of
storing the Enumeration.enumId field (e.g. CCT_VISA) we store the
Enumeration.enumCode field (e.g. "Visa")

Jacopo

[Jacques Le Roux]

Jacopo,

Quick guess, could this be related to CC specific methods in UtilValidate.java (getCardType) ?

De : "Vince M. Clark" <[hidden email]>
> I agree. The only reason for this AFAIK is to give granular control for what CC's are available on a website.
>
> It would be better to set it on the store payment settings.

To only be able to use/remove existing CC coded in the system (because of the CC specific methods in UtilValidate.java ) ? Then, yes
why not. Else (adding new CC types) seems a bit harder (pre-coded way)...

Jacques

> From: "Jacopo Cappellato" <[hidden email]>
> To: [hidden email]
> Sent: Monday, December 10, 2007 10:39:26 AM (GMT-0700) America/Denver
> Subject: Weird way to manage the CreditCard.cardType field
>
> Is there a reason for hardcoding the credit card types in the following
> template:
>
> http://svn.apache.org/repos/asf/ofbiz/trunk/framework/common/webcommon/includes/cctypes.ftl
>
> ?
>
> Why not getting the values from the Enumeration entity (we already have
> value for credit card types, with enumTypeId="CREDIT_CARD_TYPE")?
>
> Also, I've noticed that in the CreditCard.cardType field, instead of
> storing the Enumeration.enumId field (e.g. CCT_VISA) we store the
> Enumeration.enumCode field (e.g. "Visa")
>
> Jacopo
>

[Jacopo Cappellato]

Jacques Le Roux wrote:
> Jacopo,
>
> Quick guess, could this be related to CC specific methods in UtilValidate.java (getCardType) ?
>

Yes, you are right Jacques... thanks for bringing this to my attention.
I've created a Jira issue to remember this: OFBIZ-1524

Thanks,

Jacopo

> De : "Vince M. Clark" <[hidden email]>
>> I agree. The only reason for this AFAIK is to give granular control for what CC's are available on a website.
>>
>> It would be better to set it on the store payment settings.
>
> To only be able to use/remove existing CC coded in the system (because of the CC specific methods in UtilValidate.java ) ? Then, yes
> why not. Else (adding new CC types) seems a bit harder (pre-coded way)...
>
> Jacques
>
>> From: "Jacopo Cappellato" <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, December 10, 2007 10:39:26 AM (GMT-0700) America/Denver
>> Subject: Weird way to manage the CreditCard.cardType field
>>
>> Is there a reason for hardcoding the credit card types in the following
>> template:
>>
>> http://svn.apache.org/repos/asf/ofbiz/trunk/framework/common/webcommon/includes/cctypes.ftl
>>
>> ?
>>
>> Why not getting the values from the Enumeration entity (we already have
>> value for credit card types, with enumTypeId="CREDIT_CARD_TYPE")?
>>
>> Also, I've noticed that in the CreditCard.cardType field, instead of
>> storing the Enumeration.enumId field (e.g. CCT_VISA) we store the
>> Enumeration.enumCode field (e.g. "Visa")
>>
>> Jacopo
>>