Nabble - GetPaid for Plone - Dev

Re: pcommerce.core

2009-11-06T10:28:48Z

Hi,

I hadn't time yet to take a deep look at the code. It is much lighter than getpaid's. It seems only to implement cart, checkout and product variations. No reports, inventory management, UPS. (features I think not many people use...)
I am not also a very skilled coder, but I could help trying to implement in Getpaid the idea of product variations presented there..
The project owner is Simon Kaeser and theirs homepage is http://endlessx.com/ .
I cannot speak in the name of getpaid community, but maybe someone more representative could get in touch with them and see how we could maybe join forces for interoperability..

Cheers,
Rafael

Christopher Johnson escreveu:

Hi Rafael,

Thanks for pointing that out! I heard something mentioned of it at the conference, but wasn't at the open space on broader ecommerce to learn more. Have you checked it out? Do you know who developed it?

Also, are any of their interfaces able to work with GetPaid packages? Would be great to evolve towards shareable code (payment processors and other functionality).

Cheers,
Chris
On Thu, Nov 5, 2009 at 11:04 AM, rafael <rafaelcrocha@...> wrote:
Hi,

  I see it was recently released a new product for commerce in Plone,
pcommerce.core .

   Has anyone taken a look in the code? I saw there is a functionality
for product variation, something there should also exist in getpaid.
Maybe we could use some ideas from there?

Rafael
    
--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: pcommerce.core

2009-11-05T17:12:45Z

Hi Rafael,

Thanks for pointing that out! I heard something mentioned of it at the conference, but wasn't at the open space on broader ecommerce to learn more. Have you checked it out? Do you know who developed it?

Also, are any of their interfaces able to work with GetPaid packages? Would be great to evolve towards shareable code (payment processors and other functionality).

Cheers,
Chris

On Thu, Nov 5, 2009 at 11:04 AM, rafael <rafaelcrocha@...> wrote:

Hi,

  I see it was recently released a new product for commerce in Plone,
pcommerce.core .

   Has anyone taken a look in the code? I saw there is a functionality
for product variation, something there should also exist in getpaid.
Maybe we could use some ideas from there?

Rafael

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

pcommerce.core

2009-11-05T08:04:22Z

Hi,

  I see it was recently released a new product for commerce in Plone,
pcommerce.core .

   Has anyone taken a look in the code? I saw there is a functionality
for product variation, something there should also exist in getpaid.
Maybe we could use some ideas from there?

Rafael

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Alternative Session Implementation

2009-11-04T12:42:27Z

> Hi all,
>
> I had been joining the GetPaid sprint at the Plone conference in Budapest
> for one day and we shortly discussed the session implementation. If I see
> it correctly the problems of ticket 209 are resolved (except of broken
> ZODBs maybe).
>
Hi,
I still get this bug triggered every 2 days. Maybe my zodb is corrupted,
but my workaround for that bug is reinstalling getpaid... I tried using
the script to fix it, but did not work...

> We could not come up with a completely sessionless cart implementation, I
> think mainly because nobody knew the GetPaid design well enough. Anyway I
> have implemented the session based approach using zope.app.session. It
> consists of an ISession utility and an ISessionData local persistent
> utility to store the data. This means that sessions (in our case those of
> anonymous users) are written to the ZODB the portal is saved in. This can
> give you performance problems, depending on the number of anonymous
> shopping cart users. I don't know if there are bigger GetPaid installations.
> But it should be possible replace the local persistent utility with another
> implementation that does the loads/dumps dance internaly and saves the
> data somewhere else.
>
> Attached you find a patch converting the implementation and the tests to
> use zope.app.session. The functional anon cart tests are failing atm, but I
> did not have time to look at them nor do I know if they failed before
> already.
>
> ..Carsten
>
> >
>

Alternative Session Implementation

2009-11-03T15:22:07Z

Hi all,

I had been joining the GetPaid sprint at the Plone conference in Budapest
for one day and we shortly discussed the session implementation. If I see
it correctly the problems of ticket 209 are resolved (except of broken
ZODBs maybe).
We could not come up with a completely sessionless cart implementation, I
think mainly because nobody knew the GetPaid design well enough. Anyway I
have implemented the session based approach using zope.app.session. It
consists of an ISession utility and an ISessionData local persistent
utility to store the data. This means that sessions (in our case those of
anonymous users) are written to the ZODB the portal is saved in. This can
give you performance problems, depending on the number of anonymous
shopping cart users. I don't know if there are bigger GetPaid installations.
But it should be possible replace the local persistent utility with another
implementation that does the loads/dumps dance internaly and saves the
data somewhere else.

Attached you find a patch converting the implementation and the tests to
use zope.app.session. The functional anon cart tests are failing atm, but I
did not have time to look at them nor do I know if they failed before
already.

..Carsten

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Index: Products/PloneGetPaid/configure.zcml =================================================================== --- Products/PloneGetPaid/configure.zcml (Revision 3169) +++ Products/PloneGetPaid/configure.zcml (Arbeitskopie) @@ -222,11 +222,58 @@ /> + -<subscriber - for="* - getpaid.core.interfaces.IPayableCreationEvent" - handler=".events.payable_created" - /> - + +<adapter factory=".cart.ClientId" + permission="zope.Public" /> + +<configure package="zope.app.session"> + + <adapter + factory=".session.Session" + provides="zope.app.session.interfaces.ISession" + permission="zope.Public" + /> + + <adapter + factory=".session.Session" + provides="zope.traversing.interfaces.IPathAdapter" + name="session" + /> + + <class class=".session.Session"> + <allow interface=".interfaces.ISession" /> + <implements interface="zope.traversing.interfaces.IPathAdapter" /> + </class> + + + <class class=".session.PersistentSessionDataContainer"> + <require + interface=".interfaces.ISessionDataContainer" + permission="zope.Public" /> +  +  +  + </class> + + + <class class=".session.SessionData"> + <allow interface=".interfaces.ISessionData" /> + </class> + + <class class=".session.SessionPkgData"> + <allow interface=".interfaces.ISessionPkgData" /> + </class> + + <subscriber + for="zope.app.appsetup.IDatabaseOpenedEvent" + handler=".bootstrap.bootStrapSubscriber" + /> + + <subscriber + for="zope.publisher.interfaces.http.IHTTPVirtualHostChangedEvent" + handler=".http.notifyVirtualHostChanged" + /> </configure> +</configure> \ No newline at end of file Index: Products/PloneGetPaid/config.py =================================================================== --- Products/PloneGetPaid/config.py (Revision 3169) +++ Products/PloneGetPaid/config.py (Arbeitskopie) @@ -4,3 +4,6 @@ PLONE3 = True except ImportError: PLONE3 = False + +SESSION_KEY = 'PloneGetPaid' +CART_KEY = 'getpaid.cart' Index: Products/PloneGetPaid/tests/test_cart.py =================================================================== --- Products/PloneGetPaid/tests/test_cart.py (Revision 3169) +++ Products/PloneGetPaid/tests/test_cart.py (Arbeitskopie) @@ -5,6 +5,7 @@ from zope.component import getUtility from Testing.ZopeTestCase import ZopeDocTestSuite +from Testing.ZopeTestCase.utils import setupCoreSessions from Products.Five.utilities.marker import mark from utils import optionflags @@ -13,8 +14,24 @@ from Products.PloneGetPaid import interfaces from getpaid.core.interfaces import IShoppingCartUtility + +class DummySessionAndBrowserIdManager: + + __test_browser_id__ = 'funkyTestBrowserId' + + def getBrowserIdManager(self): + return self + + def getBrowserId(self): + return self.__test_browser_id__ + + class TestCart(PloneGetPaidTestCase): + def afterSetUp(self): + super(TestCart, self).afterSetUp() + setattr(self.app.REQUEST, 'SESSION', DummySessionAndBrowserIdManager()) + def mySetup(self): self.setRoles(('Manager',)) id = self.portal.invokeFactory('Document', 'doc') @@ -161,18 +178,18 @@ ... ValueError: Malformed key: example:malformed:key """ - + def pauseBrowserSession(self): """Utility that disables the current session. The session can be resumed using resumeBrowserSession. """ - self._paused_browser_id = self.portal.REQUEST.browser_id_ - self.portal.REQUEST.browser_id_ = None + self._paused_browser_id = self.portal.REQUEST.SESSION.__test_browser_id__ + self.portal.REQUEST.SESSION.__test_browser_id__ = None def resumeBrowserSession(self): """Utility to restore the previous session. """ - self.portal.REQUEST.browser_id_ = self._paused_browser_id + self.portal.REQUEST.SESSION.__test_browser_id__ = self._paused_browser_id def test_suite(): Index: Products/PloneGetPaid/setuphandlers.py =================================================================== --- Products/PloneGetPaid/setuphandlers.py (Revision 3169) +++ Products/PloneGetPaid/setuphandlers.py (Arbeitskopie) @@ -14,11 +14,11 @@ from Products.PloneGetPaid.Extensions.install import install_plone3_portlets from Products.PloneGetPaid.Extensions.install import setup_payment_options from Products.PloneGetPaid.Extensions.install import register_shopping_cart_utility - from Products.PloneGetPaid.Extensions.install import setup_addressbook from Products.PloneGetPaid.Extensions.install import setup_named_orders from Products.PloneGetPaid.Extensions.install import setup_settings from Products.PloneGetPaid.Extensions.install import register_shopping_cart_utility +from Products.PloneGetPaid.Extensions.install import register_session_data_utility from Products.PloneGetPaid.config import PLONE3 @@ -82,6 +82,9 @@ print >> out, "Registering shopping cart utility" register_shopping_cart_utility(site) + print >> out, "Registering session data utility" + register_session_data_utility(site) + print >> out, "Notifying Installation" notify_install( site ) Index: Products/PloneGetPaid/cart.py =================================================================== --- Products/PloneGetPaid/cart.py (Revision 3169) +++ Products/PloneGetPaid/cart.py (Arbeitskopie) @@ -3,16 +3,21 @@ $Id$ """ -from zope.component import getUtility +from zope.app.session.interfaces import IClientId +from zope.app.session.interfaces import ISession +from zope.component import adapts, getUtility from zope.interface import implements +from zope.publisher.interfaces import IRequest from getpaid.core.cart import ShoppingCart from getpaid.core.interfaces import IShoppingCartUtility from Products.CMFCore.utils import getToolByName +from Products.PloneGetPaid.config import CART_KEY, SESSION_KEY from persistent import Persistent from BTrees.OOBTree import OOBTree from AccessControl import getSecurityManager + class ShoppingCartUtility(Persistent): implements(IShoppingCartUtility) @@ -73,40 +78,30 @@ self._sessions[uid] = cart return cart - def _getCartForSession(self, context, create=False, browser_id=None): - session_manager = getToolByName(context, 'session_data_manager') - if browser_id is None: - if not session_manager.hasSessionData() and not create: - return - session = session_manager.getSessionData() - else: - session = session_manager.getSessionDataByKey(browser_id) - if session is None: - return - if not session.has_key('getpaid.cart'): - if create: - session['getpaid.cart'] = cart = ShoppingCart() - else: - return None - return session['getpaid.cart'] + session = ISession(context.REQUEST) + if browser_id is not None: + # we overwrite the client_id that was set during the ISession + # initialization + session.client_id = browser_id + + sessiondata = session[SESSION_KEY] + cart = sessiondata.get(CART_KEY, None) + if create and cart is None: + sessiondata[CART_KEY] = cart = ShoppingCart() + return cart + def _getDisposableCart(self, context, browser_id=None): return ShoppingCart() def _getMultiShotCart(self, context, cart_id=None): - session_manager = getToolByName(context, 'session_data_manager') + sessiondata = ISession(context.REQUEST)[SESSION_KEY] + key = "%s.%s" % (CART_KEY, cart_id) + if not sessiondata.has_key(key): + sessiondata[key] = ShoppingCart() + return sessiondata[key] - key = "getpaid.cart.%s" % cart_id - - session = session_manager.getSessionData() - - if not session.has_key(key): - session[key] = cart = ShoppingCart() - - return session[key] - - def destroy(self, context, key=None): """ Destroy the cart. """ @@ -125,37 +120,26 @@ else: return self._destroyCartForSession(context) - def _destroyCartForUser(self, context, uid): if self._sessions.has_key(uid): del self._sessions[uid] - def _destroyCartForSession(self, context, browser_id=None): - session_manager = getToolByName(context, 'session_data_manager') - if browser_id is None: - if not session_manager.hasSessionData(): #nothing to destroy - return None - session = session_manager.getSessionData() - else: - session = session_manager.getSessionDataByKey(browser_id) - if session is None: - return - if not session.has_key('getpaid.cart'): - return - del session['getpaid.cart'] + session = ISession(context.REQUEST) + if browser_id is not None: + # overwrite the client_id that was set + # during initialization + session.client_id = browser_id + sessiondata = session[SESSION_KEY] + if sessiondata.has_key(CART_KEY): + del sessiondata[CART_KEY] def _destroyMultiShotCart(self, context, cart_id=None): - session_manager = getToolByName(context, 'session_data_manager') + sessiondata = ISession(context.REQUEST)[SESSION_KEY] + key = "%s.%s" % (CART_KEY, cart_id) + if sessiondata.has_key(key): + del session[key] - key = "getpaid.cart.%s" % cart_id - session = session_manager.getSessionData() - - if not session.has_key(key): - return - - del session[key] - def getKey(self, context): """Return key that can be used to recover the cart for the current user or session. @@ -164,15 +148,12 @@ if uid is not None: return 'user:%s' % uid else: - session_manager = getToolByName(context, 'session_data_manager') - if not session_manager.hasSessionData(): + session = ISession(context.REQUEST) + sessiondata = session[SESSION_KEY] + if not sessiondata.has_key(CART_KEY): return None - session = session_manager.getSessionData() - if not session.has_key('getpaid.cart'): - return None - return 'session:%s' % session.token + return 'session:%s' % session.client_id - def _decodeKey(self, key): try: name, value = key.split(':', 1) @@ -185,3 +166,19 @@ def manage_fixupOwnershipAfterAdd(self): pass + + +class ClientId(str): + """See zope.app.interfaces.utilities.session.IClientId + + An IClientId Utility that uses Zope2's browser_id_manager + implementation. + """ + implements(IClientId) + adapts(IRequest) + + def __new__(cls, request): + return str.__new__( + cls, request.SESSION.getBrowserIdManager().getBrowserId() + ) + Index: Products/PloneGetPaid/Extensions/install.py =================================================================== --- Products/PloneGetPaid/Extensions/install.py (Revision 3169) +++ Products/PloneGetPaid/Extensions/install.py (Arbeitskopie) @@ -12,6 +12,9 @@ from zope.event import notify from zope.app.component.hooks import setSite from zope.app.component.interfaces import ISite +from zope.app.session.interfaces import ISessionDataContainer +from zope.app.session.session import PersistentSessionDataContainer + from Products.PloneGetPaid import generations, preferences, addressbook, namedorder from Products.PloneGetPaid.interfaces import IGetPaidManagementOptions, IAddressBookUtility, INamedOrderUtility from Products.PloneGetPaid.config import PLONE3 @@ -61,6 +64,21 @@ # BBB for Zope 2.9 sm.registerUtility(interface=IOrderManager, utility=manager) +def register_session_data_utility( self ): + portal = getToolByName( self, 'portal_url').getPortalObject() + sm = portal.getSiteManager() + is_already_registered = [u for u in sm.getUtilitiesFor(ISessionDataContainer)] + if not len(is_already_registered): + session_data = PersistentSessionDataContainer() + session_data.timeout = 604800 # 7 days + session_data.resolution = 100 + sm.registerUtility(session_data, ISessionDataContainer) + try: + sm.registerUtility(component=session_data, provided=ISessionDataContainer) + except TypeError: + # BBB for Zope 2.9 + sm.registerUtility(interface=ISessionDataContainer, utility=session_data) + def setup_intid( self ): portal = getToolByName(self, 'portal_url').getPortalObject() try:

