This fix removes an unnecessary setting from the portal's “Skip to content” link. It helps keep keyboard navigation predictable for users and avoids conflicts with other page elements, supporting accessibility compliance.

Commit [17e55872] added a "Skip to content" link for general accessibility concerns on the website (namely: make it possible to skip the menu links for people who browse the page with tab and for people who use assistive tools - which is a level A requirement, see [WCAG documentation]).
However, the `tabindex` on it is not needed as the link is added at the top of the DOM, and is therefore the first focused element by default. It can also conflict with other focusable elements on the page if different tabindex are set on those.

[17e55872]: https://github.com/odoo/odoo/commit/17e5587275f6b8ece9004993a7642394dfcdfef6
[WCAG documentation]: https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks.html

task-4176181

The barcode module now includes a required alias in regular setup data instead of demo-only data. This helps databases created without demo content work correctly for the scale-up scenario while keeping the change limited and temporary.

commit [1] introduce alias to handle scale up game but scale up ask to create a database without demo. So we move the alias to data. It's far from optimal but it's the cleaner temporary solution

[1] commit cfe4829be00c77935555d506d86f0f14618fd21f

The update prevents product barcode lookups from crashing when an image request returns an unexpected error response. Users can continue creating or updating products from barcode data without seeing an Odoo error for affected items.

Step to reproduce:
1. Setup barcodelookup
2. Try with 7501030682332

Error: an Odoo Error is displayed "AttributeError: 'dict' object has
no attribute 'content'"

Getting the image leads to a 418 response and in such case, we
return a dict with few informations
https://github.com/odoo/enterprise/blob/abcffc2744f9867fc63bb4e658fcfc1c9cba573f/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25
but the current code considers that the response will always have be
a `Response` object with a content:
https://github.com/odoo/enterprise/blob/9319cfa788033bda7a0be084075c6dd2fd82e8ac/product_barcodelookup/models/product_template.py#L44-L46

sentry-5790228190

A click action that was unintentionally applied too broadly in the data cleanup model view has been moved to the correct specific view. This prevents users from seeing unexpected behavior when working with model records, keeping navigation and actions consistent.

Since #64854 view_model_tree inherited an action on click that was meant only for a specific view this action has been moved to a primary inherited view.

Related to task-id: 3861100

backport of odoo/enterprise#68107

Problem: The account tax report was displaying "Matla" instead of "Malta" Purpose: Fix the type to stay consistent with naming conventions opw-4134520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178110

Problem: The account tax report was displaying "Matla" instead of "Malta"

Purpose: Fix the type to stay consistent with naming conventions 

opw-4134520




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

Forward-Port-Of: odoo/odoo#178110

When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), testing to listen to imbus should be skipped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178986

When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), testing to listen to imbus should be skipped

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

Forward-Port-Of: odoo/odoo#178986

### Steps to reproduce: - In the settings: - Change the Barcode Nomenclature to Default gs1 - Enable Promotions, Coupons, ... on Point of sale - Create a prodcut with barcode 95412427100283 - Point of Sale > Product > Discount & Loyalty - Create a new discount and change the conditional rule to set your product and a min purchase of 0 - Open a new pos session - Scan the gs1 barcode 0195412427100283 #### > the product is found but the discount is not applied ### Expected behav

### Steps to reproduce:

- In the settings:
  - Change the Barcode Nomenclature to Default gs1
  - Enable Promotions, Coupons, ... on Point of sale
- Create a prodcut with barcode 95412427100283
- Point of Sale > Product > Discount & Loyalty
- Create a new discount and change the conditional rule to set your product and a min purchase of 0
- Open a new pos session
- Scan the gs1 barcode 0195412427100283

#### > the product is found but the discount is not applied

### Expected behavior:

Just as if you scanned the barcode 95412427100283 directly the discount should be applied.

Cause of the issue:

When a barcode is scanned in the pos, the ` _scan` method is called to parse the barcode and to trigger the associated action:
https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/point_of_sale/static/src/app/barcode/barcode_reader_service.js#L69-L79
This flow use to not update the rewards after a product scanned and was fixed by commit 21392ab when the barcode associated action is `_barcodeProductAction` because fo these lines:
https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/pos_loyalty/static/src/overrides/components/product_screen/product_screen.js#L105-L107 however, if the code is identified to be gs1
Howecver, if the barcode is identified to be of the gs1 nomenclature it will trigger the `_barcodeGS1Action` which still does not update the rewards.

