OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-81) Support for PaymentMethod.description

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Nicolas Malin (Jira)

[jira] Created: (OFBIZ-81) Support for PaymentMethod.description

Support for PaymentMethod.description
-------------------------------------

Key: OFBIZ-81
URL: http://issues.apache.org/jira/browse/OFBIZ-81
Project: The Open For Business Project
Type: New Feature

Components: accounting
Reporter: Si Chen
Priority: Minor

Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")

Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419760 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

I'm going to again object to this approach. Not because this particular implementation is foreseeably too constraining, but rather because less than stellar design becomes precedent for future less than stellar design (ie "there's already examples of doing it this way").

I have three objections to this approach from a design point of view.

1) "Joe's Credit Card" is an alias for the Credit Card - not the payment method; "Our Main Checking Account" is an alias for the checking account - not the payment method.

2) "Joe's Credit Card" and "Our Main Checking Account" are aliases that do not have a one to one relationship with their control.

3) A data model should not be designed around the code that is manipulating it. Rather, the code should be modified around the data model.

I have no objection to creating a PaymentMethod.description as a denormalized field that is supported as a denormalized field (ie. a service populates PaymentMethod.description to CreditCardAttribut.attributeValue when CreditCardAtribute.attributeType="PRIMARY_ALIAS" changes)

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419763 ]

David E. Jones commented on OFBIZ-81:
-------------------------------------

I wouldn't worry too much about this comment. It shows a misunderstanding of the data model and the patterns we use in various places.

In a case where there is an entity, like PaymentMethod, that has other entities that futher describe the main entity depending on the type of that entity, here is the general rule for a new field:

- if the new field describes all types of the main entity it should go on the main entity

- if the new field describes only one, or a sub-set, of the types of the main entity, it should go on the entities for those types; if the field describes the majority of the sub-types it is okay for it to go on the main entity

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419764 ]

Si Chen commented on OFBIZ-81:
------------------------------

For anybody who'd like to read more on the history of this discussion, it's in the DEV list archives:
http://mail-archives.apache.org/mod_mbox/incubator-ofbiz-dev/200606.mbox/%3c71DEAF2E-AF5F-4B1B-9BF4-A624620EB726@...%3e

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419768 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

David,

The comment is not a misunderstanding of the data model or patterns used in various places. The comment is an attempt to repair the shortcuts that have been taken with the patterns. Those patterns fit the way many people would use the data model, but they are limiting.

Take the description fields of the Product entity for example.

A normalized data model would have two entities: Product and ProductDescription

Product would have fields productId, manufacturer partyId, casepack information, etc
ProductDescription would have productId, descriptionType, description, language, etc
with a relationship productId->productId

Now, a normalized data model does create a bottleneck because query is run much more than is update is.

To remove the bottleneck you create a DENORMALIZED data model that makes certain types of frequently querried descriptions REDUNDANT in the Product entity.

Instead of DENORMALIZING the OFBiz data model, it has been NONNORMALIZED it by making screens that directly update Product.longDescription and eliminating (or never having in the first place) the ProductDescription entity. The better pattern to would have been to have screens that update ProductDescription.description where ProductDescription.descriptionType = "LONG_DESCRIPTION" and ProductDescription.language="${mostFrequentlyUsedLanguage}"and having a seca or eca update Product.longDescription.

How is the pattern used in OFBiz better in any scenario than the one desribed here?

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419822 ]

David E. Jones commented on OFBIZ-81:
-------------------------------------

Chris: I'm only so interested in continuing this discussion due to time limits and what not. If you look at the data model from a pragmatic perspective, I think you'll learn a lot more than if you try to fit them into your preferred patterns.

With the Product entity, for example: the ProductDescription structure you are talking about is called the "ProductContent" entity in OFBiz. What's cool about it is that you can use that more flexible structure if it is needed or wanted, or if you put data in the fields directly on the Product entity then they will require less memory to cache, and can be faster overall.

There are a few things like this in OFBiz where there is some apparent redundancy, but it is there to support the variety of requirements and features that make OFBiz an option for so many organizations.

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419831 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

Don't give up on the discussion now, David, we're almost on the same page. ;)