Alternative Session Implementation

2009-11-03T15:17:56Z

Re: Sprinting on GetPaid: a plan

2009-11-01T19:31:13Z

On Mon, Nov 2, 2009 at 1:48 AM, Brandon Craig Rhodes
<brandon@...> wrote:

>
> Michael Dunstan <michael.dunstan@...> writes:
>
>> The Google Checkout processor tests fabricate the incoming signals
>> from the checkout server...
>
> Well, that's an interesting idea! At first it sounds like an
> unconvincing test, but I guess if the XML you injected in the test was
> actual real XML from Google that you'd captured during a by-hand test of
> the callback, then you are indeed testing against real data and real
> Google behavior. I like the approach enough to be comfortable with it!
> If the sprinters want to kick off a callback from PayPal, capture the
> steps, and replay them in their test, I think that will be a huge step
> forward. Thanks for this simplification!

Yeah - that's the same XML that would have come from Google Checkout.

Obviously if the XML from Google Checkout changes then the tests would
need to be updated.

There are some traceback supplements in the getpaid.googlecheckout
processor which log the received XML in the case of an error in the
wild. See TracebackSupplement and NotifyTracebackSupplement of
http://code.google.com/p/getpaid/source/browse/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/googlecheckout.py

That should help with the process of updating the tests if there is a
significant change in the XML from Google Checkout. Well - needs to be
a fatal enough error to cause an exception to be thrown.

