When moving fields name -> provider on payment.acquire, the condition in payment_transfer was not updated.
This lead to no post_msg value in the Wired Transfert acquire.
Fixes#2423, opw 613934
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Do not allow everybody to access account.transactions.
Restrict by default to readonly and even restrict the access with a record rule, give access to salesman.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
payment was added as dependance of portal_sale, which used to be auto installed when portal and sale were installed. With this new dependance, it wasnt the case anymore
With auto install of the payment module with the installation of account, this module is installed on the installation of sale (depends on account), and, therefore, on the installation of portal, portal_sale is now installed correctly
bzr revid: dle@openerp.com-20140410084846-78kxwc63nmv0rg9k
from the name. This allows to distinguish name and provider. Provider is a more
technical field, used to call some specific methods (<provider>_method_name). The
name field is used for display on the website.
Code and views udpated accordingly.
bzr revid: tde@openerp.com-20140319144608-0i4rv520l0bh53f0
[RENAME] payment_acquirer_* -> payment_ *
[CLEAN] payment_paypal duplicate of portal.payment.acquirer
- [REM] portal.payment.acquirer model, now replaced by payment.acquirer
- paypal banner generation on sale orders and invoices is done using the new payment.acquirer model. It basically works like the old portal.payment.acquirer, using a render_payment_block method.
[CLEAN] payment_paypal and paypal_account field of res.company
- in account: paypal_account is a char field (nothing changes)
- when installing payment_paypal: the char field is replaced by a function field that looks in the payment.acquirer table for paypal instances and get the first one back
- when installing payment_paypal, the company.paypal_account value is used to replace the default paypal data
- this function field and 'migration mechanism' are company aware
[IMP] payment: added pre_msg, post_msg, that are messages to be displayed before payment (like redirection warning for Paypal) and after payment (like account and communication details for transfer). Added a default message for transfer taking the visible company bank accounts.
[IMP] payment: added manual / automatic distinction. eCommerce use this information to decide whether to poll the tx status or display an information message.
[FIX] payment_*: fixed return controlers, using werkzeug.redirect instead of request.redirect that does not work anymore
[IMP] configuration
- added checkboxes to install paypal, ogone and adyen directly from the invoicing configuration
bzr revid: tde@openerp.com-20140124152541-y6e6kset056jbpkv
payment. Added post_msg, message displayed after payment.
[IMP] payment_transfer: added a default value (generated at create) for
post_msg, that contains bank accounts details. bank accounts linked to the
current company and used in report footer are shown.
[FIX] payment_*: make the buttons noupdate.
[IMP] payment: portal_published -> website_published + propagation
[IMP] payment: added process selection field that will be used for some
control in the website, telling w hether we want to refresh a payment
validation page or not.
bzr revid: tde@openerp.com-20140124134652-cc0nz08znnlmftw4
- added a call to _migrate_paypal_account in the payment_paypal data that
does the migration from company.paypal_account (char field) to a payment.acquirer
and company.paypal_account becoming a function field, with a getter / setter.
This function field is company aware.
- added an update of the res_config view of invoicing to link to the list
of acquirers
- added possibilty to install acquirers from invoicing (paypal / ogone / adyen
are installable through config)
bzr revid: tde@openerp.com-20140123150135-07b4pkbjade6vimq
now based on the new implementation of payment.
[REM] portal: removed acquirer model, views and implementation
[REF] portal_sale: now using payment rendering methods
[IMP] payment: added render_payment_block, taken from old
acquirer, that renders all portal_published acquirers.
bzr revid: tde@openerp.com-20140122190022-lef4b3o1tpcua3vx