Old s2s prototype code has been removed. It is not used anywhere and not
supported. Moreover ogone s2s implementation use its own set of methods.
In a near future a neat implementation of s2s for paypal will be added.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
- Fix for status widget (b25c054c93) moved
to appropriate file: addons/web/static/src/js/views/form_widgets.js
even though the problem is less severe in 9.0 (no crash but triggers
form save, which is unnecessary)
- Fix for website_event_sale ignored (880e951f34)
because the problem does not exist anymore in 9.0, probably due to
refactoring 66871ee65b
In addition to being mostly useless because Paypal's API
changes are supposed to be backwards-compatible, this
warning was using inconsistent version numbers.
Switched to a simple INFO line with IPN version.
This field was relevant before the salepocalypse, it is no longer.
Replaced by generic payment providers instead of putting paypal payment methods
in account.
Remove it from the res.company and res.config model
Remove the method `_migrate_paypal_account` as it was used to find paypal
accounts based on the removed field
Closes#11231, task-22286
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
Check receiver_email only if receiver_id was not checked.
In Paypal, this is possible to configure as receiver_email
a different email than the business email (the login email)
In Odoo, there is only one field for the Paypal email:
the business email. This isn't possible to set a receiver_email
different than the business email.
Therefore, if you want such a configuration in your Paypal,
you are then obliged to fill
the Merchant ID in the Paypal payment acquirer in Odoo,
so the check is performed on this variable instead of the receiver_email.
At least one of the two checks must be done, to avoid fraudsters.
opw-648776
merge *ALL* the dicts
The form rendering used to receive a dict for partner information and a dict for tx information and to transmit another dict to the qweb template; now everything is done in a single dict
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
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.
The method _paypal_form_get_invalid_parameters checks that the params passed by the paypal feedback coroborate with the transaction requested by Odoo.
It looks like the 'receiver_id' is not always passed by the paypal feedback. Therefore, we check this param only if it is available in the paypal feeback.
This issue had as side-effect to not validate the paypal transaction, which remained 'draft' permanently.
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
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
- paypal_email_id -> paypal_email_Account, to avoid confusion with a m2o field
- paypal_seller_id -> paypal_seller_account, to avoid confusion with a m2o field
- api-related fields now hidden, because WIP for saas-4
bzr revid: tde@openerp.com-20140123100509-z8wgrj8fswk4wjq2
Shivam Dudhat