Change a constraint that was meant to prevent deletion of an
account.payment.method.line when related provider is in 'enabled'
or 'test' state. The constraint is now handled only on the payment method
lines that are actually modified, and not on everything like previously.
This constraint was failing during upgrades because it was too broad,
its initial purpose was to raise error to user at the moment he tries
to remove payment method lines from its journals.
closesodoo/odoo#128214
X-original-commit: fca76bcc6c8be6e38827641555d62ab2973ab1fe
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Since odoo/odoo@2b1e2abda3 user need at least 'Account / Billing'
access to read payment.transaction, that not the case for most salesman.
So for user that don't have 'Account / Billing', this commit do:
- compute the 'amount_paid' as superuser
(fixing "Generate Payment Link" wizard access errors)
- hide "Payment Transaction" smart-button on invoice
closesodoo/odoo#127835
X-original-commit: ad2c3a873a926ac8c94d014af24ed400b493493e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
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>
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>
*: onboarding, account, account_payment, sale.
Currently used in the appointment module (See c1cf8bfb).
Related Task-3297572
task-2818586
Part-of: odoo/odoo#116641
To improve onboarding experience, configuring Stripe
has been added in Invoice onboarding process.
For db with other apps(ecommerce or sales) if onboarding is
done in one place it is considered done in other places with
exclusion of Sales, unless it was done in Sales.
task-3208045
closesodoo/odoo#114131
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The 'Generate payment link' action on account move records was only
shown to the users of the group 'Show Full Accounting Feature'
(and to salesman when sale is installed).
This means that if you only have invoicing app (`account` module) installed,
you don't see the action.
This commit makes sure the action is visible to all accounting users, like
the refund wizard.
closesodoo/odoo#118800
X-original-commit: 8cf2aebe9582a12b0f2309f25844e0b2d82ed3e2
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@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>
The logic to display the payment status of invoice(s) has been quite
messy for a long time, leading to a lot of confusion and some bugfixes.
This commit tries to simplify and harmonize the logic, and to provide
a clear logic and ordering of the payment states, following
1) the invoice state (cancelled state)
2) the accounting state (related to `account.payment` records and logic)
3) the payment state (related to `payment.transaction` records, holding
states not reflected in accounting logic until effectively confirmed).
closesodoo/odoo#111046
Related: odoo/upgrade#4409
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The module ´account_payment_invoice_online_payment_patch´ was added in stable to allow
account_payment users to disable online invoice payment
(without removing the module, critical for other flows).
It can be safely merged into the account_payment module for future versions.
Original bugfix PR: #110177
Related to opw-3114860
Part-of: odoo/odoo#111046
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>
1. Install [Studio], [Accounting] on Apps
2. Enter [Accounting]
- Click the Studio icon second to left on the top right corner
- [Edit Menu]
- [NEW MENU]
- Fill in e.g.`Test`, select [Existing Model], Model: Payment Methods
- Click the icon on the right, check it is `account.payment.method`
- [SAVE & CLOSE]
- [CONFIRM]
- [CLOSE]
3. Click on `Test` menu created next to [Configuration]
- [NEW]
- Type in all info, click to Save
- Error is thrown
Desired: block users from creating a `payment.method` by all means
Impacted versions: 14-master
opw-3148453
closesodoo/odoo#114408
X-original-commit: 59ea0e9802fc9cf98bab8fbdc065d9b5fc023ac7
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@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>
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>
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>
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
Since e3eb7d9bef, the accounting logic
has been moved out of the payment module, to be only in the
account_payment bridge module.
This bridge module has been set as strict dependency of
module providing payment & invoicing abilities, e.g. sale .
Nevertheless, the account_payment module also held the logic to
allow users to pay for their invoices on the portal and there
was no dedicated setting to enable/disable this feature.
This means that in 16.0+, you cannot disable online invoices
payment without removing sale and subsequent modules.
This commit introduces a temporary bugfix module to allow
disabling invoices payment without uninstalling the
account_payment module. It will be merged in the core
account_payment afterwards.
opw-3114860
closesodoo/odoo#110843
X-original-commit: be242cf658e7742600dec4824ba96a89f4d6142a
Related: odoo/documentation#3396
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Steps to reproduce the issue:
- Accounting > Configuration > Journals
- Click on Journal
- View metadata of Journal
Bug:
Even if no modification has been made to the journal, it marked current time
in Latest Modification By/Date
opw:3089551
closesodoo/odoo#107875
X-original-commit: 47999e7b1c9a52059f84abaafeac388f2991a621
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
As provider references are included in the memo of `account.payment`
records, it makes sense to set one on demo transactions to mimic what
is done with other providers.
task-3063368
closesodoo/odoo#106486
X-original-commit: 73865f2bd03c7d224f0a64659652e8e40c4ba192
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
The Memo field in the form view of the `account.payment` model
(the `ref` field) was a little cryptic and did not supplied a lot
of information about the payment.
After this commit the Memo will (if available) provide information
about the sales order, the partner and the payment transaction.
Task - 3063368
X-original-commit: 414fb09b718a100cb96857725523e7a9109135cf
Part-of: odoo/odoo#106486
Rather than hiding all payment providers and payment tokens from the
payment form, a warning is now shown to the user if their company is
not the same as that of the document (SO, invoice, ...) they're paying
for.
task-2983985
closesodoo/odoo#100375
Related: odoo/enterprise#31424
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- Setup Wire transfer as Payment Provider
- Create a sale from shop
- Use Wire transfer as payment method
- Go to Sales > Confirm the quotation
- Create Invoice
- Click 'Preview' to view invoice in customer portal view
Issue: internal server error
The `provider` field has been renamed to `provider_code` in b7f5eb54453737f371eda4ca897300b89abd9c2e
opw-3031308
closesodoo/odoo#104441
X-original-commit: 4841aae833c462cd28fe3dbc81f12fb35afc8187
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The confirmation message for the sale order appeared twice in the
chatter: first with the confirmation and second with the posted payment.
The second message is now rephrased in order to avoid any confusion for
the user (no double payment).
task-2965158
closesodoo/odoo#101921
X-original-commit: c1faff69db2a66e249bfbc5ea77644da0957d401
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
When payment providers receive a notification from a webhooks and log
something in the chatter of transactions, sale orders or invoices, the
message is shown as from 'Public User'.
Now, all messages will be logged as 'OdooBot'.
Part-of: odoo/odoo#100186
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount for each payment term lines.
The user can choose between three different kind of tax computation for the discount. If the conditions for the cash discount are fulfilled, the tax will either be:
- included : the tax and base amounts will be discounted.
- excluded : the tax will be left untouched, the base amount will be discounted.
- mixed : the tax is durably discounted, the base is discounted if the early payment occurs.
The discounted amount and the conditions to fulfill are printed below the invoice PDF if the option to do so is checked.
Took the opportunity to improve the display of the payment terms on the invoice in general.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
The Journal Items in the account.move, the payment and the reconciliation are modified as needed to take the discount into account.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts is also applied to allow as often as possible for an automatic reconciliation.
Related : odoo/enterprise#28607
Task-2968644
closesodoo/odoo#99572
Related: odoo/enterprise#31225
Signed-off-by: Laurent Smet <las@odoo.com>
Avoid starting the patcher two times to not create two separate
instances of it, and only stopping one of it.
closesodoo/odoo#100058
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
Claire Bretton (clbr)