The previous link was dead

closes odoo/odoo#103051

X-original-commit: 570fec0a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit, customers might see a "transaction not found" page
when returning from Adyen Pay By Link Payment Page.

Now, they'll see a "waiting for payment" page if they returned before
the webhook notification or the confirmation of payment if they
returned after the webhook notification.

opw-3006401

closes odoo/odoo#103063

X-original-commit: 4fcf2600
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>

Steps to reproduce:
- Have a portal user with a related contact (thus on the contact, partner_share is True)
- Set a default company A on the user, and the same company A on the sales tab on the contact (so the company_id field is A)
- Have a website linked to company B
- Connect to said website with the portal user
- Try to buy something

Issue:
Internal error - Multi company issue

Solution:
It is mainly a configuration error but the message is not user firendly.
Instead we make sure the partner cn proceed a transaction in the company website

opw-2734190

closes odoo/odoo#101722

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Fixing some demo data from US having an Italian VAT.
Also, a partner's name and VAT has been changed not to be too similar
to one of our actual clients. Now the Engie Italia's VAT is used.

closes odoo/odoo#102904

Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#98613

Signed-off-by: Laurent Smet <las@odoo.com>

Partial backport of [1] which should have fixed and improved the last
issues regarding theme records.
This is backporting the stable-friendly part. If really needed, we will
have to backport the rest through a new module in stable.

We would rather have people migrate to Odoo 16.0 to benefit from a lot
of new features regarding the themes.

[1]: https://github.com/odoo/odoo/commit/d9c260de4b539c2350d4e0ce04007635abec9928



Fixes #85630

closes odoo/odoo#86669

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:
- create a second Bank journal with a different currency from that of
  your company.
- create a new reconciliation model with the following settings:
  * Type: Rule to suggest counterpart entry
  * Amount Type: Paid/Received
  * Auto-validate: True
  * Journals Availability: add the bank journal you just created
  * Counterpart Entries:
    - Account: select an expense account
    - Amount Type: Percentage of statement line
    - Amount: 100
    - Taxes: add the 15% purchase tax
    - Tax Included in Price: True
- create a new bank statement on the Bank journal you created earlier
- post that statement and reconcile it
- go back to the statement and look at its journal entries.

You should see that the entries are wrong. The tax amount is incorrect,
so we have an open balance.

opw-2965948

closes odoo/odoo#99797

Signed-off-by: Laurent Smet <las@odoo.com>

For the product, the default income and expense accounts should
only contain the income/expense accounts.
Such that the dropdown menu in the product view only lists the possible
income or expense accounts. Adapt the domain on the product and product
template fields.

closes odoo/odoo#102661

Signed-off-by: Laurent Smet <las@odoo.com>

The implementation of _find_mail_template allow to call it only
on one record at a time.

This was not the case with in _send_order_confirmation_mail.

- Add excplicit constraint in _find_mail_template
- Make sure _send_order_confirmation_mail call the method once per
  record

closes odoo/odoo#102389

X-original-commit: a3d543d2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing



Issue:
When using the register payment with a token with any of the payment acquirers,
if there is a concurrent access error during the reconciliation process,
the payment intent is sent multiple times to the acquirer, making the card charged multiple times.

Steps to reproduce:

-Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing
-Configure Stripe with your public and secret key (2FA is now enforced for Stripe accounts, therefore,
 we don't have a generic test account anymore. You have to create your own.It is quite fast and easy to do)
-Have a portal user PU with an already registered payment token PT
-Go to Invoicing
-Create a new invoice I:
-Customer PU
-Add anything in invoice lines
-Confirm I
-Register a payment for I:
-Journal: Stripe
-Saved Payment token: PT
AT THIS STEP, YOU MUST ENSURE A CONCURRENT ACCESS ERROR WILL RAISE DURING THE RECONCILIATION
-Create Payment

Log analysis:
A first payment intent is sent to Stripe. The card is charged and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment intent is sent again to Stripe, The card is charged AGAIN and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.

For each retry, the intent is sent and the card is charged.

If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Stripe's side and the card will be charged 3 times.

This PR mitigate this behaviour.
It doesn't address the root cause but by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent mutliple payments to happen.

OPW-2662964

closes odoo/odoo#101243

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Problem: If you have a customer assigned to an invoice/quotation
without an e-mail address and then share a payment link with
the customer. If the customer clicks on 'Pay', he won't be
redirected to Stripe's checkout page. He'll get instead 'Invalid
e-mail address: False' (see the image attached).

Explanation:
When there is no e-mail address defined, Odoo sends 'False' to
Stripe but Stripe sees it as the e-mail address which is indeed
Invalid. To solve the issue we replace False by None for the email
value of a customer without email address.

opw-3007866

closes odoo/odoo#102324

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Currently the "abort" function in the pos_adyen module did not include
all the information necessary to cancel the current payment.
With this commit this information is added and the status is correctly
returned to the JS in order to have the correct status on the payline

https://docs.adyen.com/point-of-sale/cancel-a-transaction#cancel-from-register



closes odoo/odoo#101760

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

For box 2E, fix typo in the tag_name and code.
Bug was introduced by 85a634c7

closes odoo/odoo#102648

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Fixup of 1b80454f

closes odoo/odoo#102591

X-original-commit: 588ab3ff
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>

OPW-2976150

closes odoo/odoo#102460

Related: odoo/enterprise#32418
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before: it won't work with extension in uppercase: .XML or .XML.P7M

We put ?i: in the regex so that part would be matched case insensitively

opw-2703669

closes odoo/odoo#100465

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Of course, for an XML that is imported or exported the type of the
invoice will be different: vendor bill for import, customer invoice
for export e.g.  But in the case of vendor bill reverse charge we create
the XML from the vendor bill, but we did not think straight about how
it should be imported.

We did not expect it to be imported, but somehow in a database it was the
case and we see it is actually corresponding to a vendor bill coming from
a foreign vendor, so it would be better as well to import it as such.  Also
those types are only needed as vendor bills/refunds in our system.  (only
support bill for the moment)

opw-2977126

closes odoo/odoo#100530

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

The aim of this commit is to improve the test skipping code of the oss modules
by avoiding to hardcode the chart_template_ref (xml_id) directly in the error
message.

Before this commit:
The TestOSSSpain test class was failing when the l10n_es module wasn't
installed instead of being skipped.

After this commit:
The TestOSSSpain test class is correctly skipped instead of failing.

closes odoo/odoo#102551

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Processing failed mails is quite consuming operation that leads to browser
slowness or even crash. It's especially painful, because user doesn't see the
reason for it.

Bypass the problem by processing first 100 notifications only.

Back-port of https://github.com/odoo/odoo/pull/90138



closes odoo/odoo#102076

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

This commit cleans the tax groups:
- it removes the negative tax groups
- it makes sure that there is only one tax group per tax rate
- all the taxes with the same rates are attached to a single tax group

This commit splits the taxes to make the distinction between the goods and services.
In addition, the fiscal positions are also updated accordingly (make sure to map to another
one having the same scope: goods/services and type: sale/purchase).

These changes are based on the reliable feedback of LPDE (Didier Six). No tax were removed
from the old version. Only some were split, the others were kept (but modified).

In addition, the tax report is updated to the 2022 version and the new tax report lines
are linked to the taxes.

task-2674047

closes odoo/odoo#84918

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Items with tax "GST Only - Import" does not
appear on tax report

Add "BOX 11" tag to "GST Only" tax.

opw-2919731

closes odoo/odoo#98717

Signed-off-by: William André (wan) <wan@odoo.com>

In this commit, we add data of amortizations accounts and correct the
accumulated amortization accounts (now they are of the fixed asset
type) to be consistent with the Argentine chart of accounts.

For each accumulated amortization account we have an expense type
amortization account.

closes odoo/odoo#101630

X-original-commit: daec19f7
Signed-off-by: Josse Colpaert <jco@odoo.com>

Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.

Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.

Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.

opw-2745014

closes odoo/odoo#102098

X-original-commit: 7a41e93f
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>

**(adapted) backport of 4c9c848f**

To reproduce the issue:
(Need stock_barcode)
1. Create a product:
    - Barcode: 1234567890123
2. Print the label
3. Try to scan the barcode and check the value read.

Error: The value is 1234567890128, the last digit is incorrect (8
instead of 3)

When printing a barcode, we use the library 'report-lab' to generate a
barcode image from a value and a barcode type. In case of EAN-13, if the
value contains a non-digit character, it will raise an error. We then
catch the error and retry to generate the barcode according to the
barcode type Code128:
https://github.com/odoo/odoo/blob/87698d90f02bfe93c6e643f4876a5ccd74788eff/odoo/addons/base/models/ir_actions_report.py#L569-L575
However, if the value contains only digits, the method will use the 12
first digits:
https://github.com/mattjmorrison/ReportLab/blob/dade0f303cb6fcdbe535c4cc92e6102c2417b699/src/reportlab/graphics/barcode/eanbc.py#L187-L188


and will then add the last one, the check digit, which is computed by
the library. This explains why, in the above use case, the barcode value
returned by the scanner is not the same than the expected one.

Note: Similar behavior with type EAN-8

OPW-2980717

closes odoo/odoo#100231

Signed-off-by: Steve Van Essche <svs@odoo.com>

Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.

That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.

related commit: c112361b

task 3003939

closes odoo/odoo#101858

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

If the decimal separator of the currently selected language is a comma,
exporting data in an xlsx would use a wrong float format

Steps to reproduce:
1. Install Invoicing
2. Go to Settings > Languages, add 'French / Français' language and
   switch to it
3. Go to Facturation > Fournisseurs > Factures
4. Export the data (there should be at least one amount with a decimal
   part)
5. The decimal part of the amounts is not displayed

Solution:
Always use the same decimal separator to print in the xlsx as we can
only use a dot as a decimal separator (the comma is used as the thousand
separator). The value will then be displayed to the user according to
his OS regional settings (see https://xlsxwriter.readthedocs.io/format.html#number-formats-in-different-locales

)

Problem:
When using a comma for the float format, we actually specify the format
of the integral part of the number (the thousands) without displaying
the decimal part (which is represented with the dot)

opw-2965984

closes odoo/odoo#99286

Signed-off-by: Julien Castiaux <juc@odoo.com>

closes odoo/odoo#101863

X-original-commit: a8333b81
Signed-off-by: Josse Colpaert <jco@odoo.com>

X-original-commit: 1757a853
Part-of: odoo/odoo#101863

It seems that there is a rather frequent warning that can be added to
mail received by outlook 365 and that has the form:

```
<table border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%">
...Caution: This is an external email and has a suspicious subject or content...
</table>
```

The combination of `align="left" width="100%"` means that a div after
this alert will probably have a width of 0 (because the previous content
is floating to the left, and taking 100% of width so there is 0 pixel of
width remaining).

This is not an issue in general, but in Odoo this conflicts with a code
that adds scrollbar if a message content overflows (but here since width
is 0 pixel the content is just hidden).

With this commit, if we detect the code that is used in all our received
report (width=100% and float=left), we ignore the float to prevent this
issue from happening.

An alternative is to avoid Outlook 365 adding this structure in a
message (see [1]), but this is only possible if we can change the
configuration where this structure is added (eg. we can't if it is
a customer that is forwarding a mail already broken).

[1]: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide#first-contact-safety-tip



opw-2887342
opw-2925222
opw-2946587

closes odoo/odoo#101295

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Change 'Invoice date' label on report according move_type

closes odoo/odoo#101242

X-original-commit: 706db8a7
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: wan <wan@odoo.com>

Steps to reproduce:
- set demo to receive notifs in Odoo
- go to employees
- click "launch plan" for demo user
- login as demo user
- Click on the link for the activity that is sent in discuss

Issue:
There is no chatter in the view

Explanation:
the view of en employee coming from messaging is always
hr.employee.public that does not contain the chatter.

opw-2990577

closes odoo/odoo#100959

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Steps to reproduce:
* setup Alipay in test mode (note that Alipay's test node only support
  one currency: the USD)
* create an invoice. Make sure the invoice's total has decimal places
* generate a payment link for that invoice
* go to the generated link
* select Alipay as the payment method and click pay.

You should be met with an INVALID_PARAMETER message.

Cause:
Alipay's doc states that the parameter 'total_fee' can only have two
decimal places. Currently, this requirement is not always respected

opw-2996278

closes odoo/odoo#101798

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Work hours in a planning do not respect the timezone

Steps to reproduce:
1. Set your computer timezone to 'America/New_York'
2. Install Manufacturing
3. Go to Settings > Manufacturing > Operations and enable Work Orders
4. Go to Settings > Technical > Resource > Working Times and open
   'Standard 40 hours/week' (San Francisco)
5. Edit the timezone to 'America/New_York'
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
   the day view
7. The work hours are not correct as they do not respect the timezone

Solution:
Add the timezone of the resource's calendar when computing
unavailabilities

opw-2903591

closes odoo/odoo#100538

Related: odoo/enterprise#31913
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

When the analytic account feature is enabled, if a user marks a MO as
done and if it displays a wizard (consumption warning, backorder...),
the analytic lines will be generated twice.

To reproduce the issue:
(Need mrp_workorder, account_accountant)
1. In Settings, enable "Analytic Accounting"
2. Create a work center WC:
    - Cost per hour: 100
    - Analytic Account: a new analytic account AA
3. Create two products P_finished and P_compo
    - P_finished is storable
    - P_compo is consumable
4. Create a BoM:
    - Product: P_finished
    - Components: 1 x P_compo
    - Operations: add a new one:
        - Work Center: WC
5. Create and confirm a MO with 1 x P_finished
6. Start the WO for few seconds then mark it as done
7. Set the consumed qty of P_compo to 2
8. Mark the MO as done
    - there is a consumption warning, confirm it
9. Open the account analytic lines related to AA

Error: there are two same lines for the MO, there should be only one

Step 8, when the user marks the MO as done, we call `button_mark_done`.
Because there is a consumption issue, this method returns an action (the
wizard with the consumption warning). However, in
`/mrp_account.button_mark_done`, we still generate the costs (this is
where the analytic lines will be generated). That is not correct since
the MO is not yet done. As a result, when confirming the consumption
warning, it leads again to `button_mark_done`, so we will generate the
cost a second time.

Note: this issue will happen each time the call of `button_mark_done`
does not mark the MO as done (for instance, in case of a backorder)

OPW-2972407

closes odoo/odoo#101528

Signed-off-by: Tiffany Chang <tic@odoo.com>

If the components of the manufacturing order are in done or cancel
state you should NOT define the status of the manufacturing order as done.
It should only be set as done if components and finished moves are done/cancel.
TT38551

closes odoo/odoo#98105

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Fixup for d823033a

Portal user should not modify partner's name if an invoice for this partner is
already issued. However, delivery address contact may have empty name, while
eCommerce UI requires filling out the name. This blocks checkout process. Fix it
by allowing name changes, when it's not set.

opw-2981455

closes odoo/odoo#100797

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

This PR https://github.com/odoo/odoo/pull/97805

 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.

Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)

closes odoo/odoo#101706

X-original-commit: f6a66d7a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Steps to reproduce:

1. change system and admin's time zone to one with a different
date than UTC
2. enable multi-currency in the accounting module
3. add rates for the current date in local time zone and UTC
4. go to settings > currencies
5. the rate for the UTC date is displayed

To fix this, we should use a time zone aware field in `res_currency`.

opw-2945108

closes odoo/odoo#101640

X-original-commit: 2f1d8d6d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>