### Fix:

Inspired by commit 21392ab

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

Forward-Port-Of: odoo/odoo#179543
Forward-Port-Of: odoo/odoo#178600

**Current behavior:** Having some product with FIFO cost method, if you use it as a component in an MO, confirm and produce all, then unlock the MO and adjust the component quantity to be smaller than originally entered, the standard price of the product will be set to zero. **Expected behavior:** This operation should not affect the standard price of the product. **Steps to reproduce:** 1. Create a product with FIFO cost method and real time valuation 2. Create a purchase

**Current behavior:**
Having some product with FIFO cost method, if you use it as a
component in an MO, confirm and produce all, then unlock the MO
and adjust the component quantity to be smaller than originally
entered, the standard price of the product will be set to zero.

**Expected behavior:**
This operation should not affect the standard price of the
product.

**Steps to reproduce:**
1. Create a product with FIFO cost method and real time
     valuation

2. Create a purchase order for 10 of the fifo product, set the
     price unit on the order line to 100

3. Confirm the order and receive the product

4. Create a manufacturing order for 1 of some other product, and
     set the components to be 100 of the fifo product

5. Confirm the MO, consume the fifo product and produce all

6. Unlock the order and set the quantity of components consumed
     to 1 (from 100)

7. Observe that the standard price of fifo product is now 0

**Cause of the issue:**
A move for an MrpProduction record has a price unit == 0. Commit
https://github.com/odoo/odoo/commit/1fb4d356b5115a82dbbb004efe2e26917021b339 forces use of this when a move's picking type is
manufacturing, however it should be a narrower condition to only
do so when the move corresponds to the finished moves of a
manufacturing order.

**Fix:**
Moves for components of a production should not be able to
modify the `standard_price` of the moved product- only the final
product's cost should be able to change based on the value of
such a move.

Use a product's `standard_price` field when creating SVLs for
moves corresponding to raw production moves.

opw-4134037

Forward-Port-Of: odoo/odoo#178015

### Steps to reproduce: - Go to Inventory > Configutation > Products > Barcode Nomenclatures - Click on Default Nomenclature > Add a line with the invalid barcode Pattern: "****" and put that one on the top of the list - Open a POS session > click on the list icon on the right corner - Debug window > enter any barcode and scan #### > Odoo Error: Invalid regular expression "****" ### Cause of the issue: The pattern field of the barcode.rule model that we created does not lead to a

### Steps to reproduce:

- Go to Inventory > Configutation > Products > Barcode Nomenclatures
- Click on Default Nomenclature > Add a line with the invalid barcode Pattern: "****" and  put that one on the top of the list
- Open a POS session > click on the list icon on the right corner
- Debug window > enter any barcode and scan

#### > Odoo Error: Invalid regular expression "****"

### Cause of the issue:

The pattern field of the barcode.rule model that we created does not lead to a valid regular expression but is used as such by the String.match calls done in the "barcode_parser":
https://github.com/odoo/odoo/blob/28871371c39bcc164e167842cf7212ce05f49a51/addons/barcodes/static/src/js/barcode_parser.js#L124-L130

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

Forward-Port-Of: odoo/odoo#179473
Forward-Port-Of: odoo/odoo#178096

When an invoice is linked to a sale order or more, the ReceiverTransactionReference tag should be included in the Factura-E XML per invoice line with the value of the Customer Reference field of the Sale Order linked to that line. This commit handles this. task-4134422 Forward-Port-Of: odoo/odoo#178360

When an invoice is linked to a sale order or more, the
ReceiverTransactionReference tag should be included in the Factura-E XML per invoice line with the value of the Customer Reference field of the Sale Order linked to that line. This commit handles this.

task-4134422

Forward-Port-Of: odoo/odoo#178360

**Current behavior:** Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship: When the orders and transfers are completed and the sale order is invoiced, the stock output and expense account on the invoice will have a credit and dedit (respectively) which is too high (the degree is proportional to the `product_qty` of each move in the dropship transfer). **Expected behavior:** The account entry lines should be a

**Current behavior:**
Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship:

When the orders and transfers are completed and the sale order is invoiced, the stock output and expense account on the invoice will have a credit and dedit (respectively) which is too high (the degree is proportional to the `product_qty` of each move in the dropship transfer).

