### [FIX] website: fix GMaps deprecation console warning for s_google_map

Google deprecated the synchronous script loader for initializing the
Maps JS API. This caused browser console warnings.

The fix adopts Google's official `importLibrary()` bootstrap pattern,
which loads map libraries (places, maps, marker) lazily on demand rather
than all at once.The version is updated to `v=weekly`, which Google
recommends as it receives updates weekly versus quarterly for version
numbers(`v=number`).

Steps to reproduce:
1. Add the `s_google_map` snippet(not the`s_map`, enable debug mode)
2. Open the browser console and observe the deprecation warning


### [IMP] website: warn user to reload after GMaps config changes

Switching from the legacy Google Maps APIs to the new APIs requires
enabling additional services in Google Cloud. Existing maps using the
legacy API continue to work, but when an admin edits a map without a
proper configuration, the `GoogleMapAPIKeyDialog` dialog opens.

Google Maps configuration changes (API key update or enabling services)
do not take effect during the current editor session because the Maps
JavaScript API is loaded at page initialization.

Before this commit, such misconfigurations (disabled services or invalid
API keys) only triggered a dialog showing a generic Google Maps error.

After this commit, a notification informs the user that the page must be
reloaded for configuration changes to take effect.

The setup instructions are also updated to reference the
"Places API (NEW)" service.


### [IMP] website: replace deprecated Places API calls in GPS picker

The GPS picker relied on `PlacesService.nearbySearch` and `getDetails`,
which are part of the deprecated Places API. The new places API replaces
these with `Place.searchNearby` and `fetchFields`.

Error handling is consolidated into a single try/catch since the new
Places API throws on failure rather than returning a status code,
removing the need for `PlacesServiceStatus` checks.


### [IMP] website, *: replace deprecated Google Autocomplete
*: website_form_project

google.maps.places.Autocomplete is deprecated in the new Places API.
The replacement (`AutocompleteSuggestion.fetchAutocompleteSuggestions`)
does not fire DOM events, making it incompatible with the old
event-listener pattern used in GPSPicker.

A new Owl component (`PlacesAutoComplete`) is introduced to wrap the new
API, built on top of the existing `AutoCompleteWithPages`.


References:
https://developers.google.com/maps/documentation/javascript/load-maps-js-api
https://developers.google.com/maps/documentation/javascript/advanced-markers/migration
https://developers.google.com/maps/documentation/javascript/legacy/places-migration-overview

