User was not able to go through onboarding if they switched company.
By default it tried to edit default payment provider that was conected
to the main company so other companies were recieving Access Error.
opw-3281770
closesodoo/odoo#122590
X-original-commit: ffda55101739f9a99cabd6caee52dcb8d18d8fed
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
When creating payment links for the customer, the user can now decide on a partial amount to be
paid at the time.
Use case: when the customer cannot pay the SO amount with one payment, e.g. limit on the credit
card, the user will now have the possibility to set a partial amount on the payment links.
The order will be automatically confirmed when the amount chosen is equal to the remaining amount
to be paid.
Additionally, the customer will be notified by email for each payment done instead of only at the
confirmation of the order, which will happens only once the total amount is paid.
Task - 2672713
closesodoo/odoo#109661
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Horacio Tellez <hote@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
Since 15.0, it is no longer possible to have partnerless transactions.
Nonetheless, migrated databases could contain transactions without a
`partner_id` set.
This commit cleans existing rules to make those transactions are not
accessible to unwanted users.
We take the opportunity to clean the security of payment.transaction
records globally.
Now only admin and accounting users have access to payment.transaction
records. The code of different applications has been adapted accordingly.
Task - 3102824
closesodoo/odoo#113515
Related: odoo/upgrade#4564
Related: odoo/enterprise#40939
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit : The library underscore.js and
underscore.string.js were used in the ODOO solution.
After this commit : Every usages of a function from
underscore.js lib has been replaced with native javascript.
The goal is to remove all usages of underscore.js and to
not use anymore this library in ODOO.
---
TaskId : 3246238
closesodoo/odoo#120437
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
"ValueError: External ID not found in the system: payment.payment_provider_
stripe" is generated because the user deleted the Stripe payment provider
record and its corresponding model tried to access the record of it.
Steps to produce the error:(in >=16.0)
1. Install e-commerce
2. Install 'Payment Provider: Stripe'
3. delete the Stripe from payment Provider
4. Go to the website > Reporting > e-commerce
5. Click Activate Stripe on eCommerce Dashboard
This commit solves the above issue by preventing the deletion
of the payment provider if it has a external reference.
sentry-4041178833
closesodoo/odoo#120534
X-original-commit: 7082ce2460494891e8e063c11678226b164f99e7
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
This commit addresses an issue with the checkout form displayed on the
portal page of the Subscriptions app: when only one payment provider was
available for checkout, and it required an inline form to be displayed,
the latter would not be shown, and customers were able to hit the "Pay"
button, resulting in a client error. The problem was that Subscriptions
now simultaneously displays two payment forms on the same page, one for
checkout and one for managing payment methods, which was not supported
by the payment engine.
closesodoo/odoo#120482
X-original-commit: 91d701e34a25d2ceada1679f36a9cdbb96c6c019
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
avoid overriding payment views by creating new computed field in the payment provider property and override it if needed in inherited payment models
task-3120983
closesodoo/odoo#116573
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: web, web_editor, payment
Before this commit, templates with %d was given to sprintf but it was not interpreted by the function
After the commit, %d are replaced by %s in templates for sprintf
Also this commit converts a last _.str.sprintf into sprintf
PR#120143
closesodoo/odoo#120143
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Steps to reproduce:
- install website_sale;
- install website_sale_picking;
- enable just "Pay in store when picking the product" provider;
- pusblish just "[On Site Pick] My Shop 1" shipping method;
- go to ecommerce and make the purchase flow.
Issue:
A traceback appears on the "/shop/payment" page.
Cause:
We use the `txContext` field in the `_setPaymentFlow`
method before it is initialized.
Indeed during the `start` method, we have to wait for the end
of the super before `txContext` is initialized.
Since the `start` method is asynchronous, this will not block
the `_setPaymentFlow` method call which will use the uninitialized field.
opw-3257641
closesodoo/odoo#119351
X-original-commit: 18b629bfc26ab69e5e3bdc8aac090de66cf13f36
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the generation of token aliases in Ogone relied
on the util function `singularize_reference_prefix`, which is intended
to make transaction references (and not token aliases!) more
distinguishable by suffixing a timestamp accurate to the second. That
util function does not guarantee the uniqueness of generated reference
prefixes, which is okay because the final reference is further suffixed
if the prefix happens to collide with an existing reference.
Using the util to generate Ogone's token aliases, however, poses a
problem because aliases *must* be unique. Otherwise, a customer saving a
payment token at the same second as another customer would end up
linking their payment method to the other customer's payment token.
This commit drops the use of the util method and replaces it with a UUID.
closesodoo/odoo#115580
X-original-commit: 61d833ffcd1562950126d3c87c92569fe35a8b08
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible to partially capture a
transaction from Odoo, and doing so in the provider backend would often
result in a full capture in Odoo when capture was supported.
With this commit, partial captures are made available in Odoo directly
from the sales order or invoice, for providers that support them.
Provider can either only support full capture or also support partial
ones. It also optionally managed the automatic void of the remaining
amount at the user request when multiple captures are supported by the
provider.
As of now, the only acquirer allowing partial capture is Adyen.
task-2728768
closesodoo/odoo#87251
Related: odoo/enterprise#35205
Related: odoo/documentation#2063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the public user did not have access to tokens or the
possibility of saving payment methods.
When receiving a link to pay the customer (even if not logged in) should
be able to use tokens saved by the parter of the document and also save
new payment methods. This is intuitively correct: as the possesor of the
link, the customer have rights to pay with tokens linked to the partner.
After this commit tokens linked to the partner of the document will be
visible to the public user and also the possibily to save payment
methods.
Task - 2799296
closesodoo/odoo#104472
Related: odoo/enterprise#34792
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some providers require additional allowed states due to their refund or
transaction process justifying it. Until now, these extra states were
specified in the `payment` module, which was not ideal as it allowed
every provider in every flow to accept these additional states.
With this commit, additional states are now specified only in the
coresponding flow of a provider that requires them.
task-2869678
closesodoo/odoo#107110
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
UX was lacking comparing to other payment providers,
important fields were not always shown or were checkboxes
when they should be automatically true.
In order to make payment flow easier and more intitive, unnecessary fields
were removed, email is automatically filled. Now when user cancels transaction
on paypal before paying, it automatically cancels transaction on Odoo. Additionaly, quick
onboarding is only available if user already has paypal account and Stripe
no longer installs ond configures paypal if Stripe's onboarding get canceled.
task-2854184
closesodoo/odoo#104974
Related: odoo/upgrade#4025
Related: odoo/documentation#3063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Until this point the access to tokens was somehow arbitrary and
illogical.
After this commit we will uniformize the tokens access rule where by
default an user can only access its own tokens by default and in
function of the use case then relax the rules.
Task - 2832561
closesodoo/odoo#104808
Related: odoo/enterprise#33541
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently there is no distinction between saved tokens and providers
and there is no info on tokens under what provider they were created.
When client has more than one token it looks messy and counters the
point of token existance. Now tokens have their creation date,provider
and are no longer in the same card as providers.
task-2510973
closesodoo/odoo#108260
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The payment values in the Qweb context of sale, sale_subscription and
website_sale were computed separately, although there is a large common
basis. This split made it hard to communicate between modules and
generated a lot of duplicates. The new function `_get_payment_values`
in sales is now used as a common basis method for all sale_* modules to
get the common payment values.
closesodoo/odoo#107788
Related: odoo/enterprise#34922
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
All the messages on the "Payment Status" page were using the term
"payment". This could cause confusion in users when saving payment
methods, as a "payment" related message will appear even that no
payment related transaction is ocurring.
After this commit messages will use the more generic term "operation",
aiding in consistency and as a bonus avoiding confusion in users.
Task - 3050181
closesodoo/odoo#111868
X-original-commit: 14b5bc63a27ead3df882e5f9ebe15c0387c90844
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, when using express checkout, the shipping address
was requested only if the technical module 'delivery' was installed.
Now, over express checkout, the shipping address will be requested if
the sale order contains products that aren't services.
task-3149536
closesodoo/odoo#111796
X-original-commit: 9c16e83336b042ab77c267607ac43e0ef0db9997
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
Payment methods without image or without name does not make any sense.
Previously created payment methods without a name will be
given default name and ones without an image will be deleted.
Payment icon can no longer be created or edited from payment
provider form view.
task-2853424
closesodoo/odoo#105909
Related: odoo/upgrade#4043
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
before this commit, from the payment providers menu, even though the provider is not installed in the database, the company, website and image fields are editable for the users.
after this commit, the fields will be editable/visible only after the provider is installed in the db.
publish/unpublish button will be shown only when provider is installed.
closesodoo/odoo#110114
X-original-commit: e910dee3ce4b526aa956ad489e83442b3a425c36
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Following f3a3e34150, the l10n tests were failing due to the main
currency changing to a currency not available for the test provider.
closesodoo/odoo#109916
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Following 90af85c2e4, the management of the compatible providers
was modified by their available currency. Some tests weren't adapted to that change.
closesodoo/odoo#109665
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the lists of supported currencies by payment
provider were hard-coded in the Python scripts, which made them
unavailable to the users.
With this commit, the implemented initial lists of supported currencies
are displayed on the form view and are editable, because Odoo lists may
not be up-to-date. Empty lists do not trigger any filtering on the
payment providers to access payment methods.
For Authorize.net and Asiapay payment providers, the specific
`(authorize,asiapay)_currency_id` are removed and the generic payment
provider field `available_currency_ids` is restricted to a single-item
list when one of those providers is enabled.
task-2926016
closesodoo/odoo#101018
Related: odoo/enterprise#34158
Related: odoo/documentation#2788
Related: odoo/upgrade#4069
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
1- install any payment acquirer (e.g. stripe)
2- configure the payment acquirer and link it to a journal
3- try to delete the journal
4- the journal can be deleted which will create an internal server
error when this payment acquirer is used
Bug:
There is no restriction on deleting `account.journal` linked to
payment acquirers
Fix:
add a restriction that forces the user to remove the journal from the
payment acquirers first
OPW-3089006
closesodoo/odoo#108403
X-original-commit: 3ec6fe4ab1df3e3368fd06ff0e18a240caf088e5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Before this commit, the text of a `CopyClipboardButtonField` could be
edited with a `label` option. But this label was never translated.
After this commit, the field `string` is used instead to rename the
button. This is automatically exported for translatation.
task-3054813
closesodoo/odoo#105560
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Payment fees appeared as float (and not monetary) in the Payment
provider form and were not converted into the chosen payment
currency.
Some tests check the `_compute_fees` function.
task-2854143
closesodoo/odoo#100156
Related: odoo/upgrade#4106
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The currency_field shouldn't have to be specified in the view if it has
the same value as the field specification in python.
closesodoo/odoo#107396
X-original-commit: 47cf3688baf6aed6f027fc44db7293d9563789f4
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Martin Trigaux