**Expected behavior:**
The account entry lines should be accurate to the cost of the kit components.

**Steps to reproduce:**
1. Create a kit_product such that: - It has FIFO cost method and automated valuation - Has a component in a kit bom, also with FIFO and automated valuation as well as a vendor with non-zero price

2. Create a sale order for 2 of the kit product and set the SOL route to dropship

3. Confirm the sale order, purchase order, and validate the dropship transfer

4. Create an invoice for the sale order and confirm/post it

5. Observe that the stock output and expense accounts have a credit and debit (respectively) for 2x the correct amount

**Cause of the issue:**
The `product_qty` of each move in the dropship is errantly multiplied with the result of `_compute_average_price()`- this qty has already been taken into account.

**Fix:**
Remove this piece of the calculation.

opw-4050777

Forward-Port-Of: odoo/odoo#178976
Forward-Port-Of: odoo/odoo#176296

Steps to reproduce: --- 1. Install mass_mailing 2. Create a wrong outgoing mail server 3. ip 127.0.0.1 port 1234 4. Create a mailing list 5. Create a mailing list contact without name 6. Make the contact join the list 7. Create a mailing, set the new mailing list 8. Click on send > "1 email(s) not sent." 9. Open the mailing list contact 10. Traceback Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/5102328c3dd6e4e751ca8f906e7bd16e190fc386 `this.originThrea

Steps to reproduce:
---
1. Install mass_mailing
2. Create a wrong outgoing mail server
3. ip 127.0.0.1 port 1234
4. Create a mailing list
5. Create a mailing list contact without name
6. Make the contact join the list
7. Create a mailing, set the new mailing list
8. Click on send > "1 email(s) not sent."
9. Open the mailing list contact
10. Traceback

Cause of the issue:
---
Caused by: https://github.com/odoo/odoo/commit/5102328c3dd6e4e751ca8f906e7bd16e190fc386 
`this.originThread?.name` can be `False` instead of `Undefined`

opw-4054564

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

Forward-Port-Of: odoo/odoo#176964

Problem: When searching for a reference in contacts, the search checks for an exact match. However, the expected behavior is to use `ilike` to allow partial matches. Steps to reproduce: - Add a reference to any contact (e.g., crutest). - In the list of contacts, search for cru. - No contact will appear. opw-4133302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179678 Forward-Port-Of: odoo/odoo#177864

Problem: When searching for a reference in contacts, the search checks for an exact match. However, the expected behavior is to use `ilike` to allow partial matches.

Steps to reproduce:

- Add a reference to any contact (e.g., crutest).
- In the list of contacts, search for cru.
- No contact will appear.

opw-4133302

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

Forward-Port-Of: odoo/odoo#179678
Forward-Port-Of: odoo/odoo#177864

**Current behavior:** Creating an immediate transfer and attempting to allocate it for some existing document will not work- a valid document will not show up in the list of sources. **Expected behavior:** A source that logically matches the immediate transfer should be found for allocation. **Steps to reproduce:** 1. Enable the reception report setting 2. Create a delivery for some product and confirm it 3. Create a receipt transfer and create a move line (not move) for

**Current behavior:**
Creating an immediate transfer and attempting to allocate it for
some existing document will not work- a valid document will not
show up in the list of sources.

**Expected behavior:**
A source that logically matches the immediate transfer should
be found for allocation.

**Steps to reproduce:**
1. Enable the reception report setting

2. Create a delivery for some product and confirm it

3. Create a receipt transfer and create a move line (not move)
     for the same amount of the product in the delivery

4. Validate the picking, click the `Allocation` smart button ->
     See that the delivery is not listed

**Cause of the issue:**
After the quantity field changes on stock move/move lines, in
`ReceptionReport::_get_report_values()` a move that is created
for an immediate transfer will have a `product_qty == 0`. This
means it is never added as a dict key which is later used to
search for moves belonging to allocation sources.

**Fix:**
Use `move.quantity` when `move.product_qty == 0` to gather valid
out documents when creating the report data.

opw-4075871

Forward-Port-Of: odoo/odoo#177545

- install website_profile - open /profile/edit - BUG: see content overflow in mobile opw-4123897 Forward-Port-Of: odoo/odoo#179324

- install website_profile
- open /profile/edit
- BUG: see content overflow in mobile

opw-4123897

Forward-Port-Of: odoo/odoo#179324

Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the reward lines does not update. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Open Shop session * Select a customer that has plenty of loyalty points * Put any product in the order * Add the reward `Simple pen` (you'll havelike 230 of them) * Try changing the reward

Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the reward lines does not update.

Steps to reproduce:
-------------------
* Go to the **Point of sale** App
* Open Shop session
* Select a customer that has plenty of loyalty points
* Put any product in the order
* Add the reward `Simple pen` (you'll havelike 230 of them)
* Try changing the reward quantity to 1
> Observation: The quantity of the simple pen changes to 1 but the negative reward line still shows 230. Thus, the order can have a negative amount since 229 pens are still being deducted from the order even though they are not present.

Why the fix:
------------
This commit https://github.com/odoo/odoo/commit/de45ff3c9f23decdab176bc1511b3356d19844a8 passes the quantity and cost (in points) to the `_applyReward` function. This was done because when recomputing reward lines, if two lines came from the same reward, the quantity would be merged even though they would not apply on the same product.

In our case, this causes problems as we are using the function `_getRewardLineValuesProduct` to update the reward quantity but the quantity (230) is given as an argument and is then used as the quantity to set.
https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/pos_loyalty/static/src/overrides/models/loyalty.js#L1548-L1566

`args["quantity"] || freeQuantity` will always use `args["quantity"]` if given, bypassing the maximum quantity that is available to give.

`freeQuantity || args["quantity"]` will never use `args["quantity"]`.

Since we do not want to reward more than what is available, we add the arguments inside the `Math.min` function.

opw-4103833

Forward-Port-Of: odoo/odoo#179403
Forward-Port-Of: odoo/odoo#178805

### Steps to reproduce: - Create a fresh db with demo data - Activate the "stock_barcode" module - Activate the "point_of_sale" module #### > Error: operation cannot be completed ### Cause of the issue: Activating the "stock_barcode" module will create a second company. When you activate point of sale with the demo data, it will first install accounting and create a tax group for company 2 and then create the pos demo data: https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b

### Steps to reproduce:

- Create a fresh db with demo data
- Activate the "stock_barcode" module
- Activate the "point_of_sale" module
#### > Error: operation cannot be completed

### Cause of the issue:

Activating the "stock_barcode" module will create a second company. When you activate point of sale with the demo data, it will first install accounting and create a tax group for company 2 and then create the pos demo data:
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/point_of_sale/data/point_of_sale_demo.xml#L74-L78 However, during since no tax group is specified for this account.tax, it is expected to be computed here:
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L221-L222 But since no tax group was created for the current company, this computation will fail to give a result
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L232-L235 and the transaction will be aborted.

### Fix:

We create a tax group demo data that will be associated to the same company as the one for which our demo tax is created and hence provide a fall back value in case no other tax group was created.

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

Forward-Port-Of: odoo/odoo#178218

Category tags names are used directly as selectors. Adding spaces to the names leads to tracebacks. Reproduce --- - Install website_event - Create new event category with spaces in it - Open mobile view of all events - Select the category collapsible -> BUG opw-4009122 Forward-Port-Of: odoo/odoo#178850

Category tags names are used directly as selectors. Adding spaces to the names leads to tracebacks.

Reproduce
---
- Install website_event
- Create new event category with spaces in it
- Open mobile view of all events
- Select the category collapsible -> BUG

opw-4009122

Forward-Port-Of: odoo/odoo#178850

Allow to send UBL Bis 3 invoices using Peppol to Chorus Pro (B2G plaftorm in France). This requires to send the information contained in the already existing fields `buyer_reference`, `contract_reference`, `purchase_order_reference` in the Bis 3 xmls. task-4147787 opw-4139689 Forward-Port-Of: odoo/odoo#179500 Forward-Port-Of: odoo/odoo#178389

Allow to send UBL Bis 3 invoices using Peppol to Chorus Pro (B2G plaftorm in France).

This requires to send the information contained in the already existing fields `buyer_reference`, `contract_reference`,
`purchase_order_reference` in the Bis 3 xmls.

task-4147787
opw-4139689

Forward-Port-Of: odoo/odoo#179500
Forward-Port-Of: odoo/odoo#178389

IoT Box image build was failing due to missing `libffi-dev` pkg. In addition to that, the previously moved `odoo.conf` was inaccessible due to incorrect access rights. This commit fixes these two problems. Forward-Port-Of: odoo/odoo#179535

IoT Box image build was failing due to missing `libffi-dev` pkg. In addition to that, the previously moved `odoo.conf` was inaccessible due to incorrect access rights. This commit fixes these two problems.

Forward-Port-Of: odoo/odoo#179535

This commit fixes the error that was triggered when trying to assign a responsible user for a picking batch from the kanban view of batches. The error was thrown because the `user_id` field depends on `company_id` field in its domain, which was not existent in the kanban view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179419 Forward-Port-Of: odoo/odoo#179179

This commit fixes the error that was triggered when trying to assign a responsible user for a picking batch from the kanban view of batches. The error was thrown because the `user_id` field depends on `company_id` field in its domain, which was not existent in the kanban view.

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

Forward-Port-Of: odoo/odoo#179419
Forward-Port-Of: odoo/odoo#179179

Fixes the following issues: - When moving products to the 'Inter-company transit' location, products were effectively moved to the 'Customers' location instead. - ~Unable to see lots/serial numbers in locations having no company, such as the 'Customers' location.~ - Duplicate 'Lots/Serial numbers' field in the move details if both 'Create New' & 'Use Existing One' options are picked in the reception picking type. - ~'No operation made on this lot.' is always displayed in the traceability rep

Fixes the following issues:
- When moving products to the 'Inter-company transit' location, products were effectively moved to the 'Customers' location instead.
- ~Unable to see lots/serial numbers in locations having no company, such as the 'Customers' location.~
- Duplicate 'Lots/Serial numbers' field in the move details if both 'Create New' & 'Use Existing One' options are picked in the reception picking type.
- ~'No operation made on this lot.' is always displayed in the traceability report after a reload, requiring to leave then re-enter the report instead.~

More information on each issue in its corresponding commit.

task-3853055

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

Forward-Port-Of: odoo/odoo#167235

Specification: When creating a percent pie widget in the list view using Studio, the field's name has been added after percent pie, which is not user-friendly. Expected behavior: The duplicate label should not be visible in the list view. Task-3942207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179102

Specification:
When creating a percent pie widget in the list view using Studio, the field's name has been added after percent pie, which is not user-friendly.

Expected behavior:
The duplicate label should not be visible in the list view.

Task-3942207

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

Forward-Port-Of: odoo/odoo#179102

Scenario: - install im_livechat - create a new user with a user that has base.group_erp_manager (Administration > Access Rights) => Access Error because user doesn't have write access to res.users.settings record. Why: res.users.settings model requires base.group_system to be able to write on records of other users, but the res.users method _inverse_livechat_username and _inverse_livechat_lang_ids are writing on it with current users. Fix: Use the return value of `res.users.settings()

