Nabble - GetPaid for Plone - Dev

Re: Reviewed Brandon's work: some suggestions

2009-11-23T16:45:15Z

>
> I'm just trying out multiplepaymentprocessors branch, which offsite
> payment processors should I test with? Currently only see the onsite
> nullpayment.

Currently there should be

* PayPal (not sure which branch was correct)

* Luottokunta (Finnish credit card processing)

* Verkkomaksut (Again, Finnish generic payment processor)

Also I think there is one special processor for making real purchases
without doing the actual payment, for internal purchases of the store
owner.

Cheers,
-Mikko

>
>
>> I am willing to help to merge multiplepaymentprocessor branch with
>> brandon and brandon branch with trunk if
>>
>> 1) Community "decision making process" sees this as a necessary
>> requirement for the future
>>
>> 2) There is someone else willing to put hours on the issue
>>
>
> +1
>
>
>> -Mikko
>
> Cheers,
>
> Marton
>
> --
> 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
>

--
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: Reviewed Brandon's work: some suggestions

2009-11-23T14:43:07Z

Hi,

On Nov 15, 2:59 am, Moo <mi...@...> wrote:

> Hi,
>
> I just went through Brandon's work. Looks nice to me, though there are
> some show stopping issues.
>
> The offsite payment processor interface was empty. It is very
> difficult for third parties to implement payment processor unless
> interfaces are documented with the required precision.
>
> If I read the core correctly there can be just one on-site payment
> processor. Also, the wizard step to choose payment processor is
> missing.

The wizard step is not needed here.
The checkout process should be done with as few click from the buyer
as possible. This is important point for the shop owners.
With paypal standard, you get a checkout button from the payment
provider and put it on your site anywhere, allowing the customer the
start the payment immediately. Later the payment processor can be
asked and/or will notify the shop about the transaction.

With paypal express checkout, you have to ask the paypal server for a
token, before you can generate the checkout button, so the extra step
in checkout process after selecting paypal is needed.
The current paypal module in trunk works with paypal standard.

> As is, this work is useless for many use cases, like
>
> * Having a wire payment processor
>
> * Choose between credit card and wire payment
>
> * Choose between different on-sites processors (imagine different
> processor for different credit cards)
>

In Brandon's branch you can use offsite processors and onsite
processor together, the buyer can choose between them during the
checkout.
However the offsite button rendering is done with black magic, a
refactoring would be nice.

> What's the status of the future of Brandon's work? In
> multiplepaymentprocessor support for these use cases exist.

I'm just trying out multiplepaymentprocessors branch, which offsite
payment processors should I test with? Currently only see the onsite
nullpayment.

> I am willing to help to merge multiplepaymentprocessor branch with
> brandon and brandon branch with trunk if
>
> 1) Community "decision making process" sees this as a necessary
> requirement for the future
>
> 2) There is someone else willing to put hours on the issue
>

+1

> -Mikko

Cheers,

Marton

--
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: Reviewed Brandon's work: some suggestions

2009-11-16T16:19:33Z

Hi Mikko,

Thanks for helping us understand the differences between the multisite branch and the no overrides branch. My understanding is we really just need some more feedback on how it is set up, feedback on how clear the documentation for creating a payment processor is, and the design that was used. We've had little other testing that I know of, so thanks for your comments. I'm testing on a site with one onsite and one offsite. We have implemented 2 processors with the offsite interfaces based on Brandon's branch (NMI and authorize.net).

In discussing the use cases, we didn't know of any that would require multiple onsite payment processors. In my experience, the kinds of providers that let you do onsite usually involve a monthly fee, so site owners are unlikely to subscribe to more than one (cheaper to pay one to add a particular credit card service, like American Express or Discover, than to have an entire different service). However, I see how this could raise an issue if a Purchase Order or Bank Order implementation is made using the same infrastructure. It would probably behave like an onsite processor, and then it may not be possible for a merchant to have both a onsite payment and offline payment.

Hopefully what is there can be modified to account for this potential use case. Also, the button alignment needs some work on the cart screen and portlet :)

-chris

On Sun, Nov 15, 2009 at 6:24 AM, Moo <mikko@...> wrote:

More issues:

One cannot present paymeny processor options as a schema reference
(options_interface). They payment processor must be able to customize
its own form view as zope.schema cannot be used to express all form
use cases (custom widgets and so on...).

