**Current behavior:** In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category. **Expected behavior:** The attributes that do not have a positive count should disappear from the Search Panel. **Steps to reproduce:** 1. On a blank database, create two products:

**Current behavior:**
In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category.

**Expected behavior:**
The attributes that do not have a positive count should disappear from the Search Panel.

**Steps to reproduce:**
1. On a blank database, create two products: 
        1.1 Product A, with category CA and attributes A1 and A2.
        1.2 Product B, with category CB and attributes B1 and B2.
3. Go to Sales Order, create a new one and open the product catalog
4. The left search Panel should display the categories CA and CB, and the attributes A1, A2, B1, and B2.
5. Check the category CB.
6. Attributes A1 and A2 are still present.

**Cause of the issue:**
The search Panel JS script is modified by the `product` model, to add the Attributes section. However, the attributes are not filtered based on the selected category, and are always displayed.

**Fix:**
- Add a filtering condition in the `product` model to only display the attributes that have a positive `count`.

![all_category](https://github.com/user-attachments/assets/2121ecbb-9bed-4d3c-9f5f-c4cf309350ff)
![fix_difference](https://github.com/user-attachments/assets/612e0eeb-09c5-47eb-948f-8c8be204f862)

opw-4516166

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

Forward-Port-Of: odoo/odoo#197116

Versions -------- - 16.0+ Steps ----- 1. Set up a company located in United Arab Emirates; 2. go to Payment Providers / Stripe; 3. click the Connect Stripe button; Issue ----- > **Validation Error** > Stripe Proxy error: an error occurred while setting up your Stripe account. > Stripe gave us the following information: 'individual' is not a supported business type in the country AE. Cause ----- The initial payload sent to Stripe to connect in live mode is with `business_type

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

Steps
-----
1. Set up a company located in United Arab Emirates;
2. go to Payment Providers / Stripe;
3. click the Connect Stripe button;

Issue
-----
> **Validation Error**
> Stripe Proxy error: an error occurred while setting up your Stripe account.
> Stripe gave us the following information: 'individual' is not a supported business type in the country AE.

Cause
-----
The initial payload sent to Stripe to connect in live mode is with `business_type: individual`. This default works for most locales, but for some, e.g. `l10n_ae`, a "registered business" is required.

Solution
--------
Connect to Stripe using `business_type: company`.

This value can still be changed later _after_ entering live mode via `connect.stripe.com`.

opw-4545565

Forward-Port-Of: odoo/odoo#197367
Forward-Port-Of: odoo/odoo#197222

Before the user could add a product when in-store delivery method was activated even if the product was not available for any delivery. Now, we will check free quantities before adding. opw-4479075 Forward-Port-Of: odoo/odoo#195033

Before the user could add a product when in-store delivery method was
activated even if the product was not available for any delivery. Now,
we will check free quantities before adding.

opw-4479075

Forward-Port-Of: odoo/odoo#195033

Before this PR: Placeholder for empty char/text fields were disappearing in editor. <br> Steps to reproduce: 1. Open any appointment page with an operator assigned. 2. Go into edit mode. 3. The field with the placeholder "Add a function here..." will disappear. > Similar issue can be seen for any char/text field types. <br> The issue occurs after the https://github.com/odoo/odoo/pull/165197 update, which uses the fillEmpty utility function to add: - \<br> in empty **block** fields

Before this PR:
Placeholder for empty char/text fields were disappearing in editor.
<br>

Steps to reproduce:
1. Open any appointment page with an operator assigned.
2. Go into edit mode.
3. The field with the placeholder "Add a function here..." will disappear.
> Similar issue can be seen for any char/text field types.
<br>

The issue occurs after the https://github.com/odoo/odoo/pull/165197 update, which uses the fillEmpty utility function to add:
- \<br> in empty **block** fields (char/text)
- and Zero Width Space (ZWS) in empty **inline** fields (char/text)

Since placeholders for fields are added via SCSS targeting empty fields, the char/text fields are no longer considered empty due to the \<br> tag and ZWS. As a result, placeholders are not displayed.
<br>

This fix ensures that the SCSS now applies the same styling to fields if they are empty, contain only a \<br> tag, or contain only ZWS.

Additionally, the value for `data-oe-zws-empty-inline` attribute is now updated dynamically, enabling CSS to target fields with only ZWS content, as ZWS cannot be selected directly from CSS.
<br>

task-4297507

Forward-Port-Of: odoo/odoo#187892

Before it was possible to click on "load order" button even when there was no selected order. This commit disables the button when there is no selected order. taskId: 4562723 Forward-Port-Of: odoo/odoo#197206

Before it was possible to click on "load order" button even when there was no selected order. This commit disables the button when there is no selected order.

taskId: 4562723

Forward-Port-Of: odoo/odoo#197206

Previously, the company check on a relational field was ensuring that at least one of the related records had a compatible company. This worked fine for many2one fields, which have a single related record, but not for one2many and many2many fields, which can have multiple related records (only one of them needed to have a compatible company for the check to succeed). This fix rewrites the company check to ensure that none of the related records have an incompatible company. Forward-Port-Of:

Previously, the company check on a relational field was ensuring that at least one of the related records had a compatible company. This worked fine for many2one fields, which have a single related record, but not for one2many and many2many fields, which can have multiple related records (only one of them needed to have a compatible company for the check to succeed).

This fix rewrites the company check to ensure that none of the related records have an incompatible company.

Forward-Port-Of: odoo/odoo#197349
Forward-Port-Of: odoo/odoo#189847

mail_template_dynamic_placeholder_tour is failing, as the delay between two steps is too small and dom is rendering right after clicking the dropdown. this pr fixes the issue. [failing runbot builds](https://runbot.odoo.com/odoo/action-573/111986) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195644

mail_template_dynamic_placeholder_tour is failing, as the
delay between two steps is too small and dom is rendering
right after clicking the dropdown. this pr fixes the issue.

[failing runbot builds](https://runbot.odoo.com/odoo/action-573/111986)

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

Forward-Port-Of: odoo/odoo#195644

Improve test coverage of the `website_sale_collect` and rework test commons in `website_sale_stock` module. task-4199783 Forward-Port-Of: odoo/odoo#186773

Improve test coverage of the `website_sale_collect` and rework test
commons in `website_sale_stock` module.

task-4199783

Forward-Port-Of: odoo/odoo#186773

Versions -------- - 17.0+ Steps ----- 1. Add 5+ lines to a product's eCommerce description; 2. add this product to your wishlist; 3. open wishlist. Issue ----- The table's border is broken, left of the image. Cause ----- Commit 196f34c6b5271 added the Bootstrap classes `d-none d-md-block` to the table row, in order to hide the image on small devices. The `d-md-block` class cancels out its existing `align-middle` class, which only affects `inline` or `table-cell` elements, not

Versions
--------
- 17.0+

Steps
-----
1. Add 5+ lines to a product's eCommerce description;
2. add this product to your wishlist;
3. open wishlist.

Issue
-----
The table's border is broken, left of the image.

Cause
-----
Commit 196f34c6b5271 added the Bootstrap classes `d-none d-md-block` to the table row, in order to hide the image on small devices. The `d-md-block` class cancels out its existing `align-middle` class, which only affects `inline` or `table-cell` elements, not `block` elements. Consequently, the `vertical-align: middle` CSS rule is ignored, leaving the image unaligned on top of the table.

Solution
--------
Replace `d-md-block` with `d-md-table-cell`.

opw-4260090

Forward-Port-Of: odoo/odoo#197304

Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow. This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them. runbot-112694 runbot-112819 Forward-Port-Of: odoo/odoo#196986

Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow.

This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them.

runbot-112694
runbot-112819

Forward-Port-Of: odoo/odoo#196986

Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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#196833 Forward-Port

Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake.

runbot : 112119

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#196833
Forward-Port-Of: odoo/odoo#195457

Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer. Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode Some behaviors are left mysterious though. The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtml

Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer.

Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode

Some behaviors are left mysterious though.
The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtmltopdf actually makes a fetch request to that raw url with unspecified debug mode. The session being open, ir_qweb is in debug mode anyway, which makes that rpc rendering the main page in debug=assets. For some reason, probably time and memory, that call is responsible for hiding some parts of the report in PDF.

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#197322
Forward-Port-Of: odoo/odoo#196138

Automatically escape source terms and non-markup values passed to _t if at least one of the inserted values in a markup. This approach is believed to have the following benefits: - More XSS-proof - Any piece of HTML that needs to be inserted has to be wrapped in a call to markup. This will increase the number of lines requiring special attention that will be caught by the CI/security check. - Any part of the translated string that's not markup is escaped. - Better syntax -

Automatically escape source terms and non-markup values passed to _t if at least one of the inserted values in a markup.

This approach is believed to have the following benefits:

- More XSS-proof
    - Any piece of HTML that needs to be inserted has to be wrapped in a call to markup. This will increase the number of lines requiring special attention that will be caught by the CI/security check.
    - Any part of the translated string that's not markup is escaped.
- Better syntax
    - It eliminates the need for the sprintf function to insert markup into the safely escaped translated string, as well as the need for the escape function to escape the string itself and the interpolated non-markup values.
- API consistency (i.e. it matches the behavior of gettext with markups as it currently exists on the Python side)

```js
return markup(
    sprintf(escape(_t("Create %(value)s as a new %(field)s?")), {
        value: `<strong>${escape(this.props.value)}</strong>`,
        field: escape(this.props.name),
    })
);
```
```js
return _t("Create %(value)s as a new %(field)s?", {
    value: markup(`<strong>${escape(this.props.value)}</strong>`),
    field: this.props.name,
});
```

Task-4519529

Backport of odoo/odoo#195291
Related to https://github.com/odoo/enterprise/pull/78717

Forward-Port-Of: odoo/odoo#196805

When having other modules that depend on the module, if they make an inheritance of the method `_cart_update` like it is on the original method from module `website_sale` (with parameters and then `kwargs`) the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.  ![Website Loyalty error with PDB](https

When having other modules that depend on the module, if they make an inheritance of the method `_cart_update` like it is on the original method from module `website_sale` (with parameters and then `kwargs`) the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.

![Website Loyalty error](https://github.com/user-attachments/assets/ebe7a8dc-7b7c-4f11-8064-bcc7c24218bf)

![Website Loyalty error with PDB](https://github.com/user-attachments/assets/2bf85807-f230-4e65-9090-b6c1e390682e)


By inheriting the way the original method is set, it will avoid having to check on the `args` or `kwargs` for the `product_id` and `set_qty` values and use the parameters instead.

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

Forward-Port-Of: odoo/odoo#197290
Forward-Port-Of: odoo/odoo#197032

Issue: we you have a flex calendar the time off duration will depend on the attendance_ids even if they are hidden from the calendar view reporduce: create a new calendar and change the attendance before turing it into flex and then change the `hours_per_day`. then use this calendar on one of the employees and try to givce him a time off. the duration will be calculated based on the attendance you set before marking the calendar flex Solve: - update the `_get_durations` method to check if

Issue: we you have a flex calendar the time off duration will depend on the attendance_ids even if they are hidden from the calendar view

reporduce: create a new calendar and change the attendance before turing it into flex and then change the `hours_per_day`. then use this calendar on one of the employees and try to givce him a time off. the duration will be calculated based on the attendance you set before marking the calendar flex

Solve:
- update the `_get_durations` method to check if the calendar is flex and then use the `hours_per_day`

Notes:
this flex calendars does not have a weekdays and weekends so all the days that is selected in the leave would be counted

Task: 4535351


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

Forward-Port-Of: odoo/odoo#196011

When the vendor price is set in a different currency than main one in product's form, the PO triggered by the procurement is created in main currency. Steps to reproduce: - Activate foreign currency - Activate Route MTO - Have a product [PROD] configured with - [General Info tab] Product Type: Storable Product - [Purchase tab] Set a Vendor, a price, and foreign currency - [Inventory Tab] Routes Buy, MTO - Create a Sales Order with [PROD] and confirm it - Open the created Purchas

When the vendor price is set in a different currency than main one in product's form, the PO triggered by the procurement is created in main currency.

Steps to reproduce:
- Activate foreign currency
- Activate Route MTO
- Have a product [PROD] configured with
  - [General Info tab] Product Type: Storable Product
  - [Purchase tab] Set a Vendor, a price, and foreign currency
  - [Inventory Tab] Routes Buy, MTO
- Create a Sales Order with [PROD] and confirm it
- Open the created Purchase order

Issue: currency is in company currency and not the currency set in the product configuration

opw-4398597

Forward-Port-Of: odoo/odoo#197175
Forward-Port-Of: odoo/odoo#193005

Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `

Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence.

Steps to reproduce:
-------------------
* Install `l10n_fr`, `point_of_sale`, and `account_sepa`
* Switch to the `FR Company`
* In the **Invoicing** app, select **Configuration** > **Journals**
* Select the `Bank` journal
* Set proper IBAN account
* In **Outgoing Payments**, move `SEPA Credit Transfer` to the top
* In **Point of sale**, open pos shop
* Select any product, change the price or qty to be negative (or make a refund for an order with no customer)
* Select `Bank` payment method
* Validate
* Try closing session
> Observation: Closing session error: An error has occurred when trying to
close the sesion. You will be redirected to the back-end to manually close the session.
* In the backend, try to close the session
> Observation: To record payments with False, the recipient bank account
must be manually validated. You should go on the partner bank account in order to validate it.

Why the fix:
------------
The first payment_method_line will be used among the available payment method lines:
https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L461-L465 https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L470-L475

In the context of the point of sale, using SEPA CT in the context of refunds does not make too much sense. Indeed, in the pos a refund can be done on an order which is not related to a client. By definition, when using SEPA your are supposed to know the client and it bank account number.

We exclude the possibility of using SEPA CT when creating refund account payments coming from the Pos.

opw-4310781

Forward-Port-Of: odoo/odoo#196591
Forward-Port-Of: odoo/odoo#195784

Fix a race condition between two different event that can affect the opening of the link popover when triggered via the odoo shortcut bar. backport of #197287 runbot-115558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197345

Fix a race condition between two different event that can affect the opening of the link popover when triggered via the odoo shortcut bar.

backport of #197287

runbot-115558



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

Forward-Port-Of: odoo/odoo#197345

hen email provider rewrites message_id of odoo generated emails we lose trace of original message and/or trace in Odoo. Crafting references as already containing the original message_id ensure to keep a trace even if message_id is rewritten. Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated mail records. Task-3927616 Forward-Port-Of: odoo/odoo#197192 Forward-Port-Of: odoo/odoo#189195

hen email provider rewrites message_id of odoo generated emails
we lose trace of original message and/or trace in Odoo. Crafting
references as already containing the original message_id ensure to
keep a trace even if message_id is rewritten.

Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated
mail records.

Task-3927616

Forward-Port-Of: odoo/odoo#197192
Forward-Port-Of: odoo/odoo#189195

Version: 16.0 to master Browser: Firefox only Steps to Reproduce: 1. Open website in edit mode (In Desktop) 2. Open inspect element, switch to mobile view (Inspector mobile view) 3. Click burger menu to open 4. Traceback occurs Reason for Change: In Firefox, when the inspector's mobile view is used, it simulates touch events. Clicking the burger menu returns undefined, causing an error. This PR ensures that the page does not crash by handling the undefined case. task-398098

Version: 16.0 to master
Browser: Firefox only

Steps to Reproduce:
1. Open website in edit mode (In Desktop)
2. Open inspect element, switch to mobile view (Inspector mobile view)
3. Click burger menu to open
4. Traceback occurs

Reason for Change:
 In Firefox, when the inspector's mobile view is used, it simulates
 touch events. Clicking the burger menu returns undefined, causing an
 error. This PR ensures that the page does not crash by handling the
 undefined case.

task-3980983

Forward-Port-Of: odoo/odoo#173785

Steps to Reproduce: * Go to Website --> Edit Mode. * Drag and drop the form snippet. * Click inside the submit button such that the entire label "Submit" is selected. * Press the right arrow key. * The website will become unresponsive. **Changes made:** Assign `previousSelection` with the following properties: `anchorNode: selection.anchorNode` `anchorOffset: selection.anchorOffset` `focusNode: selection.focusNode` `focusOffset: selection.focusOffset` **Reason:**

Steps to Reproduce:

* Go to Website --> Edit Mode.
* Drag and drop the form snippet.
* Click inside the submit button such that the entire label "Submit" is
  selected.
* Press the right arrow key.
* The website will become unresponsive.


**Changes made:**

Assign `previousSelection` with the following properties:
 `anchorNode: selection.anchorNode`
 `anchorOffset: selection.anchorOffset`
 `focusNode: selection.focusNode`
 `focusOffset: selection.focusOffset`

**Reason:**

The original code attempted to spread the Selection object into previousSelection using **{...selection}**, which is incorrect since **the Selection object is not iterable**. As a result, `previousSelection` was never updated correctly, potentially causing the while loop to run indefinitely.

This fix manually extracts key properties—anchorNode, anchorOffset, focusNode, and focusOffset—from the Selection object and stores them in a plain object. This ensures that previousSelection updates properly, allowing the `hasSelectionChanged` function to function as expected.

By implementing this change, we prevent infinite loops and ensure accurate selection tracking, improving the stability and functionality of the text editor.

task-4471656

Forward-Port-Of: odoo/odoo#197010
Forward-Port-Of: odoo/odoo#194061

Fixes an issue that appeared during the forward port in 18. The way tax exemption was handled had to be changed, but it was not correctly handled and the info is missing at one place, causing the file to be wrongly generated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197167

Fixes an issue that appeared during the forward port in 18.
The way tax exemption was handled had to be changed, but it was not correctly handled and the info is
missing at one place, causing the file to be wrongly generated.

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

Forward-Port-Of: odoo/odoo#197167

Steps to reproduce: [l10n_de] - create an invoice - confirm the invoice - send the invoice - send the invoice again Issue: You will get an error "You cannot remove parts of the audit trail. Archive the record instead." Cause: We don't prevent entering the hook if there is already a generated pdf. During the hook, we want to "generate a Factur-X and embed it inside the PDF for inter-portability" https://github.com/odoo/odoo/blob/84a0b81a258262e3bb9dbaa9c9f37796303a9dad/addons/account

Steps to reproduce:
[l10n_de]
- create an invoice
- confirm the invoice
- send the invoice
- send the invoice again

Issue:
You will get an error "You cannot remove parts of the audit trail. Archive the record instead."

Cause:
We don't prevent entering the hook if there is already a generated pdf. During the hook, we want to "generate a Factur-X and embed it inside the PDF for inter-portability" https://github.com/odoo/odoo/blob/84a0b81a258262e3bb9dbaa9c9f37796303a9dad/addons/account_edi_ubl_cii/models/account_move_send.py#L124-L128

In the German loca, while trying to write on the attachment, we'll check that the move has not been already posted. In which case it will raise the error https://github.com/odoo/odoo/blob/5215428114842c606202e7b1c69f5f597a977f92/addons/l10n_de/models/ir_attachment.py#L13-L34

solution:
Prevent entering the hook if there is already a pdf as it is done a few lines before https://github.com/odoo/odoo/blob/9f65f1a3b0b6b893f230729c56f287f5aff6af35/addons/account/models/account_move_send.py#L607

opw-4471377

Forward-Port-Of: odoo/odoo#196746

The innerscrollbar of the attendance kiosk is not needed. removed the scrollbar task-4456820 Forward-Port-Of: odoo/odoo#192703

The innerscrollbar of the attendance kiosk is not needed. 
removed the scrollbar

task-4456820

Forward-Port-Of: odoo/odoo#192703

*: http_routing Since [1], the tel:// format was preferred over tel: due to reasons stated in [2]. However, the change in [2] was a workaround for a bug in the Python library used to parse URLs. According to the relevant RFC, the tel: protocol should not include double slashes. When clicking on a link like `tel://+112351221233` in a browser, a popup may appear attempting to handle the communication using `http://tel//+112351221233` as the browser does not recognize the tel protocol when do

*: http_routing

Since [1], the tel:// format was preferred over tel: due to reasons stated in [2]. However, the change in [2] was a workaround for a bug in the Python library used to parse URLs. According to the relevant RFC, the tel: protocol should not include double slashes.

When clicking on a link like `tel://+112351221233` in a browser, a popup may appear attempting to handle the communication using `http://tel//+112351221233` as the browser does not recognize the tel protocol when double slashes are included.

![image](https://github.com/user-attachments/assets/439daa46-d0d7-4ae7-8ad6-830bced02dad)

![image](https://github.com/user-attachments/assets/11b1be76-289b-4013-8115-fb518c314509)


This commit removes the unnecessary double slashes to comply with RFC recommendations and just add a trailing white space to be sure that the
url_parse method from werkzeug works properly.

[1]: https://github.com/odoo/odoo/commit/6d4a3b3ab5c0f3361d1d681d05b974e295dcbabe
[2]: https://github.com/odoo/odoo/commit/56ce29e71f75a657d4b518d86c1d7084891e898e

task-4331070

Forward-Port-Of: odoo/odoo#197276
Forward-Port-Of: odoo/odoo#190860

Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197043 Forward-Port-Of: odoo/odoo#194627

Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454

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

Forward-Port-Of: odoo/odoo#197043
Forward-Port-Of: odoo/odoo#194627

Some tests end with the selection in a link, leading the link popover to open, which blurs the editable element. To prevent that, we would focus the editable by force, then wait a tick. But when the CPU is slow, sometimes the focus into the link popover happens too late to redirect it. This waits for the popover to open before focusing the editable. runbot-112609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197201

Some tests end with the selection in a link, leading the link popover to open, which blurs the editable element. To prevent that, we would focus the editable by force, then wait a tick. But when the CPU is slow, sometimes the focus into the link popover happens too late to redirect it. This waits for the popover to open before focusing the editable.

runbot-112609

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

Forward-Port-Of: odoo/odoo#197201

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#197064 Forward-Port-Of: odoo/odoo#188309

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services

Task-4354482

Forward-Port-Of: odoo/odoo#197064
Forward-Port-Of: odoo/odoo#188309

Tremol USD device issues can be hard to investigate since we don't have access to all messages exchanged between the device and Odoo drivers. This PR adds logs for request and responses when the debug flag is enable on the proxy server installed on the user computer. opw-4453505 Forward-Port-Of: odoo/odoo#197218

Tremol USD device issues can be hard to investigate since we don't have access to all messages exchanged between the device and Odoo drivers.

This PR adds logs for request and responses when the debug flag is enable on the proxy server installed on the user computer.

opw-4453505

Forward-Port-Of: odoo/odoo#197218

## Versions: 17.0+ ## Issue: Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right. opw-4461450 Forward-Port-Of: odoo/enterprise#78116

## Versions:
17.0+

## Issue:
Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right.

opw-4461450

Forward-Port-Of: odoo/enterprise#78116

Before this PR: AEC file is sent encoded as base64. After this PR: we decode the file properly Forward-Port-Of: odoo/enterprise#79007

Before this PR: AEC file is sent encoded as base64.
After this PR: we decode the file properly

Forward-Port-Of: odoo/enterprise#79007

If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones. task-4557882 Forward

If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones.

task-4557882

Forward-Port-Of: odoo/enterprise#78800

**[FIX] account_online_synchronization: branch company failing to fetch bank's logos.** When a branch company is selected alone with a non admin user, the function `fetch_online_sync_favorite_institutions` fails due to an access error, when trying to access the original companies country code (which is not selected). To reproduce the issue: - Create a branch for a company with a bank journal that hasn't been set up. - Create new internal user with access to the new branch company as we

**[FIX] account_online_synchronization: branch company failing to fetch bank's logos.**

When a branch company is selected alone with a non admin user, the function `fetch_online_sync_favorite_institutions` fails due to an access error, when trying to access the original companies country code (which is not selected).

To reproduce the issue:

- Create a branch for a company with a bank journal that hasn't been set up.
- Create new internal user with access to the new branch company as well as the parent (origin of the journal)
- Login with the non admin user
- Choose soley the newly created branch in company selector
- Open invoicing

opw-4524368

Forward-Port-Of: odoo/enterprise#79073

In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of the alias 4. You are asked to configure servers again and you cannot set any value for the alias. Redirecting to the company settings is cumbersome and unlikely useful. Erp managers should be able to quick create here as in the company settings, as aliases are not company specific when

Commit 1:
[FIX] documents: fix showing alias fields on details panel

Reproduce:
1. Go to a folder on the kanban view
2. If not configured, configure Email Servers, then redo 1.
3. Clear the domain of the alias
4. You are asked to configure servers again and you cannot set
any value for the alias.

Redirecting to the company settings is cumbersome and unlikely
useful. Erp managers should be able to quick create here as in
the company settings, as aliases are not company specific when
receiving.

Technically, removing `load=False` on `documents_unique_folder_id`
(added when there is a `search_panel_default_folder_id` without
`no_documents_unique_folder_id` in context) is necessary to load
the existing `alias_domain_id`'s `display_name`.

Commit 2:

[FIX] documents: fix reloading only search panel

It is not necessary to reload the model when we
want to reload the search panel.

Commit 3: 

[FIX] documents: fix validation error on saving container

These records' methods are sometimes called when there is no point
(and don't work), because the record is not part of the view.

This can be seen for example when adding alias tags.


Commit 4: 

Reproduce:
As an internal user not documents manager,
open the details panel on a company root folder
with access_internal="edit".
The fields are not rendered as readonly as they should.

Test data updated in documents_spreadsheet.

Task-4543501

Forward-Port-Of: odoo/enterprise#78375

The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage. Task: 4465315 Forward-Port-Of: odoo/enterprise#78075

The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage.

Task: 4465315

Forward-Port-Of: odoo/enterprise#78075

Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505 Forward-Port-Of: odoo/enterprise#76735

Previously, the database view generated for the  meal vouchers
report in the Belgian localization didn't have an id which
caused an error on the runbot.

This commit fixes this issue by generating the id.

task-4463505

Forward-Port-Of: odoo/enterprise#76735

Forward-Port-Of: odoo/enterprise#79083

Forward-Port-Of: odoo/enterprise#79083

ADHOC ticket 85864 Forward-Port-Of: odoo/enterprise#76488

ADHOC ticket 85864

Forward-Port-Of: odoo/enterprise#76488

Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year. For example, if the fiscal year starts on the 1st of April (01/04), - in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024; - in spreadsheet, the 2024

Problem
---------
Currently, there is a discrepancy between the year filter in the reports and spreadsheet.

In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year.

For example, if the fiscal year starts on the 1st of April (01/04),
- in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024;
- in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025.

This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports.

Objective
---------
Make the report year filter behave like in spreadsheet.

Solution
---------
Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before.

opw-4493556

Forward-Port-Of: odoo/enterprise#78486

This commit fixes the following issues of the module l10n_cz_reports_2025: 1. The `tax_office_name` was changed to `name` but that change was dropped in _rec_names_search of the tax office. 2. The readonly attribute was duplicated in account move view. 3. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical). Forward-Port-Of: odoo/enterprise#78960

This commit fixes the following issues of the module l10n_cz_reports_2025:
1. The `tax_office_name` was changed to `name` but that change was dropped in _rec_names_search of the tax office.
2. The readonly attribute was duplicated in account move view.
3. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical).

Forward-Port-Of: odoo/enterprise#78960

Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled. This commit checks the feature is enabled before getting leaderboard data. task-4509858 Forward-Port-Of: odoo/enterprise#79060 Forward-Port-Of: odoo/enterprise#78858

Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled.

This commit checks the feature is enabled before getting leaderboard data.

task-4509858

Forward-Port-Of: odoo/enterprise#79060
Forward-Port-Of: odoo/enterprise#78858

Clarify owner on share panel: ============================ The panel must still indicate the owner (except for Odoobot) of the folder/document, when the partner list with access is empty. In addition, we don't want the owner to appear twice in this list, and there's no point in displaying his role. It may happen because someone sets the document's owner permission using the invitation member component of the panel. To avoid this, the owner can no longer be found from this component.

Clarify owner on share panel:
============================

The panel must still indicate the owner (except for Odoobot)
of the folder/document, when the partner list with access is empty.

In addition, we don't want the owner to appear twice in this list, and
there's no point in displaying his role. It may happen because someone
sets the document's owner permission using the invitation member component
of the panel. To avoid this, the owner can no longer be found from this
component.

Access to permission panel data:
===============================

As portals users can't use the share panel, access to the permission
panel data is restricted to internal users.

Editing permission expiration date:
==================================

We don't want users with limited read access to a document/folder to be
able to edit/remove their expiration date.

task-4527397

Forward-Port-Of: odoo/enterprise#78199

The transfer tip messages displayed at the top in the Barcode app were constructed with `<b>` markup in the OWL template. However, the translation extraction mechanism for OWL templates splits the template up per tag it encounters. So if you had a message like `Scan a <b>transfer</b>, a <b>product</b> ...`, it would extract the `, a` part separately. Moreover, if the final string didn't contain more than 1 alphanumerical character, it wouldn't be exported in the .pot file and thus not be tran

The transfer tip messages displayed at the top in the Barcode app were constructed with `<b>` markup in the OWL template. However, the translation extraction mechanism for OWL templates splits the template up per tag it encounters. So if you had a message like `Scan a <b>transfer</b>, a <b>product</b> ...`, it would extract the `, a` part separately.

Moreover, if the final string didn't contain more than 1 alphanumerical character, it wouldn't be exported in the .pot file and thus not be translatable.

Also, having these messages chopped up doesn't allow translators to change word order in other languages.

In this commit we safely construct the messages in Javascript and have them translated as one full sentence. After this, we show them in the OWL template.

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Related to https://github.com/odoo/odoo/pull/196805

Forward-Port-Of: odoo/enterprise#78717

To reproduce: (Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send" button one more level to the left, so that the button is always added, as it used to be) 1) Duplicate the Partner Ledger 2) Set the original Partner Ledger as the root report of the duplicate 3) Open the Partner Ledger, and select the duplicate in the variant selector ===> The "Send" button

To reproduce:
(Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send" button one more level to the left, so that the button is always added, as it used to be)

1) Duplicate the Partner Ledger
2) Set the original Partner Ledger as the root report of the duplicate 3) Open the Partner Ledger, and select the duplicate in the variant selector

===> The "Send" button is displayed twice on top of the report.

This is due to the fact the custom handler is first called by the report itself (since the duplicate kept the same handler as the root Partner Ledger), then by the call to super() made in the _custom_options_initializer.

In the case of the Partner Ledger, we could have removed that super call (since it's a root report), but we prefer a more generic and cleaner fix that just makes sure we don't reinitialize the same custom options if we notice the handler is the same.

opw-4506968

Forward-Port-Of: odoo/enterprise#79101

*: barcode, barcode_mrp This commit includes updates to and serial/lot number display features: - When the 'show sn/lot' feature is disabled for an operation type, unreserved serial/lot lines will no longer be highlighted with a red background. - The '/qty' demand field for sn/lot sublines is hidden when `Show Reserved SN/Lot` is disabled. Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998) Forward-Port-Of: odoo/enterprise#68153

*: barcode, barcode_mrp

This commit includes updates to and serial/lot number display
features:
- When the 'show sn/lot' feature is disabled for an operation type,
  unreserved serial/lot lines will no longer be highlighted with a
  red background.
- The '/qty' demand field for sn/lot sublines is hidden when
 `Show Reserved SN/Lot` is disabled.

Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998)

Forward-Port-Of: odoo/enterprise#68153

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces. [1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip [task-4373106](https://www.odoo.com/odoo/project.task/4373106) Forward-Port-Of: odoo/enterprise#78540

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces.

[1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip

[task-4373106](https://www.odoo.com/odoo/project.task/4373106)

Forward-Port-Of: odoo/enterprise#78540

Source: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-lemploi-plafonds-apres-indexation-05-02-2025 TaskID: 4558145 Forward-Port-Of: odoo/enterprise#79047

Source: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-lemploi-plafonds-apres-indexation-05-02-2025

TaskID: 4558145

Forward-Port-Of: odoo/enterprise#79047

[FIX] currency_rate_live: Fix BI service API calls failing. This fix adapts our request to the BI service's "unpublished changes" that require a user agent when making a request to their API. opw-4475353 Forward-Port-Of: odoo/enterprise#78362

[FIX] currency_rate_live: Fix BI service API calls failing.

This fix adapts our request to the BI service's "unpublished changes" that require a user agent when making a request to their API.

opw-4475353

Forward-Port-Of: odoo/enterprise#78362

ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#78885 Forward-Port-Of: odoo/enterprise#64454

ELM 5.0 Swissdec Certification

Forward-Port-Of: odoo/enterprise#78885
Forward-Port-Of: odoo/enterprise#64454

A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78927 Forward-Port-Of: odoo/enterprise#77991

A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). 

Followup for the Ri.Ba. task: odoo/enterprise#74097
Documentation PR: odoo/documentation#11847

Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749)
task-4497749

Forward-Port-Of: odoo/enterprise#78927
Forward-Port-Of: odoo/enterprise#77991

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#78904 Forward-Port-Of: odoo/enterprise#74412

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services

Task-4354482

Forward-Port-Of: odoo/enterprise#78904
Forward-Port-Of: odoo/enterprise#74412