code

First, a quick note...we now have over 400 downloads of our latest release (0.6.1).

Second, Ohloh reports GetPaid as now over 15,000 lines of code!

Third, there has been a good bit of code sharing going on in the community as people are helping each other in their specific projects. Keep an eye on (or join) the mailing list if you want to learn more or partake! Adding fields on the checkout, removing fields, changing payment options and more have all been discussed recently.

And, there was a new piece of documentation written about upgrading your GetPaid and Plone. Check out http://ejahn.net/Members/eric/stories/getpaid-.6-update

Finally, we are up to 125 people on the mailing list.

Code updates:

• Discounts: the discounts product has been getting an overhaul by Lucie. Latest changes include the discount portlet (shows info on the discount). Note to 2.5 users, check the README for how to get this working in your site). The product has had some fixes and has evolved.
  
• Maurits also reported changes: The price of an item is now added to its catalog brain.  So when you have a list of brains and want to know the price of them you no longer need to do a getObject and an adapter lookup to get that price.  The price is directly in the searchResults of the portal_catalog.
  This needs a reinstall btw.  And you should rebuild the catalog afterwards to get the most benefit out of it.
• And a second from Maurits: When you make an item payable, getpaid.core fires an event.  I added an event handler to PloneGetPaid that is subscribed to that event. This makes sure that the changed item gets reindexed.  That is handy for the first change above.  And in Plone 3 there is the object_provides index for which this also helps.
• Issue 152 was fixed, thanks Lucie and Maurits for working that out. This should keep the "payable" tab happy in both Plone 3 and 2.5. 
• Chinese translation was submitted by Adam

• PloneFormGen and GetPaid integration is available in the repository at http://mercurial.intuxication.org/hg/getpaid-formgen . This product allows two ways of making a formgen form: 1) create a cart from a single page or 2) create a cart and checkout from a single page. Have a look at this product (based on the way the Salesforce.com adapter for PFG works)! It is now in at least one production site...thanks to Daniel and Horacio for making this happen!
  

• A patch to fix issue 174 has been created by Robert (Jamie) and will be added to trunk shortly. This will allow anonymous users who register as part of checkout to keep the contents of their cart.
  
• Restructuring the svn repository: now that we have a proliferation of products in the GetPaid space, releasing has become challenging with just tagging the whole bunch. Restructuring so each product has its own trunk, branches, tags will enable separate lifecycles to be in play.
  
• Eggs on pypi: finally...
• New viewlet spots on the checkout wizard to allow easy registration of information collection boxes (or whatever) in those spots, as opposed to overriding the checkout. 
• Refinement of the PloneFormGen + GetPaid integration so it plays nicely with Salesforce.com + PFG integration. Also, configurable salesforce.com integation with regular GetPaid checkout.
  

Special thanks to CalvinHP, Claytron, and ChrisW for enthusiasm for taking on the taxes in GetPaid.

At the Plone Symposium in New Orleans, we did some collaborative design of the needs and requirements for tax infrastructure. Then, on last Friday, Calvin, Clayton, and Chris busted out the infrastructure!

Calvin's update reports:

The Symposium in New Orleans was a hotbed of GetPaid collaboration. We jump started a collaborative design process for integration PloneFormGen with GetPaid based on the nifty Salesforce.com adapter for PFG. Now, a week after we left New Orleans, already work is rapidly evolving:

• SteveM added a new feature to PFG (so action adapters can fail) and the code is tested and ready to release - thanks SteveM!!
• DanielHolth and perrito666 have been furiously hacking away and sharing code in a mercurial repository.
  
• Daniel's update today:
  perrito666 and I have been developing this at a rapid pace. So far we
  have something that's addable to the form and does a little bit of
  work. My end adds 0 of all the products in a given folder into the
  cart, and then the user might update their cart to select how many of
  each they want.
• Last I saw, perrito666 was working on pre-populating the PFG folder with the required GetPaid forms.
  

GetPaid's report at Ohloh has been updated to give stats on the project. We are now up to 14,937 lines of code. Other interesting factoids:

• 3 person-years worth of code (in about a year's time)
  
• 44 contributors
• 112 people following the mailing list
• 750+ downloads of the first release (plus many users with buildout)
• Over 170 downloads of the second release (only out for 2 weeks so far)
• 4 sprints
  

Payment Express is a Visa and MasterCard certified solution, developed by DPS, which facilitates electronic payments seamlessly from multiple access points i.e. Web, EFTPOS, Billing, Interactive Voice Responce, CRM, Vending, MOTO (Mail Order / Telephone Order) and Wireless.

DPS are certified with banks in Australia, New Zealand, Pacific Islands, Singapore, South Africa, USA and United Kingdom.

The payment processor is distributed as an egg getpaid.pxpay and is available on http://pypi.python.org/pypi.

This processor plugs in to the final step of the checkout. It provides the mechanism to securely authorize payment offsite.

See: http://code.google.com/p/getpaid/source/browse/trunk/getpaid.pxpay/src/getpaid/pxpay/README.txt for more help/discussion.

Thanks to Matt Halstead for integrating this and Darryl Dixon for kicking off the development!

A while ago, we created the release branch for GetPaid's second major release, 0.6. However, we didn't officially release it (with packaged code etc), and in the meantime, several fixes and changes came in. So, we are now releasing 2 versions.

0.6.0: This is the originally branched code. Works well and preserves "backwards" compatibility for those using customized GetPaid code.

0.6.1: This is a final release. Includes API refactoring and unicode fixes. May break your customized GetPaid code but not too much :)

