Internal users now receive a dedicated signature request activity instead of a generic to-do when their signature is needed. Opening that activity takes them directly to the signature request, reducing extra steps and making document signing faster.

In this commit,
- Change the activity type to request signature from to-do type when user create sign request for internal user.
- Prevent opening wizard for request signature activity when the record is linked to signature record and open signature request directly for the user.

task-4369848

The IoT Box communication format has been simplified to make message handling easier to maintain. This should reduce complexity behind connected workflows such as delivery, reporting, and self-ordering without changing the user experience.

The websocket messaged handling on the IoT Box was hardly readable. The message structure has been simplified, as well as the message handling.

Enterprise PR: odoo/odoo#207741
Task: 4756709

The Mexican e-invoicing flow now supports linking multiple related CFDI documents, aligning with SAT CFDI 4.0 requirements. This helps businesses correctly document invoice relationships across invoices, payments, POS orders, and stock transport records.

As per updates from the Mexican Tax Authority (SAT) regarding the CFDI 4.0 changes, it is now possible to link more than one CFDI. For this. Is required to use as many nodes as necessary to link the relevant CFDI.

This commit introduces the possibility to add multiple cfdi divided by multiple relations

target: master
task-4376007

The Belgian VAT listing report no longer flags customers just because their country is missing. This reduces unnecessary blocking checks when preparing Belgian tax reporting, helping users complete the VAT listing with fewer false issues.

task-4627315

Recruitment and referral screens have been refreshed to make key actions easier to find and forms easier to use. Job posting details, reporting views, and related settings were also adjusted so recruiters see clearer information in the right places.

hr_recruitment
- Remove the `Referral Campaign` cog menu button in `hr_job` form view and replace it with an action button to be more discoverable.
- Revamp the `Referral Campaign` wizard form view to improve usability.
- Show `Mission Dates` on Job Position form view only when job_boards (hr_recruitment_integration_base) is installed

hr_recruitment_reports
- made the changes for the Reports views

hr_recruitment_extract
- made the changes for the settings views

Task: 4463696

Users can more smoothly reorder items in grouped list views where supported. This update aligns related reporting and customization screens with the latest list-view behavior, reducing inconsistencies when working with ordered records.

*: account_reports, web_studio

This commit removes the parameter of list renderer's getActiveColumns method in its extensions as it is no longer useful due to https://github.com/odoo/odoo/pull/207198

Part of task-4613142

This update broadens annual closing support from Belgium-specific handling to a more generic process across localizations, while also including related accounting and reporting adjustments. It helps businesses manage year-end accounting workflows more consistently across countries.

Some follow-up items to fix after the shop floor redesign from [1].
Please refer to the individual commits for details about the different fixes.

[1] https://github.com/odoo/enterprise/pull/80469

task-4731403

Journal entries now include start and end date fields, making it easier to manage and review deferred revenue and expense periods. The workflow also avoids showing an unnecessary error when generated entries exist, opening the relevant entries instead.

1. Added 'Start Date' and 'End Date' fields on journal entry views and allow inserting start date and end date for all entries

2.Do not pop ''No entry to generate.'' error message open the the list view or form view in more than 1 of the generated entries.

task-4636850

This update adds a way to record when a WhatsApp contact was last seen. It helps teams better understand recent customer activity and can support more timely follow-ups.

PR community: https://github.com/odoo/odoo/pull/170690

The field service sales product catalog now better supports organizing products into sections, making orders easier to structure and review. Related stock and sales tests were updated to keep these workflows reliable as the catalog behavior evolves.

Invoice and sales documents now keep the correct tax column behavior when Avatax is used. This prevents tax columns from being shown or hidden incorrectly, improving consistency for customer-facing documents and portal views.

Before this fix, inherited views from account_avatax and sale were overwriting 
attributes from the community modules, causing the tax column to behave 
incorrectly in certain cases. This update ensures that both the Avatax-specific 
logic and the original community template logic are applied correctly,
preserving consistent tax column behavior.

Implementation Details:
- Using a separator, both conditions are now integrated into the inherited views.
- If is_avatax is true, the tax column will be hidden to follow the 
  Avatax-specific behavior.
- If is_avatax is false, the tax column will be displayed according to the 
  display_taxes logic, ensuring accurate visibility based on tax application 
  in order/invoice lines.

This change prevents overwriting the original conditions from the account and sale modules, ensuring better compatibility with the community code.

Community: odoo/odoo#205166
Upgrade: odoo/upgrade#7594

task-4705734

Users can no longer try to create AI tools from the related search window in AI topic setup. This avoids an error screen and keeps AI tool creation limited to the intended workflow.

When attempting to create an AI tool from the 'Search More' view within the ai.topic form view, a traceback occurs. This change resolves the issue by restricting the creation of ai.tool from that view, as ai.tool is not intended to be generated on the fly by users.