task-[4441041](https://www.odoo.com/odoo/project/974/tasks/4441041)

Forward-Port-Of: odoo/odoo#281029
Forward-Port-Of: odoo/odoo#242765

Steps to reproduce
---
1. Enable Storage Locations and Lots & Serial Numbers.
2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1.
3. Confirm a receipt reserving 2 units of that product; putaway sets the reserved move line destination to WH/Stock/Shelf 1.
4. In the Barcode app, scan a first lot, then a second lot.

The second lot lands on a separate line at WH/Stock instead of WH/Stock/Shelf 1.

Issue
---
The first lot reuses the reserved line and keeps its Shelf 1 destination. The second lot cannot reuse it because its tracking number differs, so `_findLine` returns nothing and `_getNewLineDefaultValues` builds a new line with `location_dest_id` set to `_defaultDestLocation()`, the picking's default destination (WH/Stock).

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L1591-L1601

Putaway relocates the destination on the move line at reservation, never on the picking, so only the reserved line carries Shelf 1. Since `groupKey` includes `location_dest_id`, the new line does not group with the first lot and shows separately at WH/Stock. This is not a regression: new lines have always defaulted to the operation destination.

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L239-L241

The new line now inherits the selected line's `location_dest_id`, already relocated by putaway, instead of the default.

opw-6317077

Forward-Port-Of: odoo/enterprise#125309

Steps to reproduce:
-------------------
1. Install `l10n_mx_edi_pos` and set the company to Mexico.
2. In PoS, make an order with one product and pay it.
3. Open the order in the backend, click "Return Products" to make a refund, but don't pay it, cancel it instead.
4. From the same order, click "Return Products" again to make a second refund, and pay it normally.
5. Go to the orders list, select the main order and the paid refund (not the cancelled one), then Actions > Create Global Invoice.

-> Observation: error in the global invoice.

In the CFDI tab of the main order the line is "Send Global In Error", and hovering on it the detail says "Failed to distribute some negative lines".

Why:
----
When we make the global invoice, we remove the refunds from the order. A cancelled refund was never paid, so we should not count it. But we were counting it too. So we removed the refund amount twice in our case, one for the paid refund, and one for the cancelled one, and we end up with an order with negative amount that cannot be distributed.

The fix:
--------
We now skip the cancelled orders when we search the refunds, the same way it is done above when we collect the refunded orders.

opw-6261404

Forward-Port-Of: odoo/enterprise#127560
Forward-Port-Of: odoo/enterprise#120996

Description of the issue/feature this PR addresses:

Installing Odoo via the .deb package continuously causes issues with the asset bundles. This is because of the following daisy chain of behaviors:

- `dpkg-buildpackage` parses `SOURCE_DATE_EPOCH` from debian/changelog and then clamps the Modified date of all files to at max that epoch ([src](https://launchpad.net/debian/+source/dpkg/1.18.8)). The relevate date is the one written after the email in the topmost changelog entry
- This is preserved when unpacking the .deb package, the OS does not change it
- The Asset loading logic in ir.qweb and ir.asset relies on the Modified date (via [`os.path.getmtime`](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/ir_asset.py#L49)) to determine the hash that serves a Version for the asset bundles ([src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L775), [src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L148))
- The controller and ir.qweb compiler rely on this Version hash to correctly invalidate outdated asset bundles and force re-generation of the bundle content as neccessary

Current behavior before PR:

debian/changelog has not been changed or maintained since 2020 and its timestamp remains `Tue, 15 Dec 2020 10:28:49 +0100` This results in the Modified Date being clamped to 2020, which means the files no matter how much is changed always look like last modified on this date. Therefore the Version hash for the asset bundles never changes, and the asset reload logic does not trigger correctly.
This is especially dangerous for setups which use several code sources with different file delivery methods, for example installing Community via .deb but Enterprise via git. This results in only some asset bundles not being updated (those not touched by Enterprise modules) while others are, which then generates an OWL error as it detects the content being different between the bundles ([src](https://github.com/odoo/odoo/blob/17.0/addons/web/static/lib/owl/owl.js#L3333))
For versions 18+, a very common result of this behavior is the portal chatter failing to work. This is because the same files like for example mail/static/src/core/common/thread.xml being loaded into both [`portal.assets_chatter`](https://github.com/odoo/odoo/blob/18.0/addons/portal/__manifest__.py#L69), which is not touched by an Enterprise module, but also into [`web.assets_frontend`
](https://github.com/odoo/odoo/blob/18.0/addons/im_livechat/__manifest__.py#L90) via im_livechat, which is a bundle touched by many modules, including Enterprise modules. Thus, is a file in the mail addon is changed, the changes are correctly applied to `web.assets_frontend`, but not `portal.assets_chatter`, causing an OWL error. This is extremely frustrating to fix, since it not only requires a manual Asset Rebuild, but also for every user to empty their Browser Cache, since the assets bundles are so large as to be guaranteed to be cached, and if the old version of the bundle is loaded from cache, the OWL error persists. A similar error can also happen with website, since the assets for the WYSIWIG editor are loaded as a module-specific bundle, `website.assets_wysiwyg`, which also fails to update, while of course the same assets being loaded to the general website asset bundle will be updated.

Desired behavior after PR is merged:

The builder for the nightly .deb package of Odoo writes a complete debian/changelog entry instead of merely replacing the first line. This entry includes the current date, thus ensuring the Modified date for the files is not clamped to years in the past. Down the line, this fixes the assets loading issue.


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

Forward-Port-Of: odoo/odoo#269458

Before this commit, marking several manufacturing orders as done at once crashed or could post labour costs on the wrong account, because the labour posting loop read the product and the company from the whole recordset instead of the manufacturing order being processed.

Steps to reproduce:
- activate a second company, e.g. My Company (Chicago)
- create a manufacturing order in each company and confirm them
- in the Manufacturing Orders list view, select both orders and mark them as done

A "ValueError: Expected singleton: res.company(...)" traceback is raised and none of the orders can be closed, even though each one can be marked as done individually. With same-company orders of different products, the production location resolved from the union of products, so the labour entry could be posted against another product's WIP account.

Use the manufacturing order of the current loop iteration to resolve the production location, as the rest of the loop already does.

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

Forward-Port-Of: odoo/odoo#276586

Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_fr_pdp is installed.

The module extends the method _compute_show_reset_to_draft_button which reads l10n_fr_pdp_sent_in_flow_ids.
That field is only readable by the accounting groups while show_reset_to_draft_button is declared in the standard invoice form
without any groups restriction

< field name="show_reset_to_draft_button" invisible="1"/ > in account.view_move_form

Every user able to open an invoice therefore reads it.

Steps to reproduce:
- install `l10n_fr_pdp`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create a FR company and a FR customer
- give the salesman access to the FR company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the FR company for the FR customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An Access Error dialog is raised

Failed to read field account.move.l10n_fr_pdp_sent_in_flow_ids
You are not allowed to access 'French PDP Flow' (l10n.fr.pdp.reports.flow) records.

This operation is allowed for the following groups:
  - Accounting/Administrator
  - Accounting/Invoicing
  - Show Accounting Features - Readonly
  - Show Full Accounting Features


In odoo.sh, the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights
fails for the same reason as soon as l10n_fr_pdp is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_fr_pdp installed, a non-accountant user having the possibility to create invoice should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280754

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details
- Go to my/account page.

Issue:
- Peppol related details always displayed on `my/account` page even though user select different invoice sending method like: `By Email`.

Casue:
- selector to manage visibility of Peppol related details in `my/account` is wrong and because of that those fields always display. Probably because https://github.com/odoo/odoo/pull/195764 and backport of this https://github.com/odoo/odoo/pull/198327 merged at same time.

Fix:
- Update selector to fix this

### [FIX] account_peppol: fix error when setting wrong endpoint

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details.
- Go to my/account page.
- Set some wrong Peppol value for `Peppol e-Address (EAS)` or `Peppol Endpoint` or `Electronic format`.

Issue:
- Not able to save those details without any error message on address page and getting error on console `Cannot read properties of undefined (reading 'classList')`.

Casue:
- In this PR https://github.com/odoo/odoo/pull/190312 when adapting portal page we set not existing fields in `invalid_fields` details and because of that it can't find related fields on address page and don't allow to save details without raising proper error message.

Fix:
- Updated `invalid_fields` values to properly target them

### [FIX] account_peppol: fix display issue for peppol related fields in address

Forward-Port-Of: odoo/odoo#281718

Description of the issue/feature this PR addresses:

Odoo supports WebP image fields, but `base_import` validates remote images with `PIL.Image.open()`. Odoo intentionally leaves Pillow's WebP decoder unloaded, so a valid WebP URL is rejected as an unidentified image.

Current behavior before PR:

Importing a valid WebP image URL fails with `cannot identify image file`. Oversized and unsupported WebP files are also rejected by Pillow before the import-specific size policy can be applied.

Desired behavior after PR is merged:

Use Odoo's existing WebP header parser for dimension validation. Valid WebP URLs import unchanged, unsupported WebP remains rejected, and the existing 42-million-pixel import limit remains enforced.

Tests cover valid, unsupported, and oversized WebP URL payloads. The complete `test_base_import` suite passes (56 tests, 0 failures/errors).

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

Forward-Port-Of: odoo/odoo#281829
Forward-Port-Of: odoo/odoo#276648

Steps to Reproduce:
------------------------
- Install the Point of Sale module & create an order with a customer (partner).
- Scan the QR code on the receipt to retrieve the invoice.

Issue:
-------
When clicking `Get My Invoice`, the invoice was not being generated.

Cause:
---------
- The correct partner was not being set. POS customer scanning the QR code is not logged into Odoo, so no partner is associated with the request. We were incorrectly using the logged-in user’s partner, which resulted in an empty partner and therefore an empty VAT value.
- The customer's country was also incorrect because the partner’s country was fetched but then overwritten by the order’s country due to improper value assignment.

Fix:
----
- In most POS scenarios, the customer associated with the order is the one requesting the invoice. Therefore, if no logged-in user is found, we now correctly use the order’s partner to retrieve VAT and other required information.
- The partner's country was corrected by ensuring the values are assigned in the proper order and no longer overridden incorrectly.

task: 5406951

Forward-Port-Of: odoo/odoo#239811

Steps to reproduce:
1. Install CRM
2. Activate the Arabic language with English
3. Create a lead with a new email, a new company name, and the Arabic language
4. Save and try to send a message from the chatter

Issue:
- After the message is sent, the language of Lead is changed to EN from Arabic
- Contacts created with the English language

Cause:
- When we send a message from the chatter of a Lead that has an email_from, a partner_name, and the Arabic language, this forces the creation of a new contact First child contact is created with arabic language, but `parent_name` is present in the creation dictionary, so this triggers `_create_parent_from_name` that builds a dictionary to create the parent company, but it does not pass the language. As a result, the parent company is created with the English language. then `_create_parent_from_name` links the child to this new parent and this linking triggers the `_compute_lang` on the child and overwrites the child's language with the parent's language At last, Lead's own computed field `_compute_lang_id` triggers and sets the language to English

Solution:
- pass the language in the dictionary to create the parent company

opw-6449407

Before this commit, the test "Shows warning badge on mic/camera on non-granted permission in meeting conversations" failed on runbot, on 19.0:

Failed to find 1 of "button[title='Turn camera on']" (Timeout of 10 seconds). Found 0 instead.

This happens because the mock server numbers a new record with the highest id of the model plus one, so a record created right after the last one is deleted takes its id back. Joining another call leaves the meeting call first, and the session of the new call carries the id of the one just left. Leaving broadcasts
"discuss.channel.rtc.session/ended" for that id, and under load it lands after the join: the client reads it as its own session being closed and ends the call it has just joined.

This commit numbers the records of a model with a counter, started above the ids its definition gives, as a database sequence does, so a notification about a deleted record can no longer name a live one.

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

Forward-Port-Of: odoo/odoo#282244

Behavior before:
When uploading an animated GIF to fields utilizing image responsive sizing or cropping (such as employee avatars or product images), no downscaling or cropping occurs for sub-variants like 'image_128' or 'image_1024'. The responsive fields replicate the exact file size and data footprint of the original large image, leading to heavy storage overhead and unnecessary frontend asset loading.

Behavior after:
Animated GIF images scale down and crop correctly to match requested responsive dimensions and aspect ratios. Sub-variants take up significantly less space in the filestore, matching proportional dimensions without dropping or stripping the underlying animation loop. Large images that are smaller than requested boxes are safely left un-upscaled to maximize database deduplication.

Root Cause:
Historically, a legacy safeguard bypassed GIF resizing and cropping because older versions of the Pillow library did not gracefully handle multi-frame sequential image buffers. As a result, standard 'image.crop()', 'image.thumbnail()', or 'image.resize()' implementations would flatten multi-frame animated sequences down into a single, static first frame or throw dimension/mode mismatches during save operations.

Fix:
Intercept the image processing pipeline when encountering an asset identified as a GIF where 'is_animated' evaluates to True. Implemented a unified, in-place multi-frame helper routine (`_apply_gif_operation`) using PIL's 'ImageSequence.Iterator' to cleanly step through, normalize to a uniform color mode (RGBA), duplicate, and modify each animation frame individually. 

This single helper handles sequential workflows for both 'crop' and 'thumbnail' operations while preserving individual frame duration arrays and native loop metadata. Both 'resize' and 'crop_resize' leverage this logic to achieve precise dimensions cleanly.

Crucially, upscaling (expanding) is intentionally unsupported for animated GIFs. Forcing a low-resolution, 256-color indexed animation to stretch beyond its native dimensions forces heavy color dithering across every single frame. This breaks the sequential LZW pattern compression, causing the resulting file sizes to skyrocket catastrophically. The logic utilizes thumbnail boundaries to completely block this expansion, protecting the filestore from accidental bloat.

Benchmark:

--------------------------------------------------------------------------------------------
| GIF size    | Variant          | Size Before (KB)   | Size After (KB)   |
|---------------|--------------------|--------------------------|-----------------------|
| (2.5MB)    | image_1024  | 2475.87                 | 2475.87             |
|                   | image_128    | 2475.87                 |  257.93              |
|---------------|--------------------|--------------------------|-----------------------| 
| (3.8MB)     | image_1024 | 3724.93                 | 3724.93             |
|                    | image_128   | 3724.93                 |  463.62              |
|----------------|-------------------|--------------------------|-----------------------|
| (442KB)     | image_1024 |  432.49                  |  432.49              |
|                    | image_128   |  432.49                  |   36.14               |
|----------------|-------------------|--------------------------|-----------------------|
| (3.6MB)     | image_1024 | 3491.98                 | 3491.98             |
|                    | image_128   | 3491.98                 | 1728.25             |
|----------------|-------------------|--------------------------|-----------------------|

opw-6232841

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#273098