Nabble - GetPaid for Plone

Re: Currency Configuration

2009-11-30T18:56:55Z

Sounds reasonable to me :D

On Mon, Nov 30, 2009 at 1:29 AM, Hannes Calitz <hannesc@...> wrote:

Hi Christopher

Well, as the original configuration (that was half way written, but not implemented) only allowed for the symbol to be changed, I didn't really look into multi-currency configurations. As mentioned before, this bit was never intended for currency conversion, but merely to assist in localization by allowing the currency symbol to change and set whether said symbol should be before or after the pricing values.

Hope this answers your questions. :)

H

2009/11/30 Christopher Johnson <cjj.ifpeople@...>

Hi Hannes,

Great to hear about the simplified interface! Thanks for reporting back the progress.

Have you thought about or looked into how the changes enable multi-currency sites to handle translations? Is there some awareness of the currency that the site would have to be able to convert?

Sounds like we are near needing to review and merge a bunch of branch work!

-c

On Tue, Nov 24, 2009 at 4:57 AM, Hannes Calitz <hannesc@...> wrote:

Hey guys

I have been working on getting the currency configuration working on GetPaid (http://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/hannesc/trunk/). As some of you know (well those of you who were at PloneConf2009 anyway) this has been a thorn in my side for a while now. I am glad to say that I have got a branch going with currency configuration working 100%.

From the discussions at the PloneConf2009 Sprint, I found that there are basically only two options that are truly needed in the configuration. This allowed me to simplify the configuration considerably. I have removed all the options in the original interfaces.py except for the currency symbol. Well, seeing as the currency configuration was never fully implemented, you could say that this option was 'added'. Once this was completely working, I added the ability to set whether the currency symbol should appear in front or behind the price. The template code is a bit messy, so if someone feels like cleaning that up, I would appreciate it.

I have tested the workings of it and everything seems to work fine. Because of the fact that I simplified the original interface so much, I don't know if this should be merged with the trunk. I leave that up to the community.

On a side note, this is not meant to do conversion. It is merely to allow people from different countries to use their local currencies instead of the originally hard-coded $.

Anyhow, any feedback will be greatly appreciated.

Thanks
Hannes

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

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

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

From forum: GetPaid for Plone - Dev

Re: Currency Configuration

2009-11-29T22:29:53Z

Hi Christopher

Well, as the original configuration (that was half way written, but not implemented) only allowed for the symbol to be changed, I didn't really look into multi-currency configurations. As mentioned before, this bit was never intended for currency conversion, but merely to assist in localization by allowing the currency symbol to change and set whether said symbol should be before or after the pricing values.

Hope this answers your questions. :)

H

2009/11/30 Christopher Johnson <cjj.ifpeople@...>

Hi Hannes,

Great to hear about the simplified interface! Thanks for reporting back the progress.

Have you thought about or looked into how the changes enable multi-currency sites to handle translations? Is there some awareness of the currency that the site would have to be able to convert?

Sounds like we are near needing to review and merge a bunch of branch work!

-c

On Tue, Nov 24, 2009 at 4:57 AM, Hannes Calitz <hannesc@...> wrote:

Hey guys