-Mikko

> I just went through Brandon's work. Looks nice to me, though there are
> some show stopping issues.
>
> The offsite payment processor interface was empty. It is very
> difficult for third parties to implement payment processor unless
> interfaces are documented with the required precision.
>
> If I read the core correctly there can be just one on-site payment
> processor. Also, the wizard step to choose payment processor is
> missing.
>
> As is, this work is useless for many use cases, like
>
> * Having a wire payment processor
>
> * Choose between credit card and wire payment
>
> * Choose between different on-sites processors (imagine different
> processor for different credit cards)
>
> What's the status of the future of Brandon's work? In
> multiplepaymentprocessor support for these use cases exist.
>
> I am willing to help to merge multiplepaymentprocessor branch with
> brandon and brandon branch with trunk if
>
> 1) Community "decision making process" sees this as a necessary
> requirement for the future
>
> 2) There is someone else willing to put hours on the issue
>
> -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%2Bunsubscribe@...

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

--
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: The future of GetPaid?

2009-11-16T13:25:20Z

Hi,

Thanks for sharing your notes after the conference and sprint. Certainly some of the points you mention are an accurate description of the current state of GetPaid (ie there is no product manager now), but I think your characterization of GetPaid's viable underestimates both the product and the people in the community and I wanted to respond and provide some of the information that was shared in the conference presentation as well.

Thanks for very good response Chris. I hope I was not over-critical with some of my points, I must some I love getpaid very much though feeling the frustration now and then, like many of us do. It's almost there that you could use it for Plone commercing needs, but it gives some problems which would be solved if you used external shopping system. I was hoping that my email would inspire some discussion so people, even ones who didn't go to conference, could see that the train is still going :)

There are several sites that have been launched with GetPaid already. About two dozen are listed at http://www.plonegetpaid.com/why/sites-using-getpaid . Some are just "out of the box" GetPaid and work well for the client as is, some are customized (and many of the docs about how to achieve the customizations shown are linked to in the presentation I gave at the ploneconf2009: http://snurl.com/getpaid-slides ).

I think the barrier comes when you need to have some "deeper" customizations. Like having a new field on Order. You basically need to go to hand-edit getpaid.core or override various, various, adapters and templates. Which makes it difficult as it is not very clear how things are connected. Getpaid architecture, nice as it is, tries very hard to keep "architecture" (getpaid.core) and "implementation" (Products.PloneGetPaid) separate from each other. For example, payment processor contain both architectural and UI drop ins. The problem comes with latter when people create plug-ins which need to use overrides.zcml to get things done. However these problems are just technical, and they can be solved when community knows what they are aiming at and have time do the work. This issue has been already discussed partially with's Brandon's work on payment processors.

Regarding people who are playing roles to maintain the product, GetPaid has gone through a period of activity and evolution, several releases. Unfortunately, I left some of this story out of the presentation in Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe) and Lucie at SIx Feet Up has managed releases over the 0.7 series of PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8. These are all people in the Plone community who are/were involved over a period when they were using GetPaid and were working to make it better for their needs. I'm hoping that is what we are starting again as a community.

Great :) The problem is that no one really knows when to commit trunk. Lots of patches end up being in the bug reports and email attachment (like the late issues with inter-database references), when there is no a single point of contact who would help to maintain the trunk. As already discussed, some nice ideas come up.

>The project is now in a period where we need new people with interest in ecommerce in Plone to step up and lead in various aspects of the project. That's an invitation I extended during the presentation at the conference. There are >several people interested in getting the remaining needed functionalities (downloadable files, premium content, others), and the model we took in organizing this project originally (see Social Sourcing presentation, >www.ifpeople.net/solutions/social-sourcing ) was about getting people involved upfront in a round of changes. So yes, as you point out, there was an original architect who is no longer active in the project. But, of the other sponsors, >supporters and contributors at the very outset of the project, about 3/4 are still involved in the project in one way or another, which gives us a solid basis of community around GetPaid. Now it's time to get the community involved in >actively shaping the future again.

Here we are!

Cheers,

Mikko

Re: The future of GetPaid?

2009-11-16T13:00:12Z

I agree with Chris here. I would see the following would help:

- some life breathed into http://plone.org/products/getpaid/roadmap
... there are many features and core fixes that people are
contributing to, it would be useful to list these and bring them
together as proposals that could be discussed and timelined

