I've been following getpaid for a while, but I have not had a project
involving e-commerce until now. I'm currently fixing some bugs in
getpaid related to internationalization, creating a new danish payment
processor, and have a translation to danish ready. I would really like
to get some of the current issues in getpaid fixed soon, and are
willing to put in some time.
I might just commit some of the insignificant fixes to trunk, and post
for feedback on this list for the larger ones.
I'm freelancing for Headnet (Copenhagen, Denmark), and we have quite a
few plone 4 projects involving getpaid starting up, so its good news
with the beginning of the getpaid on plone 4 efforts. I'm willing to
put in a lot of effort to get this going.
I contributed a while back to PloneMall. And its good to see that some
of the PloneMall architectural problems are fixed in getpaid. My plone
experience goes back to 2.0.5.
A) What are the thoughts about ditching at least plone 2.5
compatibility in this process? The code could be cleaned up and
streamlined a bit while making getpaid plone 4 compatible.
B) David Glick wrote in another thread:
"Okay, I think I've sorted out the issues with the refactored getpaid
development buildout now -- bin/buildout -c 334.cfg should now work.
My solution was to make it check out all of the eggs that getpaid
requires forks of (zc.resourcelibrary, zc.table, yoma.batching, and
hurry.workflow) -- otherwise the original (and now incompatible)
versions get grabbed from PyPI.
Incidentally, this is kind of a mess. I'd love to see us take the
eggs that we've forked and rename them to getpaid.* so that we can
release them to PyPI without colliding with the original packages."
I would like to see no forks of other (non-getpaid specific) eggs.
Lets use the standard releases from pypi or we have chaos. Additional
features needed should be incorporated into those packages - or we
should make our own packages, building on top of (and still using)
those third party packages. Like plone.app.z3cform building on top of
z3c.form, and so on.
C) What's the status of merging Brandons and Mikkos branches?
I'll look into the plone4 work already committed during this week.
Do we have some sort of roadmap with version numbers for the next
releases of getpaid? How do the (if any) GetPaid version correspond to
getpaid.core / Products.PloneGetPaid? For instance, plone 4 support
from version xx, and plone 2.5 compatibility until yy.
Regards,
Sune B. Woeller
Hi,
I guess, I'm not the only one buzzled about the current feature-specific
branches and their current state & future... :)
- As far as I've understood, there was some progress for Brandon's
branches during the PyCon sprint, but eventually, they were not merged
into the trunk? Is that correct?
- I've read that Mikko's multipaymentprocessor-branches have been
upgraded to Plone4. It also seems that they are kept up-to-date with the
current trunk. Is that correct?
- Yesterday, David merged and released GetPaidForPlone4-branches (Great
thanks for you all, who did the hard work!), but the releases didn't
seem to include any features from either Brandon's or Mikko's branches?
Is that correct?
Since both Brandon's and Mikko's branches affect how custom
paymentprocessors (and/or their wizard support) should be
implemented/upgraded, decisions regarding the future directions would be
appreciated.
And after that there's a nice awaiting Sales Tax implementation (for us
Europeans) in Mikko's "miohtama-taxes"-branches, but those again are
based on Brandon's branches... :)
Finally, I'd be personally interested to enhance the current Currency
Options with "currency_formatting" option (should the currency symbol be
rendered before or after the currency value) from hannesc's branch (see:
http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a).
Or does someone oppose it?
Best Regards,
Asko
Asko> - As far as I've understood, there was some progress for
Asko> Brandon's branches during the PyCon sprint, but eventually,
Asko> they were not merged into the trunk? Is that correct?
yes
Asko> - I've read that Mikko's multipaymentprocessor-branches have
Asko> been upgraded to Plone4. It also seems that they are kept
Asko> up-to-date with the current trunk. Is that correct?
yes, i've also committed a buildout config to setup a plone4 environment
to use them.
Asko> - Yesterday, David merged and released
Asko> GetPaidForPlone4-branches (Great thanks for you all, who did
Asko> the hard work!), but the releases didn't seem to include any
Asko> features from either Brandon's or Mikko's branches? Is that
Asko> correct?
Yes, I think i was a "conservative" choice made by David to publish the
work already done while we come to a decision on the subject. I will
continue to backport new features from trunk to
"GetPaidForPlone4-multipaymentprocessors" branches until then.
Asko> Since both Brandon's and Mikko's branches affect how custom
Asko> paymentprocessors (and/or their wizard support) should be
Asko> implemented/upgraded, decisions regarding the future
Asko> directions would be appreciated.
Thanks fro opening (or re-opening) the discussion on this.
I agree, personally i've updated Mikko's branches beacuse i seemed the
"simplest" and more clean solution. The differences between the trunk
and multiplepaymentprocessors branches are some "insertion points" into
checkout and configuration and a registry of the payments methods.
What i failed to grasp of Brandon's branches is the reason for the
differentiation between onsite and offsite payment processors and why
there can be only one of the former active per site. If someone with
more experience of the two different solution can point out what's on
Brandon's code that is missing on Mikko's, i will volunteer on merging
the two.
Also i would like to see some bugreports cleanup. Many seems obsolete,
many are so vague that it's impossible to verify if the trunk is still
affected. Sometimes they are used to discuss stuff that goes far beyond
the subject of the bug but it's nearly impossible to track bugs recently
changed as the addition of comments doesn't seem to update the
"changed" field on bug. Can anyone with more knowledge about the project
or that is in charge of any of them update their status?
Asko> And after that there's a nice awaiting Sales Tax
Asko> implementation (for us Europeans) in Mikko's
Asko> "miohtama-taxes"-branches, but those again are based on
Asko> Brandon's branches... :)
never looked at it, my shop will sell stuff with clients that that don't
need to know anything about vat and other taxes.
Asko> Finally, I'd be personally interested to enhance the current
Asko> Currency Options with "currency_formatting" option (should the
Asko> currency symbol be rendered before or after the currency
Asko> value) from hannesc's branch (see:
Asko> http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a). Or
Asko> does someone oppose it?
not me
Thanks a lot. I've already been using multipaymentprocessors on Plone3
so this is very news for me.
On 08.04.2010 23:23, Mikko Ohtamaa wrote:
>>> And after that there's a nice awaiting Sales Tax
>>> implementation (for us Europeans) in Mikko's
>>> "miohtama-taxes"-branches, but those again are based on
>>> Brandon's branches... :)
>
> I can help to backport it to (Plone 4?) branch. It was not too many
> files. The work was done on Brandon's branch as it was enjoying the
> most of the development by the time.
Now, when I look at it, it doesn't seem to have any dependencies on
Brandon's changes, so it should be trivial to backport.
On the other hand, it did have the controversial approach of replacing
built-in (but not really used) "TaxUtility-framework"... I think, I'll
still have to try the built-in tax framework myself first, and only then
come to the same conclusion and backport Mikko's approach of simple
built-in SalesTaxOptions (replacing TaxUtility) and a
PriceValuAdjuster-adapter.
I think, it's relevant to add here a link to Mikko's original post on
his taxes implementation:
http://groups.google.com/group/getpaid-dev/browse_thread/thread/e477909168a9ef2a
>>> Finally, I'd be personally interested to enhance the current
>>> Currency Options with "currency_formatting" option (should the
>>> currency symbol be rendered before or after the currency
>>> value) from hannesc's branch.
>
> I think there are getpaid.core options for more rich formatting, we
> just lack the settings interface to enter then.
I don't recall seeing any support in getpaid.core, but
Products.PloneGetPaid.interfaces.IGetPaidManagementCurrencyOptions
indeed defines a few options I don't understand:
* positive_currency_format, TextLine, "Positive Currency Format"
* negative_currency_format, TextLine, "Negative Currency Format"
* us_currency_formatting, TextLine, "US Currency Formatting"
Does anyone know, how those should be used?
Anyway, I'm open to any ideas, how to configure the formatting of price
from "$ 10.00" to "10.00 �", but without new ideas, I'm continuing to
use Hannes' approach
(http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a,
diff included as an attachment, if those get through).
Of course, if those existing currency settings are necessary for some
add-ons, it's not necessary to remove them as Hannes has done, but just
add a one new setting (Hannes' "currency_format")... :)
Best Regards,
Asko
Oh, meant *good* news for me.
> (http://groups.google.com/group/getpaid-dev/browse_thread/thread/1956c8017245532a,
> diff included as an attachment, if those get through).
... and just noticed that I made a reverse diff from Hannes' changes to
the trunk just before them. Anyway, the idea comes clear :)
Best Regards,
Asko
Btw, is there some specific reasons, why installing and configuring
multiple payment processes must be totally different from installing and
configuring multiple shipping methods/services?
Of course, this is a bit theoretical questions, since there is not many
shipping plugins available. But since I spent my afternoon trying to
understand how getpaid.ups installs its using getpaid.core's
IPluginManager and makes its configuration available using
PloneGetPaid's ISettingsShipmentManager, I must ask, why the same
approach on payment processor configuration (ISettingsPaymentManager)
was abandoned?
:)
-Asko
Because when I asked fellow Plone developers how settings should be
done they told me to stick with portal_properties until plone.registry
is complete. I really didn't understand ISettingsPaymentManager by the
time and thus I steered away with it, trying to stick something more
understandable.
Storing settings as annotations in the site root is bad because the
settings are "invisible" - i.e. the user has no way to access, except
magically guess Python code in Zope debug shell, if things go borked.
I believe Alberto rewrote this bit for Plone 4 branch so it should not
be an issue anymore. In long term, i think that GetPaid can start
utilizing plone.registry and try to decrease the amount of GetPaid
specific code. This concerns at least form wizards also.
Mikko> Because when I asked fellow Plone developers how settings
Mikko> should be done they told me to stick with portal_properties
Mikko> until plone.registry is complete. I really didn't understand
Mikko> ISettingsPaymentManager by the time and thus I steered away
Mikko> with it, trying to stick something more understandable.
I don't get the point of ISettingsPaymentManager, it seems like a marker
interface and derives from IViewletManager, so this suggests to me that
it was intented to be used to organize visual aspects of settings that
belongs to payments? It's declared in Products.PloneGetPaid.interfaces
and isn't used anywhere else in PloneGetPaid. Is there any other
products which uses it?
Mikko> Storing settings as annotations in the site root is bad
Mikko> because the settings are "invisible" - i.e. the user has no
Mikko> way to access, except magically guess Python code in Zope
Mikko> debug shell, if things go borked.
Using utilities seems equally obscure to me, in zope2.... but i must say
it has been some time since my last zope2 project so maybe i' missing
something.
Mikko> I believe Alberto rewrote this bit for Plone 4 branch so it
Mikko> should not be an issue anymore. In long term, i think that
Mikko> GetPaid can start utilizing plone.registry and try to
Mikko> decrease the amount of GetPaid specific code. This concerns
Mikko> at least form wizards also.
I have simply moved the enabled_processors field out of
portal_properties and added it to IGetPaidManagementPaymentOptions along
with other payments setting fields (allow_anonymous_checkout,
use_ssl_for_checkout, accepted_credit_cards). Sadly, this means that now
enabled_processors is indeed stored in an annotation, but it's at least
stored the same way as other settings. Anyway, I can refactor all that
to use a persistent utility, it this is the preferred taste.
azazel
I am waiting this to have some ground for testing getpaid.pagseguro. As
I took getpaid.paypal as a model, I am waiting getpaid.paypal to be
updated so I can see what needs to be changed for getpaid.pagseguro..
Yeah, it overrides the whole checkout page and just sends the user off
to the PayPal website so shouldn't really require much updates at all. I
need to make some time to look at this too.
-Tim
> David
>
Correct, ISettingsXXXManager's are only about generating configuration
panes for plugins. ISettingsPaymentManager is defined next to
ISettingsShipmentManager but, AFAIK, only the latter is used. Although,
there remains a portion of commented out code in
PloneGetpaid/browser/admin.py for the former also.
ISettingsShipmentManager is successfully used at least in getpaid.ups.
Originally, I was wondering, if there exists a working pluggable
configuration viewlet architecture for multiple shipment plugins, why it
was not used also with configuration of payment processors?
>> should not be an issue anymore. In long term, i think that
>> GetPaid can start utilizing plone.registry and try to
>> decrease the amount of GetPaid specific code. This concerns
>> at least form wizards also.
Is there any consensus on which parts of getpaid should be fully
independent from Plone? I see that the original desing has been to keep
the architecture of getpaid.* fully independent from Plone (or
Products.PloneGetPaid), but since Products.PloneGetPaid is the only
GetPaid implementation, none of the plugins really work without it.
The independent way seems to be storing settings on local persistent
utilities. Let me explore getpaid.ups as an example:
- getpaid.ups provides a local persistent utility called UPSRateService,
which implements IShippingRateService from getpaid.core
- UPSRateService both handles the business logic and stores the settings
- UPSRateService is registered by UPSPlugin, which implements
IPluginManager from getpaid.core and is run on IStoreInstalledEvent from
getpaid.core (it seems that there originally was plans to have a gui for
installing and uninstalling plugins by other means than listening
IStoreInstalledEvent)
- Finally, getpaid.ups defines UPSSettings browser:viewlet for
ISettingsShipmentManager from Products.PloneGetPaid for
displaying and managing settings using SettingsViewletManager
architecture from Products.PloneGetPaid (I guess, this is the
only part, which makes getpaid.ups dependent on
Products.PloneGetPaid and this can fixed by adding a simple
condition into ZCML-configuration)
Best Regards,
Asko
Hi,
as some already noticed, I recently created "a yet another multipayment branch" (branches/atsoukka)...
Actually, I'm going to experiment with multiple things: trying to embrace getpaid.core's "plugin support" (though still supporting primarily GenericSetup), creating payment processors as local persistent utilities instead of adapters, storing settings on plone.registry (when it exists), adapting Mikko's sales tax ideas on getpaid.core's current interfaces, trying to implement checkout wizard using collective.z3cform.wizard and re-design user interfaces to rely heavily on viewlets (as already used e.g. with shipping plugin settings; Mikko called for easy-to-use plug-in points and broader use of custom ViewletManagers could be one solution).
Because this might take a few months, please, try to ignore my branches and don't let them interfere with your work integrating Brandon's and Mikko's branches into the current stable design :)
I can't promise anything, of course, because, my main goal is to create a flexible and heavily integrated Plone(4)-based e-commerce solution to my employer (until the end of this year). Still, I hope, that I manage to create something, which will eventually benefit also the community.
Best Regards,
Asko
I have been thinking on how to implement this...
We have default Line items and some extensions of it as Shippable items.
(I always though this was a bit confusion, because a shippable item is a
buyable item, but ok)
So we should create a new extension
class VariableLineItem( LineItem ):
I don't know what would be a nice aproach, but there are many ways to do
this.
We could have a ViariableItem object that stores multiple ShippingItems
inside it..(I always use shippable items, because hey are more complete
than Payable items and can have attributes like weight)
I see that Mikko's approach was to create a factory that create a
payable item and then modify it. The item gets a variation code, that is
used in the cart to identify it.
Or maybe we could have this item with a dictionary storing its
prices/colours/sizes/etc , then modify the portlet to deal with it...
Anyway, I think those line just show that I don't know very well getpaid
code. So one more time I cry for a getpaid ninja help... Can we meet in
#getpaid irc to discuss how to and implement this? It sure is the most
needed feature now... And it should not be an add on product, instead
this should be out of the box...
Thanks,
rafael