code

GetPaid Presentation at Plone Conf 2008

GetPaid will be present at the upcoming Plone Conference session "Ecommerce in Plone: Surveying the state of the art". If you are interested in learning what you can do with GetPaid, how the Sites Using GetPaid were made, and what you can do with GetPaid, please join us on Wednesday, October 8, 2008 (Day 1) at 2:30pm in the Polaris room for this presentation!

Also, don't forget that GetPaid will be present at the Plone Conference Sprint! Sign up to participate here. A schedule of tasks is coming in a week.

PloneFormGen Integration Gets Refactoring

You may have read about the integration between GetPaid and PloneFormGen that happened a couple months ago. Recently, it got some refactoring to make it clearer, thanks to perrito666 (aka Horacio Duran). He also implemented the ability for it to accept multiple "adapters" (in the PFG sense, not the Zope 3 sense). What does that mean? Now you can seamlessly use PloneFormGen with GetPaid and add in your Salesforce.com integration adapters (or whatever other PFG adapters you may have)!

The latest updates are available at the mercurial repo available here: http://code.except.com.ar/hg/hgwebdir.cgi/getpaid.formgen

Remote Sprints Continue to Further GetPaid

Lucie Lejard of Six Feet Up is the Goddess of Remote Sprints in GetPaid throughout the summer. After a vacation in France, she returned to wrap up work on improving ease of integrating GetPaid. She has been on a quest for the holy grail of GetPaid deployments - the recipe.

And behold! With the guidance of Clayton (claytron) she is unleashing the power of the recipe! The recipe grabs the eggs, grabs the vendor products, and makes GetPaid a part of your buildout! It is so close to finished.

Recap

(12:04:11 AM) dixond: effectively what I've built is a way to turn a Plone site with GetPaid into an advertising channel, where people can pay to publish their content for a fixed time. The basic framework and concept can be extended then to other things also.

Stepping down from dixond's elloquent marketing-speak, the use case is something like this: A user needs some credit to make their content public in some way (ie "for a week" or by virtue of a group membership).

OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2) TickingMachine subscriber that knows about ICreditPublishedContent and applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased

Basically, what I've been building is a way to buy 'non-things' much like the notion of the 'donatable' type and to keep track of them and then use them for controlling access to arbitrary actions later. At present it works great, I'm spending most of my time 'generic-ifying' it so that it can be re-used elsewhere and isn't tied too closely to my specific use-case. Also on the list are other credit types like 'group membership' etc. Once I've generic-ified it enough this should be 'easy'.

Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit

Future extensions could also allow content to be accessed by using credits, if a payment processor is implemented which consumes credits.

What are others saying: "that's a really needed usecase of getpaid - lots of people will be hopping happy :)" -duffyd on #getpaid

New stuff

So, it did land in the repo - in sandbox: https://getpaid.googlecode.com/svn/sandbox/dixond/

Here is the full post dixond made (can be found in mailing list archive also):

I have been busy implementing a slightly different sort of use-case on top of GetPaid for the last couple of weeks. The scenario is based around a site where the site owner would like to charge the general public to run, eg, user-submitted advertisements for a fixed period of time. Think 'classified ads' or similar. The user is put in complete control of publishing their content according to a policy (eg, the first one implemented is for week-by-week publishing). The user pays for a 'week' of credit, and can then consume those in publishing their own content for that period of time. Also on the cards is month-by-month group membership, which could then give them access to special roles etc for 'all you can eat publishing'.

The overall framework is a relatively big, semi-independent component/app in its own right, but the payment portion of it is tied quite closely to GetPaid, and the rest seems to me to tie in nicely to GetPaid as a whole, so I've attached it in name and spirit to GetPaid for the moment ;)

There are three pieces that I have uploaded code for currently, all of them relatively divorced from the nitty-gritty implementation details and specifics of the use-case that birthed them:

1. getpaid.purchasablecredits -- This is just a very simple content type with Title, Description, and Price that acts as a sort of 'meta-product'. Its only purpose is to be a buyable type that you can put any details in that you want.
2. getpaid.creditregistry -- This is a very basic registry tool to store 'credits'. The interface could very easily be implemented with collective.lead in an RDBMS, but the package contains a simple implementation of getpaid.creditregistry.interfaces.ICreditRegistry which uses a Persistent utility in the ZODB and BTrees to store the purchased credits and allow them to be added/removed.
   
3. getpaid.creditpublish -- This is where all the action is. A number of different pieces all collaborate inside here to make everything hang together:
1. Event handler that watches for purchases of content items providing IOneWeekPublishedCredit and increments the counters in the ICreditRegistry utility appropriately
2. Portlet providing the mechanism for purchasing 'One Week Publishing' credits. It gets the price and description of this from any content item that implements IBuyableContent - when the portlet is created it asks for the UID of an item to use for Title/Description/Price - the 'representative object'
3. Adapter from the IOrder, ILineItem, and 'representative object' to be able to add credit records into the ICreditRegistry utility
   
4. Portlet to allow users to publish/depublish IOneWeekCreditPublishedContent content items (marked with ZCML).
5. schema extender for items marked with IOneWeekCreditPublishedContent to provide some utility fields (weeksLeftPublished, republishedReminderSent)
6. Event handler subscribed to Products.TickingMachine.ITickEvent.ITickEvent: this handler provides the de-publish/re-publish logic that drives the time-based publishing. It runs however often you have your ticking machine set, and runs a catalog search for IOneWeekCreditPublishedContent items that have expired or are about to expire and performs various policy logics on them (eg, re-publish for another week if the user has requested that, de-publish if they are out of credit, etc)

1. archetypes.schemaextender (self explanatory I hope)
   
2. cornerstone.browser (this is a great utility package for BrowserViews and portlet Renderers to make form/session/cookie handling much nicer and more standard)
3. TickingMachine (this one could be made redundant with a persistent utility in the site root and then cron or ClockServer configured to just call the method on the utility, but frankly, that is really just duplicating what TickingMachine already does, and z3 style events are nice)

1. There's no tests yet (that's why it's in the sandbox currently ;)
2. Probably there's cruft in various places in the packages as I have spent the last week refactoring it all out to make it more generally usable
3. It's complicated and I haven't documented it yet, except in this email :)

1. It works. A user can sign up to your site, purchase some credit, create an IOneWeekCreditPublishedContent item, and get a portlet offering to let them publish it for however many weeks they want. The only thing you need to do is add a <five:implements ... /> statement to your ZCML marking your content with getpaid.creditpublish.interfaces.IOneWeekCreditPublishedContent, and tell the Credit Publishing portlet which content item contains the price that should be charged for 'one week of publishing'
2. It's egg-ified already (no pypi yet)
   
3. I intend to keep working on it as it is for a live and motivated client

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!