- a set of rotating release managers, with each release manager
delegating responsibility for certain proposals in the timeline which
are coming up for release and ensuring the release goes ahead.

- it is quite difficult to get a sense of what testing is required
when a new feature or fix is added and I think this may stop a lot of
individuals contributing to the code where their local need requires
some changes. The number of combinations of getpaid packages and plone
versions is quite high (I'm including all the different payment
processors in there) and it feels like quite a large task to test
these in relation to a change that you want to make. It would be nice
to have a recipe and some kind of delegation for testing too. I would
like to at least see each payment processor having a 'current' owner
whose responsibility it is to test their processor for a given release
candidate.

One of the most difficult aspects of helping to maintain this code is
that as a developer you are seldom using it each day (unlike core
plone components and addons that you rely on for perhaps most of your
site's function). So contribution seems to be adhoc on a need to fix
something basis, which makes momentum difficult to maintain. Finding
some funding to maintain some continued part-time contribution for a
number of people (which could rotate over time) would probably help. I
don't think many people would have to contribute much per month for
the right momentum to be achieved.

cheers
Matt

On Nov 17, 7:32 am, Christopher Johnson <cjj.ifpeo...@...>
wrote:

> Hi Mikko,
>
> Thanks for sharing your notes after the conference and sprint. Certainly
> some of the points you mention are an accurate description of the current
> state of GetPaid (ie there is no product manager now), but I think your
> characterization of GetPaid's viable underestimates both the product and the
> people in the community and I wanted to respond and provide some of the
> information that was shared in the conference presentation as well.
>
> One thing to clarify though about the purpose of the project - GetPaid isn't
> meant to attract ecommerce people to using Plone. It's meant to keep people
> from leaving Plone because they have ecommerce needs. This was what drove
> the origin of the project and I think today is still relevant. If people
> want only ecommerce and don't care about all the power Plone brings, there's
> little reason they should use GetPaid.
>
> The architecture does have a fairly high barrier to entry for developers. In
> part, because it was created as a zope3 product in the very early days of
> zope3 products for Plone. So a python programmer with no Plone knowledge
> will have to ramp up on some technologies before being able to customize it.
> I think this can be said about Plone in general these days also.
>
> But, that depends on how you want to customize it...there are many things
> that are fairly straight forward to do. If that weren't the case, we
> wouldn't have had such huge growth in add ons for the product and payment
> processors over the last year (over twice as much code overall and over
> twice as many payment processors). And most of the time, that's what someone
> implementing a site needs to do.
>
> There are several sites that have been launched with GetPaid already. About
> two dozen are listed athttp://www.plonegetpaid.com/why/sites-using-getpaid. Some are just
> "out of the box" GetPaid and work well for the client as
> is, some are customized (and many of the docs about how to achieve the
> customizations shown are linked to in the presentation I gave at the
> ploneconf2009:http://snurl.com/getpaid-slides).
>
> Regarding people who are playing roles to maintain the product, GetPaid has
> gone through a period of activity and evolution, several releases.
> Unfortunately, I left some of this story out of the presentation in
> Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe)
> and Lucie at SIx Feet Up has managed releases over the 0.7 series of
> PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8.
> These are all people in the Plone community who are/were involved over a
> period when they were using GetPaid and were working to make it better for
> their needs. I'm hoping that is what we are starting again as a community.
>
> The project is now in a period where we need new people with interest in
> ecommerce in Plone to step up and lead in various aspects of the project.
> That's an invitation I extended during the presentation at the conference.
> There are several people interested in getting the remaining needed
> functionalities (downloadable files, premium content, others), and the model
> we took in organizing this project originally (see Social Sourcing
> presentation,www.ifpeople.net/solutions/social-sourcing) was about getting
> people involved upfront in a round of changes. So yes, as you point out,
> there was an original architect who is no longer active in the project. But,
> of the other sponsors, supporters and contributors at the very outset of the
> project, about 3/4 are still involved in the project in one way or another,
> which gives us a solid basis of community around GetPaid. Now it's time to
> get the community involved in actively shaping the future again.
>
> In doing this, I'm willing to help transfer knowledge I have about the
> product to those who want to take a role in the community. Also, I think it
> would be great to have a collaborative design process at this point, as we
> did originally, so the new people involved in GetPaid can shape where the
> product is going. I'm willing to help those involved in this also, and if
> needed, to raise additional funds for the buildout of features/refactoring
> for GetPaid.
>
> With the knowledge of our community, we should be able to unlock the good
> stuff in GetPaid and make it much more accessible for those using the
> system.
>
> Best wishes,
> Chris
>
>
>
> On Sat, Nov 14, 2009 at 9:18 PM, Moo <mi...@...> wrote:
> > Hi,
>
> > I participated the GetPaid sprint in Budapest. There were some worries
> > among the participants for which I have ginve thoughts afterwards.
>
> > Many people would love to use GetPaid for creating shops, but it won't
> > do it.
> > Currently there are huge gaps within the code (payment processors,
> > taxes, variant items, architecture limitations) which are necessities
> > for a basic shop functionality. If you want to use GetPaid, be
> > prepared to spent countless of hours writing everything from scratch
> > and "fight against the framework".
>
> > Until we have a solid working shop platform I suggest not mentioning
> > "shop" onwww.plonegetpaid.comand actually tell the people to seek
> > help from Python shopping products.
>
> > Also, GetPaid future does not look very bright. Since the orignal work
> > was sponsored, the orignal authors have not been very activate with
> > the community. With the current state of the code it is hard to get
> > anything done unless you have years of Plone experience. Most users
> > who would like to use or develop GetPaid don't necessarily have this.
> > They might try and get frustrated after couple of hours.
>
> > There is also lack of release manager or trunk maintainer. There is no
> > one "in control" and people may or may not commit something into
> > trunk. The vision and active maintenance is missing. There is no
> > roadmap. There is no committed maintainers. This kind of organization
> > may fit for small static components like most of those in Plone
> > collective, but it definite doesn't seem to work with GetPaid.
>
> > So, should people looking for shopping products abandon GetPaid in
> > favour of other solutions? There is so much good work in GetPaid, but
> > it is so hard to get anything out of it.
>
> > -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@...<getpaid-dev%2Bunsubscribe@...>
>
> > For more options, visit this group at
> >http://groups.google.com/group/getpaid-dev?hl=en?hl=en
>
> --
> Cofounder and CEO
> ifPeople - Innovation for Peoplewww.ifpeople.net
> t: 678-608-3408
> 130 Boulevard NE, #6
> Atlanta, GA 30312

Re: The future of GetPaid?

2009-11-16T10:32:56Z

Hi Mikko,

Thanks for sharing your notes after the conference and sprint. Certainly some of the points you mention are an accurate description of the current state of GetPaid (ie there is no product manager now), but I think your characterization of GetPaid's viable underestimates both the product and the people in the community and I wanted to respond and provide some of the information that was shared in the conference presentation as well.

One thing to clarify though about the purpose of the project - GetPaid isn't meant to attract ecommerce people to using Plone. It's meant to keep people from leaving Plone because they have ecommerce needs. This was what drove the origin of the project and I think today is still relevant. If people want only ecommerce and don't care about all the power Plone brings, there's little reason they should use GetPaid.

The architecture does have a fairly high barrier to entry for developers. In part, because it was created as a zope3 product in the very early days of zope3 products for Plone. So a python programmer with no Plone knowledge will have to ramp up on some technologies before being able to customize it. I think this can be said about Plone in general these days also.

But, that depends on how you want to customize it...there are many things that are fairly straight forward to do. If that weren't the case, we wouldn't have had such huge growth in add ons for the product and payment processors over the last year (over twice as much code overall and over twice as many payment processors). And most of the time, that's what someone implementing a site needs to do.

There are several sites that have been launched with GetPaid already. About two dozen are listed at http://www.plonegetpaid.com/why/sites-using-getpaid . Some are just "out of the box" GetPaid and work well for the client as is, some are customized (and many of the docs about how to achieve the customizations shown are linked to in the presentation I gave at the ploneconf2009: http://snurl.com/getpaid-slides ).

Regarding people who are playing roles to maintain the product, GetPaid has gone through a period of activity and evolution, several releases. Unfortunately, I left some of this story out of the presentation in Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe) and Lucie at SIx Feet Up has managed releases over the 0.7 series of PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8. These are all people in the Plone community who are/were involved over a period when they were using GetPaid and were working to make it better for their needs. I'm hoping that is what we are starting again as a community.

