Marketing automation users can now select which outgoing mail server is used when sending mass emails from templates. This gives businesses more control over email delivery setup while keeping the option hidden for SMS templates where it does not apply.

Purpose:
--------
Allow users to select which outgoing mail server is used when sending mass mailings from the mail templates.
The `mail_server_id` has been added in a new `advanced` group in the marketing activity's mailing mailing form view.
It also removed the `readonly` attribute from the field on the marketing automation's mailing mailing form view (because mailings used in marketing automation are set as `done` by default, hence this field was always readonly).

This field is made invisible for sms templates.

Task-3862060

Businesses can now choose which appointment details customers see on the website and in confirmation emails. This helps tailor booking pages for different use cases, such as hiding approximate durations or timezone information when they are not relevant to customers.

[Task 3568931](https://www.odoo.com/web#id=3568931&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form)
[Mock Up](https://app.excalidraw.com/l/65VNwvy7c4X/2FcgfyW3hU2)

## Purpose

Depending on the business scope, company may want to display a different confirmation page to their customers.
e.g. : If you are a restaurant, a duration of 3 hours is just an approximation for your own organization, customers should not read about it

## Changes

### Appointment Type:
In order to customize the appointment views on the website and the mail templates, we need to add some fields to the appointment type model:
- hide_duration
- hide_timezone

### Appointment Templates:
With the two fields created above, we add some t-if condition to show or not some informations on the templates views.

### website_appointment:
Add a new snippet to customize the page related to an appointment type that contains 4 checkboxes:
- Show Timezone
- Show Duration
- Show User/Resource Pictures
- Allow Guests

When triggered, these options will modify the record of the appointment type related to the view.

As we want this snippet to be shown during the whole flow of the appointment registration, we created a common CSS class :
o_wappointment_type_widget
This class will be used to show the snippet in each view of the flow.

The snippet is associated to a JS snippet that will handle the calls to the ORM in order to update the record of the appointment type.

This fix ensures that new payments created through online account synchronization use the correct company together with the selected journal. It prevents payment records from being created with missing or mismatched company information, reducing accounting inconsistencies.

When creating a new payment, we need to specify the company along with the journal.
Even if the company is normally computed, it isn't the case here because of protection of fields with the `_inherits` feature, along with a de-normalized field.

This update cleans up how several business areas retrieve grouped data, without changing the visible features users rely on. It helps keep payroll, subscriptions, accounting settings, and localization processes easier to maintain and aligned with the main Odoo platform changes.

https://github.com/odoo/odoo/pull/163317

This update simplifies how embedded views are configured in Knowledge, making the underlying code easier to maintain and extend. There is no expected change for end users, but it reduces future development friction and avoids duplicated configuration data.

The function `_insertEmbeddedView` accepts 7 parameters to set up an embedded view. Some of these parameters are optional or incompatible with each other. For example: it makes no sense to pass the xml id of an action and an actual action object. To insert an embedded view, the developer has to pass many null, undefined or falsy values to the function, making the code difficult to read and maintain.

To improve this, the function will accepts a single object containing all the props of the embedded views. This object will directly be encoded in the blueprint of the behavior. The caller will now be responsible for providing a valid configuration with the required values.

The advantage of directly passing the props of the embedded view to the `_insertEmbeddedView` function is that we will not have to update the API of the function in the future whenever we define a new prop to the embedded view behavior.

The `_insertEmbeddedView` function will also no longer copy the action helper of the action to the behavior props of the embedded view. Doing the copy was duplicating data and was not necessary as the action helper is, by default, loaded from the loaded action unless a custom one is defined in the behavior props.

task-3847699

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts. We'll make it required in master. Forward-Port-Of: odoo/enterprise#60847

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts.

We'll make it required in master.

Forward-Port-Of: odoo/enterprise#60847

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered. Steps to reproduce: ------------------- * Go to the **Field Service** App * Switch to the calendar view * Select "Tomorrow" (x+1) * For the new task, set the `Planned Date` as follows: * Start date : The day after tomorrow at 3PM (x+2 3PM) * End date: Three days after the start at 4PM (x+5 4PM) * Fill anything for the other required fields > *

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered.

Steps to reproduce:
-------------------
* Go to the **Field Service** App
* Switch to the calendar view
* Select "Tomorrow" (x+1)
* For the new task, set the `Planned Date` as follows:
  * Start date : The day after tomorrow at 3PM (x+2 3PM)
  * End date: Three days after the start at 4PM (x+5 4PM)
* Fill anything for the other required fields > **Save & Close**
* Switch to the kanban view and select the task created
> Observation: the start date of `Planned Date` is set at Tomorrow 7AM instead of the day after at 3PM

Why the fix:
------------
This behavior was introduced after this commit: https://github.com/odoo/enterprise/commit/39b9362d0469d71b59d47e9d66d5e73b9a46520b.

This commit added an inverse method to the field `planned_date_start` to enable drag and droping tasks in the calendar view. And `planned_date_start` is a field that exists purely for calendar displaying of tasks.

https://github.com/odoo/enterprise/blob/c8c4a52b508621b45239332273832de26a085931/project_enterprise/models/project_task.py#L299-L305

When creating a task in the calendar view, the context contains `default_planned_date_start` and its value depends on the first day you selected in the calendar. At task creation, `default_planned_date_start` triggers a write in `planned_date_start` which triggers its inverse method.

This removes the `default_planned_date_start` from the context which won't trigger the inverse method. We don't have to worry about the line `default_planned_date_begin: default_planned_date_start,` as if we have selected a start date in the form, it will be present inside `vals_list` in the create function and will use that value instead of the one in the context.

opw-3850455

Forward-Port-Of: odoo/enterprise#62232
Forward-Port-Of: odoo/enterprise#61351

We should not rely on the `type_name` field (which is a translated) to determine if an order is a confirmed subscription. To reproduce: - Active a second language (for. ex French) and enable it as well for the current website - Create a subscription, set a customer reference to 'CUST-REF' then confirm it - Click on "Preview" => In English, the 'CUST-REF' is visible in the subscription header, in other languages it was not visible. Forward-Port-Of: odoo/enterprise#62093

We should not rely on the `type_name` field (which is a translated) to determine if an order is a confirmed subscription.

To reproduce:
- Active a second language (for. ex French) and enable it as well for the current website
- Create a subscription, set a customer reference to 'CUST-REF' then confirm it
- Click on "Preview"

=> In English, the 'CUST-REF' is visible in the subscription header, in
  other languages it was not visible.

Forward-Port-Of: odoo/enterprise#62093

This commit converts all the tests that rely on mail test utils and helpers into hoot. **part of task**-[3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61927

This commit converts all the tests that rely on mail test utils and helpers into hoot.

**part of task**-[3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#61927

When receiving emails, the attachments of the email may be made directly into a document. This will not make a copy, meaning restrictions on message attachments apply on these attachments. By extension this means the related fields on documents cannot be used properly. We now do a second check, filtering documents, if the access rights check fails because of message attachment restrictions. The reason to do two checks is that we do not want to add querries in the most common cases where th

When receiving emails, the attachments of the email may be made directly into a document. This will not make a copy, meaning restrictions on message attachments apply on these attachments. By extension this means the related fields on documents cannot be used properly.

We now do a second check, filtering documents, if the access rights check fails because of message attachment restrictions.

The reason to do two checks is that we do not want to add querries in the most common cases where the check will succeed regardless of filtering.

issue introduced in odoo/odoo@4c4e63f01aefa01c2377f15f2020485cb0f7e4da

task-3519815

Forward-Port-Of: odoo/enterprise#62338
Forward-Port-Of: odoo/enterprise#62174

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank. UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/pay

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank.

UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/payments-and-reporting/insidebusiness-payments/domestic-uk-file-format-description-february-2024.pdf that this identifier should be 999999 + 4 blanks or SUN + 4 blanks, so we make the choice to use 999999 if we have no SUN, for HSBC.

We don't want to make the SUN field optional for everyone just because of that one use case. Instead, we ask people to write 'HSBC' as their SUN number in the settings if they don't have any, and this considers the field as blank for the file generation.

(HSBC's doc can be found on the related ticket)
opw-3863262

Forward-Port-Of: odoo/enterprise#62323
Forward-Port-Of: odoo/enterprise#62111

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed. opw-3905455 Forward-Port-Of: odoo/enterprise#62185

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed.

opw-3905455

Forward-Port-Of: odoo/enterprise#62185

…atable Those fields are just counting stuff, and their labels are never displayed. So it's useless having them in the .pot file Forward-Port-Of: odoo/enterprise#61019

…atable

Those fields are just counting stuff, and their labels are never displayed. So it's useless having them in the .pot file

Forward-Port-Of: odoo/enterprise#61019

Before this PR, the sign_request record was browsed but we did not checked if the record was correct. Before this PR, when the sign_document_from_mail controller was called without timestamp parameter, it would redirect to the sign.sign_request_expired template because current_request_item._validate_expiry(post.get('timestamp'), post.get('exp')) would return False. For human triggered interaction, it is not an issue. Some customer complained of massive email sent. One of the signer

Before this PR, the sign_request record was browsed but we did not checked if the record was correct.

Before this PR, when the sign_document_from_mail controller was
called without timestamp parameter, it would redirect to the
sign.sign_request_expired template because
current_request_item._validate_expiry(post.get('timestamp'),
post.get('exp')) would return False.

For human triggered interaction, it is not an issue.

Some customer complained of massive email sent. One of the signer is
probably relying on MS Defender. This is system is known to click on
links in email and cleaning the GET parameters of the URL.

In that case, the bot will get the sign.sign_request_expired which has a
button that allows to resend the sign request. If the bot click on that
button, it will send an email, that will be analyzed by the bot. it will
clean the parameters, get the sign.sign_request_expired template etc
etc.

Forward-Port-Of: odoo/enterprise#61853

This commit extends tax reports added in l10n_ng to show warnings and hide the Closing Entry button on Withholding tax report. Also adds tax report tests. Odoo PR: https://github.com/odoo/odoo/pull/148370 Task [link](https://www.odoo.com/web#model=project.task&id=3607459) task-3607459 Forward-Port-Of: odoo/enterprise#62147 Forward-Port-Of: odoo/enterprise#58603

This commit extends tax reports added in l10n_ng to show warnings and hide the Closing Entry button on Withholding tax report. Also adds tax report tests.

Odoo PR: https://github.com/odoo/odoo/pull/148370
Task [link](https://www.odoo.com/web#model=project.task&id=3607459)
task-3607459

Forward-Port-Of: odoo/enterprise#62147
Forward-Port-Of: odoo/enterprise#58603

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one. This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it. task-id: none Forward-Port-Of: odoo/enterprise#62227 Forward-Port-Of: odoo/enterprise#60822

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one.

This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it.

task-id: none

Forward-Port-Of: odoo/enterprise#62227
Forward-Port-Of: odoo/enterprise#60822

Reproducing: 1. Use a folder with one `binary` and one `url`-type documents. 2. Add a tag on the `binary` one. 3. Check the tag in the search panel 4. Share the folder Problem: You are warned about having included a link in the share, but you had not. Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`). Task-3806121 Forward-Port-Of: odoo/enterprise#58650

Reproducing:
1. Use a folder with one `binary` and one `url`-type documents.
2. Add a tag on the `binary` one.
3. Check the tag in the search panel
4. Share the folder

Problem:
You are warned about having included a link in the share, but you had not.

Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`).

Task-3806121

Forward-Port-Of: odoo/enterprise#58650

Before this commit, the open shifts without any SOL set are not fetched during the auto plan process because the following condition is falsy for them inside the domain used: `('sale_line_id.state', '!=', False)`. This commit changes the domain to check if the SOL is false or if the state of the SOL set is different than 'cancel'. runbot-61465 Forward-Port-Of: odoo/enterprise#62026

Before this commit, the open shifts without any SOL set are not fetched during the auto plan process because the following condition is falsy for them inside the domain used: `('sale_line_id.state', '!=', False)`.

This commit changes the domain to check if the SOL is false or if the state of the SOL set is different than 'cancel'.

runbot-61465

Forward-Port-Of: odoo/enterprise#62026

This update adds support for Mercado Pago's Smart Point payment terminal, enabling businesses in Latin America to accept payments directly through their point-of-sale system. This new payment method integration streamlines the checkout process for retailers in the region.

This PR add the Mercado Pago "Smart Point" payment terminal dedicated to the LATAM (Latin America) region

task-3350386
    
mool

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

This update improves the user experience by hiding Avalara tax-related fields in the system for countries outside the United States and Canada, where Avalara services are not applicable. This prevents confusion and streamlines the interface for users in other regions by only showing relevant tax configuration options.

Avalara fields should not be shown to countries that are neither US or Canada. This commit handles this.

task-3477234

This update removes the validation requirement that prevented users from having multiple bills with the same reference number. This change improves the user experience by eliminating a frustrating restriction that doesn't align with real-world business practices, making the system more flexible and easier to use.

[REM] account: remove validation on bills ref

Remove validation on bills ref and allow users to have multiple bills with same ref

Reason: improve user experience with the system as it's a pain for them in a real life scenario

Task-3869240

odoo-PR#https://github.com/odoo/odoo/pull/161995

This update automatically populates Swift and BIC codes when setting up bank accounts in Odoo. Since the bank connection API already provides this information, we now capture and store it in your journal records. This streamlines the account setup process and reduces manual data entry, improving your overall experience.

[IMP] account_online_synchronization: populate swift/bic in journals

Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals

Reason: Improve the user-experience

Task-3891695

odoofin-pr: https://github.com/odoo/odoofin/pull/273

This update improves the double holiday benefit calculation in the Belgian payroll system by incorporating employees' job roles from the previous year. This ensures more accurate holiday entitlements by considering employment history, which is important for proper payroll compliance and employee compensation.

This will add the previous year occupation to the double holiday computation.

Task: 3893810

This update changes the default invoice sending method to use Peppol only, instead of sending by both email and Peppol simultaneously. Customers can still choose to send by both methods if needed. This prevents duplicate invoice deliveries and streamlines the default sending experience.

[IMP] Accounting: Set send by Peppol default instead of Send by email & Send by Peppol

Set send by Peppol default instead of Send by email & Send by Peppol in sending the invoice

Reason: To avoid sending the email twice unless the client wants that, He will still have the option to do so

Task-3829627

This update significantly speeds up the process of changing project settings (like billable status) when dealing with projects that have thousands of associated tasks and timesheets. The improvement optimizes how the system processes these changes, reducing the time from over 4 minutes to just over 1 minute—a 3.6x performance boost that directly improves user experience when managing large projects.

## Description
The `onchange` triggered when changing the `allow_billable` setting of a large long living project with a high number of associated timesheets can take a quite a while.
After profiling, a significant portion of the bottleneck was coming from *frequent* calls to the `__hash__` function, called when initializing a new `set` in
https://github.com/odoo/odoo/blob/cf9aa2a14761a417c641243fc0b2be121c387b46/odoo/models.py#L6838
Left Heavy profile:
![profile_onchange_billable_after_orm_patch](https://github.com/odoo/odoo/assets/111067497/fb6bc313-478a-44e1-9684-a7dc266171ae)


## Improvements
- Invariant hoisting: the `set(self._ids)` can be lifted out of the lambda scope capture, passing only a reference to a local variable for all callsite of the lambda. This prevents the re-computation of `set(self._ids)` for each record in `cache_records` due to the linear iteration done by `filtered`.
- `not isdisjoint` vs `intersection`: the lambda is checking for the existence of an intersection between 2 sets. But in python the `&` or `intersection` method *construct* a new instance of a `set`. In our case we don't care about the resulting intersection, only about the existence of it. We can improve the situation by inverting the logic using `not isdisjoint`, as `isdisjoint` is simpler internal implementation and doesn't construct any new set, it just checks for disjunction.
  - CPython `intersection`:
https://github.com/python/cpython/blob/333c7dccd87c637d0b15cf81f9bbec28e39664fd/Objects/setobject.c#L1179-L1256
  - CPython `isdisjoint`: https://github.com/python/cpython/blob/333c7dccd87c637d0b15cf81f9bbec28e39664fd/Objects/setobject.c#L1338-L1373 

  A local small `timeit` benchmark showed +- 25% faster performance in favor of `not isdisjoint`.

## Benchmark
On a staging database (saas-17.1, blindly backported), the `onchange` triggered by setting a project `allow_billable` from `True` -> `False`, with 70k tasks, and 25k associated timesheets.

|         | Before               | After               | Speed Up    |
|---------|----------------------|---------------------|-------------|
| Timings | 246.66 sec (4.1 min) | 66.83 sec (1.1 min) | 3.6x faster |

## Reference
task-3872314

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

This fix corrects how account reports handle an empty account type filter field. Previously, leaving this optional field empty would incorrectly limit results to only payable and receivable accounts. Now it properly behaves as if the filter is disabled, allowing all relevant accounts to be included in reports.

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts.

We'll make it required in master.

This update improves the WhatsApp template variables page by hiding unnecessary fields that were cluttering the interface. Specifically, the model, line type, and name fields are now hidden from view, making the Variables page cleaner and easier to use while maintaining all the important information users need.

A separate tree view is defined in `whatsapp_template_view_form` to display the `variable_ids` field on the Variables page. This tree view contains fields that are not needed to display, such as `model`, `line_type`, and `name`. These fields are made invisible using `column_invisible="1"`.

Task-3902030

This fix prevents products from being moved to incorrect storage locations when using the barcode scanning app. Previously, users could scan a barcode for any location, even if it wasn't the designated destination for that receipt. Now the system validates that scanned locations must be the correct destination or a sub-location of it, ensuring inventory accuracy and preventing misplacement of goods.

How to reproduce:
- Enable "Storage Locations";
- Create a receipt with WH/Stock/Shelf 2 as the Destination Location;
- Add a product with a barcode in this receipt and mark it as todo;
- Open the created receipt in the Barcode app;
- Scan the product;
- Scan WH/Stock/Shelf 1 barcode.

-> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.)

-> Expected behavior: a product cannot be moved in a destination who is not (a part of) the picking's destination.

[OPW-3895328](https://www.odoo.com/web#id=3895328&cids=1&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#61665
Forward-Port-Of: odoo/enterprise#61560

This fix resolves an issue where negative stock quantities were preventing Amazon inventory updates from being processed. The system now sends only positive stock amounts to Amazon, ensuring that inventory availability feeds are properly updated and accepted by the platform.

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed.

opw-3905455

Forward-Port-Of: odoo/enterprise#62185

This change reverts a previous update to restore the functionality that hides Avalara tax-related fields for companies operating outside the United States and Canada. This ensures that users in other countries don't see irrelevant Avalara configuration options in their system.

This reverts commit 3a0c8b1f8d1055e7ce84791c665b4d37ca37109f.

See https://github.com/odoo/enterprise/pull/60554#issuecomment-2107979637

This fix resolves an error that occurred when creating sales orders with products from a parent company using a branch. Previously, confirming such orders would fail with an "incompatible companies" error. The fix updates how products validate company relationships to properly support branch operations, allowing products to be seamlessly used across parent companies and their branches.

Steps
-----
1. Have inventory installed.
2. Have a product belonging to a company with a branch.
3. Create a SO with this branch and add the product to it.
4. Confirm the SO.
** Invalid Operation : incompatible companies on records **

Issue
-----
While it is possible to add a product from a parent company to
a SO, we get an error when confirming the SO and creating the move because
of
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move.py#L1358
As the product_id field of stock.move has check_company=True, we have
an inconsistency because we are using the default domain of
_check_company_domain which is just the company itself.
https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L3999-L4007

Fix
-----
We provide a new _check_company_domain to product.product.
https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed made changes to allow products
to be used by branches, in particular this security rule:
https://github.com/odoo/odoo/blob/5a801bc60209713a3ba5313debb4daa05c4e2405/addons/product/security/product_security.xml#L34-L38

**opw-3815736**

This fix corrects an issue where product variant prices were not being saved properly when customers ordered through the self-service QR menu. Previously, when staff later modified the order quantity in the regular point-of-sale system, the variant's extra price would be lost and revert to the base price. Now the pricing is correctly preserved throughout the ordering process.

Current behavior:
When adding a product with variant in a self order. The extra price was not saved correctly, and so when modifying the quantity from the normal PoS the price was not taking the extra price into account.

Steps to reproduce:
- Setup PoS to use QR Menu ordering
- Create a product with a variant (never create option)
- Make sure the variants adds an extra price
- Open the self ordering screen an add this product
- Add the product to the order and validate it
- Go on the normal PoS and open the order
- Change the quantity of the product
- The unit price is back to the normal (not considering the extra price)

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

This fix resolves a critical issue where event badge generation was causing website registrations to freeze indefinitely. The problem occurred when badge images weren't configured, causing the system to attempt unnecessary background image fetches that created database conflicts. With this fix, the badge generation process now works smoothly without blocking user registrations.

__Current behavior before commit:__
If the `badge_image` field of the event isn't set, the badge div's style defaults to `background-image: url();`. When `wkhtmltopdf` interprets this, it attempts to fetch the background image from the website's base URL. Consequently, each time the badge PDF is generated, `wkhtmltopdf` accesses the website's homepage, inadvertently altering the `website_visitor` table. If the badge PDF creation is triggered by a request from the website, it will lead to a deadlock due to simultaneous transactions on the same `website_visitor` row.

__Description of the fix:__
Do not write the `background-image` instruction at all when `badge_image` is not set.

__Steps to reproduce the issue on runbot:__
- Install `website_event`
- Go to Email Templates > **Event: Registration Confirmation** > Settings
- Put `Badge` in **Dynamic Reports**
- Create a new Event and register to it on its website page

-> The registration loads forever and it's impossible to go on any other page on the website

opw-3884132

This fix prevents lazy-loaded images from being incorrectly marked as edited when the website editor makes temporary style adjustments. Previously, a single word change in a section could trigger 27 unnecessary save operations for unrelated images. The fix disables change tracking during these temporary adjustments and prevents empty style attributes from being left on images.

There is an issue with some of the images having `loading="lazy"`
attribute. Those are incorrectly marked as edited (dirty).

This is because those images do receive a `min-height` style attribute
change when the widget is started thanks to [1]:
- On page load, the images receive `style.minHeight = '1px';`
- Once the images have been load a few moment later, this `min-height`
  is removed / restored to its initial value. If there were no initial
  value and if there is no other style attribute on the image, it will
  leave the image with an empty `style` attribute.

But commit [2] made it so those empty attribute (class/style) are
removed from the DOM as part of the sanitizing process.

This commit does 2 things:
- It disable the wysiwyg observer while commit [1] `min-height`
  operations are being one.
- It prevent commit [1] to leave images with an empty `style` attribute.

Note:
- it was detected on our Odoo.com/app/expenses where a single word
  change in a section flags 27 unrelated images as o_dirty and
  ultimately triggers 27 save rpc call instead of only one.
- commit [2] was merged in Odoo 16 but only seems to lead to this bug in
  Odoo 16.4. Something else is probably involved in the o_dirty addition
  process. It doesn't seems worth it investigating deeper to find
  exactly what as this commit changes are things that probably should
  have been done initially anyway.

[1]: https://github.com/odoo/odoo/commit/e9ef21b6cd5ae58322fa9102f9f34f06835f0485
[2]: https://github.com/odoo/odoo/commit/5962b9ee2e90cc04ede1c1f9bbb519869db77f71

Forward-Port-Of: odoo/odoo#150535

This fix improves phone number formatting to work consistently even when no country information is available on a record or company. Previously, the system would skip formatting entirely in these cases, but now it attempts to format the number and returns a properly formatted result or indicates when formatting isn't possible. This makes phone number handling more reliable and predictable across the system.

Currently when using _phone_format on any model without any country (on record or on company) the phone format calls is skipped. However if input is already a formatted number it works even without the country information.

In this commit we now always call the format tool even when no country is found. It means the returned value might change in some cases (i.e. no country -> was returning original number). However the method spec is that it should return the formatted number or False when no formatting is possible.

Calls of _phone_format has been checked and they effectively generally do sanitized or original_number, meaning they expect the returned number to be False when the formatting is not possible. So there should not be any unwanted side effect.

Task-3918417
Runbot-64570

This fix resolves a test failure in the Ecuador localization module for website sales. When the system creates invoices, it now properly passes required arguments through the method chain, ensuring tests pass and the invoice finalization process works correctly.

`test_invoice_is_final` enforces that `_create_invoices` is called with the final argument.
The issue is that when overriding the method in l10n_ec_website_sale, 
we call super() without respecifying the arguments, which makes the test fail.

runbot-56914



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

This fix resolves an issue where recurring calendar events were being duplicated when edited. The problem occurred because an internal method was being called twice during event modifications. By adding a condition to prevent duplicate processing, users will no longer see duplicate events when managing recurring calendar entries with multiple attendees.

Versions:
------------
16.0

Steps to reproduce:
-------------------
1)Update the email field of users with gmail id for admin and demo 2) Connect odoo with google calendar
3) Create a recurring event with admin as Organizer, demo as attendee and recurrence as "Daily" with "1" repeatation.
4) Then edit the event by changing the repeatation as "2" and save it in "This and following event"
5) Check the event duplication

Issue:
-------
Recurring events in the calendar are being duplicated.

Cause:
------
The `_apply_recurrence_values` method is being called twice, resulting in duplicate events.

Solution:
---------
Added a condition to prevent the method from being called multiple times.

task-3786429

Forward-Port-Of: odoo/odoo#160062

This fix resolves a technical issue in the loyalty module that was preventing other customizations from working properly. The change makes the cart update feature more flexible and easier for partners to extend, reducing errors when adding custom functionality to the shopping cart.

Description of the issue/feature this PR addresses:
  Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's `_cart_update` override, all overrides of that method, that earlier, need to pass arguments to super by key instead of position. Otherwise, an error is raised, because the override in question, receives those parameters in args, instead of kwargs, producing a KeyError. This should not be something a community plugin should need to worry about. This commit makes it so, the override is declared with explicitly stated base arguments, instead of using `*args`, and `**kwargs`. This not only fixes the issue, but also simplifies the method.

Current behavior before PR:
  If any potential `_cart_update` overrides call `super` with position based arguments, a KeyError is raised.

Desired behavior after PR is merged:
  `super` may be called with either key and position based arguments in `_cart_update` overrides.


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

This fix resolves an issue where users could no longer edit text or character fields after removing all content and saving. The problem occurred because empty tags couldn't receive cursor focus. The solution automatically fills empty editable fields when the document loads, allowing users to edit them again.

Description of the issue/feature this PR addresses:

After removing the text from a tag with data-oe-type 'text' or 'char', and then saving, you can no longer edit it. It is because when the text is removed and and field is saved it becomes empty and its not possible to put the cursor inside an empty tag. This PR fills such empty tags when loading the document.

task-3858711

Forward-Port-Of: odoo/odoo#162426

This update fixes a problem where users could interact with a background popup while a second popup was open on top of it. The system now properly manages the layering of multiple popups so that only the topmost popup can be interacted with, improving the user experience when dealing with nested dialog boxes.

Previously, when a popup was opened and it was possible to open a second popup within that popup, when the second popup was opened it was still possible to interact with the first popup.

Now we've added a zIndex to the popup service, which corrects this problem

This update corrects a bug where average calculations in list views were including section and note lines that should have been excluded. When users add section headers or notes to a list, the average will now calculate correctly by only considering the actual data rows, providing accurate reporting and analysis.

When using "avg" in a list view with the "section_and_note_one2many" widget and adding a 'line_section' or a 'line_note', the average calculation does not exclude those lines, returning an incorrect result.

Fixed an issue where numeric fields in forms weren't displaying with proper formatting (thousands and decimal separators) after users edited and re-entered the same value. Now when users press Enter, Tab, or Shift-Tab, the number will always display with the correct formatting, improving consistency and reducing user confusion.

Have a numeric field in a form view. The displayed value is formatted, according to the thousands and decimal separators. Say the value is 1,240.00. If the user edits the input and types the same value, i.e. 1240, and then press "Enter", "Tab" or "Shift- Tab", the value won't be formatted as it should be, because we detect no change of value (which is true, but the value should be formatted anyway).

With this commit, the value is always formatted on "Enter", "Tab" and "Shift-Tab".

Issue spotted by fp

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#165069
Forward-Port-Of: odoo/odoo#164953

Fixed an issue in the expense split feature where splitting an expense attributed to another employee would show an empty view. The fix updates the view filter to properly display the expenses that were modified or created by the split operation, regardless of who the expense is assigned to.

The aim of this commit is to fix the view returned from the expense split wizard

Context:
When splitting an expense, the wizard view returns the expense list view with "my expenses" a "to report" filters activated. This makes splitting an expense attributed to someone else return an empty view.

After this commit:
The view now uses a domain that selects the expenses the wizard modified and/or created

task-id: 3911134

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

Forward-Port-Of: odoo/odoo#164499

This fix resolves test failures in the Event module when running without demo data. The issue occurred because the system couldn't properly identify email authors for event registrations when the company lacked an email address. The fix ensures companies have email addresses configured during testing, matching the behavior of demo mode.

This pull request documents the signing of the Contributor License Agreement (CLA) by appti.mx, represented by David Goldfeder. This is a legal compliance requirement that allows the company to contribute code to the Odoo project. No functional changes are included in this update.

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