(Unfortunately I don't see any tests for those traceback supplements.)

--
Michael Dunstan

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: paypal payment processor

2009-11-01T16:45:44Z

2009/10/31 Silvio <silviot@...>

Hi,

while writing tests for the getpaid.paypal module this came to my mind:
the approach currently is that we don't create an order if it's not paid, but we instead create it after the paypal process is over and an IPN comes.

Customer data is also collected on the paypal site.
Some customers are propably going to place an order and for some reasons (computer crash or phone call etc) wait some time before paying it, or lose their browser session.

I really think we should create the order object and destroy the cart before the customer is sent to paypal, collecting data on the getpaid-enabled site as well.

+1, a "review your order" page should be handy to create the order without the need of js, but adds an extra click...

BTW, while implementing getpaid.nmi I faced another orders workflow problem. There is a subcriber to the IWorkflowTransitionEvent than when the workflow triggers to charging state tries to found the processor and call capture to get the transaction result,

        processor = component.getAdapter( context,
                                          interfaces.IPaymentProcessor,
                                          self.order.processor_id )

        result = processor.capture( self.order, self.order.getTotalPrice() )

        if result == interfaces.keys.results_async:
            return
        elif result == interfaces.keys.results_success:
            self.order.finance_workflow.fireTransition('charge-charging')
        else:
            self.order.finance_workflow.fireTransition('decline-charging', comment=result)

But we're not implementing an IPaymentProcessor, so this fails and we can't move the order over the wf... a real pain because without it we only have orders in the "REVIEWING" state.

My first fix was a change on payment.DefaultFinanceProcessorIntegration than caused some problems to Brandon.

So after some testing I ended up with this solution,

First I created a new Orded class inheretied from getpaid one...

class INMIOrder(interfaces.IOrder):
    """
    """

class Order(BaseOrder):
    """
    """
    implements(INMIOrder)

Now the processor implements an orderid method,

    def orderid(self):
        cartutil=getUtility(IShoppingCartUtility)
        cart=cartutil.get(getSite())
        # we'll get the order_manager, create the new order, and store it.
        order_manager = getUtility(IOrderManager)
        new_order_id = order_manager.newOrderId()
        order = Order()

        # register the payment processor name to make the workflow handlers happy
        order.processor_id = 'getpaid.nmi.processor'

        # FIXME: registering an empty contact information list for now - need to populate this from user
        # if possible
        order.contact_information = payment.ContactInformation()
        order.billing_address = payment.BillingAddress()
        order.shipping_address = payment.ShippingAddress()

        order.order_id = new_order_id

        # make cart safe for persistence by using pickling
        order.shopping_cart = loads(dumps(cart))
        order.user_id = getSecurityManager().getUser().getId()

        order.finance_workflow.fireTransition('create')
        order.finance_workflow.fireTransition('authorize')

        order_manager.store(order)

        return order.order_id

To get this working I needed my own FinanceProcessorIntegrator,

class FinanceProcessorIntegration(payment.DefaultFinanceProcessorIntegration):

    def __call__( self, event ):
        # NMI processor is async, so just return
        return

and register it,

And thats all... now I have a working orders workflow for my offsite processor...
IMHO this could be moved to getpaid.core.processors, so offsite processors don't need to worry about order creation, wf states and events, only aprove or decline orders based on external response...

Regards,
Juan Pablo

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: paypal payment processor

2009-11-01T10:29:52Z

Two more things I forgot to mention:

The proposed workflow is intended to provide a sane user experience allowing the site manager to mix

cash on delivery, onsite payments as well as offsite payments with a similar process.

I think they don't mix well in the current implementation.

Silvio

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

specifying version of five.intid

2009-11-01T07:54:30Z

Hey everybody,

Just thought I would share how to override the versions specified in
getpaid.recipe.release. If an egg is specified directly in the part of
the recipe, the version can be overridden/unpinned.

If the recipe is used like this:

[getpaid]
recipe = getpaid.recipe.release
eggs =
five.intid

five.intid will be unpinned.

You can then, if needed, specify another version to pin in the
[versions]-section of your buildout.

Thanks to Maurits van Rees for writing about this in his blog here:
http://maurits.vanrees.org/weblog/archive/2008/01/easily-creating-repeatable-buildouts

Happy sprinting,
Sune B. Wøller

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: paypal payment processor

2009-11-01T07:34:40Z

On Sun, Nov 1, 2009 at 2:23 PM, Brandon Craig Rhodes <brandon@...> wrote:

First:

I am "-1" on destroying the cart.

I probably was not clear enough. This morning Lee Joramo drew a very useful diagram that shows what my proposal looks like.

I just uploaded it to Google wiki, together with the email where I expose my ideas. Check it out at

http://code.google.com/p/getpaid/wiki/NewOrderWorkflowProposal

So, again, we should not destroy the cart until we know the customer has
succeeded in paying; and, second, when we do get payment notification we
shouldn't "destroy" the cart, we should just remove from it whichever
items were actually paid for, using the little list of items that PayPal
will send us back in their IPN message.

I'm -1 about this because it doesn't fit my usecases (but I am aware I'm biased here) and because it seems harder to implement than necessary.

Second:

I have a less strong opinion on creating an Order before they actually
leave the site. The issues would seem to be:

Con

* Orders are designed to hold information, but in this case there's
nothing to store except the fact that the user pressed "Checkout" and
left the site. You'd have all these orders sitting around with
nothing but an order number and a copy of a cart inside of them,
because the user reached PayPal and was annoyed with its interface and
decided not to check out after all.

I meant to ask for user info on our site before the payment, and have the paypal forms automatically filled with the data provided to us.

(I don't know many store owners, I must admit, but rumor has it
that they tend to like customers to be as few clicks away from
finishing paying as possible!).

This is why we should trat anonymous (no user/password) checkout as a first class citizen.

In my experience, at least for the Italian users I'm used to and the kind of business I developed for, asking for a username/password is a thing that I need to avoid as much as possible.

But, it seems to me that this mechanism uses space, time, and additional
complexity, in order to accomplish something that the off-site service
does anyway.

It does use space. I think store owners might be happy with the extra space requirements if it translates to a better user experience.

But, I'm not an actual Store Owner, so I'm quite open to changing my
opinion here based on actual GetPaid users if they (or you) would like
to share more about how they actually use the service in practice.

I'd like to hear more opinions about this too. What do you all think on this ML?

> We could then provide the "pay with paypal" button on the order
> summary page.

Ah! I see! You are not advocating JavaScript, you're advocating
two-step checkout process: the person sees their cart and presses
"Checkout", then is shown their cart *again* and has to press "PayPal
Checkout" to actually go off-site.

Yes, I'm really positive this is not an issue. I never had the impression any of my users (I use the described approach in production, and it works well) had anything to complain about.

> BTW, we should also fix the personal details form and separate "first
> name" from "surname": we can't programmatically split "Full name" when
> we pass it to paypal.

I'm certainly not an expert on this area, but two objections immediately
occur to me:

1. Isn't the personal details page something that's a Plone-wide
standard and that we can't change? Surely we don't want that form to
change on the day that someone adds GetPaid to a site that's been
maybe running for years, and have to go back through and add two
names to all of their users before proceeding?

2. The first+last formula doesn't work everywhere in the world - nor
even with everyone in a large university. I think that's why Plone
has a free-form field.

If PayPal needs first and last, I suspect that we will just have to do
our best using .split() and so forth with the normal Plone name field.
But, again, I could easily be wrong here!

-1000: programmatically splitting name and surname can lead to weird results. I would never ever do that.

> One more issue: anonymous users can't see their own orders, so they
> wouldn't be able to pay with the described setup.

Can they pay with my proposed setup? They would just click "Check out
with PayPal" and be immediately whisked off-site?

I'm actually proposing to change that, and ask for name/address before sending them to paypal.

> We could solve this providing a token in the emails we send after the
> order is created; the token could be the md5 hash of the date and time

> of the order. ... What do you think?

A strongly random UUID, not the date and time, is what is needed here
for each Order; but, aside from that, your idea is a very good one!
It's just like the Tracking links that lots of sites send out: because
no one else can guess a 30-character random string, the URL is
essentially private to whomever reads the email. That would be a nice
way for people (at least who type their emails correctly) to have a way
back to their Order. Plus, on the final Order page itself we could say
"to visit this later, bookmark..." and have the link there too.

Good, that should be some attribute on the order, randomly generated on order creation.

This also leaves room for some improvement: in case we need the order url to expire, we could store an expiration date with the token and let the user ask for a new url in case it's expired, providing their email address.

Silvio

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: paypal payment processor

2009-11-01T05:23:13Z

Silvio <silviot@...> writes:

> I really think we should create the order object and destroy the cart
> before the customer is sent to paypal, collecting data on the
> getpaid-enabled site as well.

First:

I am "-1" on destroying the cart. If the HTTP forwarding to PayPal
fails - if, say, there is a DNS glitch or their Internet connection goes
down for a moment - then the user will have to return to the store to
press "Checkout" again, but all the hard work to fill their cart will be
gone. They'll have to go all over the site again, refilling their cart,
and then maybe find that their link to PayPal is down *again* when they
finish and hit "Checkout" the second time - and now, again, their cart
is destroyed and gone. This is not an acceptable customer experience.

In crafting the customer experience, in fact, I'm going to consistently
argue that we should be acting as much like Amazon as possible, because
I think that their approach works extremely well. It looks like neither
GetPaid nor Satchmo has spent enough time looking at corner cases that
Amazon handles well and trying to emulate them. For example: it is
actually irresponsible to empty the cart upon payment, because the user,
in another browser tab, might have already added new items to their
shopping cart that are not line items in the order they're checking out
with. Amazon handles this entirely correctly: if I put A and B in my
shopping cart, then press "Checkout", then while waiting for one of the
checkout screens to process I open another tab and put C in my cart - so
that my cart now has A, B, and C, in it - then when the payment goes
through only A and B disappear from my cart and C is still there,
waiting for me to start a new purchase.

So, again, we should not destroy the cart until we know the customer has
succeeded in paying; and, second, when we do get payment notification we
shouldn't "destroy" the cart, we should just remove from it whichever
items were actually paid for, using the little list of items that PayPal
will send us back in their IPN message.

Second:

I have a less strong opinion on creating an Order before they actually
leave the site. The issues would seem to be:

Con

* Orders are designed to hold information, but in this case there's
nothing to store except the fact that the user pressed "Checkout" and
left the site. You'd have all these orders sitting around with
nothing but an order number and a copy of a cart inside of them,
because the user reached PayPal and was annoyed with its interface and
decided not to check out after all.

* It requires a JavaScript trick: the "PayPal" button actually has to
redirect to an internal page that creates the order and then uses
JavaScript to press the "Submit" button on the actual form that POSTs
to PayPal. If the JavaScript doesn't work with their browser, then
the "PayPal checkout" button will just have taken them to a screen
with another PayPal checkout button, and making users click twice to
leave the site is something that lots of store owners might want to
avoid (I don't know many store owners, I must admit, but rumor has it
that they tend to like customers to be as few clicks away from
finishing paying as possible!).

Pro

* Using the user IDs and timestamps on all of those empty Order objects,
you could see how many visitors filled their cart then pressed
"Checkout" without completing the process.

Please add any more Pro and Con here that you can think of!

But, it seems to me that this mechanism uses space, time, and additional
complexity, in order to accomplish something that the off-site service
does anyway. I mean, the off-site service has several steps in its
checkout process, and if you want analytics on checkout process
abandonment you've got to go check out whatever stats PayPal keeps for
you, to see who left the process and quit at which stages in the
checkout. And, since you have to use PayPal to get complete analytics
anyway, why invest in extra complexity on our end just to keep a
duplicate copy of one of the several numbers?

But, I'm not an actual Store Owner, so I'm quite open to changing my
opinion here based on actual GetPaid users if they (or you) would like
to share more about how they actually use the service in practice.

> We could then provide the "pay with paypal" button on the order
> summary page.

Ah! I see! You are not advocating JavaScript, you're advocating
two-step checkout process: the person sees their cart and presses
"Checkout", then is shown their cart *again* and has to press "PayPal
Checkout" to actually go off-site.

> It would also simplify the solution of a bug with the current
> implementation; the function order_id of the view
> getpaid.paypal.views.PayPalCheckoutButton is:
> 30 def order_id(self):
> 31 return 'PUT ORDER ID HERE'
> and it would be handy to have the actual order id available when we
> create the button.

My proposal, which I entirely forgot to mention in the sprint docs, is
that every time we generate the "PayPal" form - which might be dozens of
times, at least, during each person's shopping experience - we generate
a fake "Order Id" that embeds the user's Plone ID somewhere secretly
inside of it. That way, when we later get an IPN message for that Order
and see that it doesn't exist yet, we can create it and auto-associate
it with the right cart owner using their embedded Plone Id.

But before coding this I wanted to have everyone else think through
whether this would raise any security concerns (I can't see any myself)
and I wanted opinions on whether it should be explicit, where the user
themselves (if they check) could see that the order number is
"69391959632-brhodes", or whether we should encode it somehow as part of
the order number so that it looks like numbers or hex codes too.

> BTW, we should also fix the personal details form and separate "first
> name" from "surname": we can't programmatically split "Full name" when
> we pass it to paypal.

I'm certainly not an expert on this area, but two objections immediately
occur to me:

1. Isn't the personal details page something that's a Plone-wide
standard and that we can't change? Surely we don't want that form to
change on the day that someone adds GetPaid to a site that's been
maybe running for years, and have to go back through and add two
names to all of their users before proceeding?

2. The first+last formula doesn't work everywhere in the world - nor
even with everyone in a large university. I think that's why Plone
has a free-form field.

If PayPal needs first and last, I suspect that we will just have to do
our best using .split() and so forth with the normal Plone name field.
But, again, I could easily be wrong here!

> One more issue: anonymous users can't see their own orders, so they
> wouldn't be able to pay with the described setup.

Can they pay with my proposed setup? They would just click "Check out
with PayPal" and be immediately whisked off-site?

> We could solve this providing a token in the emails we send after the
> order is created; the token could be the md5 hash of the date and time
> of the order. ... What do you think?

A strongly random UUID, not the date and time, is what is needed here
for each Order; but, aside from that, your idea is a very good one!
It's just like the Tracking links that lots of sites send out: because
no one else can guess a 30-character random string, the URL is
essentially private to whomever reads the email. That would be a nice
way for people (at least who type their emails correctly) to have a way
back to their Order. Plus, on the final Order page itself we could say
"to visit this later, bookmark..." and have the link there too.

Anyway, please feel free to provide ideas, thoughts, and counter-objects
to anything above!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-11-01T04:48:21Z

Michael Dunstan <michael.dunstan@...> writes:

> The Google Checkout processor tests fabricate the incoming signals
> from the checkout server...

Well, that's an interesting idea! At first it sounds like an
unconvincing test, but I guess if the XML you injected in the test was
actual real XML from Google that you'd captured during a by-hand test of
the callback, then you are indeed testing against real data and real
Google behavior. I like the approach enough to be comfortable with it!
If the sprinters want to kick off a callback from PayPal, capture the
steps, and replay them in their test, I think that will be a huge step
forward. Thanks for this simplification!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

paypal payment processor

2009-10-31T17:46:49Z

Hi,

while writing tests for the getpaid.paypal module this came to my mind:

the approach currently is that we don't create an order if it's not paid, but we instead create it after the paypal process is over and an IPN comes.

Customer data is also collected on the paypal site.

Some customers are propably going to place an order and for some reasons (computer crash or phone call etc) wait some time before paying it, or lose their browser session.

I really think we should create the order object and destroy the cart before the customer is sent to paypal, collecting data on the getpaid-enabled site as well.

We could then provide the "pay with paypal" button on the order summary page. This would allow orders to be paid after they have been taken.

It would also simplify the solution of a bug with the current implementation; the function order_id of the view getpaid.paypal.views.PayPalCheckoutButton is:

30 def order_id(self):

31 return 'PUT ORDER ID HERE'

and it would be handy to have the actual order id available when we create the button.

BTW, we should also fix the personal details form and separate "first name" from "surname": we can't programmatically split "Full name" when we pass it to paypal.

One more issue: anonymous users can't see their own orders, so they wouldn't be able to pay with the described setup.

We could solve this providing a token in the emails we send after the order is created; the token could be the md5 hash of the date and time of the order.

Would this be secure enough? It would prevent a random person from collecting personal data of users, would it?

I currently use this approach in production and, at least for me, it has worked well; but I'm not sure it's secure enough. Anyway, users like *a lot* not to be forced to remember username/password pairs. This would also allow them to email the link to the order details page to a friend, and he could see only that particular order. This could be useful for gifts if the recipient wants to check the shipping status.

What do you think?

Silvio

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T08:09:28Z

>> > My vote would be against a default "buildout.cfg" in Subversion if we're
>> > going to support multiple versions of Plone; it just makes it too
>> > dangerous, in my opinion, for people working on some other version. If
>> > you run "buildout" without choosing a version, that error message is
>> > necessary to remind you that the choice must be made.
>>

Extending buildout is much better way than having a default buildout
for each version. buildourt.cfg might be different depending on
installer and OS - we do not want to support that variation. If you
want to see the heacache check out buildout.cfg in Windows installer.
Instead we could provide different extension for each Plone version if
version soup is a problem.

I suggest we use combination of extends and [versions] to deal with
versioning problems.
E.g.
[buildout]
extends = http://dist.plone.org/release/3.3/versions.cfg
http://svn.plone.org/svn/collective/getpaid.buildout/getpaid_for_3.3.cfg

getpaid_for_3.3.cfg contains

[versions]
Products.PloneGetPaid=0.8
getpaid.somepackage=0.7
...

vs.

[buildout]
extends = http://dist.plone.org/release/4.0/versions.cfg
http://svn.plone.org/svn/collective/getpaid.buildout/getpaid_for_4.0.cfg

-Mikko

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T05:14:20Z

2009/10/31 Juan Pablo Giménez <jpg@...>

El vie, 30-10-2009 a las 19:21 -0400, Brandon Craig Rhodes escribió:

> Silvio <silviot@...> writes:
>
> > I forgot to specify the cfg file here (as I don't usually do) and it
> > didn't work. So I added a buildout.cfg that loads 316.cfg to be used
> > as a default for the latest supported version.
>
> The "buildout.cfg" used to be the one for Plone 2.5.5, which was never
> the version I wanted, and I got tired of ruining my buildout every time
> that I forgot and re-ran "buildout" without any arguments. :-)
>
> My vote would be against a default "buildout.cfg" in Subversion if we're
> going to support multiple versions of Plone; it just makes it too
> dangerous, in my opinion, for people working on some other version. If
> you run "buildout" without choosing a version, that error message is
> necessary to remind you that the choice must be made.

+1

Ok, sorry for committing that change without asking: I didn't think the choice of not having a buildout.cfg was intentional.

I stay however on my point that we should have a sensible default buildout.cfg that actually extends the buildout for the latest supported Plone.

Silvio

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T05:12:11Z

Juan Pablo Giménez <jpg@...> writes:

> I'm not using orders workflow because
> DefaultFinanceProcessorIntegration is tied to IPaymentProcessor and we
> are implementing IOffsitePaymentProcessor, that was what I changed on
> getpaid.core.payment and you reverted (brandon)...

I reverted the change because it broke GetPaid for me and I couldn't
understand why it was there. Let me go take a look now while the sprint
is going on!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T02:20:19Z

Hi all,

Brandon, thanks for the great work!

Unfortunately I will be participating document spring, so I cannot help you here. Also my work laptop said BOOOM so I cannot work on the code in any case.

If you need help with Mr. Developer or you have questions about getpaid.atshop I am here to answer to questions. I might or might not get to IRC.

-Mikko

On Fri, Oct 30, 2009 at 8:47 PM, Brandon Craig Rhodes <brandon@...> wrote:

I have an important outstanding branch of GetPaid which needs to be
merged, but I would like some help with it before merging.

Christopher Johnson asked me to describe the tasks that need to be
completed, in a format convenient for sprinters. Hence this email! If
you are sprinting on GetPaid, try reading through this whole email, then
seeing whether one of the issues is one within your range of competence
to tackle!

Briefly, here is the process to get started on if you are a sprinter:

1. Build out my "no-overrides" branch.
2. Verify that buttons now appear and disappear.
3. Practice running tests.
4. Choose a task.
5. Sprint!

For each of these five items, I've written an extended explanation
below. Read through it carefully, and let me know if you have any
questions!

Build out my "no-overrides" branch
----------------------------------

Unlike the main GetPaid buildout, which pulls in the official version of
each GetPaid package, my buildout pulls in the branches from SVN where I
have been working on the new functionality. You will need Python 2.4 to
work on it; if you do not have that version of Python on your system and
are unsure how to install it, please ask a more experienced sprinter how!

Here are the commands for creating your own copy of my buildout; there
are only four of them, but they can take quite a while to run. I have
shown the amount of time that they take on my own laptop, but I think my
laptop already has many packages installed that the buildout needed; if
these packages need to be downloaded for the first time on your own
computer, then the times below could run much longer:

(5 minutes)
svn co https://getpaid.googlecode.com/svn/getpaid.buildout/branches/brandon-no-overrides no-overrides

(Immediate)
cd no-overrides

(10 seconds)
python2.4 bootstrap.py -c 316.cfg

(4 minutes)
bin/buildout -c 316.cfg -v

Once these commands have finished, you should then be able to run a
Plone instance very simply:

bin/instance fg

You *might* at this point receive the error "ImportError: No module
named PIL". If you do, simply ask someone more experienced how to
install the Python Imaging Library for Python 2.4 on your system. Once
it is installed, you should be able to run the above command successfully.

Once the instance is up and running:

* Visit the URL:

http://localhost:8080/manage_main

and log in as "admin" with the password "admin". Then select "Plone
site" from the pull-down menu next to "Add", press Enter, give it the
Id "Plone" and select "PloneGetPaid" from the "Extension Profiles"
down at the bottom, and press "Add Plone Site". You should now be
able to visit your new Plone site at:

http://localhost:8080/Plone

* Make a "Page" a buyable type by visiting the following URL and moving
"Page" into the right column at the top and clicking "Apply":

http://localhost:8080/Plone/@@manage-getpaid-content-types

* Create a buyable Page by returning to your home page:

http://localhost:8080/Plone/

and selecting "Add new…" "Page". Give it a title of "Sweater" and
click "Save". Then select "Actions…" "Make buyable", give it a
product code of "1001" and a price of "59.95", and click "Activate".

* Add the page to your shopping cart by finding the "Product details"
portlet in the lower-right of the Sweater page and clicking "Add to
Cart".

Verify that buttons now appear and disappear
--------------------------------------------

After following the instructions above, and with your Plone instance
running, you are ready to check out the new features of my branch. It
is designed to allow multiple off-site payment processors to live
happily together on the screen at the same time, and also to allow
on-site payment processing to be an option that can be turned on or off.
Here is how to try out my new features:

* Visit your shopping cart at:

http://localhost:8080/Plone/@@getpaid-cart

The cart should have a single checkout button, beneath the "Continue
Shopping" button, and it should be labeled "Checkout". Try clicking
on it; it should send you to the first page of the built-in checkout
process.

* The first feature of my branch that you should try out is that onsite
checkout can now be enabled or disabled, separately from the offsite
payment options. To see this, visit:

http://localhost:8080/Plone/@@manage-getpaid-payment-options

and un-check the "Activate On-site Payment" button and click "apply".
Now return to and re-load your shopping cart page. You should note
that no "Checkout" button now appears.

* The next feature you should try out is the fact that off-site payment
buttons can be made to appear. Return to the payment options screen
and move "Google Checkout" into the right column and press "Apply".
Re-load your cart and you should now see a Google Checkout button
appear. Now return to the payment options screen and add the "PayPal"
processor to the list on the right as well; now, your cart should show
two checkout buttons. Now return to the payment options and turn the
"Activate On-site Payment" check box back on; your cart should now
show all three buttons for the user to choose from.

There; that's, essentially, what the branch accomplishes. Rather than
require every off-site payment solution to perform messy ZCML overrides
to hijack the main GetPaid checkout button, my branch lets them each
cleanly offer their own button that appears or disappears under the
control of the site owner, not the programmer.

Actually, there's another effect that you can observe - the Payment
Processor options page at:

http://localhost:8080/Plone/@@manage-getpaid-payment-processor

provides a block of options for each active payment processor, but makes
them disappear if the payment processor is turned off. Isn't that cool?

Practice running tests
----------------------

Good programmers always try to include comprehensive unit and
integration tests as part of a package. Test can verify, as we keep
"improving" our products, that all of their old features actually keep
working even as we are busy adding new ones.

Most of the work I have done has been in four packages. Here is the
status of their tests:

* Products.PloneGetPaid - Working
* getpaid.core - Working
* getpaid.paypal - Broken!
* getpaid.googlecheckout - Broken (package might not even completely work)!

As you can guess, those last two statuses have a lot to do with what I
would like to see accomplished during the sprint. :-)

Here is how to run the two working sets of tests, so that you can see
that they indeed succeed - and so that you can also learn the pattern,
in case the sprint task you choose involves running the tests for any of
the other GetPaid packages:

bin/instance test --package Products.PloneGetPaid
bin/instance test --package getpaid.core

You should see lots of crazy warning and deprecation messages scroll
past (ah, Plone!) then the dots "...." that are printed as each test
runs. Once the ordeal is over, you should receive a report telling you
that, despite all of those scary messages, the tests actually passed:

Ran 147 tests with 0 failures and 0 errors in 96.076 seconds.

If they pass, then your buildout is a safe place for you to begin work.

Look at all you've accomplished! You now have a working development
instance of GetPaid, you can run its Plone, you can explore its
features, and you can run its tests. It's now about time to choose a
task and start sprinting!

Choose a task
-------------

If you are new to Plone development, there is one issue that might not
have been thought about ahead of time: establishing your legal ability
to contribute code back to GetPaid. I know that contributing to Plone
requires signing and returning a form to the foundation, but you should
talk to Christopher Johnson as you get started on this sprint to make
sure that code or patches you generate can indeed be legally contributed
back to the effort.

So, how can you choose a task?

What I would like to see the sprint accomplish is to get both the PayPal
and the GoogleCheckout mechanisms working great with my new branch.
That would bring about two great results:

1. Just the fact that everyone would have worked with and tried out my
branch for hours and hours would hopefully make us all comfortable
that my "Products.PloneGetPaid" and "getpaid.core" innovates can now
be merged back into trunk.

2. Instead of my new feature appearing for the first time in trunk with
its "Offsite Payment Processors" setup option blank, we could now
include both PayPal and GoogleCheckout in the default GetPaid build.

To help people communicate during this sprint, I will here invent a
little rating system for GetPaid off-site payment processors:

"Tin" - the off-site payment processor does not even use my new plug-in
mechanism, but relies on an "overrides.zcml" file instead.

"Bronze" - the processor has been rewritten to use my new plug-in
mechanism and can therefore live peacefully with other off-site
payment processors.

"Silver" - the processor's tests have been re-written (or written for
the first time, if it lacked them before) to demonstrate that it
plugs in fine with my new mechanism.

"Gold" - the processor supports a callback mechanism that lets the
off-site payment solution report back to Plone about which orders
users actually carried through with.

"Platinum" - tests are written, and work, for the callback mechanism.

Given the above ratings, here is now I would rate the two payment
processors I have touched:

PayPal - Bronze
GoogleCheckout - on the way to Bronze

The goal that I would suggest for the sprint is to work on these two
change processors to get them both at least to "Silver", because that is
a tolerable working state: while shop owners can't use "Silver"-level
processors and expect to be able to manage orders on their Plone site,
many won't need to because they can do their management on PayPal or
Google Checkout's own site. Of course, if sprinters are available to
start working on going Gold, then please do so!

So, having given that background, what are the available projects for
the sprint? Here are some projects that I think could be divvied up
among you.

Easy Tasks - require only basic knowledge of Plone
..................................................

* Add "Available" and "Selected" headings to the "Off-site Payment
Processors" controller on the @@manage-getpaid-payment-options page.

Take a look at the @@manage-getpaid-payment-options page; do you see
something funny about the off-site selection boxes up at the top?
That's right! They contain absolutely no indication of which box is
for the ones you *do* want to use, and which box is for the ones you
*don't*. :-)

That's because I couldn't figure out how to label them, and after
one or two tries I ran out of time and had to turn to other things.

The odd thing is that the "Accepted Credit Cards" setting just below
it on the same page *does* have headings; but I couldn't figure out
what the difference was!

This whole form is powered by the "IGetPaidManagementPaymentOptions"
interface in:

Products.PloneGetPaid/Products/PloneGetPaid/interfaces.py

Somehow there's a way to turn those little headings on; go find it!
If you're new to Plone, this should be a great little project.

* Fix the fact that checkout buttons are too close to each other.

You probably noticed this already: the checkout buttons run right up
against each other (in Firefox, at least) where they are sitting
beneath the shopping cart. If you know a little HTML and CSS, then
please consider jumping in and fixing this! I am probably just
failing to put a <div> around them with the right class to tell the
default Plone stylesheets that they're buttons and need some room
around them.

The (admittedly primitive) template that I use for the stack of
buttons is here:

Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/checkout-buttons.pt

What am I doing wrong? You will want to compare my HTML to other
buttons around the Plone site, that are presumably done the "right"
and "standard" way, and then try modifying the above template until
things look better.

It's annoying that the checkout buttons are different sizes, isn't
it? But we have to use the logos for user recognition of these
common services, right? You might also think about whether there's
any way to improve the appearance when the Google button is so much
bigger than the PayPal one!

* Disable the checkout process if "Activate On-site Payment" is
unchecked.

Okay, you might have noticed something of a flaw in my design: if
the store owner un-checks the "Activate On-site Payment" box at

http://localhost:8080/Plone/@@manage-getpaid-payment-options

then, as planned, the normal "Checkout" button disappears. But,
behind the scenes, the view is still there and ready to let the user
check out! It should really be disabled. To be more exact, if the
"Activate On-site Payment" box is unchecked by the store owner, then
any attempt to access:

http://localhost:8080/Plone/@@getpaid-checkout-wizard

(whether by a user who knows GetPaid, or because an old link to the
checkout has been left in a site template somewhere) should be met
with some sort of refusal. Maybe it should redirect back to the
main cart view? Or should it show an error and provide a link back
to the rest of the site? First, write the logic. Then you can
debate with other GetPaid people about what action the logic should
trigger.

You will probably accomplish this by finding the class that runs the
"getpaid-checkout-wizard" view (look through the ZCML to find the
module and class that run that view), and putting an "if" statement
inside of it somewhere that grabs the GetPaid global options (you
can find the pattern for this in several places; look for the portal
root being adapted to an options interface from getpaid.core!) and
then looks to make sure that onsite checkout is enabled.

Intermediate Tasks
..................

* Write tests for PayPal

The PayPal processor in "trunk" lacks tests entirely, from what I
can see, and it needs some! You can verify that it works by hand by
creating a PayPal sandbox account and entering its username into
your PayPal Processor Options (if PayPal is turned on!) at:

http://localhost:8080/Plone/@@manage-getpaid-payment-processor

By "works", I mean that you'll indeed be forwarded to PayPal which
will display the total of your shopping cart, and if you click on
the pull-down arrow on the margin just below the total you'll see
all of the "line items" appear that detail the objects that were in
your shopping cart. This all demonstrates that information is
making it through from GetPaid to PayPal correctly.

But this is the world of Python, and testing things by hand is not
enough for us! The PayPal change processor needs tests. How can
you add them?

First, look at the trunk of "getpaid.googlecheckout":

http://code.google.com/p/getpaid/source/browse#svn/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/tests

You will see that its tests.test_suite() function runs two doctests
that you'll find one level up, outside the test directory: one test
just named "googlecheckout.txt" and another that is named
"googlecheckout-browser.txt". If you checked out the project trunk
and ran these tests, you'd even see that they pass!

To give PayPal tests, copy these tests as an example and adapt them
to PayPal: have them create some purchasable objects,

* Get the Google Checkout button working.

Though the Google Checkout button will appear when that payment
processor is activated, the form that surrounds the button is pretty
much empty. Unlike the PayPal checkout button, which I've been able
to spend more time on, the Google Checkout button is pretty much
blank.

It needs someone to go in and add all of the hidden fields that will
make it an effective button. If you choose to tackle this problem,
you will have the advantage of having the PayPal branch to work off
of: it will show you how an effective form can be generated that is
full of information about the current shopping cart.

You will have succeeded if, when you are done, the Google Checkout
button - like the PayPal button - actually takes the person clicking
it off-site and if, upon arrival, Google Checkout knows what items
were in their cart. Expect to need to bring up the Google Checkout
docs to complete this task; but use the PayPal branch to see
examples of how to get to the information (like payment processor
settings and cart contents) that you'll need to fill out the form.

* BONUS: Tests for Google Checkout.

If the previous item is actually accomplished, and the Google
Checkout button becomes useful, then write working tests for it -
check out the instructions in the first item in this Intermediate
section for thoughts on testing.

Advanced Tasks
..............

* Get PayPal notification working.
* Get Google Checkout notification working.

Okay, here is a real challenge in case some serious Plone hackers
show up and the above items don't provide enough entertainment.

Your task is to write tests - I have no idea how - that verify that
either the PayPal or Google Checkout payment processor, after
sending the user off-site, correctly receives back the messages
telling them that the buyer is progressing through checkout.

There are two challenges here that are actually a bit steep for me,
as a developer, to tackle (which is why I've not even attempted to
tackle them):

1. No "Order" object exists yet when the user leaves the site. How,
then, will the return messages from PayPal or Google Checkout -
that refer to the order number - be associated with the correct
user, and result in an order being created for them? My guess is
that the buttons that send users off-site should generate
one-time disposable order numbers that have the user's username
encoded inside of them. When the notification comes back, if no
order of that number exists yet, then the username can be decoded
to figure out what user to create the order for. And when the
order is finalized and purchased, you can even empty that user's
shopping cart. For bonus points, only empty it of the items that
have actually been purchased, leaving items inside that were not
included in the order the user just paid for. :-)