The Product / ProductDescription entity example was to simplify the illustration. Explaining a Product / ProductContent/ Content / DataResource / ElectronicText? example would be more dificult to explain and to follow.

>>There are a few things like this in OFBiz where there is some _apparent_ redundancy. <<

Having the redundancy is fine. I have no objection to there being redundancy in the data model for frequently querried fields. The objection here is that the data isn't becoming redundant.

If this example were redundant in OFBiz, Catalog Manager -> Product -> Content -> Override Simple Fields screen would update the ElectronicText Entity, and then a SECA or ECA would update the Product Entity's redundant, denormalized field. In other words, the data in Product.longDescription would exist in the ElectronicText? entity. If it were redundant, you could still find all of the Product Content in a single entity. Because there is only _apparent_ redundancy, you need to look in two places to obtain a complete set of a product's content.

The current pattern is trying to obtain the benefits of redundancy in querry at the cost of finding information where it is expected to be found. It's not necessary. If you want the benefit of redundancy in query then actually be redundant.

This is the same problem that arises by creating Payment.description as THE field to implement what Si is suggesting. If you want the benefit of query on the Payment entity have a SECA or ECA update Payment.description from source fields (CreditCard.description, GiftCard.description, BillingAccount.description, etc).

This also becomes an issue for backwards compatability. If what I have proposed in OFBIZ-74 is palatable and is more advantageous than the current checkout approach, this issue's approach creates orphaned information as Si's intended query would be done on the CheckoutMethod.description field. Actual, redundant data can be removed without consequence. _Apparent_, redundant data cannot be removed without consequence.

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419840 ]

David E. Jones commented on OFBIZ-81:
-------------------------------------

Chris: I'm sorry to say it, but some of this just isn't correct. Could I recommend reviewing code to test some of your assumptions?

For the Product description stuff: there isn't really any redundancy. If the fields on the Product entity are populated it won't look at the corresponding ProductContent records, that is part of the pattern. It works out very nicely and support the needs of both camps: those that want the simple fields and those that want the managed content, and this even though it was implemented this way incrementally as the fields on the Product entity were there from the beginning, and the ProductContent stuff was added later. The way this works has nothing to do with ECAs or anything. Copying that data over would kill the flexibility of the ProductContent model.

As for Payment.description... why would we have a description field on the sub-type entities like CreditCard and such? That just isn't making sense to me.

Just a side note: BillingAccount is NOT a payment type and if I have any say in it never will be as it confuses the purpose of it and related entities.

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commenté: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419847 ]

Jacques Le Roux commented on OFBIZ-81:
--------------------------------------

Hi Chris, David,

I'm very far to be a DB specialist (actually I always tried to avoid working with DB, my background is IA, symbolic-logical part) but I find this discusssion interesting.

The main reason is that I worked at the beginning in OFBiz mostly on i18n. And I had a hard time understanding the way OFBiz manages description (aka content).

I think that Chris as a point when he say :

<<Catalog Manager -> Product -> Content -> Override Simple Fields screen would update the ElectronicText Entity, and then a SECA or ECA would update the Product Entity's redundant, denormalized field. In other words, the data in Product.longDescription would exist in the ElectronicText? entity. If it were redundant, you could still find all of the Product Content in a single entity. Because there is only _apparent_ redundancy, you need to look in two places to obtain a complete set of a product's content.

The current pattern is trying to obtain the benefits of redundancy in querry at the cost of finding information where it is expected to be found. It's not necessary. If you want the benefit of redundancy in query then actually be redundant.>>

I can't say more for the moment, I agree with Chris about this point but have not enough time yet to think about a solution around description/content and i18n problem. What is interesting me at most is to build an *easier* interface for admin to modify i18n contents (name, descriptions) of at least catalogs, categories and products (did I miss something here?).

About that point I propose a patch in OFBIZ-75 for i18n of categories. If a commiter has some time to spent...

Thanks

Jacques

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commenté: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419850 ]

Jacques Le Roux commented on OFBIZ-81:
--------------------------------------

David,

Sorry, I wrote my comment before yours but sent it after.

