Closed (fixed)
Project:
e-Commerce
Version:
master
Component:
payment
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
3 Oct 2005 at 09:55 UTC
Updated:
23 Jul 2007 at 17:13 UTC
Jump to comment: Most recent file
please find attached a patch for HEAD to fix initial payment status assignment (pending) when using a translated ecommerce.
this patch for HEAD also fix misc translation issues already fixed for 4.6, see http://drupal.org/node/31936
patch modifies cart.module, payment.module, product.module, and store.module.
thanks
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | ec-head-payment-status-transaction-workflow-fix.patch | 1.6 KB | PierreM-1 |
| #12 | ec-head-payment-status-fix_3.patch | 777 bytes | PierreM-1 |
| #9 | ec-head-payment-status-fix_2.patch | 789 bytes | syllance |
| #2 | ec-head-payment-status-fix_1.patch | 788 bytes | ñull |
| #1 | ec-head-payment-status-fix_0.patch | 791 bytes | syllance |
Comments
Comment #1
syllance commentedhere's a new patch that only fix the payment status problem.
function payment_build_status() returns translated strings, so t() calls were removed in payment_get_status() and payment_get_status_id(), fixing the initial payment status bug when using translated ecommerce.
fix for translation issues was moved to a translation related thread, here : http://drupal.org/node/34096
Comment #2
ñull commentedIn your payment status patch I discovered something that imho looks incorrect to me:
should be:
Comment #3
syllance commentedafter a quick look, i don't think the t() should be removed.
payment_get_status_id() is called using untranslated status strings, such as : payment_get_status_id('pending') or ('failed'). the function uses array_search to find the index of its parameter (untranslated status string) in the payment status array returned by payment_build_status. this array contains translated strings, so i think the array_search should be done with both translated strings. that's why the t() is imho needed (and was there in the original code).
my last comment is wrong (writtent quickly ... sorry), but my patches should be correct.
are you facing any issue due to this particular t() call ?
Comment #4
ñull commentedIt is my suspicion that a problem I see with Paypal transactions have to do with it. I use Spanish localized version and your patches drew my attention.
With Paypal sandbox transactions I saw a blank payment status and did not I see them updated through IPN. I am still fiddling around with it and will report if that was the problem or not.
Comment #5
ñull commentedPaypal sandbox was down today. I could not continue my tests :-(
I will continue after the weekend.
Comment #6
syllance commentedwhile playing with the latest 4.6 e-commerce, which now contains backported HEAD code, i faced again the issue of payment status not being set, and the _0 patch fixes it.
the patch for head now also applies to 4.6.
Comment #7
syllance commentedthere's a similar issue with workflow status, and i've sent a similar patch (http://drupal.org/node/36284). my setups still works fine with the _0 patch of this issue, although i did not yet played very much with paypal.
com2, did you find anything new on this ? is the paypal problem happening after applying my _0 patch ?
Comment #8
ñull commentedYes, sorry for the late response. I found another error that caused my problem, in the Paypal module. See here for more details: http://drupal.org/node/36083 . If you have access to CVS, could you please include it after verifying?
Comment #9
syllance commentedok. thanks for the update com2. i'm posting a new patch that applies to latest HEAD.
it does the same job than my first patch, it was just updated to follow HEAD changes.
If you look at the issues postings, you'll see that there are a lot patches that would be added to CVS if i had an account :-)
Comment #10
syllance commentedthe patch also applies to 4.6.
Comment #11
ñull commentedWhen I apply this patch I still get incorrectly zero totals on the store overview page, only when I set the user to another language then English. Then when I add
t( )around the status strings in the get...id functions:only then I see the totals correctly in the other language. This, however, is difficult to understand when you see that both functions (transaction_get_workflow_id and payment_get_status_id) translate the parameter already:
Can you explain why there would be a need to translate twice, once outside and once inside these functions? And when you understand it, can it be done better? I did not want to upload a patch until I understand what I am doing.
Comment #12
PierreM-1 commentedThe latest patch (ec-head-payment-status-fix_2.patch) works for me and fixes a bug with cod.module not changing the payment status to completed (when the option is selected in cod settings), as the bug makes payment_get_status_id returning nothing.
I am not sure if the "strtolower" call in the patch is necessary since payment_build_status returns a case-untouched array. I am correcting this in ec-head-payment-status-fix_3.patch.
I think this patch can be commited.
Comment #13
PierreM-1 commentedThere is a similar issue with transaction_get_workflow functions. It breaks the store admin overview.
Here is a patch against HEAD that corrects both transaction workflow and payment status functions.
Comment #14
simebumping - a lot of work went into this it seems
Comment #15
brmassa commentedIts simply too old. anyone that wants to continue the issue, reopen it.