Long document names no longer cause action buttons in the document preview header to shift out of alignment. On larger screens, these actions are grouped under the More menu to keep the viewer clean and easier to use.

Steps to Reproduce:
1. document with long title
2. Upload document
3. preview the document

When a document had a long title, action buttons in the DocumentsFileViewer
header became misaligned.

After this commit:
If the screen is not small, all action buttons are moved inside the More
dropdown to maintain alignment.

Task-4600177

The Timesheets Analysis report has been removed from timesheet-related modules. This simplifies the available reporting options and may affect users who previously relied on this specific report for reviewing timesheet data.

task-4047790

This refactor standardizes the test setup for Point of Sale-related modules by using shared products with simple prices and tax rates. It makes future testing easier and removes or merges duplicated backend tests where equivalent frontend coverage already exists, with no expected change for everyday users.

*: l10n_br_edi_pos, l10n_ke_edi_oscu_pos

The aim of this commit is to make test writing easier, by choosing
easy-to-calculate prices with their corresponding taxes.

The products created have prices of 10 or 20 with taxes of 5, 10 or 15
percent.

A global class will be created and inherited by all Point of Sale tests,
with the aim of always using products already available. If a different
product is required in a specific test, existing products can be
modified.

---

Test in file: `point_of_sale/tests/test_point_of_sale_flow.py`:

- Test `test_order_refund_lots` is removed and adapted in the frontend
tour `test_lot`

- Test `test_order_to_invoice` is removed because frontend is already
testing this behavior, related tests:
    - Test `test_02_pos_with_invoiced`
    - Test `test_order_and_invoice_amounts`
    - And more in submodules...

- Test `test_order_with_deleted_tax` is removed because it is using
`sync_from_ui` method which should not be used in the backend.
Frontend tours are already testing its behavior

- Test `test_order_refund_picking` is merged with `test_order_to_picking`

- Test `test_order_with_different_payments_and_refund` is removed
because its description don't correspond to the actual behavior of the
test. The goal of the test isn't clear.

- Test `test_product_combo_creation` is removed because its already
tested in owner module.

- Test `test_order_refund_with_owner` was merged with the frontend
test `test_lot`

- Test `test_change_is_deducted_from_cash` was merged with the frontend
test `test_tracking_number_closing_session`

This update standardizes how linked record values are handled across Odoo screens such as forms, lists, kanban views, documents, accounting, appointments, helpdesk, field service, and knowledge. The change is mostly internal, helping the platform support richer related information while keeping standard server data calls unchanged.

Currently, in the RelationalModel, the value of a many2one is represented by an Array [id, display_name].
In the PR [1], we already introduced a change on their value. The value is still an Array but properties are set on it too. This allows to add relatedFields on many2ones.
With this commit, we fully replace the array value by an object thus properties 0 and 1 are not available anymore.
Calling an orm method like read or search_read still gives the array representation, the change is done only by using RelationalModel (in form view, list, kanban, fields, etc.).

[1]: https://github.com/odoo/odoo/pull/202534

task-3547961
task-4658840

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves. The assumption is that rec

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#81440
Forward-Port-Of: odoo/enterprise#79255

### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of material for a final product FP with one raw: - 3 x COMP (storable product with 10 units in stock) - Create and confirm an MO for 1 unit of FP. > This create a picking from stock to preprod for 3 unit of COMP - In the shopfloor on your MO click on the 3 dots and add components - Register

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#83555
Forward-Port-Of: odoo/enterprise#81818

### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP. ### Steps to reproduce: - Install UK accounting and select UK's company: the currency will be GBP - Install and set up Fedex Integration - Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type - Create a sale order,

### Issue:

Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP.

### Steps to reproduce:

- Install UK accounting and select UK's company: the currency will be GBP
- Install and set up Fedex Integration
- Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type
- Create a sale order, add shipping and get the shipping rate for your set up fedex UK.
#### > Fedex request error: `CURRENCY.TYPE.INVALID`

### Cause of the issue:

The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error.

### Fix:

We should use the currency conversion available between GBP and UKL.

opw-4712354

Forward-Port-Of: odoo/enterprise#83388

## Display Callee Suggestions The dialer's "Show More" button - which appears when your search returns more than one result - can now be clicked and open a list of all the results, grouped by whether they match the contact's name or phone number. ## Separate Dialer from Keypad The "keypad" part of the Dialer component is extracted into its own component, as it will be reused in the upcoming Transfer view. ## Improve i18n support Normalization helpers needed by the match function are add

## Display Callee Suggestions
The dialer's "Show More" button - which appears when your search returns more than one result - can now be clicked and open a list of all the results, grouped by whether they match the contact's name or phone number.