I agree with you about the flexibility of the current pattern. Actually I don't feel concerned by the normalized/de-normalized discussion. I just find that trough the UI we may help beginners to understand the override concept (perhaps just a sentence to explain a little bit, as there are already in some places) and help them to find their way to change i18n content.

Jacques

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12419853 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

I take it back. We're not almost on the same page. We may not even be reading the same book. What is it that you think I mean when I say "redundant" and "denormalize"? I think we may have a difference in vocabulary.

Please reread my comment 12419831.

The point was precisely that there wasn't any redundancy. The point is that there SHOULD BE.

HOW IT IS:
Sometimes product content is added to ProductContent entity (and the rest of that chain) by the user
Sometimes it is added to the Product entity by the user
Never is it added to both.
Never is a SECA used
Never is a ECA used
A gap exists in the Product descriptions that are resolved through code
***Disadvantage with this approach ***
absent utilizing the same coding pattern (ie two querries and mapping) a gap will will exist in the result set.

HOW IT SHOULD BE:
Always have product content added to ProductContent entity (and the rest of that chain) by the user
Never have it added to the Product entity by the user
Always have the system add the content to the Product entity through a SECA or ECA
***Disadvantage of this approach***
Slight bit of overhead when primary product descriptions are updated (rarely)

I don't see how that removes ANY flexibility on the ProductContent model.

>>As for Payment.description... why would we have a description field on the sub-type entities like CreditCard and such? That just isn't making sense to me. <<

From a design point of view, you're looking at the wrong end of the horse. You're starting with the PaymentMethod entity and asking "What kind of different payment methods exist out there?"

The way the Entity-Relationship model works is:
"Hey I have a Credit Card. What's everything I can know about this Credit Card?" - creditCardId, creditCardNumber, bank, description, etc
and
"Hey I have a Gift Card. What's everything I can know about this Gift Card?" - giftCardId, giftCardBalance, description, etc
and
"Hey I have a Checking Account. What's everything I can know about this Checking Account?" - checkingAccountId, checkingAccountNumber, bank, description, etc
and
"You know what? Credit Cards and Gift Cards and Checking Accounts IN SOME CONTEXTS perform the same function, it would be really convenient to create an Entity to describe this relationship. In some contexts they are all used to actually transfer funds."

This is a properly designed, normalized Entity-Relationship data model.

You put this properly designed, normalized data model into production and you find that it's a bit sluggish because it has to do three querries to return the description of each of the payment methods. So you think "hey, if I put the description field into the PaymentMethod entity then in the context that I use it the most, I'll only have to do one query." That would be just fine. That's denormalizing the data model for performance. The difference between "just fine" and what OFBiz does is the following:

JUST FINE:
Service populates PaymentMethod.description by looking up CreditCard.description and GiftCard.description and CheckingAccount.description during a time when the load is low. This is redundant, meaning the data is in two places. The source in CreditCard.description, GiftCard.description, CheckingAccount.description and the copy in PaymentMethod.description

What OFBiz does:
"Well I'll be, all of our payment methods have descriptions. We can simplify our data model by moving the description to the PaymentMethod entity and getting rid of CreditCard.description, GiftCard.description and CheckingAccount.description. Shoot, I can describe the same data with two less fields (+1 field, -3 fields). Ain't I smart?"

Now consider this example:

Gift Cards are only Payment Methods in SOME contexts. Now lets say you have a marketing department that is really big on Gift Card type promotions and personalizing those Gift Cards for their customers. And the marketing department goes crazy with their promotions. In their promotions they have Coupon codes, gift cards, referral incentives, and they go:
"Hey CouponCodes, and GiftCards and ReferalIncentives IN SOME CONTEXTS perform the same function, it would be really convenient to create an entity to descirbe this relationship."
Let's evaluate this results of this scenario in the "just fine" approach and what OFBiz does.

JUST FINE:
Service populates Promotion.description by looking up GiftCard.description and CouponCode.description and ReferralIncentive.description during a time when the load is low. This is redundant, meaning the data is in two places. The source in GiftCard.description, CouponCode.description and ReferalIncentive.description and the copy in Promotion.description.