Scenario:

- install im_livechat
- create a new user with a user that has base.group_erp_manager
  (Administration > Access Rights)

=> Access Error because user doesn't have write access to
   res.users.settings record.

Why:

res.users.settings model requires base.group_system to be able to write
on records of other users, but the res.users method _inverse_livechat_username
and _inverse_livechat_lang_ids are writing on it with current users.

Fix:

Use the return value of `res.users.settings()._find_or_create_for_user` for
writing since they are returned in superuser mode.

opw-4157859

Forward-Port-Of: odoo/odoo#179412

…osting a batch of moves When we tried to confirm a batch of moves during the tax closing in a multi company setup with branches, an error was raised because the dependant closing moves should be posted before the parent move. This error was only catched in the `action_post` method but not on the modal that validates the batch. Original Commit: https://github.com/odoo/enterprise/pull/65645 opw-4148070 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi

…osting a batch of moves

When we tried to confirm a batch of moves during the tax closing in a multi company setup with branches, an error was raised because the dependant closing moves should be posted before the parent move.

This error was only catched in the `action_post` method but not on the modal that validates the batch.

Original Commit: https://github.com/odoo/enterprise/pull/65645

opw-4148070

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

Forward-Port-Of: odoo/odoo#179290
Forward-Port-Of: odoo/odoo#178601