Both of these work on Plone 2.5 and 3.0, and apparently on Plone 3.1 also (though we currently aren't providing a buildout for 3.1).

To check out the changelogs, see http://groups.google.com/group/getpaid-changes 

Throughout the history of GetPaid, there have been several people interested in multiple currencies in GetPaid.  I was excited to hear from Jean-François Roche of Affinitic today about his progress in getting multiple currencies working in the context of GetPaid. I found out that he already has some useful use cases working and is waiting to get them in production to be able to merge them back into GetPaid.

Code monkeys can check out the latest in an svn repo. For those of us who prefer English explanations...a brief summary of what I learned about the work:

• The work grew out of the need to manage currency based on the country of the buyer
• The UI gets the price from the buyer at first entrance in the shop and then a utility that manages policies for the link between the country and currency picks which price to show.
  
• Each country defined in the policies then has a separate price
  

As of earlier today, we had 258 tests passing on 2 versions of Plone (2.5 and 3.0) - yippeee!

So, with much joy, we are moving the trunk to the 0.6 branch for this release.

Next we will tag a 0.6.0 release candidate.

This release got a new directory of documentation as well as a lot of work on new features for shipping, fulfillment and reporting. Have a look at the latest buildout!

GetPaid's second major release, this one provides complete fulfillment and shipping functionality as well as several enhancements to the base product, such as address book, warehouse and inventory management, reports, and UPS shipping calculator integration. This version supports Plone 2.5 and Plone 3.0. Hopefully it will also get the Discount product included as well.

Where are we today?

Lots of changes have been going on (see the older blog posts for a summary) and great new features, especially around fulfillment and shipping.  Basically, to the solid framework established in the Red Ochre release (0.3), we have built out fulfillment functionality quite extensively.

Ohloh reports us as having over 10,000 lines of code now!

What next?

Next week, probably, we will make our release branch of the code. There will be some complexity around making tarballs that work, so expect them a while later.

We still have several issues that are targeted at this release.

We also need a catchy code name for this release :)

One thing to note...this will be our last release supporting Plone 2.5, unless someone new steps up to do the maintenance on that part of the code. The future release (0.9) will probably be lots of cleaning and UI improvements, plus the new features people think up to include :)

What a busy month! I think I have missed about 150 revisions since the last update, so here goes an attempt to catch up...to get the latest, grab our buildout (see documentation here).

Some stats:

• Over 500 downloads of our last stable release!
• A good number of tests going into new products!
• There are now LOTS of open issues (68, actually) in the tracker, which includes lots of change/improvement requests also. If you want to help out please take 'em on!
  

Highlights of what is in the latest code now:

• UPS shipping support. Still don't quite understand it (some configuration magic that has to happen), but there has been a LOT of work to get this going. Thanks to Kapil, Liam, Perrito and others for working, reworking, and fixing this.
  
• Shipping setup: this got refactored to be a bit cleaner and have some nice viewlets. Makes it easy to add in multiple shipping methods as we grow.
  
• Inventory management: Yes!!! getpaid.warehouse now available. This is a rather recent addition (you can only find it now by adding @@inventory to the URL), but it is there! Checkouts change the quantity, there is the ability to add warehouses for a site. More goodies to come as the work is rounded out by Kapil. Nicely done!
• Address book: Thanks to a use case we had for an ifPeople client, we built a means of saving shipping addresses in your profile during checkout, which are then accessible in checkout.
  
• Auto-loading your details: get tired of typing same details into the screen? Now they get autoloaded! Go lazy programmers!!
• Order templates: reordering your viagra supply ever couple months? Now you can save time in checkout by loading your orders from your past orders!
• Shipping price wired into total price: Now when you select shipping service, it will be added to the total price in the cart/checkout. 
• SSL: Now, by default, the site wants SSL. If you are just testing, you need to deactivate this in the GetPaid setup area for checkout to work. 
• Checkout wizard refactoring: after a significant refactoring, it got some fixes and improvements and additional testing.
  
• Relational database: there is also a relational database implementation of getpaid.core (called getpaid.rdb).
  

• PayPal processor interface!!! No really...I am serious! daMaestro told me in #getpaid just now :)
• PXPay processor: The Kiwis finally have their chance at GetPaid too! Apparently Winterhouse Consulting has done an implementation of this pay processor from Payment Express.
  
• Authorize.net recurring payments: ifPeople has also done integration with of the Automatic Recurring Billing (ARB) service of authorize.net. Currently in a branch...
• A new release: no details...but probably will be associated with a shipping wrap up. Possibly in late April.
  
• More sites using GetPaid!