Opening a field service task from the Activity view now works reliably on large screens. This prevents an error that could interrupt dispatchers or field service users when accessing task details.

Steps to Reproduce:
-  Open the Industry FSM app and navigate to the Activity view.
-  Click on any task to open its form view.

Issue:
- A traceback error occurs when opening a task on large screens due to 'newWindow' being undefined.

Solution:
- Passed the 'options' argument to super.openRecord in FsmMyTaskActivityController to ensure 'newWindow' is defined on large screens.
- Ensured consistent behavior for openRecord across devices.

task-4664793

Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295

Versions
--------
- 16.0+

Steps
-----
1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`.

Issue
-----
`AttributeError`

Cause
-----
The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`.

Solution
--------
The test works just as well without the method call, so we can simply remove it.

runbot-163194

Forward-Port-Of: odoo/odoo#206295

Before this commit, deleting a synced orderline linked to an event registration and then adding a new event product to the same order could cause an error when validating the order. Steps to reproduce: 1. Enable Events with PoS 2. Enable Online Payment 3. Add a ticket product to the order 4. Proceed to the payment screen, and select online payment 4. Delete the ticket line and add a different one 5. Complete the order using cash or another offline payment method opw-4714193 --- I

Before this commit, deleting a synced orderline linked to an event registration and then adding a new event product to the same order could cause an error when validating the order.

Steps to reproduce:
1. Enable Events with PoS
2. Enable Online Payment
3. Add a ticket product to the order
4. Proceed to the payment screen, and select online payment
4. Delete the ticket line and add a different one
5. Complete the order using cash or another offline payment method

opw-4714193

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#205418

Before this commit, cash payments from cancelled orders were included in the total cash payments, leading to inaccurate bank statements and an incorrect ending balance after closing the session. This issue was not visible during the session closing process, as cancelled orders are correctly excluded from the closing cash control computation. opw-4654848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203732

Before this commit, cash payments from cancelled orders were included in the total cash payments, leading to inaccurate bank statements and an incorrect ending balance after closing the session.

This issue was not visible during the session closing process, as cancelled orders are correctly excluded from the closing cash control computation.

opw-4654848

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#203732

Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508

Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it.

Forward-Port-Of: odoo/odoo#204508

… behavior Fix the demo mode of Peppol to be closer to the behavior in production. task-no (review with TSB/PMAX 31/03/25) Forward-Port-Of: odoo/odoo#204241

… behavior

Fix the demo mode of Peppol to be closer to the behavior in production.

task-no (review with TSB/PMAX 31/03/25)

Forward-Port-Of: odoo/odoo#204241

Before this commit, if the state of an order was set to 'cancel' and then the order was synced to the server, it would incorrectly be saved as 'paid'. This could happen in a POS restaurant environment, for example, when releasing a table. As a result, empty orders would appear as paid, which is incorrect. This behavior was particularly problematic in certain localizations where such empty, paid orders lacked required fiscal data, leading to errors during session closing. opw-4714877 ---

Before this commit, if the state of an order was set to 'cancel' and then the order was synced to the server, it would incorrectly be saved as 'paid'. This could happen in a POS restaurant environment, for example, when releasing a table. As a result, empty orders would appear as paid, which is incorrect.

This behavior was particularly problematic in certain localizations where such empty, paid orders lacked required fiscal data, leading to errors during session closing.

opw-4714877

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#205334

Description of the issue/feature this PR addresses: modified labels are not sent to the ETA Current behavior before PR: -> change an invoice line label -> post the invoice -> send to ETA -> only product name is sent to the ETA Desired behavior after PR is merged: -> change an invoice line label -> post the invoice -> send to ETA -> line label is sent to the ETA this is based on this pr: https://github.com/odoo/odoo/pull/200907 --- I confirm I have signed the CLA and read the PR

Description of the issue/feature this PR addresses:
modified labels are not sent to the ETA
Current behavior before PR:
-> change an invoice line label
-> post the invoice
-> send to ETA
-> only product name is sent to the ETA
Desired behavior after PR is merged:
-> change an invoice line label
-> post the invoice
-> send to ETA
-> line label is sent to the ETA

this is based on this pr: https://github.com/odoo/odoo/pull/200907

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#203275

…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre

…ds) account move line text, based on pos orders

**Description of the issue/feature this PR addresses:**

During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable.

**Current behavior before PR:**