2. How can a Plone test - whether a doctest or normal unit test -
submit a form to an off-site service and at the same time already
be ready to receive a signal back? There are two parts to this
question: first, since the test will often be running on a
computer behind a firewall, the test will have to be given the
name of an SSH account it can log into with an "-R" option so
that "http://wherever.it.is:PORT/" becomes a location that the
remote service can POST to and have it actually be received by
the test on whatever port it opens. And, second, how can the
test break into two threads to do the actual HTTP handling?

These, again, are quite advanced challenges, and are actually a bit
beyond my own knowledge at this point; you should only seize them if
you are among the Great Among Plone, and happen to be wanting to
sprint upon GetPaid. If we are so honored.

Sprint!
-------

Finally, after choosing a task from the above: get started!

I'll try to be on IRC, and helpful GetPaid folks should be somewhere
nearby to help. I have tried to be clear in everything above, and I'll
apologize ahead of time if any inaccuracies in what I've written waste
your time; I've taken part in several sprints before, and I know how
frustrating it can be just getting set up, much less trying to
accomplish anything!

If you could, use the mailing list to let us know what you're working
on, so that everyone has a record of who has grabbed what task. When
the sprint is over, send a reply to your message telling what happened,
where things stand, and including your patch or improvement if you
generated one but weren't in a position to commit it.

