| Age | Commit message (Collapse) | Author |
|---|
|
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closes odoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2
Have a multiwebsite setup
have a payment installed for one of the two websites
Make an order on that website and try to pay
Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP
After this commit, the payment success page is opened as we took
the request's url as the return url
opw-2080352
closes odoo/odoo#39643
X-original-commit: a9fb15b33fd041ee420581a5ba450017db06e0c7
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
|
|
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
|
|
Co-Authored-By: William Andre <wan@odoo.com>
|
|
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
|
|
|
|
|
|
|
|
|
|
- Activate Adyen
- In the eCommerce, purchase an item
- Change the delivery address
- Pay with Adyen
A internal error is raised.
It is caused by `val.replace(...)` where `val` is `False` ( due to
`shopperEmail`).
We make the code more robust by fallbacking on the billing email, then
on an empty string.
opw-2002974
[1] https://docs.adyen.com/classic-integration/hosted-payment-pages/hpp-payment-response/payment-response-merchantsig-sha-256/
closes odoo/odoo#33840
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
|
|
Adyen requires the amount to be multiplied by 10^k,
where k depends on the currency code.
https://docs.adyen.com/developers/development-resources/currency-codes
Provides a map of codes to factors.
Before, k was assumed to be 2 (which is correct in most cases).
opw 1928918
closes odoo/odoo#31984
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
|
|
Adyen requires the amount to be multiplied by 10^k,
where k depends on the currency code.
https://docs.adyen.com/developers/development-resources/currency-codes
Provides a map of codes to factors.
Before, k was assumed to be 2 (which is correct in most cases).
opw 1928918
closes odoo/odoo#32001
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
|
|
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
|
|
|
|
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
|
|
When returning from the Adyen payment website, SHA signature check fails
because of an inconsistent bytes vs string comparison. This is due to
`base64.b64encode` returning bytes in P3.
opw-1841103
|
|
* in _adyen_generate_merchant_sig_sha256 no need to encode dict key as we
have a normal dict. Because of this encoding it will search for byte
string key but we have string key;
* _adyen_generate_merchant_sig method requires the latest computed data
from adyen_form_generate_values method. If we directly pass the dictionary
while updating it, it will pass only business parameters and we don't need
it. After updating values we have actual transaction data.
This commit is related to task ID 1815966.
|
|
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
|
|
|
|
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
|
|
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
|
|
* LDAP import: python-ldap is not python3-compatible, pyldap is
Warning: only supported from debian Stretch (current testing)?
https://packages.debian.org/search?searchon=names&keywords=pyldap
* implicitly relative imports
* imports of moved or removed stdlib modules
issue #8530
|
|
Add `sudo()` to call `get_param` where necessary, and make the web client use a
controller instead of directly accessing parameters.
|
|
|
|
|
|
|
|
|
|
As provider model is intended to be used internally restricting the read of
some private fields to the employee group avoid creating access issues.
|
|
No functional change.
|
|
|
|
Methods with signature
- cr, uid, id
- cr, uid, <browse_record>
have been refactored to be future multi ensure one methods.
|
|
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a2746e24b9ca312261c3a536e9af4c9d4e 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 eae045949d65fb4236e1d7b3fc3e806673711fe1.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
|
|
From v4.1.0 of the documentation (2015-06-29), the HMAC SHA-1 key is
deprecated. Indeed, it should be considered as a legacy option to
guarantee compatibility with older skins.
The HMAC SHA-256 key should be used instead, and moreover, it seems that
any new skin created does not support SHA-1 at all, even if the option
is available.
The merchant signature code is inspired from the documentation example.
Source: https://docs.adyen.com/developers/hpp-manual
Fixes #9786
opw-676081
|
|
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
|
|
compatibility for payment providers
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
|
|
adding specific fields for every.payment.provider
|
|
|
|
in python, if-else has a lower priority(operator precedence) than %
opw:642886
|
|
|
|
opw-640208
|
|
|
|
The production payment page of Adyen is not
`https://prod.adyen.com/hpp/pay.shtml`
but
`https://live.adyen.com/hpp/pay.shtml`
opw-634894
|
|
|
|
signature + correctly raise errors in validation.
|
|
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.
|
|
with the incoming new API.
bzr revid: tde@openerp.com-20140416121055-01ygh1zer7cfv98a
|
|
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
|
|
bzr revid: tde@openerp.com-20140122175702-1h1e51z4njt4s70w
|