![image](https://github.com/user-attachments/assets/f6745f54-ee75-4fc8-9070-4e1c65eba709)


**Desired behavior after PR is merged:**

Text can be translated.
+ french translation added.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#202727
Forward-Port-Of: odoo/odoo#174511

Problem: When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call: request.env[fields['res_model']] .browse(fields['res_id']) .check_access_rights('write') Solution: Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does: fields['res_id'] = fields.get('res_id') or 0 Steps to re

Problem:
When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call:

    request.env[fields['res_model']]
        .browse(fields['res_id'])
        .check_access_rights('write')

Solution:
Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does:

    fields['res_id'] = fields.get('res_id') or 0

Steps to reproduce:
1. Go to "Email Marketing" > "New".
2. Fill in the "Subject" and choose a mailing list.
3. In the mail body, insert a template containing an image.
4. Click on the image and replace it.
5. Save (only at this step). → Traceback occurs since `modify_image` is called with a `None` res_id.

opw-4715999

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#206092
Forward-Port-Of: odoo/odoo#205838

Problem --------- As of Jan 01, 2025 the Romanian tax authority will accept blank tax IDs for recipient individuals of an e-invoice in the form "0000000000000".  However, in Odoo a blank tax id number for an individual contact is denoted as '/'. Objective --------- When creating the Invoice XML, if the res.partner has an empty Tax ID, or a tax ID that is "/" or <2 characters, replace the value by  0000000000000 in the produced XML. task-4610149 --- I confirm I have signed the CLA a

Problem
---------
As of Jan 01, 2025 the Romanian tax authority will accept blank tax IDs for recipient individuals of an e-invoice in the form "0000000000000".  However, in Odoo a blank tax id number for an individual contact is denoted as '/'.

Objective
---------
When creating the Invoice XML, if the res.partner has an empty Tax ID, or a tax ID that is "/" or <2 characters, replace the value by  0000000000000 in the produced XML.

task-4610149

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#205704
Forward-Port-Of: odoo/odoo#200977

There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now, - if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change); - if it is made to a non-company customer, then we send to the new endpoint. task-4645442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205867 Forward-Port-Of: odoo/odoo#203743

There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now,
- if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change);
- if it is made to a non-company customer, then we send to the new endpoint.

task-4645442

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#205867
Forward-Port-Of: odoo/odoo#203743

**Current behavior before PR:** - Clicking at the start of a link which has some format applied on it would trigger a traceback error. **Desired behavior after PR is merged:** - Now, Clicking at the start of the formatted link will now correctly display the cursor before the link. task:4699778 Forward-Port-Of: odoo/odoo#204768

**Current behavior before PR:**

- Clicking at the start of a link which has some format applied on it would trigger a traceback error.

**Desired behavior after PR is merged:**

- Now, Clicking at the start of the formatted link will now correctly display the cursor before the link.

task:4699778

Forward-Port-Of: odoo/odoo#204768

Steps to reproduce: - Drag and drop image gallery snippet. - Delete the snippet. - Click on Undo. - The snippet appears but images will not be there. The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted. task-4690318 Forward-Port-Of: odoo/odoo#206019

Steps to reproduce:

- Drag and drop image gallery snippet.
- Delete the snippet.
- Click on Undo.
- The snippet appears but images will not be there.

The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted.

task-4690318

Forward-Port-Of: odoo/odoo#206019

Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`. Steps to reproduce: - make a livechat with visitor with `crh-Latn` locale - as livechat operator, attempt to translate the message This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Langu

Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`.

Steps to reproduce:
- make a livechat with visitor with `crh-Latn` locale
- as livechat operator, attempt to translate the message

This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Language on April 4th [1], very recently from the date of this commit.

Because of the recency of the new locale, babel lack its parsing. Failure lead to error `UnknownLocaleError`, which is a problem because data of translated message also passes the Language name, which requires the good parsing of the locale by babel.

This commit fixes the issue by displaying the language name as the locale code in case babel was unable to parse it. In practice this happens rarely, and there's incentive to update babel as quickly as possible, but that's not a reason to display the translated message even if it cannot deduce the lang name.

[1]: https://babel.ua/en/news/116901-ukraine-approves-new-crimean-tatar-orthography-based-on-latin-script

Forward-Port-Of: odoo/odoo#205943

Fix some issues related to the comment composer in portal chatter. task-4715576 Forward-Port-Of: odoo/odoo#205939

Fix some issues related to the comment composer in portal chatter.

task-4715576

Forward-Port-Of: odoo/odoo#205939

Before this commit: - No `I` button was displayed on configuring combo products Following this commit: - The `I` button is made visible when configuring combo products. task-4654063 Forward-Port-Of: odoo/odoo#203210

Before this commit:
- No `I` button was displayed on configuring combo products

Following this commit:
- The `I` button is made visible when configuring combo products.

task-4654063

Forward-Port-Of: odoo/odoo#203210

Revealed by the changes to single app tests (which now test every module). While at it, remove a few unnecessary setting of product-id on non-variant scenarios, they don't blow up but they look a lot like odoo/odoo#206050 and why bother? https://runbot.odoo.com/odoo/error/163244 Forward-Port-Of: odoo/odoo#206053

Revealed by the changes to single app tests (which now test every module).