And, most of all, have fun. :-) I look forward to hearing your reports!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--
Mikko Ohtamaa
Managing director, Red Innovation Ltd.
+358 40 743 9707
www.redinnovation.com
Every problem is solvable if you can throw enough energy drinks at it

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T00:36:25Z

El vie, 30-10-2009 a las 14:47 -0400, Brandon Craig Rhodes escribió:

> I have an important outstanding branch of GetPaid which needs to be
> merged, but I would like some help with it before merging.
>
> Christopher Johnson asked me to describe the tasks that need to be
> completed, in a format convenient for sprinters. Hence this email! If
> you are sprinting on GetPaid, try reading through this whole email, then
> seeing whether one of the issues is one within your range of competence
> to tackle!
>
> Briefly, here is the process to get started on if you are a sprinter:
>
> 1. Build out my "no-overrides" branch.
> 2. Verify that buttons now appear and disappear.
> 3. Practice running tests.
> 4. Choose a task.
> 5. Sprint!

FYI, getpaid.nmi processor is working again! and have a running test
suite,

./bin/instance test -s getpaid.nmi
...
Installing PloneGetPaid ... done (0.052s)
Running Products.PloneTestCase.layer.PloneSite tests:
Set up Products.PloneTestCase.layer.PloneSite in 0.009 seconds.
Running:
...Installing Five ... done (0.040s)
2009-10-31 04:04:06 WARNING plone.z3cform Monkey patching
z3c.form.term.ChoiceTerms to correctly bind fields
.............
Ran 16 tests with 0 failures and 0 errors in 10.508 seconds.
Tearing down left over layers:
Tear down Products.PloneTestCase.layer.PloneSite in 0.544 seconds.
Tear down Products.PloneTestCase.layer.ZCML in 0.006 seconds.
Testrunner took: 11.792 seconds.

I'm not using orders workflow because DefaultFinanceProcessorIntegration
is tied to IPaymentProcessor and we are implementing
IOffsitePaymentProcessor, that was what I changed on
getpaid.core.payment and you reverted (brandon)... but its ok, maybe we
shouldn't change DefaultFinanceProcessorIntegration but "overrides" the
adapter (not actually overrides, but find a way to wire another class)
or define a full new workflow for offsite processors... I'm not sure
what is better (and is too late here... :))

Regards,
Juan Pablo

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-31T00:36:17Z

El vie, 30-10-2009 a las 19:21 -0400, Brandon Craig Rhodes escribió:

> Silvio <silviot@...> writes:
>
> > I forgot to specify the cfg file here (as I don't usually do) and it
> > didn't work. So I added a buildout.cfg that loads 316.cfg to be used
> > as a default for the latest supported version.
>
> The "buildout.cfg" used to be the one for Plone 2.5.5, which was never
> the version I wanted, and I got tired of ruining my buildout every time
> that I forgot and re-ran "buildout" without any arguments. :-)
>
> My vote would be against a default "buildout.cfg" in Subversion if we're
> going to support multiple versions of Plone; it just makes it too
> dangerous, in my opinion, for people working on some other version. If
> you run "buildout" without choosing a version, that error message is
> necessary to remind you that the choice must be made.

+1

> However, I happily encourage *local* symlinks that we each make from
> "buildout.cfg" to the version we're currently working on.

I usually use a local.cfg pointing to the correct cfg and overriding
recipes with local stuff, like instance port number, additional eggs,
etc... so my bash history only have buildout lines with -c local.cfg,
even usable on buildouts with a buildout.cfg file...

Regards,
Juan Pablo

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T23:31:39Z

Hi Brandon

Sweet, it seems to work now. I don't think I am going to have time to run through your entire email before the sprint today, but I will do so as soon as I get a chance. Probably this evening some time.

Hannes

2009/10/31 Brandon Craig Rhodes <brandon@...>

Hannes -

Thanks for the bug report! The problem was that the PayPal payment
processor didn't know what to do if you turned it on before choosing
whether to use the sandbox or production server (whoops!). I have now
fixed it to make it more robust: it uses the sandbox server in that
case. Run "svn up" and let me know if that fixes it!

--

Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T16:34:11Z

On Sat, Oct 31, 2009 at 7:47 AM, Brandon Craig Rhodes
<brandon@...> wrote:

> 2. How can a Plone test - whether a doctest or normal unit test -
> submit a form to an off-site service and at the same time already
> be ready to receive a signal back? There are two parts to this
> question: first, since the test will often be running on a
> computer behind a firewall, the test will have to be given the
> name of an SSH account it can log into with an "-R" option so
> that "http://wherever.it.is:PORT/" becomes a location that the
> remote service can POST to and have it actually be received by
> the test on whatever port it opens. And, second, how can the
> test break into two threads to do the actual HTTP handling?

The Google Checkout processor tests fabricate the incoming signals
from the checkout server. See

http://code.google.com/p/getpaid/source/browse/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/googlecheckout.txt#128

http://code.google.com/p/getpaid/source/browse/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/googlecheckout-browser.txt#201

--
Michael Dunstan

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T16:33:50Z

Hannes -

Thanks for the bug report! The problem was that the PayPal payment
processor didn't know what to do if you turned it on before choosing
whether to use the sandbox or production server (whoops!). I have now
fixed it to make it more robust: it uses the sandbox server in that
case. Run "svn up" and let me know if that fixes it!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T16:21:20Z