What OFBiz does:
Well we can go ahead and put ReferralIncentive.description and CouponCode.description into Promotion.description and get ride of ReferralIncentive.description and CouponCode.description. But, where are we going to get GiftCard.description? Oh, we have to do a querry to first get the related GiftCard, then another Query to get the related PaymentMethod. So while the marketing department is hogging the server doing querries on PaymentMethod for their Promotion, none of their customers who are answering the promotion can access the site and actually buy stuff. "Ain't I smart?"

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor

>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=all ]

Ashish Vijaywargiya updated OFBIZ-81:
-------------------------------------

Attachment: Product_Description_July_14.patch

Hi,
In this patch i added a field "description" in PaymentMethod entity.
And also added support for this field in the create, update, and view payment method services.

I worked in Party,Accounting,ecommerce and order component.
There were some small mistake in ecommerce like update button for Gift Card was not working and there were some display text problem in Gift Card screen...I resolved all this small mistakes.

If by mistaken i forgot something then please let me know.
Thanks for your support.

Thanks & Regards
Ashish Vijaywargiya

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Type: New Feature

> Components: accounting
> Reporter: Si Chen
> Priority: Minor
> Attachments: Product_Description_July_14.patch
>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=all ]

Ashish Vijaywargiya updated OFBIZ-81:
-------------------------------------

Attachment: PaymentMethod_Description_July_15.patch

Hi,
In this page there are some improvement in viewprofile.ftl file of "party" and "ecommerce " component.

Regards
Ashish

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Issue Type: New Feature
> Components: accounting
> Reporter: Si Chen
> Priority: Minor
> Attachments: PaymentMethod_Description_July_15.patch, Product_Description_July_14.patch
>
>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12421216 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

Many thanks to Ashish and his efforts for creating a patch that completes the approach.

If I may ask a question, though. Why is the patch being applied without first answering the flaws with the approach?

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12421218 ]

David E. Jones commented on OFBIZ-81:
-------------------------------------

Please don't hesitate to ignore this last comment from Chris. The comments about supposed flaws were answered, he simply refused to accept them. For this case it makes absolutely no sense to add a description field to the various sub-entities instead of to the main entity, neither from a pragmatic point of view for the design nor the actual details of what is intended to be implemented.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12421222 ]

Chris Howe commented on OFBIZ-81:
---------------------------------

They are not "sub-entities" of PaymentMethod. In ONE CONTEXT CreditCard, GiftCard, etc are used as methods of payments. They ARE NOT used as methods of payment in ALL contexts. Treating them as if they are ALWAYS used in that ONE CONTEXT is a FLAW.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=comments#action_12421224 ]

Leon Torres commented on OFBIZ-81:
----------------------------------

Hi Ashish, I'm looking through the July 15 patch above. It's exposing the GL Account ID to a customer in ecommerce who is looking at his profile. Probably don't want to do that.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=all ]

Ashish Vijaywargiya updated OFBIZ-81:
-------------------------------------

Attachment: PaymentMethod_Description2_July_15.patch

Thx Leon.
I removed the GL account info from the ecommerce viewprofile.ftl file.

Regards
Ashish Vijaywargiya

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Issue Type: New Feature
> Components: accounting
> Reporter: Si Chen
> Priority: Minor
> Attachments: PaymentMethod_Description2_July_15.patch, PaymentMethod_Description_July_15.patch, Product_Description_July_14.patch
>
>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.

Nicolas Malin (Jira)

[jira] Closed: (OFBIZ-81) Support for PaymentMethod.description

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-81?page=all ]

Si Chen closed OFBIZ-81.
------------------------

Fix Version/s: SVN trunk
Resolution: Fixed

Thanks for your help Ashish!

> Support for PaymentMethod.description
> -------------------------------------
>
> Key: OFBIZ-81
> URL: http://issues.apache.org/jira/browse/OFBIZ-81
> Project: The Open For Business Project
> Issue Type: New Feature
> Components: accounting
> Reporter: Si Chen
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: PaymentMethod_Description2_July_15.patch, PaymentMethod_Description_July_15.patch, Product_Description_July_14.patch
>
>
> Add additional field "description" to PaymentMethod to describe the payment method (ie, "Joe's credit card" or "Our main checking account")
> Add support for this field in the create, update, and view payment method services.