## Separate Dialer from Keypad
The "keypad" part of the Dialer component is extracted into its own component, as it will be reused in the upcoming Transfer view.

## Improve i18n support
Normalization helpers needed by the match function are added. These are more complete than the ones in web/ and are based, among other things, on the list of characters handled by PostgreSQL's unaccent function. At some point it'd be nice to move the helpers to web.

Part of task-4642428

Forward-Port-Of: odoo/enterprise#84013

In the VAT report return, we check that there are no draft moves in the period. However, we only want customer invoices and bills, MISC entries should not be included in the check. task-4627315 Forward-Port-Of: odoo/enterprise#84046

In the VAT report return, we check that there are no draft moves in the period. However, we only want customer invoices and bills, MISC entries should not be included in the check.

task-4627315

Forward-Port-Of: odoo/enterprise#84046

fix wrong formulas in different tables: - in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed" - in "worst contraction", the 10th line didn't use the list 4 like the rest of the table - in "top expansion", the 10th line didn't use the list 2 like the rest of the table Task: 4711532 Forward-Port-Of: odoo/enterprise#84242 Forward-Port-Of: odoo/enterprise#83019

fix wrong formulas in different tables:
- in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed"
- in "worst contraction", the 10th line didn't use the list 4 like the rest of the table
- in "top expansion", the 10th line didn't use the list 2 like the rest of the table

Task: 4711532

Forward-Port-Of: odoo/enterprise#84242
Forward-Port-Of: odoo/enterprise#83019

This PR updates the chevron icons with the OI version to remain consistent with the frontend design. task-4720641 Requires: - https://github.com/odoo/odoo/pull/205691 | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/ente

This PR updates the chevron icons with the OI version to remain consistent with the frontend design.

task-4720641

Requires: 
- https://github.com/odoo/odoo/pull/205691