The project is now in a period where we need new people with interest in ecommerce in Plone to step up and lead in various aspects of the project. That's an invitation I extended during the presentation at the conference. There are several people interested in getting the remaining needed functionalities (downloadable files, premium content, others), and the model we took in organizing this project originally (see Social Sourcing presentation, www.ifpeople.net/solutions/social-sourcing ) was about getting people involved upfront in a round of changes. So yes, as you point out, there was an original architect who is no longer active in the project. But, of the other sponsors, supporters and contributors at the very outset of the project, about 3/4 are still involved in the project in one way or another, which gives us a solid basis of community around GetPaid. Now it's time to get the community involved in actively shaping the future again.

In doing this, I'm willing to help transfer knowledge I have about the product to those who want to take a role in the community. Also, I think it would be great to have a collaborative design process at this point, as we did originally, so the new people involved in GetPaid can shape where the product is going. I'm willing to help those involved in this also, and if needed, to raise additional funds for the buildout of features/refactoring for GetPaid.

With the knowledge of our community, we should be able to unlock the good stuff in GetPaid and make it much more accessible for those using the system.

Best wishes,
Chris

On Sat, Nov 14, 2009 at 9:18 PM, Moo <mikko@...> wrote:

Hi,

I participated the GetPaid sprint in Budapest. There were some worries
among the participants for which I have ginve thoughts afterwards.

