2. I would like to create a project to support ongoing development for the uc_cim module, which does not currently have a project on Drupal.org. This module provides several features related to Authorize.net's Customer Information Manager functionality:
A. A page where the customer can edit/update the credit card information that you have on file for them (user/[uid]/creditcards). This was critical for a few of my sites which have recurring fees because people needed to be able to change which card should be used and/or update their info when the card expires.
B. A page where the admin can view a list of all customer payment profiles and click through for more info.
C. The admin can edit or delete payment profiles.
D. The admin can issue refunds or make charges on an order using the payment profile.
E. A configurable notification can be sent when a customer's credit card is about to expire or has expired. This has some token integration.
F. Critical error notifications can be sent to an admin or developer when an order is unable to be processed because the site cannot connect to Authorize.net.
These items are all extra functionality which is not part of Ubercart's core Authorize.net module.
The module is in need of some additional work. I plan to implement test coverage, refactor the code to be more consistent with Drupal 6/7 style, and either port it to Drupal 7 or make a transition/upgrade path if the additional functionality can be rolled into Ubercart's core module. A project page with an active issue queue is needed to support this development and assist people who are using an older version of the module.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | uc_echopay.tar_.gz | 7 KB | rstaylor |
| #1 | uc_echopay.tar_.gz | 17.54 KB | rstaylor |
| #1 | uc_cim.tar_.gz | 66.24 KB | rstaylor |
Comments
Comment #1
rstaylor commentedAttached are current working versions of uc_echopay module and uc_cim module.
Comment #2
avpadernoWe review just a module/theme; which one do you want to use for the review?
Comment #3
rstaylor commenteduc_echopay should be simpler to review
Comment #4
avpadernoThen, uc_echopay.module will be.
Comment #5
avpadernoThe code should use
module_load_include().Comment #6
avpadernoThere have not been replies from the OP in the past 7 days. I am marking this report as .
Comment #7
rstaylor commentedPlease reopen, I've gone through this to make the changes mentioned.
1 & 2. I've removed the EchoPHP class and its license, and put instructions for obtaining them in the README and in a hook_requirements check.
3. Removed the version from .info
4. Changed _uc_echopay_charge() to use module_load_include() which should be safe there, but used
in the hook_requirements, since "install-time requirements must be checked without access to the full Drupal API". This appears to be the solution currently used by other modules to prevent fatal errors in hook_init or similar early hooks (http://drupal.org/node/587572)
5. Reread the standards and reran coder module. The only thing that stood out to me is that I used substr() to force a max length on the order info in order to conform to EchoPay's API requirements, instead of drupal_substr(), but I don't think that a multibyte substr would correctly limit the number of bytes. The drupal_substr() documentation says "Note that for cutting off a string at a known character/substring location, the usage of PHP's normal strpos/substr is safe and much faster.", but should it be drupal_truncate_bytes() instead?
Comment #8
avpadernoYou need to re-apply for the CVS account, as the application has already been declined; changing the status of this report doesn't change the status of the application.
Comment #9
avpaderno