Silvio <silviot@...> writes:

> I forgot to specify the cfg file here (as I don't usually do) and it
> didn't work. So I added a buildout.cfg that loads 316.cfg to be used
> as a default for the latest supported version.

The "buildout.cfg" used to be the one for Plone 2.5.5, which was never
the version I wanted, and I got tired of ruining my buildout every time
that I forgot and re-ran "buildout" without any arguments. :-)

My vote would be against a default "buildout.cfg" in Subversion if we're
going to support multiple versions of Plone; it just makes it too
dangerous, in my opinion, for people working on some other version. If
you run "buildout" without choosing a version, that error message is
necessary to remind you that the choice must be made.

However, I happily encourage *local* symlinks that we each make from
"buildout.cfg" to the version we're currently working on.

Anyway, that's just my vote. :-) I know that's not how things have been
working in trunk, so I'd assumed that this change would disappear once
my branch is merged then destroyed.

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T15:24:39Z

Hey there Brandon

I was busy going through your email, and following all the steps when suddenly I got an error. Below is where I was, and in red I posted the traceback.

2009/10/30 Brandon Craig Rhodes <brandon@...>

Verify that buttons now appear and disappear
--------------------------------------------

After following the instructions above, and with your Plone instance
running, you are ready to check out the new features of my branch. It
is designed to allow multiple off-site payment processors to live
happily together on the screen at the same time, and also to allow
on-site payment processing to be an option that can be turned on or off.
Here is how to try out my new features:

* Visit your shopping cart at:

http://localhost:8080/Plone/@@getpaid-cart

The cart should have a single checkout button, beneath the "Continue
Shopping" button, and it should be labeled "Checkout". Try clicking
on it; it should send you to the first page of the built-in checkout
process.

* The first feature of my branch that you should try out is that onsite
checkout can now be enabled or disabled, separately from the offsite
payment options. To see this, visit:

http://localhost:8080/Plone/@@manage-getpaid-payment-options

and un-check the "Activate On-site Payment" button and click "apply".
Now return to and re-load your shopping cart page. You should note
that no "Checkout" button now appears.

* The next feature you should try out is the fact that off-site payment
buttons can be made to appear. Return to the payment options screen
and move "Google Checkout" into the right column and press "Apply".
Re-load your cart and you should now see a Google Checkout button
appear. Now return to the payment options screen and add the "PayPal"
processor to the list on the right as well; now, your cart should show
two checkout buttons.

And this is where I hit a wall :/

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish

  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object

  Module Products.PloneGetPaid.browser.cart, line 47, in __call__
  Module Products.Five.browser.metaconfigure, line 417, in __call__

  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec

  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
  Module Products.PageTemplates.PageTemplate, line 89, in pt_render

  Module zope.pagetemplate.pagetemplate, line 117, in pt_render
  Module zope.tal.talinterpreter, line 271, in __call__

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 891, in do_useMacro

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal

  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 891, in do_useMacro

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal

  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 949, in do_defineSlot

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 949, in do_defineSlot

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal

  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 534, in do_optTag_tal

  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal
  Module Products.PageTemplates.Expressions, line 221, in evaluateStructure

  Module zope.tales.tales, line 696, in evaluate
   - URL: index

   - Line 6, Column 1
   - Expression: <PathExpr standard:'view/manager/render'>

   - Names:
      {'container': <PloneSite at /Plone>,

       'context': <PloneSite at /Plone>,
       'default': <object object at 0xb7cab528>,

       'here': <PloneSite at /Plone>,
       'loop': {},

       'nothing': None,
       'options': {'args': (<Products.Five.metaclass.SimpleViewClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/cart-manage.pt object at 0xd2f23ec>,)},

       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd2f2bac>,
       'request': <HTTPRequest, URL=http://localhost:8080/Plone/@@getpaid-cart>,

       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd2f27cc>,

       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,

       'view': <Products.Five.metaclass.SimpleViewClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/cart-manage.pt object at 0xd2f23ec>,

       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd2f2fcc>}
  Module zope.tales.expressions, line 217, in __call__

  Module Products.PageTemplates.Expressions, line 161, in _eval
  Module Products.PageTemplates.Expressions, line 123, in render

  Module zope.viewlet.manager, line 110, in render
  Module Shared.DC.Scripts.Bindings, line 313, in __call__

  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec

  Module Products.PageTemplates.PageTemplate, line 89, in pt_render
  Module zope.pagetemplate.pagetemplate, line 117, in pt_render

  Module zope.tal.talinterpreter, line 271, in __call__
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 824, in do_loop_tal
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag

  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 534, in do_optTag_tal
  Module zope.tal.talinterpreter, line 516, in no_tag

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal

  Module Products.PageTemplates.Expressions, line 221, in evaluateStructure
  Module zope.tales.tales, line 696, in evaluate

   - URL: viewlet-manager
   - Line 4, Column 5
   - Expression: <PathExpr standard:'viewlet/render'>

   - Names:
      {'container': <PloneSite at /Plone>,

       'context': <PloneSite at /Plone>,
       'default': <object object at 0xb7cab528>,

       'here': <PloneSite at /Plone>,
       'loop': {'viewlet': <Products.PageTemplates.Expressions.PathIterator object at 0xd3102cc>},

       'nothing': None,
       'options': {'args': (),

                   'viewlets': [<Products.Five.viewlet.viewlet.SimpleViewletClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/cart-listing.pt object at 0xd2f26ec>,

                                <Products.Five.viewlet.viewlet.SimpleViewletClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/cart-actions.pt object at 0xd2f29ec>]},

       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd2e6cec>,
       'request': <HTTPRequest, URL=http://localhost:8080/Plone/@@getpaid-cart>,

       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd2f4a2c>,

       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,

       'view': <UnauthorizedBinding: context>,
       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd2e696c>}

  Module zope.tales.expressions, line 217, in __call__
  Module Products.PageTemplates.Expressions, line 161, in _eval

  Module Products.PageTemplates.Expressions, line 123, in render
  Module Products.PloneGetPaid.browser.cart, line 290, in render

  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec

  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
  Module Products.PageTemplates.PageTemplate, line 89, in pt_render

  Module zope.pagetemplate.pagetemplate, line 117, in pt_render
  Module zope.tal.talinterpreter, line 271, in __call__

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 855, in do_condition

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 534, in do_optTag_tal

  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal
  Module Products.PageTemplates.Expressions, line 221, in evaluateStructure

  Module zope.tales.tales, line 696, in evaluate
   - URL: cart-actions

   - Line 30, Column 2
   - Expression: <PathExpr standard:'context/@@getpaid-checkout-buttons'>

   - Names:
      {'container': <PloneSite at /Plone>,

       'context': <PloneSite at /Plone>,
       'default': <object object at 0xb7cab528>,

       'here': <PloneSite at /Plone>,
       'loop': {},

       'nothing': None,
       'options': {'args': ()},

       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd31066c>,
       'request': <HTTPRequest, URL=http://localhost:8080/Plone/@@getpaid-cart>,

       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd310e6c>,

       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,

       'view': <Products.Five.viewlet.viewlet.SimpleViewletClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/cart-actions.pt object at 0xd2f29ec>,

       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd310e0c>}
  Module zope.tales.expressions, line 217, in __call__

  Module Products.PageTemplates.Expressions, line 161, in _eval
  Module Products.PageTemplates.Expressions, line 123, in render

  Module Products.PloneGetPaid.browser.checkout_buttons, line 62, in __call__
  Module Shared.DC.Scripts.Bindings, line 313, in __call__

  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec

  Module Products.PageTemplates.PageTemplate, line 89, in pt_render
  Module zope.pagetemplate.pagetemplate, line 117, in pt_render

  Module zope.tal.talinterpreter, line 271, in __call__
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 824, in do_loop_tal
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag

  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 534, in do_optTag_tal
  Module zope.tal.talinterpreter, line 516, in no_tag

  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal

  Module Products.PageTemplates.Expressions, line 221, in evaluateStructure
  Module zope.tales.tales, line 696, in evaluate

   - URL: index
   - Line 9, Column 2
   - Expression: <PathExpr standard:'offsite_button'>

   - Names:
      {'container': <PloneSite at /Plone>,

       'context': <PloneSite at /Plone>,
       'default': <object object at 0xb7cab528>,

       'here': <PloneSite at /Plone>,
       'loop': {'offsite_button': <Products.PageTemplates.Expressions.PathIterator object at 0xd3150ec>},

       'nothing': None,
       'options': {'args': ()},

       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd31022c>,
       'request': <HTTPRequest, URL=http://localhost:8080/Plone/@@getpaid-cart>,

       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd31042c>,

       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,

       'view': <Products.Five.metaclass.SimpleViewClass from /home/hannes/zopes/getpaid/no-overrides/src/Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/checkout-buttons.pt object at 0xd31012c>,

       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd310c6c>}
  Module zope.tales.expressions, line 217, in __call__

  Module Products.PageTemplates.Expressions, line 161, in _eval
  Module Products.PageTemplates.Expressions, line 123, in render

  Module Products.Five.browser.metaconfigure, line 417, in __call__
  Module Shared.DC.Scripts.Bindings, line 313, in __call__

  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec

  Module Products.PageTemplates.PageTemplate, line 89, in pt_render
  Module zope.pagetemplate.pagetemplate, line 117, in pt_render

  Module zope.tal.talinterpreter, line 271, in __call__
  Module zope.tal.talinterpreter, line 346, in interpret

  Module zope.tal.talinterpreter, line 408, in do_startTag
  Module zope.tal.talinterpreter, line 485, in attrAction_tal

  Module Products.PageTemplates.Expressions, line 228, in evaluateText
  Module zope.tales.tales, line 696, in evaluate

   - URL: index
   - Line 1, Column 0
   - Expression: <PathExpr standard:'view/action_url'>

   - Names:
      {'container': <getpaid.paypal.paypal.PayPalStandardProcessor object at 0xd310b8c>,

       'context': <getpaid.paypal.paypal.PayPalStandardProcessor object at 0xd310b8c>,
       'default': <object object at 0xb7cab528>,

       'here': <getpaid.paypal.paypal.PayPalStandardProcessor object at 0xd310b8c>,
       'loop': {},

       'nothing': None,
       'options': {'args': (<Products.Five.metaclass.SimpleViewClass from /home/hannes/zopes/getpaid/no-overrides/src/getpaid.paypal/src/getpaid/paypal/templates/paypal-checkout-button.pt object at 0xd310c2c>,)},

       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd312fac>,
       'request': <HTTPRequest, URL=http://localhost:8080/Plone/@@getpaid-cart>,

       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd3123ec>,

       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,

       'view': <Products.Five.metaclass.SimpleViewClass from /home/hannes/zopes/getpaid/no-overrides/src/getpaid.paypal/src/getpaid/paypal/templates/paypal-checkout-button.pt object at 0xd310c2c>,

       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd31296c>}
  Module zope.tales.expressions, line 217, in __call__

  Module Products.PageTemplates.Expressions, line 161, in _eval
  Module Products.PageTemplates.Expressions, line 123, in render

  Module getpaid.paypal.views, line 18, in action_url
  Module getpaid.paypal.paypal, line 22, in server_url

KeyError

Now return to the payment options and turn the
"Activate On-site Payment" check box back on; your cart should now
show all three buttons for the user to choose from.

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Slides from PloneConf talk

2009-10-30T14:52:00Z

Hi there, the full URL to the slides is:
http://www.slideshare.net/ifPeople/getpaid-exploring-ecommerce-in-plone

Enjoy

And thanks for the great talk Chris. :)

2009/10/30 Iain Mac Donald <google.tools@...>