| Before | After |
|--------|--------|
| ![Capture d’écran 2025-04-11 à 12 07 07](https://github.com/user-attachments/assets/8aa3a28b-6ddc-4a15-9b5a-d07d53556ef6) | ![Capture d’écran 2025-04-11 à 12 10 08](https://github.com/user-attachments/assets/d93c2b5c-d277-4a5e-9079-63879f4622d3) |

Forward-Port-Of: odoo/enterprise#83293

Forward-Port-Of: odoo/enterprise#84237

Forward-Port-Of: odoo/enterprise#84237

Forward-Port-Of: odoo/enterprise#84038 Forward-Port-Of: odoo/enterprise#83992

Forward-Port-Of: odoo/enterprise#84038
Forward-Port-Of: odoo/enterprise#83992

This is illegal. https://runbot.odoo.com/odoo/error/161658 Forward-Port-Of: odoo/enterprise#84270

This is illegal.

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

Forward-Port-Of: odoo/enterprise#84270

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Duplicate the delivery
* Validate both deliveries delivery
> Observation: I have 4 jobs send for printing instead of 2

Why the fix:
------------
Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1

as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46

opw-4526013

Forward-Port-Of: odoo/enterprise#82091

### Steps to reproduce: - Accounting dashboard - Click on the three dots of the "Bank" card - Click "import file" - Try importing a CAMT file with the namespace "camt" - Traceback Other issue: - Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1") - Traceback ### Cause: Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace ke

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

- Set default `filter_account_type` to 'receivable' in follow-up report view for more relevant results. - Update the selection of default journal types to 'sale', 'bank' and 'cash' for follow-up reports. opw-[4724675](https://www.odoo.com/odoo/project/967/tasks/4724675), [4735031](https://www.odoo.com/odoo/project/967/tasks/4735031) Forward-Port-Of: odoo/enterprise#84214 Forward-Port-Of: odoo/enterprise#83513

- Set default `filter_account_type` to 'receivable' in follow-up report view for
  more relevant results.
- Update the selection of default journal types to 'sale', 'bank' and 'cash'
  for follow-up reports.

opw-[4724675](https://www.odoo.com/odoo/project/967/tasks/4724675), [4735031](https://www.odoo.com/odoo/project/967/tasks/4735031)

Forward-Port-Of: odoo/enterprise#84214
Forward-Port-Of: odoo/enterprise#83513

In this commit, --------------- When multi-domains are configured in Odoo, it will generate various webhooks at UrbanPiper, which leads to the creation of duplicate draft orders along with the original order. Added a check to restrict duplicate orders with the same delivery ID and the same delivery provider. task - 4727174 Forward-Port-Of: odoo/enterprise#84182 Forward-Port-Of: odoo/enterprise#83583

In this commit,
---------------
When multi-domains are configured in Odoo, it will generate various webhooks at UrbanPiper, which leads to the creation of duplicate draft orders along with the original order. Added a check to restrict duplicate orders with the same delivery ID and the same delivery provider.

task - 4727174

Forward-Port-Of: odoo/enterprise#84182
Forward-Port-Of: odoo/enterprise#83583

Interaction with the amazon marketplace models requires sales admin access. Furthermore, these accesses are also necessary during the `l10n_es_sale_amazon` tests (which use this setup), so adding then removing the group for the setup or locally using `sudo` doesn't seem like a great option. https://runbot.odoo.com/odoo/error/163666 Forward-Port-Of: odoo/enterprise#84262

Interaction with the amazon marketplace models requires sales admin access. Furthermore, these accesses are also necessary during the `l10n_es_sale_amazon` tests (which use this setup), so adding then removing the group for the setup or locally using `sudo` doesn't seem like a great option.

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

Forward-Port-Of: odoo/enterprise#84262

When the user tries to reply a whatsapp message, a traceback will appear. Steps to reproduce the Error: - Install ``whatsapp`` and ``contacts`` module - Go to WhatsApp > Configuration > WhatsApp Business Account > create a new account > Default Users: Mitchell Admin > Save - Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp > Send a message with any template - Contact will receive the message > Reply to that whatsapp message Traceback: ``` UniqueViolation d

When the user tries to reply a whatsapp message,
a traceback will appear.

Steps to reproduce the Error:
- Install ``whatsapp`` and ``contacts`` module
- Go to WhatsApp > Configuration > WhatsApp Business Account >
  create a new account > Default Users: Mitchell Admin > Save
- Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp >
  Send a message with any template
- Contact will receive the message > Reply to that whatsapp message

Traceback:
```
UniqueViolation
duplicate key value violates unique constraint "discuss_channel_member_partner_unique"
DETAIL:  Key (channel_id, partner_id)=(84, 175) already exists.
```

https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to
``partners_to_notify`` multiple times.
Channel members should be unique.
So, when it tries to create ``channel_member_ids`` with same partners,
It will lead to the above traceback.

1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219

2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249

sentry-6252537579

Forward-Port-Of: odoo/enterprise#83908

current implementation of `_get_linked_record_action` searches in `ir.actions.act_window` model to fetch data to create action for `Back button`, a user might not have access to the this model which comes from "Settings/Administration" group, this leads to Access Error steps to reproduce: 1. install sign and sales module 2. login with demo user 3. create a sign template 4. open a sale order and request a sign 5. sign the document 6. Access error (though the document is signed properly)

current implementation of `_get_linked_record_action` searches in `ir.actions.act_window` model to fetch data to create action for `Back button`, a user might not have access to the this model which comes from "Settings/Administration" group, this leads to Access Error

steps to reproduce:
1. install sign and sales module
2. login with demo user
3. create a sign template
4. open a sale order and request a sign
5. sign the document
6. Access error (though the document is signed properly)

[opw-4575288](https://www.odoo.com/odoo/project/49/tasks/4575288)

Forward-Port-Of: odoo/enterprise#83138

This is a fix for a bug that happens from time to time. It was reported more than once that another user was viewed as a caller instead of the actual caller. This happened because when someone calls from a local number, they have a `0` at the beginning of their number. For that case, we use a wildcard that matches anything that the phone number is a suffix to. So, it happened that it matched more than one number when the calling local number is a suffix to more than one international number.

This is a fix for a bug that happens from time to time. It was reported more than once that another user was viewed as a caller instead of the actual caller.

This happened because when someone calls from a local number, they have a `0` at the beginning of their number. For that case, we use a wildcard that matches anything that the phone number is a suffix to. So, it happened that it matched more than one number when the calling local number is a suffix to more than one international number. Then, the code just picks the first one randomly, which may be incorrect.

This commit fixes this bug by removing the logic of using a wildcard when the call is made through a local number. Instead, we use an exact match.

Task-4707543

Forward-Port-Of: odoo/enterprise#84129

When submitting message templates to the WhatsApp API, the request could occasionally time out before receiving a response. This resulted in templates being created on Facebook's side, but not registered in Odoo, as the template ID assigned by Facebook was never received. Since template names must be unique, resubmitting the same template fails, leaving the systems out of sync. This commit increases the request timeout to (10s connect, 30s read) to reduce the chance of timeouts. opw-470

When submitting message templates to the WhatsApp API, the request could occasionally time out before receiving a response. This resulted in templates being created on Facebook's side, but not registered in Odoo, as the template ID assigned by Facebook was never received.

Since template names must be unique, resubmitting the same template fails, leaving the systems out of sync.

This commit increases the request timeout to (10s connect, 30s read) to reduce the chance of timeouts.

opw-4706852
opw-4720635

Forward-Port-Of: odoo/enterprise#84209
Forward-Port-Of: odoo/enterprise#83581