Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The present kanban view of acquirers is not the most appealing
one. It is full of useless information (e.g. "online payment") and the
combination of provider logos makes it look "old".
After this commit, the kanban view will hopefully have a "cool" and
concise look simular to the "Apps"'s kanban view.
Task - 284171
closesodoo/odoo#98345
Related: odoo/enterprise#30585
Related: odoo/upgrade#3803
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Computing the fields instead of storing them allows to implement the
feature for each provider more easily, without needing a migration
script.
task-2841744
closesodoo/odoo#91961
Related: odoo/enterprise#27618
Related: odoo/upgrade#3535
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
When setting up an acquirer there is sensible information to
be supplied.
There was inconsistency on what was obfuscated and what not.
Now sensible information as passwords and keys is obfuscated
and public information as names and addresses is visible.
Task - 2694139
closesodoo/odoo#81211
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
With commit 7b165cd5, it was incorrectly assumed that PDT notifications
sent by PayPal could not be verified with the suggested method
(dedicated to PDT notifications) because they were missing some required
parameters. The code was thus adapted to have their verification done
with the method already in place for IPN notifications, as it seemed to
do the job. It turns out that the PayPal sandbox account that was used
at that time was not properly configured, and that PayPal was then
sending IPN-like notifications instead of actual PDT notifications,
which is the reason why the swap of methods worked.
Actually, once the account is properly configured, PayPal sends
correctly populated PDT notifications that must be verified with the
method dedicated to PDT notifications, as the one dedicated to IPN
notifications stops working in that case.
With this commit, the method used to verify the origin and integrity of
PDT notifications is replaced by the one that was previously removed.
The method is however implemented in a more defensive manner to:
1. accept and process the notification without verification if the
account is not properly configured on PayPal.
2. silently discard the notification if the acquirer is not properly
configured on Odoo. We then rely on the IPN (webhook) to confirm the
transaction.
task-2744043
closesodoo/odoo#83659
X-original-commit: 7367f543498810bbdb018aa3566c7afed5684436
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Before this commit, users returning from PayPal to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of PayPal with `save_session=False`,
hence allowing all users to immediately post-process their transactions
when they return to Odoo.
closesodoo/odoo#83327
X-original-commit: 33ae5e491609c580a3aeb83568c74cd1acaae336
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The logs for payments contain the transaction reference whenever possible.
Before logs for transactions contained the reference or the id of the
transaction in an inconsitent way. No transactions are identified by
reference whenever possible.
The logs for payments for the same function on different acquirers should
have the same format. Same flow step for different acquirers had
information passed in different formats. Now at each step of a transaction
flow log messages have the same format regardless of the acquirer.
Overall the payment logs should have an uniform format. Hopefully
understanding log messages related to transactions should be easier, as
now log format is independent of the acquirer and transaction are easily
identified by reference.
Task - 2545450
closesodoo/odoo#79547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible to refund a payment from Odoo.
Users had to go through the payment acquirer's backend and update the
payment accordingly in Odoo.
With this commit, refunds are made available in Odoo directly from the
payment form, for acquirers that support them. Acquirer can either only
support full refunds or also support partial refunds.
As of now, the only acquirer allowing refunds is Adyen, with partial
refund support.
task-2527891
closesodoo/odoo#70881
Related: odoo/upgrade#2689
Related: odoo/enterprise#19829
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Fix two issues:
The search of suitable payment token was searching on the journal_id
field of the payment acquirer that is no longer stored.
Change it to now search on the acquirer_id directly, since we have
this information.
The _inverse_journal_id method on payment acquirers would create
new payment line with the manual payment method when no provider
are given to an acquirer, or no payment method is existing for
a given provider. This would cause issues with the creation of
multiple line with the same name on a same journal, which would
trigger the constrains blocking that.
closesodoo/odoo#74990
X-original-commit: a3a2fcb0b299fafbf359ec9015da5c85cdb57b3a
Related: odoo/enterprise#20193
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
data are not acknowledged by PayPal, rather than displaying an
internal server error
task-2494916
closesodoo/odoo#70885
X-original-commit: 948c22243c88dd905f1a7838f6fba75f44f06b2a
Related: odoo/enterprise#18349
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Steps to reproduce the bug:
1) Enable Paypal on the Payment Acquirers and select "BE Company CoA" on the company
2) fill the email and enable the "Add Extra Fees"
3) create an invoice on the company "BE Company CoA"
4) preview it as a public user
Bug:
An access error was raised:
Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
opw:2439896
closesodoo/odoo#65507
X-original-commit: 6b23ff3bdd1d5a3f34a431e2301db5984e0f761a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Add a test for the computation of the Paypal fees
opw:2369557
closesodoo/odoo#61750
X-original-commit: 8bedef042bd7be5830de92ae9a6976c9e17fb792
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The variable fee (Var) and fixed fee (Fix) indicated by paypal must be subtracted from the transaction amount (Am).
So let's consider that Am = 100€, Var = 2.9% and Fix = 0.3€
Total fee = 100€ * (2.9/100) + 0.3€ = 3.20€
So in this case, the merchant will get 96.80€ and Paypal will get 3.20€
This computation can be verified with the simulator here: https://salecalc.com/paypal?p=100&l=us&r=0&e=0&f=0&m=2&c=0.
So the idea here is to compute Am such that the merchant will get 100€ if he set his price to 100€
fees = amount_fees_included * percentage / 100 + fixed
fees = (amount + fees) * percentage / 100 + fixed
fees = (amount * percentage / 100 + fixed) / (1 - percentage / 100)
if the merchant needs to keep 100€, Am will be equal to 103.30€.
That way, paypal takes 103.30 * 2.9% + 0.30 = 3.30 and the merchant takes 103.30 - 3.30 = 100
opw:2369557
X-original-commit: 6850e638dfa652ab3fe8065ea09e23cb07648d7a
Co-authored-by: AdrienHorgnies <aho@odoo.com>
If a Paypal account is configured to send IPN notifications to Odoo at
the account level (as we officially advise in our doc) and is used in
another system than Odoo, transactions from that other system will
trigger notifications that gets sent to Odoo with references that are
unknown.
This tends to generate 500 errors, but Paypal will keep trying to send
the same notification over and over; this will cause a lot of errors in
logs and could also could Paypal to contact the account owner regarding
repeated failure on the IPN endpoints, which is somewhat scary for
lambda users.
This commit simply ensures that any such payment will not trigger a
faulty response (Paypal only accept 200 OK responses), but still keep a
trace of it in the logs as a warning.
Note that enabling IPN at the account level is not strictly necessary,
as transactions sent by Odoo force this behaviour regardless of the
setting with the 'notify_url' param.
closesodoo/odoo#56323
X-original-commit: e4e4b51e0d97c5dd6afe332bf7c70d8321469a52
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The `payment` module introduces a certain amount of payment acquirers,
each one corresponding to a `payment_` module.
When a `payment_` module is installed, this data is updated so that
payments done with the corresponding acquirer change in behaviour using
the provider installed by the `payment_` module.
When a `payment_` module is uninstalled, this data should be reset to
default, more especifically the `view_template_id` and the `provider`
fields of `payment.acquirer`.
This was not possible before this commit, and more importantly it would
make the uninstallation of such `payment_` module impossible as the
`view_template_id` is a required m2o ondelete='set null', which will
make the registry crash. Even if the former wasn't a problem, the
provider field would remain set to a non-existing selection option,
which would make the registry crash (eventually, when checking a record
with such a selection option).
With this commit, we reset these fields to their default value upon
module uninstall.
In 13, the issue with `view_template_id` should be fixed, as required
m2o that are ondelete='set null' are no longer possible. As for the
provider Selection field, a fix should arrive in master soon.
opw-2225333
closesodoo/odoo#48916
X-original-commit: 4f0c1c1bfd71dd1ff6793d0a91b49984c54d1351
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
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.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Move links shortening tools on mail.render.mixin to have rendering and
post procesing tools available on that mixin.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
This is a small fixup of previous commit 581020c733044b52cacd0d41a6a8eb8708671d0d.
closesodoo/odoo#47127
X-original-commit: e1e224bbf880718bcfb8d3874bad003aef5e8a27
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Install Sales
- Configure Paypal payment acquier
- Add extra fees such as 10€ of domestic fee
- Create a customer C with an email E and with no country
- Create a quotation Q of 100€ for C and send it by email to C
- Go in the email box of E and click on the link
- Click on 'Sign and Pay' button
- Sign Q and click on 'Pay'
- Choose Paypal as payment acquier
- Process the payment with Paypal
Bug:
An error log was displayed saying:
Paypal incorrect data:
mc_gross received 100 instead of 110
PS: the domestic fee was not counted because the partner_country_id
was not set in function render defined in model payment.acquirer
Inspired from function create defined in model payment.transaction
(addons/payment/models/payment_acquirer.py +961) where the domestic fee
is counted.
opw:2167104
closesodoo/odoo#43265
X-original-commit: 581020c733044b52cacd0d41a6a8eb8708671d0d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, the log displayed "set as done"
before actually trying to put the transaction in done.
If an error then occurred in the'_set_transaction_done'
function and the transaction could not be processed,
this could lead to a misinterpretation of these logs.
This log is therefore moved after the transaction is
processed and is only displayed if it is actually successful.
This is valid for'done','pending' and'cancel'.
closesodoo/odoo#42089
X-original-commit: dd7552b1a48020f3f48cd40a5fc1cbc4c38a7f90
Signed-off-by: jev <jev-odoo@users.noreply.github.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose of this commit is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover it
is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed to
be accurate notably when involving super user.
Mail message creation could lead to desynchronized values between author
and email_from. This is improved with this commit by correctly inheriting
from default_get and computing both of them at the same time instead of having
two default values. Indeed they depend on each other.
Same thing is done for mail composer. Mail Thread offers a tool method to
find email_from / author_id based on having one of those values or current
user and it is called whenever necessary.
Some calls to mail template send_mail are also cleaned.
Task ID 1853147
PR #32243
The paypal payment flow was crashing because no transaction was found
when the client wasn't connected.
closesodoo/odoo#40966
X-original-commit: 48f02f32fc3c32812a391d1fa37d561a8ae55e74
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Horacio Tellez