Closed (fixed)
Project:
Moneris Payment Gateway for Ubercart
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
25 Jun 2009 at 17:43 UTC
Updated:
18 Sep 2009 at 18:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
gregglesYep, this makes sense to me.
Comment #2
tr commentedOK, here are the patches. uc_moneris.module.patch renames the variables in the module. uc_moneris.install.patch adds an update function which copies the values of the old variables into the new ones, then deletes the old ones.
Comment #3
gregglesUntested, but don't we need something more like the attached so that the form saves the variables in the right place? I changed the values in the form array in uc_moneris_settings_form.
Comment #4
tr commentedI'm not against changing the form keys for consistency, but it's not necessary. The keys are only used to save variables when using system_settings_form(), which is not the case for this module.
Comment #5
gregglesAh, yeah, that makes sense. Thanks, TR!
Committed - http://drupal.org/cvs?commit=256168
Comment #6
tr commentedActually ...
This got me thinking about how the form settings are saved in uc_moneris, so I looked at the code and I don't see anywhere where the variables are set - they're only used. So clearly they're saved somewhere else, outside the uc_moneris module.
Digging a little deeper, it seems uc_payment_gateways_form() invokes hook_payment_gateway() (by calling _payment_gateway_list()) in order to find out which functions the gateways use to define their settings. In the case of uc_moneris, that function would be uc_moneris_settings_form().
Then uc_payment_gateways_form() invokes these individual gateway settings forms and MERGES the returned $form from these functions into one big form, which is THEN processed as a system_settings_form() ! So that's how the form values get saved as variables - system_settings_form() IS being used, but this fact is obscured.
Bottom line, you're right that the form keys MUST be changed, but not for the reason you thought!
Comment #7
gregglesCrosspost? Or is there still work to do?
Comment #8
tr commentedLooks like you took care of renaming the form keys so this issue is fixed.
Comment #9
tr commentedWhoops, moving back to fixed.
Comment #10
j0rd commentedAug 27th release contains:
api/mpgClasses.php
This makes all transactions getting sent out to the test server, which is causing me grief.
same issue in api/mpiClasses.php
Comment #11
j0rd commentedchanged to critical. Please make sure this is resolved in mpiClasses.php and mpgClasses.php
Comment #12
gregglesNow fixed http://drupal.org/cvs?commit=259240
I appreciate your help debugging this and pointing out the solution. Marking it critical doesn't actually make anyone want to fix things sooner. Much better would be to provide a patch - please see getting a bug fixed sooner.
Comment #13
gregglesComment #14
j0rd commentedTHanks for the advice greggles. I figured a bug which makes your processor send all live transactions to the test server was best flagged as critical instead of minor. Had nothing to do with getting it fixed sooner as mine is already fixed :D As for the patch, my uc_moneris is a mess at the moment with debugging statements and such.
There are two other bug which I'm not sure if they're fixed.
One has to do with the improper naming of the txnType vs. txn_type variable. THe other has to do with sending an invalid transaction type when you turn off AVS or CVV checking.
Both issues are discussed here: http://drupal.org/node/525268