I have been working on getting the currency configuration working on GetPaid (http://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/hannesc/trunk/). As some of you know (well those of you who were at PloneConf2009 anyway) this has been a thorn in my side for a while now. I am glad to say that I have got a branch going with currency configuration working 100%.

From the discussions at the PloneConf2009 Sprint, I found that there are basically only two options that are truly needed in the configuration. This allowed me to simplify the configuration considerably. I have removed all the options in the original interfaces.py except for the currency symbol. Well, seeing as the currency configuration was never fully implemented, you could say that this option was 'added'. Once this was completely working, I added the ability to set whether the currency symbol should appear in front or behind the price. The template code is a bit messy, so if someone feels like cleaning that up, I would appreciate it.

I have tested the workings of it and everything seems to work fine. Because of the fact that I simplified the original interface so much, I don't know if this should be merged with the trunk. I leave that up to the community.

On a side note, this is not meant to do conversion. It is merely to allow people from different countries to use their local currencies instead of the originally hard-coded $.

Anyhow, any feedback will be greatly appreciated.

Thanks
Hannes

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

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

From forum: GetPaid for Plone - Dev

Re: Currency Configuration

2009-11-29T20:05:02Z

Hi Hannes,

Great to hear about the simplified interface! Thanks for reporting back the progress.

Have you thought about or looked into how the changes enable multi-currency sites to handle translations? Is there some awareness of the currency that the site would have to be able to convert?

Sounds like we are near needing to review and merge a bunch of branch work!

-c

On Tue, Nov 24, 2009 at 4:57 AM, Hannes Calitz <hannesc@...> wrote:

Hey guys

I have been working on getting the currency configuration working on GetPaid (http://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/hannesc/trunk/). As some of you know (well those of you who were at PloneConf2009 anyway) this has been a thorn in my side for a while now. I am glad to say that I have got a branch going with currency configuration working 100%.

From the discussions at the PloneConf2009 Sprint, I found that there are basically only two options that are truly needed in the configuration. This allowed me to simplify the configuration considerably. I have removed all the options in the original interfaces.py except for the currency symbol. Well, seeing as the currency configuration was never fully implemented, you could say that this option was 'added'. Once this was completely working, I added the ability to set whether the currency symbol should appear in front or behind the price. The template code is a bit messy, so if someone feels like cleaning that up, I would appreciate it.

I have tested the workings of it and everything seems to work fine. Because of the fact that I simplified the original interface so much, I don't know if this should be merged with the trunk. I leave that up to the community.

On a side note, this is not meant to do conversion. It is merely to allow people from different countries to use their local currencies instead of the originally hard-coded $.

Anyhow, any feedback will be greatly appreciated.

Thanks
Hannes

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

From forum: GetPaid for Plone - Dev

A web ontology for the ecommerce

2009-11-29T05:24:22Z

I would like to report "GoodRelations", a standardized and free
vocabulary/ontology for product, price, and company data.
I hope it could be of some interest to the GetPaid community:

http://www.heppnetz.de/projects/goodrelations/

And here you can find some import/export plugins for some cms/ecommerce
systems...
http://www.ebusiness-unibw.org/wiki/GoodRelations#Applications

It would be nice to see something similar for GetPaid... and yes, I know hot
open source works but until I can sponsor this kind of development, I guess
that report that is better than nothing :)

Best regards,
Enzo Cesanelli

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

From forum: GetPaid for Plone - Dev

Currency Configuration

2009-11-24T01:57:01Z

Hey guys

I have been working on getting the currency configuration working on GetPaid (http://getpaid.googlecode.com/svn/Products.PloneGetPaid/branches/hannesc/trunk/). As some of you know (well those of you who were at PloneConf2009 anyway) this has been a thorn in my side for a while now. I am glad to say that I have got a branch going with currency configuration working 100%.

From the discussions at the PloneConf2009 Sprint, I found that there are basically only two options that are truly needed in the configuration. This allowed me to simplify the configuration considerably. I have removed all the options in the original interfaces.py except for the currency symbol. Well, seeing as the currency configuration was never fully implemented, you could say that this option was 'added'. Once this was completely working, I added the ability to set whether the currency symbol should appear in front or behind the price. The template code is a bit messy, so if someone feels like cleaning that up, I would appreciate it.

I have tested the workings of it and everything seems to work fine. Because of the fact that I simplified the original interface so much, I don't know if this should be merged with the trunk. I leave that up to the community.

On a side note, this is not meant to do conversion. It is merely to allow people from different countries to use their local currencies instead of the originally hard-coded $.

Anyhow, any feedback will be greatly appreciated.

Thanks
Hannes

From forum: 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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

Re: pcommerce.core

2009-11-06T10:28:48Z

Hi,

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

Cheers,
Rafael

Christopher Johnson escreveu:

Hi Rafael,

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

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

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

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

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

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

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

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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:

From forum: GetPaid for Plone - Dev

Alternative Session Implementation

2009-11-03T15:17:56Z

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev

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

From forum: GetPaid for Plone - Dev