More on GetPaid "credits" products

Recap

Last week we learned:

(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)

The various portlets and subscribers are geared currently to the IOneWeekCreditPublishedContent policy, but there is no reason other policies can not be added and patterned off the existing one. In fact I intend to do this for group membership.

Several dependencies are introduced by getpaid.creditpublish:

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)

Of those three, cornerstone.browser is not yet egg-ified (I think) so it's an svn checkout, and TickingMachine is an old-style product available via tarball. I have these two both being fetched with my custom buildout and can supply buildout steps if anyone needs help.

Known Issues:

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 :)

Good Stuff:

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

So that's it. The code is currently available at:
https://getpaid.googlecode.com/svn/sandbox/dixond/

I'd love any feedback, constructive criticism, svn commits ;),  and most importantly some sort of consensus as to whether this is something that would be nice to have in the main GetPaid repository as a plugin.