On Fri, 30 Oct 2009 15:02:52 -0400
Christopher Johnson <cjj.ifpeople@...> wrote:

> I've posted the slides from the Plone Conference 2009 GetPaid talk
> here: http://snurl.com/getpaid-slidesThe

Unfortunately, link is not valid.

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Sprinting on GetPaid: a plan

2009-10-30T14:06:02Z

On Fri, Oct 30, 2009 at 7:47 PM, Brandon Craig Rhodes <brandon@...> wrote:

I have an important outstanding branch of GetPaid which needs to be
merged, but I would like some help with it before merging.

Great, I'm sprinting tomorrow on this.

(10 seconds)
python2.4 bootstrap.py -c 316.cfg

I forgot to specify the cfg file here (as I don't usually do) and it didn't work.

So I added a buildout.cfg that loads 316.cfg to be used as a default for the latest supported version.

Is there any known problem with 3.3.1? Can we use that as the default supported version?

(4 minutes)
bin/buildout -c 316.cfg -v

so this can also be simplified to

bin/buildout -v

Silvio

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Slides from PloneConf talk

2009-10-30T12:36:18Z

On Fri, 30 Oct 2009 15:02:52 -0400
Christopher Johnson <cjj.ifpeople@...> wrote:

> I've posted the slides from the Plone Conference 2009 GetPaid talk
> here: http://snurl.com/getpaid-slidesThe

Unfortunately, link is not valid.

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Slides from PloneConf talk

2009-10-30T12:02:52Z

Hi,

I've posted the slides from the Plone Conference 2009 GetPaid talk here:

http://snurl.com/getpaid-slides

The video from the presentation :http://www.ustream.tv/recorded/2447051 . The presentation was meant to provide information about the state of the project and how to get into it now.

David Glick's case study talk on setting up GetPaid and Salesforce integration is also available here: http://www.ustream.tv/recorded/2446810

Regards,
Chris

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Sprinting on GetPaid: a plan

2009-10-30T11:47:16Z

I have an important outstanding branch of GetPaid which needs to be
merged, but I would like some help with it before merging.

Christopher Johnson asked me to describe the tasks that need to be
completed, in a format convenient for sprinters. Hence this email! If
you are sprinting on GetPaid, try reading through this whole email, then
seeing whether one of the issues is one within your range of competence
to tackle!

Briefly, here is the process to get started on if you are a sprinter:

1. Build out my "no-overrides" branch.
2. Verify that buttons now appear and disappear.
3. Practice running tests.
4. Choose a task.
5. Sprint!

For each of these five items, I've written an extended explanation
below. Read through it carefully, and let me know if you have any
questions!

Build out my "no-overrides" branch
----------------------------------

Unlike the main GetPaid buildout, which pulls in the official version of
each GetPaid package, my buildout pulls in the branches from SVN where I
have been working on the new functionality. You will need Python 2.4 to
work on it; if you do not have that version of Python on your system and
are unsure how to install it, please ask a more experienced sprinter how!

Here are the commands for creating your own copy of my buildout; there
are only four of them, but they can take quite a while to run. I have
shown the amount of time that they take on my own laptop, but I think my
laptop already has many packages installed that the buildout needed; if
these packages need to be downloaded for the first time on your own
computer, then the times below could run much longer:

(5 minutes)
svn co https://getpaid.googlecode.com/svn/getpaid.buildout/branches/brandon-no-overrides no-overrides

(Immediate)
cd no-overrides

(10 seconds)
python2.4 bootstrap.py -c 316.cfg

(4 minutes)
bin/buildout -c 316.cfg -v

Once these commands have finished, you should then be able to run a
Plone instance very simply:

bin/instance fg

You *might* at this point receive the error "ImportError: No module
named PIL". If you do, simply ask someone more experienced how to
install the Python Imaging Library for Python 2.4 on your system. Once
it is installed, you should be able to run the above command successfully.

Once the instance is up and running:

* Visit the URL:

http://localhost:8080/manage_main

and log in as "admin" with the password "admin". Then select "Plone
site" from the pull-down menu next to "Add", press Enter, give it the
Id "Plone" and select "PloneGetPaid" from the "Extension Profiles"
down at the bottom, and press "Add Plone Site". You should now be
able to visit your new Plone site at:

http://localhost:8080/Plone

* Make a "Page" a buyable type by visiting the following URL and moving
"Page" into the right column at the top and clicking "Apply":

http://localhost:8080/Plone/@@manage-getpaid-content-types

* Create a buyable Page by returning to your home page:

http://localhost:8080/Plone/

and selecting "Add new…" "Page". Give it a title of "Sweater" and
click "Save". Then select "Actions…" "Make buyable", give it a
product code of "1001" and a price of "59.95", and click "Activate".

* Add the page to your shopping cart by finding the "Product details"
portlet in the lower-right of the Sweater page and clicking "Add to
Cart".

Verify that buttons now appear and disappear
--------------------------------------------

After following the instructions above, and with your Plone instance
running, you are ready to check out the new features of my branch. It
is designed to allow multiple off-site payment processors to live
happily together on the screen at the same time, and also to allow
on-site payment processing to be an option that can be turned on or off.
Here is how to try out my new features:

* Visit your shopping cart at:

http://localhost:8080/Plone/@@getpaid-cart

The cart should have a single checkout button, beneath the "Continue
Shopping" button, and it should be labeled "Checkout". Try clicking
on it; it should send you to the first page of the built-in checkout
process.

* The first feature of my branch that you should try out is that onsite
checkout can now be enabled or disabled, separately from the offsite
payment options. To see this, visit:

http://localhost:8080/Plone/@@manage-getpaid-payment-options

and un-check the "Activate On-site Payment" button and click "apply".
Now return to and re-load your shopping cart page. You should note
that no "Checkout" button now appears.

* The next feature you should try out is the fact that off-site payment
buttons can be made to appear. Return to the payment options screen
and move "Google Checkout" into the right column and press "Apply".
Re-load your cart and you should now see a Google Checkout button
appear. Now return to the payment options screen and add the "PayPal"
processor to the list on the right as well; now, your cart should show
two checkout buttons. Now return to the payment options and turn the
"Activate On-site Payment" check box back on; your cart should now
show all three buttons for the user to choose from.

There; that's, essentially, what the branch accomplishes. Rather than
require every off-site payment solution to perform messy ZCML overrides
to hijack the main GetPaid checkout button, my branch lets them each
cleanly offer their own button that appears or disappears under the
control of the site owner, not the programmer.

Actually, there's another effect that you can observe - the Payment
Processor options page at:

http://localhost:8080/Plone/@@manage-getpaid-payment-processor

provides a block of options for each active payment processor, but makes
them disappear if the payment processor is turned off. Isn't that cool?

Practice running tests
----------------------

Good programmers always try to include comprehensive unit and
integration tests as part of a package. Test can verify, as we keep
"improving" our products, that all of their old features actually keep
working even as we are busy adding new ones.

Most of the work I have done has been in four packages. Here is the
status of their tests:

* Products.PloneGetPaid - Working
* getpaid.core - Working
* getpaid.paypal - Broken!
* getpaid.googlecheckout - Broken (package might not even completely work)!

As you can guess, those last two statuses have a lot to do with what I
would like to see accomplished during the sprint. :-)

Here is how to run the two working sets of tests, so that you can see
that they indeed succeed - and so that you can also learn the pattern,
in case the sprint task you choose involves running the tests for any of
the other GetPaid packages:

bin/instance test --package Products.PloneGetPaid
bin/instance test --package getpaid.core

You should see lots of crazy warning and deprecation messages scroll
past (ah, Plone!) then the dots "...." that are printed as each test
runs. Once the ordeal is over, you should receive a report telling you
that, despite all of those scary messages, the tests actually passed:

Ran 147 tests with 0 failures and 0 errors in 96.076 seconds.

If they pass, then your buildout is a safe place for you to begin work.

Look at all you've accomplished! You now have a working development
instance of GetPaid, you can run its Plone, you can explore its
features, and you can run its tests. It's now about time to choose a
task and start sprinting!

Choose a task
-------------

If you are new to Plone development, there is one issue that might not
have been thought about ahead of time: establishing your legal ability
to contribute code back to GetPaid. I know that contributing to Plone
requires signing and returning a form to the foundation, but you should
talk to Christopher Johnson as you get started on this sprint to make
sure that code or patches you generate can indeed be legally contributed
back to the effort.

So, how can you choose a task?

What I would like to see the sprint accomplish is to get both the PayPal
and the GoogleCheckout mechanisms working great with my new branch.
That would bring about two great results:

1. Just the fact that everyone would have worked with and tried out my
branch for hours and hours would hopefully make us all comfortable
that my "Products.PloneGetPaid" and "getpaid.core" innovates can now
be merged back into trunk.

2. Instead of my new feature appearing for the first time in trunk with
its "Offsite Payment Processors" setup option blank, we could now
include both PayPal and GoogleCheckout in the default GetPaid build.

To help people communicate during this sprint, I will here invent a
little rating system for GetPaid off-site payment processors:

"Tin" - the off-site payment processor does not even use my new plug-in
mechanism, but relies on an "overrides.zcml" file instead.

"Bronze" - the processor has been rewritten to use my new plug-in
mechanism and can therefore live peacefully with other off-site
payment processors.

"Silver" - the processor's tests have been re-written (or written for
the first time, if it lacked them before) to demonstrate that it
plugs in fine with my new mechanism.

"Gold" - the processor supports a callback mechanism that lets the
off-site payment solution report back to Plone about which orders
users actually carried through with.

"Platinum" - tests are written, and work, for the callback mechanism.

Given the above ratings, here is now I would rate the two payment
processors I have touched:

PayPal - Bronze
GoogleCheckout - on the way to Bronze

The goal that I would suggest for the sprint is to work on these two
change processors to get them both at least to "Silver", because that is
a tolerable working state: while shop owners can't use "Silver"-level
processors and expect to be able to manage orders on their Plone site,
many won't need to because they can do their management on PayPal or
Google Checkout's own site. Of course, if sprinters are available to
start working on going Gold, then please do so!

So, having given that background, what are the available projects for
the sprint? Here are some projects that I think could be divvied up
among you.

Easy Tasks - require only basic knowledge of Plone
..................................................

* Add "Available" and "Selected" headings to the "Off-site Payment
Processors" controller on the @@manage-getpaid-payment-options page.

Take a look at the @@manage-getpaid-payment-options page; do you see
something funny about the off-site selection boxes up at the top?
That's right! They contain absolutely no indication of which box is
for the ones you *do* want to use, and which box is for the ones you
*don't*. :-)

That's because I couldn't figure out how to label them, and after
one or two tries I ran out of time and had to turn to other things.

The odd thing is that the "Accepted Credit Cards" setting just below
it on the same page *does* have headings; but I couldn't figure out
what the difference was!

This whole form is powered by the "IGetPaidManagementPaymentOptions"
interface in:

Products.PloneGetPaid/Products/PloneGetPaid/interfaces.py

Somehow there's a way to turn those little headings on; go find it!
If you're new to Plone, this should be a great little project.

* Fix the fact that checkout buttons are too close to each other.

You probably noticed this already: the checkout buttons run right up
against each other (in Firefox, at least) where they are sitting
beneath the shopping cart. If you know a little HTML and CSS, then
please consider jumping in and fixing this! I am probably just
failing to put a <div> around them with the right class to tell the
default Plone stylesheets that they're buttons and need some room
around them.

The (admittedly primitive) template that I use for the stack of
buttons is here:

Products.PloneGetPaid/Products/PloneGetPaid/browser/templates/checkout-buttons.pt

What am I doing wrong? You will want to compare my HTML to other
buttons around the Plone site, that are presumably done the "right"
and "standard" way, and then try modifying the above template until
things look better.

