|
NaplesSprintTasks
Outline of tasks for Naples sprint on GetPaid
IntroductionWith a goal to get to the Release Candidate for GetPaid Red Ochre version, the info below is about what needs to be done (from Kapil, kapilt(at)gmail.com ). DetailsGetPaid Sprint Goals For Release What we need to make the release happen. TESTS!!!!PloneGetPaid is lacking tests and needs some major help there. Issues- Issue 124 - Issue 95 - Issue 126 - See http://code.google.com/p/getpaid/issues/list?can=2&q=milestone:M1&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary Refactor Checkout Wizardthe checkout wizard basically sequences a set of formlib pages, based on list of steps. its a linear implementation at the moment. changing to a viewlet manager, would be more appropriate as we typically provide access to the wizard from the formlib step. Form Passing Refactoring Taskwe want the wizard to be customizable in terms of adding/removing steps and overriding any given step, we get the latter via the component architecture, and while we notionally allow for changing the sequence of steps, the form passing in that case is won't work, and needs to be fixed. This needs some rework of the form passing, currently steps advertise which fields they will accept via the passed_fields atttribute, all the form passing should be reworked to automatically export all the current form vars already in the request. individual steps will control which variables they will export by defining an exported_fields attribute. form fields from a step which are not present should be deleted from the request variables, during update. this task has one golden rule though, never transmit credit card information directly back to the browser. so we'll explicitly not list it as exported field. Dependent Task : Duplicate Processing Protectionwe want to avoid processing any charges on a card multiple times. after the form passing refactoring, we'll be able to pass an order id generated by the wizard, into the request form variables, that will be carried through to processing the checkout. if this order is already in use, and is owned by the same user we redirect to the thank-you page, else we regenerate the order id and continue processing. the checkout wizard makePayment action will check if an order already exists before creating a new one (from the passed in order id), if it does exist with appropriate timestamp and and the current user is the customer listed on the order as its owner, then we can redirect to the thank you page, directly. Dependant Task: Separate Delivery Stepwe should only be collecting delivery/shipping address information on orders that are shippable. additionally we need to select a shipping method for these. add a new step, that collects shipping address and shipping method. automatically enabling the delivery step it would be nice to make this step automatically enabled if the cart contains shippable items, via viewlet filtering or other. Product Catalog Taskwe need a queryable index for products, that allows us to search and query for products. there is an implementation thats not wired in getpaid.core. the one issue for it is that its based on an order manager refactoring to be generic, meaning it actually wants to store products, but we really don't want. this needs to use intids to reference the individual products, so we need to index but not store the data, which is stored as annotations on the product. it needs subscribers for payable creation, payable modification, and payable destruction, and payable deletion. destruction is the case where the payable interface is removed from a content. might need the introduction of this event publication for the payable initialized and payable destruction events into browser/content.py views, the rest are given by standard object events. the subscribers will keep the catalog in sync. Create a sample customization productThis would help integrators understand what they should do to customize getpaid. Hopefully we should be able to answer CustomizationsBestPracticesDoc and issue 107 Ogone pay processor mergingOgone pay processor is working in a branch of GetPaid. It needs to have the interface updated for trunk and merged in and working. DocumentationWe need more documentation, filling out the missing pieces on http://code.google.com/p/getpaid/wiki/DocumentationHowTosAndTutorials ScreencastDemonstrating the use of GetPaid via screencast |
Sign in to add a comment
Use case:
A common use case which would be nice for the product is the ability to add a "drop down" price selector to a payable form. ie the "price" on a donation may be variable (ie donate: 10, 20, 50, 100...). the field should be able to be activated from the "payable" screen and the site admin should be able to set the values (ie enter in values, separated by a coma)
Observation: do we associate this with some kind of more general variance capability in the system? ie each level could optionally correspond to a different type of donation, as a different price could correspond to different product criteria (ie small, medium, large).
GTD: But basically, I would like a selectable amount for the release. That should be integrated; I mention the flexible part for consideration in architecting, as it is surely to be a priority use case soon.