This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, tokens were prefixed with usually 12 X’s. To improve
readability, modernity and to shorten the length, this commit changes
token prefixes to a standard of •••• 1111.
task-2832669
closesodoo/odoo#94978
Related: odoo/upgrade#3738
Related: odoo/enterprise#29190
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The message returned by `_get_sent_message` for validation transaction
was wrong, refering to a token, but there is no token on validation transactions.
This doesn't have to be fixed in stable since validation transactions are not linked to
any specific document, so the wrong message was never posted anywhere.
Now that we improve the display logic of payment tokens and noticed the problem,
this commit fixes it (for code consistency, and if any custom code/... uses this
message as well.
Part-of: odoo/odoo#94978
This rule has no effect for a while!
In settings, we had to delete it because converting it would add
space in the first column.
In payment, it seems that this offset was used to center the content.
We prefer to convert it.
closesodoo/odoo#98438
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Calling `_build_url` for a test class that only inherited from
`PaymentCommon` would raise an error, as the method depends on the
`HttpCase` test class that is only inherited by `PaymentHttpCommon`.
closesodoo/odoo#95860
Related: odoo/documentation#2532
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The button should only be shown if a tokenization-capable acquirer is
enabled (or if a token already exists), but a typo made the button being
shown regardless of that (first) condition.
closesodoo/odoo#97276
X-original-commit: b301844cbdcb07b4e13186cae85257b18ca54654
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
When making transaction with 'validation' type and where fees
were active, fees were added to the amount.
This behaviour is problematic because
validation operations are used for tokenization for example where
no credit should charged to the customer.
Now validation operations have no fees even if fees are active
on the acquirer.
Task - 2784765
closesodoo/odoo#96712
X-original-commit: 69b04e753ab4e90e68b9d3e678ebea277586e7ac
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The csrf token given to the assignTokenRoute is not necessary
and will trigger warnings in the logs.
closesodoo/odoo#94020
Related: odoo/enterprise#28595
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The alert block content and style for the transaction status after
payment were computed in two different places: In the dedicated
`payment.transaction_status` QWeb template, and in the
/payment/confirmation` route's controller which, for some reason, was
re-inventing the wheel instead of relying on the dedicated template.
This commit combines the slightly different behaviors in the template
and gets rid of the duplicated logic in the controller to:
- Handle the states 'draft' and 'error'.
- Always show the transaction's state message, and not only when the
transaction was in a state for which there exists no pre-defined
message (`draft` and `error`).
task-2924873
closesodoo/odoo#96348
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was impossible to migrate from one payment
acquirer to another as the only way to do so was to change a payment
acquirer’s state to ‘disabled’, subsequently disabling all tokens of that
acquirer (detrimental for eg. running subscriptions).
After this commit, payment acquirers have an additional boolean
‘Published’. With this functionality, users can safely migrate by
keeping an acquirer ‘enabled’, but invisible for customers.
There are five combined states an acquirer can take:
‘enabled’ & ‘published’: Visible to all users
‘enabled’ & ‘unpublished’: Visible only to internal users
‘disabled’ & ‘unpublished’: Same as previously ‘disabled’
‘test’ & ‘published’: Same as previously ‘test’
‘test’ & ‘unpublished’: visible only to internal users
task-2871459
closesodoo/odoo#94242
Related: odoo/upgrade#3688
Related: odoo/documentation#2308
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a customers paid a transaction through the `/payment/pay` route and
the transaction was authorized, the message for confirmed transactions
would be shown on the `/payment/confirmation` route instead of the one
specific to authorized transactions.
task-2527323
closesodoo/odoo#78843
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, zombie payment tokens (= tokens linked to disabled
acquirers) could still
1) be used by internal users and
2) reactivated when the acquirer’s state changed to ‘test’ or ‘enabled’.
This is not desirable because zombie tokens should neither be used,
nor reactivated.
After this commit, all tokens related to an acquirer are unassigned
from linked documents and archived as soon as the acquirer’s state is
changed to ‘disabled’. Creating a payment with an archived token is
prohibited. In addition, archived tokens cannot be un-archived anymore.
task-2649806
closesodoo/odoo#93774
Related: odoo/enterprise#28661
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Sometime Paypal took 3 or 4 days for some payment verification due to
weekend. This raises the retry limit days for 4 days instead of 2 to
solve the issue
closesodoo/odoo#95522
X-original-commit: 5aaaaf8f072b3f8ab66a269bb3dba02714b593ad
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Due to an oversight, the "Save my payment details" checkbox was shown on
the inline payment form of SEPA Direct Debit acquirers, which should
never happen because the transaction is *always* tokenized with those.
With this commit, the `_is_tokenization_required` method is slightly
refactored to read the provider from the current `payment.acquirer`
record rather than from the kwargs. This conveniently fixes the issue
and prevents it from happening again elsewhere.
closesodoo/odoo#95519
X-original-commit: ebeebd87ed6d687b96dda3006b81356dfa76d0a0
Related: odoo/enterprise#29237
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the reference of a validation transaction followed
this format: “validation-20220222072710”, which did not match the
standard format for refund transactions (”R-S000001”). Moreover, some
providers limit the length of transaction references which forced us to
truncate the quite long reference.
With this commit, future validation transactions will have a reference of
the format: “V-20220222072710”.
task-2830826
closesodoo/odoo#94921
Related: odoo/enterprise#29076
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Hide the 'Pay Now' button for invoices which transactions total amount
equals their total amount.
When the total amount of all transactions related to the invoice is
equal to or greater than the total amount of said invoice, the 'Pay Now'
button should no longer be displayed.
task-2527323
closesodoo/odoo#95262
X-original-commit: de81225d39e7951ea9a63e24bab3a0138a6942e3
Signed-off-by: Achraf <abz@odoo.com>
After the payment apocalypse, `payment_test` was cleaned and stripped of
all useless parts. It was a very basic testing acquirer that allowed to
enter fake arbitrary payment details, choose whether they should be
tokenized, and then pay. It was intended to test the payment flow of
various applications (Sales, Subscriptions, Invoicing, ...) for a single
scenario: successful payments with immediate capture.
In order to extensively test an app's payment flow (explore other
scenarios), we need `payment_test` to have additional features.
Now, `payment_test` will allow profound testing of these features:
- separate authorization and capture
- customer fees computation
- tokenization
- refunds
- on the /pay page, users will be able to select the status of the
payment
- on the payment transaction form view, users can change the status of
a payment 'pending' to either succeed or fail
- on the payment token form view, users can change the state of future
transactions made with that token
task-2512196
closesodoo/odoo#78083
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: xlu-odoo <xlu@odoo.com>
Some payment tests were unexpectedly relying on the 'transfer' payment acquirer
to work because of a multi-company issue in the core payment tests setup.
This commit fixes the problem and adds an additional check in the tests to
make sure they rely correctly on the 'dummy' acquirer created in the payment
tests common.
closesodoo/odoo#94972
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Before this commit, the `major_amount` was rounded before the conversion
to the minor currency unit, leading to an approximation error when
multiplying a float.
After this commit, the conversion of the `major_ amount` to the minor
currency unit is done before the rounding, ensuring no float approximation.
closesodoo/odoo#94698
X-original-commit: 4a4e0129c09e2db11c46a90a07704dc37cb4fb20
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Users can now ask for a refund from Odoo for their transactions done
through Authorize.net. A refund will be triggered from Odoo when
necessary.
Only full refunds are possible.
Note that unsettled transactions will be voided as they cannot be
refunded.
Task - 2678757
closesodoo/odoo#92279
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The multi-company common of payment was only used in a single specific
test class of the same module. Since we don't aim to test multi-company
flows in specific payment_ modules, we might as well remove the common
and move the setup content in the only class using this common.
Task - 2848326
Part-of: odoo/odoo#90716
During the payment pocalypse, new tests common were introduced. Those
commons were split into different classes to be as modular as possible
but we noticed during the following months (/year) that they weren't so
easy to understand and use.
Therefore, this commit aims to simplify those commons by removing the
core PaymentTestUtils common, integrating it in the base PaymentCommon,
and making the HttpCommon depend on the core PaymentCommon, instead of
using only the utils.
This doesn't require much changes in the tests since they all used
either the PaymentCommon or both PaymentCommon and PaymentHttpCommon.
Task - 2848326
Part-of: odoo/odoo#90716
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>
Before this commit, users may saw the capture and void buttons but
couldn't use them.
As capture or void actions need to access acquirer-related fields,
these actions are now sudoed to allow any users that see the button
to use it.
The access rules and rights are also checked before executing the action
to avoid abusive RPC calls.
task-2785144
closesodoo/odoo#91923
X-original-commit: 2e351d6ff9b7f72b486e83c827ff6e15a05c3331
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Users without the right permission see the buttons but can't use them.
Capture and void buttons are now only visible and usable for admin or
users in account.group_account_invoice group (for invoicing module).
task-2785144
X-original-commit: db6b54cc49ba7d9266e766112017604ed98c2cb3
Part-of: odoo/odoo#91923
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
When a 'manual capture' is set for Authorize.net and a client
make a payment in several partial payments the user can capture
all the authorized transactions without crashing now.
Task - 2676914
closesodoo/odoo#90212
X-original-commit: 68b354f7353e3b5fd1faaad1b762c3c73a286f0f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
Denis Ledoux