Many people would love to use GetPaid for creating shops, but it won't
do it.
Currently there are huge gaps within the code (payment processors,
taxes, variant items, architecture limitations) which are necessities
for a basic shop functionality. If you want to use GetPaid, be
prepared to spent countless of hours writing everything from scratch
and "fight against the framework".

Until we have a solid working shop platform I suggest not mentioning
"shop" on www.plonegetpaid.com and actually tell the people to seek
help from Python shopping products.

Also, GetPaid future does not look very bright. Since the orignal work
was sponsored, the orignal authors have not been very activate with
the community. With the current state of the code it is hard to get
anything done unless you have years of Plone experience. Most users
who would like to use or develop GetPaid don't necessarily have this.
They might try and get frustrated after couple of hours.

There is also lack of release manager or trunk maintainer. There is no
one "in control" and people may or may not commit something into
trunk. The vision and active maintenance is missing. There is no
roadmap. There is no committed maintainers. This kind of organization
may fit for small static components like most of those in Plone
collective, but it definite doesn't seem to work with GetPaid.

So, should people looking for shopping products abandon GetPaid in
favour of other solutions? There is so much good work in GetPaid, but
it is so hard to get anything out of it.

-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%2Bunsubscribe@...

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

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

Re: Taxes implementation ready to be merged

2009-11-16T09:39:17Z

Hi Mikko,

Thanks for the notes and the work on getting taxes working!

I just wanted to get clarification on your email. The subject said the work was ready to merge, but the text said you have not implemented taxes. It looks from your notes that it is ready, so I just wanted to clarify.

With what you have done, how does someone create a new tax configuration (ie for another country, or for a state within a country)?

Thanks again,

Chris

On Sat, Nov 14, 2009 at 9:43 PM, Moo <mikko@...> wrote:

Hi,

I have not implemented working salex tax implementation for GetPaid.
It will work in both United States and Europe.

Below are notes. Updates notes txt available here for the future
readers:

https://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/miohtama-taxes/Products/PloneGetPaid/docs/taxes_and_prices.txt

Taxes and prices
----------------

Problem: Depending on the country sales taxes may be included in the
store prices or they
may be applied to the total on the checkout.

* In Scandinavia sales taxes are included in the consumer visible
prices

* In US sales taxes depend on the state and are applied on the
checkout

To support both behaviors GetPaid must be sales tax aware

* How store owner manages taxes internally: are they put in the price
data or should system calculate them afterwards

* How consumer sees the prices: does the price tag contain taxes or
not

getpaid.core.interfaces.IPriceValueAdjuster is an utility to tackle
this problem.
It provides methods

* To get tax and tax free prices

* To get user visible prices

* Extendable tax behavior: subclass and override this utility to have
custom tax algorithms

* Different taxes for different item categories: line item and content
item adapters can be used
to return item specific tax percent

Where should be used
--------------------

* When totals are queried: CartTotals, checkout

* When item prices are displayed: portlets, page templates

* When invoice or recipient is generated

