Routes introspection fixes:
* convert <int:x_id> to <model():x>
* remove **kw, specify explicit enable_editor parameter
Suckless:
* remove useless `/blog/tag/` route
* add pagination support in tags
* add pagination support when no category or tag (`/blog/`)
* remove handling of impossible case of category *and* tag
* make exclusive cases more exclusive, avoid repeatedly checking the
same condition over and over
bzr revid: xmo@openerp.com-20131108142149-v2z2m6kwgf97o7b0
* most controllers turn out to be complete cork and thus can't be
reversed
* fixup a pair of simple controllers
TODO:
* fixup more controllers
* how can labels/page names be produced?
* grouping/categories of links?
At a high level, workings are pretty simple:
* iterate on all rules (every url pattern produces a werkzeug rule)
* check if the url can make sense as a link: GET, http, no auth or
public auth, coming from the CMS (no web client links) and all
converters can generate values for themselves (e.g. a url with an
`int` converter can't be generated as there is no finite set of
integers, let alone one small enough to make sense to show to users)
* check if the controller function bound to the URL can use the URLs
we can generate (no **kwargs as that means arbitrary get|post
parameter, no query param without a default value (a query param is
a parameter which does not come from a URL/rule converter))
* use rule converter(s) to generate a matrix of values, and build urls
from these
bzr revid: xmo@openerp.com-20131108132615-2n7t1vj8hz9v9eis
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
Christophe Simonis