Entries For: 2008

Just in time for the Plone Conference sprint, our Remote Sprint Goddess, Lucie, finished a release recipe for GetPaid, making it much easier for you to include GetPaid in your own recipe. Please give her your thanks and pat on the back!

More from Lucie:

The recipe is working and uploaded on pypi:
http://pypi.python.org/pypi/getpaid.recipe.release/1.0

You have all the detail on how to use it if you follow the link above. I will probably continue updating it today and make the documentation
prettier. I am currectly using it for one of our sites and seems to work correctly so far.

Well, just in time production (thanks to perrito and dunny), I had the various "howto's" I needed to explain how to use GetPaid for the talk.

In the talk, I introduce GetPaid and its core features, and then show how it can be used to satisfy various use cases, both with the out-of-the-box components as well as with some customization.

The audience was a decent size (especially considering I was up against Joel Burton at same time slot!),

Download slides here.

http://plonegetpaid.com/updates/files/getpaid-presentation-ploneconf-2008.pdf

Surveying the State of the Art in Plone Ecommerce

I intended my talk for the conference to be a good learning experience that pushed my own understanding of GetPaid. As I am not a developer, I certainly don't know how to do a lot of things that people do with GetPaid. But, as GetPaid was my motive for actually learning how to use svn and making my first checkin, I figure I should be able to figure some of this stuff out using the available documentation and my knowledge of GetPaid. So as part of my talk, which will be walking through what you can do with GetPaid: out of the box, with community addons and with basic customziations, I have been asking a lot of questions! This has motivated some new documentation being produced that will continue to support new community members who are finding GetPaid. Also, I found a few bugs that are now in our tracker.

Some of the things I will show:

• Managing inventory with GetPaid
• One-page checkout (with PloneFormGen integration)
• Making a store

• Pay-to-publish content (working that integrates a payment step for job listings, ads, applications, etc)
• Making your own content type buyable (programmatically)
• Showing GetPaid information on your templates

Sprint Preparation and Plans

Distribution

• Eggify components and get to pypi (everything in externals already there)
• getpaid.warehouse
• getpaid.report
• Finish GetPaid? recipe; Document usage
• Buildouts:
• Test and finish reorganization (base, 30, 25, currently on meteoroid-branch) and document buildouts (how to add getpaid)
• Document and use in DevGettingStarted
• Merge branch or copy files on existing buildout
• update anonymous buildout (diff svn externals and cfg file). Fairly easy, as it was last updated in August.

Bugs & Issues

• fix issues
• Issue #209
•  Issue #202 
• Issue #117
• Improve paypal processor: make multi-item checkout possible, make/fix admin screen for processor

i18n

• update translations
• Spanish: in progress (FranGM, Wu, cjj)
• French (very close to done)
• German
• Italian
• Chinese
• Dutch

Testing

• add greater test coverage:
• getpaid.report

Documentation

• gather/improve/update/add documentation (list specific here)
• Review and improve content type integration for devs doc
• How to show price (or other GetPaid? properties) on a template in your site
• How to wire payment process to a workflow state change (ie create a piece of content, but pay before it is published)
• How to get and use getpaid.formgen
• How to customize the checkout process (including using available slots, ie for comments)
• Enabling components in buildouts
• Using the new buildouts
• Using the recipe
• Review mailing list and document errors messages (on plone.org doc collection) and how to fix them
• How to get and use getpaid.salesforce
• ReorganizeIssueTracker (in progress; cjj, gabrielle)

Release prep

• 0.7.0 release (would support 2.5 and 3 together)
• update changelog on plone.org/products/getpaid
• branch code
• make a branch to separate future 2.5 and 3 support (dennis)

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.

The Sites Using GetPaid page had become a nightmare to maintain with kupu and I simply couldn't edit it without things blowing up. So, I am really excited to announce that the page is now something organized, lovely, and scalable :D.

I went for my inclination to use structured data and some nice features to clean that mess up and used the ATSuccessStory product (what is also used for sponsors on the site...this is a version slightly customized by the product author, frapell).

Soo.....check out the all new, improved and attractive http://plonegetpaid.com/why/sites-using-getpaid/

I added 4 new sites that hadn't been there previously:

• ABB Orderliterature.com > read more
• Natural Awakenings Magazine > read more
• Health Food Guide > read more
• Women of Reform Judaism > read more
  

You will also notice that there is a portlet with rotating site features on plonegetpaid.com to highlight the sites as you navigate around.

We have some really great example sites out there, so please have a look!

If you have a site to add - please let me know - I am now all caught up with all the sites I know of. Also, if you want to send changes to any info there, please let me know.

The CIA bot dumped a long list of checkin updates into #getpaid yesterday afternoon, and remarkably we passed our 2000th revision! In that swirl of code, paypal workings got fixed thanks to duffyd, some error controls and bug fixes to the getpaid.report component were added (and perrito666 hit the 2000 milestone!), googlecheckout got updated by dunny, and more. See changelog.

Thanks to all who have been working on the project!

Other noteables from GetPaid:

• GetPaid 0.6.1 tarball now has 895 downloads and has surpassed the 0.3 downloads total!

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

Last week, we peered into the top secret skunkworks of dixond and well, let the cat out of the bag about an exciting new extension coming to GetPaid any day now :) Ok, so maybe skunkworks is a bit of exageration...but I deal with developers who are hard to get to talk! It is often classified (in heads) until checked in...thanks to a shocking burst of verbosity, we got this insight:

(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

At last the Ohloh report is updated! So here is the update:

• 11k+ lines of code
• 19 enlistments (aka different packages/products/libraries)
  
• Contributors report is now updated. Our top five contributors are now:
  
• Kapil
• Lucie
• Maurits
• Horacio
  
• Matt Halstead

We are building on the momentum of last week's 2 day sprint and the previous Friday sprints in getting GetPaid super-charged. An amazing amount of cleanup, organizing and catchup is going on in the community right now - it is great to see (and Fridays are regular GetPaid sprint days now!).

We want to continue this momentum and engage new folks - while taking advantage of a great change to work together in person - at the Plone Conference in DC in October. We hope you will join us! If you are interested, please sing up at http://www.openplans.org/projects/plone-conference-2008-dc/getpaid