Products.PloneGetPaid.price module contains documentation how to use
IPriceValueAdjuster.

Backward incompatible changes
-----------------------------

The following backward incompatible changes have been made:

* Querying ILineContainerTotals utility needs to have
IPriceValueAdjuster argument

* Remove of getpaid.core.tax.TaxUtility

Code migration examples are available in Products.PloneGetPaid.price
module.

Necessary changes have been made to most of the parts of PloneGetPaid
and getpaid.core.
Some use cases might have slipped under the radar.

This work deals with sales tax only. getpaid.core support multiple tax
bases somehow.
getpaid.core.tax.TaxUtility and getpaid.core.interfaces.ITaxUtility
have been
removed, since they had no working implementations. getpaid.core.cart
uses now IPriceValueAdjuster directly. If one wants to support various
taxes
with getpaid.core it would need serious changes to user interface and
GetPaid subsystems
in any case.

Discussion
----------

The serious problem is that getpaid.core.order.Order class exposes
getTotal()
by directly inhering from CartItemTotals. It should not do this.

* When using getTotals() etc. functionality the site context is
available and
you cannot access such values as the current tax settings

* Currently you need to resort zope.app.component.hooks.getSite hack
to
have context inside tese functions.

I suggest deprecating getTotals() and CartItemTotals totally.
They should be replaced with site-aware adapters which can access
context data.

Also, when the order is create at least the following data
should be copied to the order to make orders future proof

* Used taxes

* Item price as taxed, tax free and taxes applied to item

Work available
--------------

2009/11: Available in getpaid.core and Products.PloneGetPaid miohtama-
taxes branch.
Branch is based on brandon-no-overrides branch.

Files touched

* getpaid.core.interfaces

* getpaid.core.cart

* Products.PloneGetPaid.interfaces

* Products.PloneGetPaid.price

* Products.PloneGetPaid.tests.base

* Products.PloneGetPaid.tests.test_taxes_and_prices

* Products.PloneGetPaid.browser.cart

*

--
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%2Bunsubscribe@...

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

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

Re: Reviewed Brandon's work: some suggestions

2009-11-15T03:24:25Z

More issues:

One cannot present paymeny processor options as a schema reference
(options_interface). They payment processor must be able to customize
its own form view as zope.schema cannot be used to express all form
use cases (custom widgets and so on...).

-Mikko

> I just went through Brandon's work. Looks nice to me, though there are
> some show stopping issues.
>
> The offsite payment processor interface was empty. It is very
> difficult for third parties to implement payment processor unless
> interfaces are documented with the required precision.
>
> If I read the core correctly there can be just one on-site payment
> processor. Also, the wizard step to choose payment processor is
> missing.
>
> As is, this work is useless for many use cases, like
>
> * Having a wire payment processor
>
> * Choose between credit card and wire payment
>
> * Choose between different on-sites processors (imagine different
> processor for different credit cards)
>
> What's the status of the future of Brandon's work? In
> multiplepaymentprocessor support for these use cases exist.
>
> I am willing to help to merge multiplepaymentprocessor branch with
> brandon and brandon branch with trunk if
>
> 1) Community "decision making process" sees this as a necessary
> requirement for the future
>
> 2) There is someone else willing to put hours on the issue
>
> -Mikko

Taxes implementation ready to be merged

2009-11-14T18:43:12Z

Hi,

I have not implemented working salex tax implementation for GetPaid.
It will work in both United States and Europe.

Below are notes. Updates notes txt available here for the future
readers:

https://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/miohtama-taxes/Products/PloneGetPaid/docs/taxes_and_prices.txt

Taxes and prices
----------------

Problem: Depending on the country sales taxes may be included in the
store prices or they
may be applied to the total on the checkout.

* In Scandinavia sales taxes are included in the consumer visible
prices

* In US sales taxes depend on the state and are applied on the
checkout

To support both behaviors GetPaid must be sales tax aware

* How store owner manages taxes internally: are they put in the price
data or should system calculate them afterwards

* How consumer sees the prices: does the price tag contain taxes or
not

getpaid.core.interfaces.IPriceValueAdjuster is an utility to tackle
this problem.
It provides methods

* To get tax and tax free prices

* To get user visible prices

* Extendable tax behavior: subclass and override this utility to have
custom tax algorithms

* Different taxes for different item categories: line item and content
item adapters can be used
to return item specific tax percent

