* payment, im_livechat
Inline scripts using `odoo.define` cannot work anymore as the boot.js
file loading will be deferred.
Most of features which used an inline script should probably be entirely
refactored. This commit focuses on removing the inline scripts
with a minimal diff (or at least tried to).
Note: for the website livechat, the inline script was kept as it seems
to be a longer refactoring to get rid of it (even though it is clearly
possible). The inline script was however adapted to make sure it works
with lazy loaded JS in the frontend.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
When paying an eCommerce order with an acquirer which doesn't
redirect (payment_flow: s2s) the "Pay Now" button is correctly
disabled after clicking it. This prevents a user from clicking it
multiple times and being charged multiple times.
When paying with an existing payment token however the button was not
disabled and the user gets no feedback his request is being
processed. Charging an existing payment token takes a while (~5
seconds with Authorize) and so it's possible users will hit the button
multiple times.
This disables the button when reusing an existing payment
token. Additionally it now uses the correct font awesome icon (fa-lock
instead of fa-plus-circle).
opw-1981064
closesodoo/odoo#33196
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit will correctly check for a custom payment.transaction create method
on 'self' instead of the acquirer's provider before calling it.
closesodoo/odoo#33033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After deep comparison between majors versions, it seems that
there is no breaking changes and this fix a lot of issues in
mobile.
e.g.:
Before this update, the validity date wasn't correctly formated
and the end user had to enter the right format himself.
Some users were blocked at the payment process.
The root cause for this issue is the inconsistent list of native
events triggered by mobile devices.
Note that this library is only used for acquirer forms (S2S Form
Template) when "Redirection to the acquirer website" is checked
(payment_flow == 's2s') in the acquirer configuration.
We are aware that this library is deprecated and should be replaced
in the future.
See https://github.com/stripe/jquery.payment
opw-1986545
closes#33356closesodoo/odoo#33376
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
when we get an error while making the payment, it should be shown to the user.
But the message is not getting from proper dict, so it will break every time.
closes - https://github.com/odoo/odoo/pull/33231closesodoo/odoo#33231
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
simplification of payments objects and refactoring of the code
* registering payment(s) from the list of invoice now generate a single payment per invoice selected
* no more abstract object for payments/payment wizard as the logic is now really simple:
- group_invoices option is now removed and we never try to group payments based on the currency/customer of whatsoever (see above),
- the payment amount is the full residual amount of invoice and users cannot change it anymore
* partner_bank_account_id not required as soon as visible (depends on the payment method)
* refactoring to name tags and allow easier inheritance via xpath
part of task #1918423
- When validating payments on the payment process polling page
errors can occurs and the tracebacks aren't logged which doesn't help
when trying to understand the issues.
With this commit we display the traceback instead of shadowing them.
closesodoo/odoo#33537
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When processing payments on the payments processing page,
`psycopg2.OperationalError` can be raised.
We do not want those exceptions to be displayed to the customers,
instead we want the polling page to try to process the payments again.
This commit hides the display of psycopg2 operational errors.
- This commit also fixes the "processing your payments" message being
hidden after the first polling, no matter if the processing has succeeded or not.
closesodoo/odoo#33462
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This prevent the uninstallation of all payment provider through the
NOT NULL constraint. There is no reason for this field to be explicitely
required - it will fail if the template is wrong anyway.
closesodoo/odoo#33170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This commit introduces the Alipay payment provider, a popular acquirer
in the Chinese market.
There are 2 possible ways to use this acquirer:
- express checkout mode (only available for merchants located in CN)
- standard checkout mode (availabe for foreign merchants)
Note that this provider does not support server-to-server payments,
tokenization or any other bells and whistles besides fees. There are no
specific behaviours related to this acquirer, it behaves like most 'form
based' payment acquirers with a form submission, s2s notification from
the provider as well as redirect in case the s2s did not reach the
server in time.
closesodoo/odoo#21855
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Currently, when some add token for s2s payment, dummy transaction of
1 unit was performed and it was frautrating for customer.
So added option on acquirer's settings that check if you want's
to validate the transaction or not.
If 'verify Card validity' is ticked on payment acquirer then and then
it will verify with dummy transaction otherwise it will not going to verify
the card details.
Task-1903170
closesodoo/odoo#29595
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
* = hr, im_livechat, mail, payment, purchase, web, web_editor, web_unsplash,
website_profile, website_slides
Since the merge of all image tools into one function, the intermediary functions
are not needed anymore.
task-1958000
PR: #31811
Christophe Simonis