It's annoying that the checkout buttons are different sizes, isn't
it? But we have to use the logos for user recognition of these
common services, right? You might also think about whether there's
any way to improve the appearance when the Google button is so much
bigger than the PayPal one!

* Disable the checkout process if "Activate On-site Payment" is
unchecked.

Okay, you might have noticed something of a flaw in my design: if
the store owner un-checks the "Activate On-site Payment" box at

http://localhost:8080/Plone/@@manage-getpaid-payment-options

then, as planned, the normal "Checkout" button disappears. But,
behind the scenes, the view is still there and ready to let the user
check out! It should really be disabled. To be more exact, if the
"Activate On-site Payment" box is unchecked by the store owner, then
any attempt to access:

http://localhost:8080/Plone/@@getpaid-checkout-wizard

(whether by a user who knows GetPaid, or because an old link to the
checkout has been left in a site template somewhere) should be met
with some sort of refusal. Maybe it should redirect back to the
main cart view? Or should it show an error and provide a link back
to the rest of the site? First, write the logic. Then you can
debate with other GetPaid people about what action the logic should
trigger.

You will probably accomplish this by finding the class that runs the
"getpaid-checkout-wizard" view (look through the ZCML to find the
module and class that run that view), and putting an "if" statement
inside of it somewhere that grabs the GetPaid global options (you
can find the pattern for this in several places; look for the portal
root being adapted to an options interface from getpaid.core!) and
then looks to make sure that onsite checkout is enabled.

Intermediate Tasks
..................

* Write tests for PayPal

The PayPal processor in "trunk" lacks tests entirely, from what I
can see, and it needs some! You can verify that it works by hand by
creating a PayPal sandbox account and entering its username into
your PayPal Processor Options (if PayPal is turned on!) at:

http://localhost:8080/Plone/@@manage-getpaid-payment-processor

By "works", I mean that you'll indeed be forwarded to PayPal which
will display the total of your shopping cart, and if you click on
the pull-down arrow on the margin just below the total you'll see
all of the "line items" appear that detail the objects that were in
your shopping cart. This all demonstrates that information is
making it through from GetPaid to PayPal correctly.

But this is the world of Python, and testing things by hand is not
enough for us! The PayPal change processor needs tests. How can
you add them?

First, look at the trunk of "getpaid.googlecheckout":

http://code.google.com/p/getpaid/source/browse#svn/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/tests

You will see that its tests.test_suite() function runs two doctests
that you'll find one level up, outside the test directory: one test
just named "googlecheckout.txt" and another that is named
"googlecheckout-browser.txt". If you checked out the project trunk
and ran these tests, you'd even see that they pass!

To give PayPal tests, copy these tests as an example and adapt them
to PayPal: have them create some purchasable objects,

* Get the Google Checkout button working.

Though the Google Checkout button will appear when that payment
processor is activated, the form that surrounds the button is pretty
much empty. Unlike the PayPal checkout button, which I've been able
to spend more time on, the Google Checkout button is pretty much
blank.

It needs someone to go in and add all of the hidden fields that will
make it an effective button. If you choose to tackle this problem,
you will have the advantage of having the PayPal branch to work off
of: it will show you how an effective form can be generated that is
full of information about the current shopping cart.

You will have succeeded if, when you are done, the Google Checkout
button - like the PayPal button - actually takes the person clicking
it off-site and if, upon arrival, Google Checkout knows what items
were in their cart. Expect to need to bring up the Google Checkout
docs to complete this task; but use the PayPal branch to see
examples of how to get to the information (like payment processor
settings and cart contents) that you'll need to fill out the form.

* BONUS: Tests for Google Checkout.

If the previous item is actually accomplished, and the Google
Checkout button becomes useful, then write working tests for it -
check out the instructions in the first item in this Intermediate
section for thoughts on testing.

Advanced Tasks
..............

* Get PayPal notification working.
* Get Google Checkout notification working.

Okay, here is a real challenge in case some serious Plone hackers
show up and the above items don't provide enough entertainment.

Your task is to write tests - I have no idea how - that verify that
either the PayPal or Google Checkout payment processor, after
sending the user off-site, correctly receives back the messages
telling them that the buyer is progressing through checkout.

There are two challenges here that are actually a bit steep for me,
as a developer, to tackle (which is why I've not even attempted to
tackle them):

1. No "Order" object exists yet when the user leaves the site. How,
then, will the return messages from PayPal or Google Checkout -
that refer to the order number - be associated with the correct
user, and result in an order being created for them? My guess is
that the buttons that send users off-site should generate
one-time disposable order numbers that have the user's username
encoded inside of them. When the notification comes back, if no
order of that number exists yet, then the username can be decoded
to figure out what user to create the order for. And when the
order is finalized and purchased, you can even empty that user's
shopping cart. For bonus points, only empty it of the items that
have actually been purchased, leaving items inside that were not
included in the order the user just paid for. :-)

2. How can a Plone test - whether a doctest or normal unit test -
submit a form to an off-site service and at the same time already
be ready to receive a signal back? There are two parts to this
question: first, since the test will often be running on a
computer behind a firewall, the test will have to be given the
name of an SSH account it can log into with an "-R" option so
that "http://wherever.it.is:PORT/" becomes a location that the
remote service can POST to and have it actually be received by
the test on whatever port it opens. And, second, how can the
test break into two threads to do the actual HTTP handling?

These, again, are quite advanced challenges, and are actually a bit
beyond my own knowledge at this point; you should only seize them if
you are among the Great Among Plone, and happen to be wanting to
sprint upon GetPaid. If we are so honored.

Sprint!
-------

Finally, after choosing a task from the above: get started!

I'll try to be on IRC, and helpful GetPaid folks should be somewhere
nearby to help. I have tried to be clear in everything above, and I'll
apologize ahead of time if any inaccuracies in what I've written waste
your time; I've taken part in several sprints before, and I know how
frustrating it can be just getting set up, much less trying to
accomplish anything!

If you could, use the mailing list to let us know what you're working
on, so that everyone has a record of who has grabbed what task. When
the sprint is over, send a reply to your message telling what happened,
where things stand, and including your patch or improvement if you
generated one but weren't in a position to commit it.

And, most of all, have fun. :-) I look forward to hearing your reports!

--
Brandon Craig Rhodes brandon@... http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Request for info on sites using Getpaid

2009-10-30T11:06:06Z

We offer paypal as an option. There are two buttons: clicking the one
on the left takes you to the GetPaid donation form.

Kyle

On Fri, Oct 30, 2009 at 12:56 PM, Christopher Johnson
<cjj.ifpeople@...> wrote:

> Thanks all for the feedback and sites. I took a first pass at the update
> ,but it was before I saw all this. The conference is over now and I'm about
> to be traveling so it will have to wait for another day. Here's some
> questions/comments:
>
> Taito, Rafael -thanks for sending those sites!
>
> Kyle - I don't see how GetPaid is actually used here. Appears to just be a
> button to paypal on the page. Can you explain?
>
> Tim - great to hear you will be sharing that! There's a couple people here
> from Vietnam who will be interested in that! Please let us know once that is
> available.
>
> Best wishes,
> Chris
>
> On Wed, Oct 21, 2009 at 6:07 PM, Taito Horiuchi <taito.horiuchi@...>
> wrote:
>>
>> Hi Chris,
>>
>> FinnMall.com uses GetPaid.
>> This is a shopping mall located in Finland where registered body can
>> add its own shop there.
>> Shopping cart and ordering parts of GetPaid are used there.
>>
>> TAX, shipping method, payment methods are all customized.
>>
>> Taito
>>
>>
>
>
>
> --
> Cofounder and CEO
> ifPeople - Innovation for People
> www.ifpeople.net
> t: 678-608-3408
> 130 Boulevard NE, #6
> Atlanta, GA 30312
>
> >
>

Re: Request for info on sites using Getpaid

2009-10-30T10:56:07Z

Thanks all for the feedback and sites. I took a first pass at the update ,but it was before I saw all this. The conference is over now and I'm about to be traveling so it will have to wait for another day. Here's some questions/comments:

Taito, Rafael -thanks for sending those sites!

Kyle - I don't see how GetPaid is actually used here. Appears to just be a button to paypal on the page. Can you explain?

Tim - great to hear you will be sharing that! There's a couple people here from Vietnam who will be interested in that! Please let us know once that is available.

Best wishes,
Chris

On Wed, Oct 21, 2009 at 6:07 PM, Taito Horiuchi <taito.horiuchi@...> wrote:

Hi Chris,

FinnMall.com uses GetPaid.
This is a shopping mall located in Finland where registered body can
add its own shop there.
Shopping cart and ordering parts of GetPaid are used there.

TAX, shipping method, payment methods are all customized.

Taito

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Trouble getting GetPaid Buildout to run

2009-10-30T10:02:35Z

I am trying to get my machine set up for tomorrow's (1 November 2009)
GetPaid sprint at the Plone Conference, and as such want to set it up
as a developer machine, not using the recipe. I tried following the
"New Easy Way" as describe in http://code.google.com/p/getpaid/wiki/DevGettingStarted,
but as soon as the buildout reaches yoma.batching, it says that the
package can't be found.

I think I have had this problem even without Mr. Developer. I think it was some funky error with package dependencies.

You do not auto-checkout if you manually checkout all packages:

bin/develop co ""

(must use "" cannot use * because shell expands it)

-Mikko

Has anyone come across this, and would anyone be able to help me sort
it out?

Thanks guys
Hannes

PS. As Mikko updated the wiki last, I though that he might be able to
sort me out. :)

--
Mikko Ohtamaa
Managing director, Red Innovation Ltd.
+358 40 743 9707
www.redinnovation.com
Every problem is solvable if you can throw enough energy drinks at it

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Trouble getting GetPaid Buildout to run

2009-10-30T09:55:10Z

2009/10/30 Hannes Calitz <hannesc@...>:

> OK, I seem to have found the problem. Except for the things mentions in the
> instructions ,the following also needs to be added to the buildout:
>
> [buildout]
> .....
> sources = sources
> auto-checkout =
>     Products.PloneGetPaid
>     zc.resourcelibrary
>     zc.table
>     five.intid
>     yoma.batching
>     ore.viewlet
>     hurry.workflow
>     getpaid.core
>     getpaid.wizard
>     getpaid.nullpayment
>
> Adding those sorted things out. However, ore.viewlet did not checkout
> properly with mr.developer, and I had to do it manually.

Ok, thanks :)

davide

--~--~---------~--~----~------------~-------~--~----~
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Trouble getting GetPaid Buildout to run

2009-10-30T09:20:24Z

OK, I seem to have found the problem. Except for the things mentions in the instructions ,the following also needs to be added to the buildout:

[buildout]
.....
sources = sources
auto-checkout =
    Products.PloneGetPaid
    zc.resourcelibrary
    zc.table
    five.intid
    yoma.batching
    ore.viewlet
    hurry.workflow
    getpaid.core
    getpaid.wizard
    getpaid.nullpayment

Adding those sorted things out. However, ore.viewlet did not checkout properly with mr.developer, and I had to do it manually.

2009/10/30 hannesc <hannesc@...>

I am trying to get my machine set up for tomorrow's (1 November 2009)
GetPaid sprint at the Plone Conference, and as such want to set it up
as a developer machine, not using the recipe. I tried following the
"New Easy Way" as describe in http://code.google.com/p/getpaid/wiki/DevGettingStarted,
but as soon as the buildout reaches yoma.batching, it says that the
package can't be found.

Has anyone come across this, and would anyone be able to help me sort
it out?

Thanks guys
Hannes

PS. As Mikko updated the wiki last, I though that he might be able to
sort me out. :)

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---