The stepDelay argument in the l10n_co_edi_website_sale tour tests fails when loading the js for the tours https://runbot.odoo.com/web/#id=77298&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form Forward-Port-Of: odoo/enterprise#69732

The stepDelay argument in the l10n_co_edi_website_sale tour tests fails when loading the js for the tours https://runbot.odoo.com/web/#id=77298&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form

Forward-Port-Of: odoo/enterprise#69732

Current behaviour: --- Ivory Coast phone numbers aren't formatted correctly `0708151718 => 225708151718` Expected behaviour: --- `0708151718 => 2250708151718` National number leading zero should be preserved Steps to reproduce: --- ```py from ... import phone_validation as wa_phone_validation wa_phone_validation.wa_phone_format( record, number='0708151718', force_format="WHATSAPP", ) ``` Result => `'225708151718'` Should be => `'2250708151718'` NB: record has an

Current behaviour:
---
Ivory Coast phone numbers aren't formatted correctly 
`0708151718 => 225708151718`

Expected behaviour:
---
`0708151718 => 2250708151718`
National number leading zero should be preserved

Steps to reproduce:
---
```py
from ... import phone_validation as wa_phone_validation 
wa_phone_validation.wa_phone_format(
    record, number='0708151718',
    force_format="WHATSAPP",
)
```
Result => `'225708151718'`
Should be => `'2250708151718'`
NB: record has an Ivory Coast `country_id`