While at it, remove a few unnecessary setting of product-id on non-variant scenarios, they don't blow up but they look a lot like odoo/odoo#206050 and why bother?

https://runbot.odoo.com/odoo/error/163244

Forward-Port-Of: odoo/odoo#206053

…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204630

…simplfied

When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default.

If it is wrong, the user can still change it.

opw-4633564

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#204630

The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435

The SP-API doesn't support SKU containing commas, not even when escaping
and listing them in a correct CSV like string, as they'll be considered
as either separate SKU or a different one, thus leading to an error
saying there are too many identifiers, or not recognizing them anyway.
In order to let the synchronization continue for the other items, ensure
their SKU are valid beforehand.

As from Amazon side, using a comma is a valid value, we can't constrain
the SKU either.

opw-4710435

Forward-Port-Of: odoo/enterprise#83367

**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the

**Problem:**
When doing a scrap from the barcode app, the source location field is not accessible.
The default source location of the scrap will be the one of the stock move, this could be a problem
if the product is located in a child location.
For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order
will be from WH/Stock to WH/Output (default pick values).
In the barcode app, if doing a scrap from this picking, the source location will be WH/stock and the client will not be able
to change that because the field does not appear.

**Steps to reproduce:**
- From the inventory app dashboard select "internal transfer"
- Create a new internal transfer
- Enter a storable product
- Set a demand quantity
- Click on "Mark as Todo"
- Open the barcode app
- Click on operations
- Select "Internal Operations"
- Select the transfer you just created
- Click on the gear icon on the top right and select "scrap"

**Current Behavior:**
The source location field is not visible

**Expected Behavior:**
The source location field should be visible and editable

**Cause of the issue:**
The source location field is not in the view
https://github.com/odoo/enterprise/blob/a9334bb551606d0151d8fc7a8f3393c3a6e312b9/stock_barcode/views/stock_scrap_views.xml#L68

**Fix:**
I added the source location field in the view

opw-4489401

Forward-Port-Of: odoo/enterprise#82174

### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open the shopfloor > Register By-Product > generate serial numbers > input SN0012 > Generate > Save #### > your input was not taken into account, not lot was created. ### Cause of the issue: Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_d

### Steps to reproduce:

- In the settings enable by products.
- Create two products FP and SN where SN is tracked by serial numbers
- Create and confirm an MO for FP where SN is a by product
- Open the shopfloor > Register By-Product > generate serial numbers
  > input SN0012 > Generate > Save
#### > your input was not taken into account, not lot was created.

### Cause of the issue:

Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_dialog`. Clicking on Generate will then call the `_onGenerate` method and an rpc call of the
`action_generate_lot_line_vals` will be made:
https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/lots_dialog.xml#L12 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/generate_serial.js#L34
However, if you triggered these actions from the shopfloor, you never provided a `default_picking_type_id` in the context so that the lot will never be created by any mean:
https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L919-L927 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L945-L948

opw-4544734

Forward-Port-Of: odoo/enterprise#82355

STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatte

STEPS
------------
0. You'll require IAP credit for PDF extraction
1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company
2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product
3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1
4. Create a bill and use the Auto-Complete field to manually select PO-1
5. Drag and drop INV-1 in the chatter -> IAP should trigger -> The chatter says
'''
The invoice already contains lines, it was not updated from the attachment.

'''
but yet, it updated the purchase reference to PO-2 and updated the lines

OBJECTIVE
------------
If a bill has lines, it should not be updated with the content of the PO.

task-4633298

Forward-Port-Of: odoo/enterprise#83336
Forward-Port-Of: odoo/enterprise#83246

**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-i

**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Go to "Settings / Technical / Database Structure / Decimal Accuracy"
- Set 4 digits for "Product Price"
- Create a product with a lower price than 0.01 (e.g. 0.0045)
- Create an invoice:
  * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.)
  * Product: [the created product]
  * Quantity: 100
- Confirm the invoice
- Process the invoice by the E-invoicing service

**Issue:**
An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free.
But in this case, it is not free.

**Cause:**
"PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price.
As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True.

**Solution:**
Compute "PriceTypeCode" from the line subtotal instead of the unit price.
This is not perfect as it can also be lower than 0.01, but it's less probable.

opw-4608671

Forward-Port-Of: odoo/enterprise#83401
Forward-Port-Of: odoo/enterprise#82019

https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current us

https://runbot.odoo.com/odoo/error/163099

This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps.

The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if:

- The current user is the employee's, which is not the case because the employee doesn't have a user.
- Or the current user is the employee's leave manager, which is also not the case because the employee does not have a leaves manager.

As a result the creation of the leaves fails immediately.

Fix in 17.4 as the test was introduced in #53940 which was merged in (what would become) 17.3, even though the test setup means it might not be possible to trigger there because of all the demo messing with groups.

Forward-Port-Of: odoo/enterprise#83427