Manufacturing backorders now correctly keep available materials reserved for the production order they were meant for. This prevents stock from being incorrectly consumed or marked as used before the backorder is completed, improving reliability in manufacturing workflows.

Community-side fix for creating move lines instead of moves for
production backorders. This change ensures that product quantity
which was *intended* to be used by one production will rightly
get reserved by that production's backorder.

Additionally, we now use more care when marking moves as picked
because this field has an inverse which will mark all of the
move's move lines as consumed / done, despite them being
incomplete.

opw-4148050

A redundant internal selector option in the web testing tools was removed because it duplicated existing functionality. This keeps the codebase cleaner with no expected impact on business users or normal application behavior.

This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM.

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

**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *

**Steps to reproduce:**
- Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai
- Switch to a Spanish company (e.g. ES Company)
- Create an invoice for a Portugese customer:
  * Customer: [a Portugese customer]
  * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"]
- Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization"
- Confirm the invoice
- Process the invoice by E-invoicing service: TicketBAI (ES)
- Check the generated EDI document

**Issue:**
The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes.

opw-4034659




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

Forward-Port-Of: odoo/odoo#182730
Forward-Port-Of: odoo/odoo#179289

Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 42040

Steps to reproduce :
====
- Install pos_sale module.
- Create a quotation in sales and confirm it.
- Open Point of Sale
- Open Session and load orders from session.
- Select the quotation and do 50% down payment.
- Create new order and again load the same quotation.
- Due balance remains same.

Issue:
====
- Due balance is not updated, everytime it shows total amount.

Fix :
====
- Instead of total amount , amount unpaid is displayed which show correct due balance.

task- 4204048

Forward-Port-Of: odoo/odoo#181809

Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547

Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order.

Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... )

Original credits to `kerteszgergo`: odoo/odoo#108301

Forward-Port-Of: odoo/odoo#181547

**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corre

**Current behavior:**
Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory.

Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move.

**Expected behavior:**
The moves and their corresponding lines should be the inverse of those which are generated by this action when the product's on-hand quantity is positive.

**Steps to reproduce:**
1. Enable automatic accounting, create a stored product whose category has `FIFO` costing and `real_time` valuation

2. Create an in move for the product so it gets some cost assigned to it

3. Create an out move for more of the product than is currently in stock (so it's on-hand qty becomes negative)

4. Change the product category's `cost_method` to average/AVCO

5. Observe the journal items created by this action in the accounting application -> see that the stock valuation account is credited in both of the created moves

**Cause of the issue:**
The replenishing move's debiting/crediting accounts are currently adjusted if the associated SVL's quantity is non-positive, but the preceding emptying move's accounts are not. This results in the mismatch.

**Fix:**
Similarly adjust the emptying move accounts as was done to the replenishing move in commit: f7e3ada

opw-4127737

Forward-Port-Of: odoo/odoo#182304

Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182181 Forward-Port-

Steps to reproduce:
- have two companies A and B
- create a new partner
- create a new payment term for Company A
- In Company A, set the customer's payment term the newly created one
- Configure aliases for invoice in company A and B
- Make sure the default company for OdooBot is COmpany A
- Send an email to company B

Issue:
Access Error

Cause:
payment_term is pre-compute and the company context is the one of OdooBot

opw-4103229

Forward-Port-Of: odoo/odoo#182181
Forward-Port-Of: odoo/odoo#178829

[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries

[FIX] website: fix Facebook snippet
The goal of this commit is to solve three bugs introduced by [1].

The first one can be observed thanks to the `/website/demo/snippets`
page:
- Go on the `/website/demo/snippets` page.
- Try to enter in edit mode.

-> The system never enters in edit mode.

The problem is that the Facebook snippet on this page does not have the
`href` data attribute. Due to it, the public widget is started without
creating `this.resizeObserver`. When the user tries to enter in edit
mode, the `FacebookPageWidget` public widget is destroyed and the system
tries to disconnect `this.resizeObserver`. As it is not defined, the
system fails in the `destroy()` method.

Steps to reproduce the second bug:
- Add an "Image-Text" snippet on the website.
- Add a "Text-Image" snippet under the "Image-Text" one.
- Save and edit.
- Drop a "Facebook" snippet on the "Image-Text" snippet.
- Move the "Facebook" snippet on the "Text-Image" snippet.
- Click on the undo button.

-> Two iframes are on the Facebook snippet.

The problem is that since [1], the editor observer is not deactivated
when removing the iframe in the `destroy()` method of the
`FacebookPageWidget` widget.

Finally, this commit also adds back the `frameborder` and
`allowTransparency` attributes on the iframe (removed due to [1]) and
sets the width and height in the style attribute. Although the
`frameborder` and `allowTransparency` attributes are deprecated, this
commit adds them back in case a potential customization relies on it.

[1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25

task-4220972

Forward-Port-Of: odoo/odoo#182810
Forward-Port-Of: odoo/odoo#182134

This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719

This commit will change the name of some account group.

task:4186654




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

Forward-Port-Of: odoo/odoo#180719

The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032

The Issue:
Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one.

The Fix:
Pass the correct website within the context

runbot-54617

Forward-Port-Of: odoo/odoo#177598
Forward-Port-Of: odoo/odoo#176032

On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767

On the IoT box, translations are not supported as
there is no language context and no po/pot files.
However, there were still some usages of the `_`
function which will now log a warning in version
18.0+.

In this PR we simply remove the usages of `_`, as
it was not translating anyway and removes the
warnings.

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

Forward-Port-Of: odoo/odoo#182767

In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821

In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance.

However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change.

With this commit, we don't raise if the code doesn't actually change.

Back-port of #181234

task-4192627

Forward-Port-Of: odoo/odoo#182821

Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but afte

Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b

Steps to reproduce the issue:
=============================
- Create a new mass mailing
- Add cover snippet
- Test the email
- Background image doesn't appear

Origin of the issue:
====================
After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but after the `inline` process of the template we convert rgba colors to hex color with `rgbToHex` because some email engines doesn't support rgba. As a result, we will have a black div that covers the background image in the sent email.

Solution:
=========
Rever the change.

task-4070400

Forward-Port-Of: odoo/odoo#177174

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182743 Forward-Port-Of: odoo/odoo#180758

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye.
So, its name needed to be changed in its Odoo modules.
Moreover, updated Turkish modules descriptions according to this excalidraw:
https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true

task-4182931





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

Forward-Port-Of: odoo/odoo#182743
Forward-Port-Of: odoo/odoo#180758

odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173

odoo/enterprise#69056

Forward-Port-Of: odoo/odoo#178173

### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons - **Validity**: Today's date for example - Conditional rule with a **Minimum Purchase** of 0.00 - Start a new POS session. Add a product and click **Payment**. - **Validate** the order. - In the receipt shown, notice how the text show **_'Valid until: no expiration'_** althoug

### Steps to reproduce:
- Install **pos_loyalty** module
- Go to **Point of Sale** app > **Products** > **Discount & Loyalty**
- Create a **New** program with: 
    - **Program Type**: Next Order Coupons 
    - **Validity**: Today's date for example 
    - Conditional rule with a **Minimum Purchase** of 0.00
- Start a new POS session. Add a product and click **Payment**.
- **Validate** the order.
- In the receipt shown, notice how the text show **_'Valid until: no expiration'_** although a Validity date is defined!

### Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78

opw-3838427

Forward-Port-Of: odoo/odoo#170295
Forward-Port-Of: odoo/odoo#160633