Cleaned init files, removing some licences (keeping only in init and openerp
in base directory of modules). Cleaned some class name, added forgotten
test file for payment_acquirer_transfer.
bzr revid: tde@openerp.com-20131108101005-a149bvatw5w6sdql
Added payment_acquirer_paypal and .._ogone modules. Those modules hold
the model / data / controllers related to the specific acquirer.
Also updated website_payment, to use website.menu instead of custom change
in header, as menus are now editable.
bzr revid: tde@openerp.com-20131107180444-bbzobquqq9o6pctv
paypal: only form is currently implemented. Method name and call order will change.
However the basic mechanism is impelmented. IPN is implemented (paypal contact us
back after the transaction with transaction details).
ogone: form and server2server are implemented. Method names and call order will
change. Based on chs / dle / ... implementation for ogone server2server.
basic addition of tests, still wip.
This commit is not a clean commit but a WIP commit. Please excuse me
but it's time to commit.
bzr revid: tde@openerp.com-20131107172236-chmg198305crgrud
Two main models : payment.acquirer and payment.transaction.
payment.acquirer models the acquirer: paypal, ogone. Each specific
acquirer will inherit from the class and add specific fields.
payment.transaction models the transaction itself. It has basic fields
for a transaction: date, partner, partner fields (to hold data at
transaction time), reference, state and its message, amount, currency.
Class methods are not finished and still quite WIP.
payment.acqurier has a render method that is used to render
its form. The form is the 'pay now' button with the specific
sementic of each acquirer.
This model is supposed to work on form-based and server-to-server
implementation methods.
bzr revid: tde@openerp.com-20131107171558-jrwrj3ll9kol6bav
context was not passed while setting request.website
forced to refactor a bit in order to make true model methods but stopped
because it will be duplicated work when migrating to the new api
bzr revid: fme@openerp.com-20131107151400-9dmtgz7xs34qmbmq
Depending on the way the search view is setup, a single item
(e.g. "Search foo for bar") can follow a list of a bunch of
completions. In that case, it is hard to notice that it's not just one
more item of said list.
Add a marker on the first of every completion list in order to catch
1-item lists (or lists without titles/categories) and prepend a small
border every time, so that single-element completions following
lists-with-titles can be noticed.
bzr revid: xmo@openerp.com-20131107112858-1xyvcesize0doblz
This dummy button is only meant to save the
order and refresh the view, which is easily
accomplished by sending an non-existing
workflow signal. Setting the button type
to the default `workflow` type (or simply
removing the wrong type) fixes the problem.
bzr revid: odo@openerp.com-20131107110256-zfok0mwkbesrkf81
This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
bzr revid: odo@openerp.com-20131107105302-hf8lublc1x3qc87h
The access right test expect an exception
to be raised when accessing any of the
followers, but this is not 100% correct,
as the test user (Chell) should be able to
read her own record.
This worked by chance because the ORM
prefetching was triggering an access error
whenever any follower was accessed, but
this was a bug, now fixed in server at
rev-id odo@openerp.com-20131119153700-5sbo2cl13vvqsgz5
revno 5136
bzr revid: odo@openerp.com-20131119175658-1nv5c9iwfizkrasc
Thibault Delavallée