Where should be used
--------------------

* When totals are queried: CartTotals, checkout

* When item prices are displayed: portlets, page templates

* When invoice or recipient is generated

Products.PloneGetPaid.price module contains documentation how to use
IPriceValueAdjuster.

Backward incompatible changes
-----------------------------

The following backward incompatible changes have been made:

* Querying ILineContainerTotals utility needs to have
IPriceValueAdjuster argument

* Remove of getpaid.core.tax.TaxUtility

Code migration examples are available in Products.PloneGetPaid.price
module.

Necessary changes have been made to most of the parts of PloneGetPaid
and getpaid.core.
Some use cases might have slipped under the radar.

This work deals with sales tax only. getpaid.core support multiple tax
bases somehow.
getpaid.core.tax.TaxUtility and getpaid.core.interfaces.ITaxUtility
have been
removed, since they had no working implementations. getpaid.core.cart
uses now IPriceValueAdjuster directly. If one wants to support various
taxes
with getpaid.core it would need serious changes to user interface and
GetPaid subsystems
in any case.

Discussion
----------

The serious problem is that getpaid.core.order.Order class exposes
getTotal()
by directly inhering from CartItemTotals. It should not do this.

* When using getTotals() etc. functionality the site context is
available and
you cannot access such values as the current tax settings

* Currently you need to resort zope.app.component.hooks.getSite hack
to
have context inside tese functions.

I suggest deprecating getTotals() and CartItemTotals totally.
They should be replaced with site-aware adapters which can access
context data.

Also, when the order is create at least the following data
should be copied to the order to make orders future proof

* Used taxes

* Item price as taxed, tax free and taxes applied to item

Work available
--------------

2009/11: Available in getpaid.core and Products.PloneGetPaid miohtama-
taxes branch.
Branch is based on brandon-no-overrides branch.

Files touched

* getpaid.core.interfaces

* getpaid.core.cart

* Products.PloneGetPaid.interfaces

* Products.PloneGetPaid.price

* Products.PloneGetPaid.tests.base

* Products.PloneGetPaid.tests.test_taxes_and_prices

* Products.PloneGetPaid.browser.cart

*

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

The future of GetPaid?

2009-11-14T18:18:42Z

Hi,

I participated the GetPaid sprint in Budapest. There were some worries
among the participants for which I have ginve thoughts afterwards.

Many people would love to use GetPaid for creating shops, but it won't
do it.
Currently there are huge gaps within the code (payment processors,
taxes, variant items, architecture limitations) which are necessities
for a basic shop functionality. If you want to use GetPaid, be
prepared to spent countless of hours writing everything from scratch
and "fight against the framework".

Until we have a solid working shop platform I suggest not mentioning
"shop" on www.plonegetpaid.com and actually tell the people to seek
help from Python shopping products.

Also, GetPaid future does not look very bright. Since the orignal work
was sponsored, the orignal authors have not been very activate with
the community. With the current state of the code it is hard to get
anything done unless you have years of Plone experience. Most users
who would like to use or develop GetPaid don't necessarily have this.
They might try and get frustrated after couple of hours.

There is also lack of release manager or trunk maintainer. There is no
one "in control" and people may or may not commit something into
trunk. The vision and active maintenance is missing. There is no
roadmap. There is no committed maintainers. This kind of organization
may fit for small static components like most of those in Plone
collective, but it definite doesn't seem to work with GetPaid.

So, should people looking for shopping products abandon GetPaid in
favour of other solutions? There is so much good work in GetPaid, but
it is so hard to get anything out of it.

-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

Reviewed Brandon's work: some suggestions

2009-11-14T17:59:41Z

Hi,

I just went through Brandon's work. Looks nice to me, though there are
some show stopping issues.

The offsite payment processor interface was empty. It is very
difficult for third parties to implement payment processor unless
interfaces are documented with the required precision.

If I read the core correctly there can be just one on-site payment
processor. Also, the wizard step to choose payment processor is
missing.

As is, this work is useless for many use cases, like

* Having a wire payment processor

* Choose between credit card and wire payment

* Choose between different on-sites processors (imagine different
processor for different credit cards)

What's the status of the future of Brandon's work? In
multiplepaymentprocessor support for these use cases exist.

I am willing to help to merge multiplepaymentprocessor branch with
brandon and brandon branch with trunk if