Cause of the issue:
---
`WHATSAPP format` is country_code + national_number
But because `national_number` is an `int`, the leading zero gets removed.

Fix:
---
See [phonenumbers/phonenumber.py](https://github.com/daviddrysdale/python-phonenumbers/blob/7f60158f325ed2ee14212b71ef7e7dc2ce5f01bb/python/phonenumbers/phonenumber.py#L124 )
The `italian_leading_zero` is set True when the national number starts with a zero, 
and it should be kept. (ie: Italian numbers) `number_of_leading_zeros` counts the zeros.
Taking those into account when formatting.

opw-3963124

Forward-Port-Of: odoo/enterprise#67132

The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637 Forward-Port-Of: odoo/enterprise#69409

The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name.

Task: 4163637

Forward-Port-Of: odoo/enterprise#69409

New module for electronic invoicing Forward-Port-Of: odoo/enterprise#69462 Forward-Port-Of: odoo/enterprise#51266

New module for electronic invoicing

Forward-Port-Of: odoo/enterprise#69462
Forward-Port-Of: odoo/enterprise#51266

Add tests for the community side changes in https://github.com/odoo/odoo/pull/167235, as these changes mostly impact inter-company transaction flows. task-3853055 Forward-Port-Of: odoo/enterprise#64078

Add tests for the community side changes in https://github.com/odoo/odoo/pull/167235, as these
changes mostly impact inter-company transaction flows.

task-3853055

Forward-Port-Of: odoo/enterprise#64078

Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is curren

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

Steps
-----
1. Enable Belgian localization;
2. create a public holiday;
3. have a contracted employee with CP200 salary structure;
4. make sure they get representation fees;
5. create a month-long maternity leave overlapping the holiday;
6. generate a payslip for that month.

Issue
-----
Employee receives representation fees, meant to compensate work expenses, despite not having worked that month.

Cause
-----
Representation fee calculation is currently based on "paid days" rather than days where the employee worked. As maternity leave is unpaid, the employee would normally not get representation fee, but because of the paid public holiday, the calculation continues as if the worker wasn't on leave.

Solution
--------
Check the `work_entry_type_id` of worked days, and skip representation fee calculation if all have `is_leave` set to `True`.

opw-3908980

Forward-Port-Of: odoo/enterprise#69742
Forward-Port-Of: odoo/enterprise#68462

Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller Task-3819134 Forward-Port-Of: odoo/enterprise#69676 Forward-Port-Of: o

Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore

replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller

Task-3819134

Forward-Port-Of: odoo/enterprise#69676
Forward-Port-Of: odoo/enterprise#59226

We need TaxClosingNonPostedDependingMovesError inside account because it is now also used there to catch it when confirming batch of moves. Forward-Port-Of: odoo/enterprise#69518 Forward-Port-Of: odoo/enterprise#69206

We need TaxClosingNonPostedDependingMovesError inside account because it is now also used there to catch it when confirming batch of moves.

Forward-Port-Of: odoo/enterprise#69518
Forward-Port-Of: odoo/enterprise#69206