1) Community "decision making process" sees this as a necessary
requirement for the future

2) There is someone else willing to put hours on the issue

-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: Alternative Session Implementation

2009-11-13T19:48:43Z

On Nov 13, 9:45 pm, Silvio <silv...@...> wrote:

> On Fri, Nov 13, 2009 at 8:24 AM, Matt Halstead <matt.halst...@...>wrote:
>
>
>
> > > 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.
>
> > Can you elaborate on why session storage needed to be reimplemented?
>
> I can help about this. I had a conversation with Carsten and other people at
> the sprint in Budapest. My point about issue 209 is that, even if it is now
> resolved, it was initially caused by a bad design decision: storing carts in
> a non persistent database. This decision makes anonymous customers lose
> their carts when Zope (or zeo in a zeo cluster) is restarted; site owners
> never want customers to lose their carts.

I'd agree with that. They will lose their carts after the session time
out, but at least that's a constant. I have a couple of questions
about the proposed implementation:

should the session data container be configured with an explicit
pkg_id so that we can control its settings just for the shop and not
any other use of sessions?

should timeout and resolution be configurable through the web?

we should also create an upgrade step that:

1) calls register_session_data_utility( self ) from the Install.py so
people don't have to do a full product reinstall to update the session
management

2) identifies unusable carts in the _sessions persistent storage and
removes them since these will still cause problems.

If this is the direction people want to head, I'd be quite keen to see
this in action in the next few weeks. I don't mind making a test
branch if you or Carsten don't have time.

> And the storage of carts in the
> temporary zodb requires the loads/dumps dance that seems to be very
> error-prone and leads to hard-to-trace bugs.

>
> Silvio

--
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: Alternative Session Implementation

2009-11-13T14:41:43Z

FWIW - independent of the functional use case in discussion here -
ZODB 3.9 has an option which can be used to prevent cross database
references from being created in the first place.
allow-implicit-cross-references. So that these kinds of bugs become
trivial to trace.

In the other news Plone 3 won't be running on ZODB 3.9 because ZODB has been changed too much between versions. So monkey-patch is way to go.

Here is patch that enables the same functionality for ZODB 3.8
http://code.google.com/p/getpaid/issues/detail?id=209#c52

--
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%2Bunsubscribe@...

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

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

Re: Alternative Session Implementation

2009-11-13T13:05:25Z

On Fri, Nov 13, 2009 at 9:45 PM, Silvio <silviot@...> wrote:
> And the storage of carts in the
> temporary zodb requires the loads/dumps dance that seems to be very
> error-prone and leads to hard-to-trace bugs.

FWIW - independent of the functional use case in discussion here -
ZODB 3.9 has an option which can be used to prevent cross database
references from being created in the first place.
allow-implicit-cross-references. So that these kinds of bugs become
trivial to trace.

Here is patch that enables the same functionality for ZODB 3.8
http://code.google.com/p/getpaid/issues/detail?id=209#c52

--
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: Alternative Session Implementation

2009-11-13T00:45:54Z

On Fri, Nov 13, 2009 at 8:24 AM, Matt Halstead <matt.halstead@...> wrote:

> 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.

Can you elaborate on why session storage needed to be reimplemented?

I can help about this. I had a conversation with Carsten and other people at the sprint in Budapest. My point about issue 209 is that, even if it is now resolved, it was initially caused by a bad design decision: storing carts in a non persistent database. This decision makes anonymous customers lose their carts when Zope (or zeo in a zeo cluster) is restarted; site owners never want customers to lose their carts. And the storage of carts in the temporary zodb requires the loads/dumps dance that seems to be very error-prone and leads to hard-to-trace bugs.

Silvio

Re: Alternative Session Implementation

2009-11-12T23:24:00Z

Hi Carsten,

On Nov 4, 12:22 pm, Carsten Senger <sen...@...> wrote:
> 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).

I just committed the patch the michael dunstan provided - it was
previously not committed, that does seem to resolve the source of the
issue for non-broken _session storages.

> 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.

Can you elaborate on why session storage needed to be reimplemented?

>
> 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.

It would be great if you could create a branch with your changes and
fix the tests to work.

>
> ..Carsten
>
> Products.PloneGetPaid.session.patch
> 13KViewDownload

cheers
Matt

--
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-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...

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
-~----------~----~----~----~------~----~------~--~---