This update aligns enterprise tests with a related community change for project sharing and validated timesheet invoicing. It helps ensure invoicing behavior remains reliable when customers interact with shared projects.

This commit's purpose is to update the test
test_project_sharing_with_validated_timesheet_invoicing by taking into account the change made in the corresponding community PR.

community pr: https://github.com/odoo/odoo/pull/134492

task - 3186700

Event communication templates for social posts and WhatsApp messages now show distinct symbols, making them easier to identify when configuring event messaging. The underlying notification setup was also cleaned up to align with related platform changes, improving consistency across event communication channels.

Copied documents are now automatically given an updated name, making it easier for users to distinguish originals from duplicates. This reduces confusion when managing document libraries and working with copied files, including spreadsheets.

This PR introduces an automated naming mechanism for creating copies of a document.

TaskID: [3515793](https://www.odoo.com/web#id=3515793&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Record merges will no longer add irrelevant technical fields to the activity log. This keeps merge history easier to read and reduces the chance that sensitive technical details, such as access tokens, appear in chatter messages.

When merging two records, all of the fields of the merged record are logged into the master record chatter.
We filter out some fields, such as file fields or fields with access rights, but there are still many irrelevant technical fields and even some potentially sensitive fields (access tokens, etc.) being logged.

Moreover, with [the introduction of the export_string_translation field flag](https://github.com/odoo/odoo/pull/142329), those fields could not even be translated anymore.

The goal of this PR is to exclude fields with the export_string_translation flag set to true from the chatter logs to reduce clutter.

Task-3716421

The Field Service Task Analysis report no longer shows the duplicate “Average Rating” option in the Measures menu. This keeps rating reporting clearer by leaving the intended “Rating (/5)” measure available without confusing users with two similar choices.

Steps:
- Install Field Service and Project module
- Open the Project's Configuration
- Click on the Customer Rating checkbox
- Now, go to the Field Service's Task Analysis
- Click on Measures dropdown

Issue:
- Within the Measures button both 'Average Rating' and 'Rating (/5)' is represeting rating values . Therefore, We don't need 'Average Rating' in 'Measures' dropdown menu.

Cause:
- There is no any field to hide the 'Average Rating' field from the 'Measures'.

Fix:
- Hided the 'Average Rating' field from 'Measures' dropdown menu.

Task-3513873

Steps to reproduce: [account_accountant, sale_subscription] - create two quotations/subscriptions (sales) yearly: one with an analytic account, one without - confirm - create invoice - confirm - Go on Deferred Revenue - Filter Analytic with the one used in your quotation Issue: The analytic filter does not work Solution: We want to make sure to use `_query_get` to be consistent with other report generation and to make the retrieval of lines more easily maintainable opw-3603096 F

Steps to reproduce:
[account_accountant, sale_subscription]
- create two quotations/subscriptions (sales) yearly: one with an analytic account, one without
- confirm - create invoice - confirm
- Go on Deferred Revenue
- Filter Analytic with the one used in your quotation

Issue:
The analytic filter does not work

Solution:
We want to make sure to use `_query_get` to be consistent with other report generation and to make the retrieval of lines more easily maintainable

opw-3603096

Forward-Port-Of: odoo/enterprise#55462
Forward-Port-Of: odoo/enterprise#52622

When the home menu was modified to use the command palette on 2a518bc6, some ARIA attributes were lost that are still required. Such attributes are intended to indicate what is the focused app when no search is performed, i.e. the command palette has not been opened yet. Forward-Port-Of: odoo/enterprise#52570

When the home menu was modified to use the command palette on 2a518bc6, some ARIA attributes were lost that are still required. Such attributes are intended to indicate what is the focused app when no search is performed, i.e. the command palette has not been opened yet.

Forward-Port-Of: odoo/enterprise#52570

Added new module l10n_in_reports_gstr_documents_spreadsheet it allows us to generate a spreadsheet report for gstr1 before sending the json to the portal task-3293298 Forward-Port-Of: odoo/enterprise#55467 Forward-Port-Of: odoo/enterprise#40589

Added new module l10n_in_reports_gstr_documents_spreadsheet it allows us to generate a spreadsheet report for gstr1 before sending the json to the portal

task-3293298

Forward-Port-Of: odoo/enterprise#55467
Forward-Port-Of: odoo/enterprise#40589

Follow up to 8c4445fc63dc01ea0cf359066e3cd21fbac23a7b. The field that was changed in that commit is computed, which is means it's readonly by default. opw-3635484 Forward-Port-Of: odoo/enterprise#55500

Follow up to 8c4445fc63dc01ea0cf359066e3cd21fbac23a7b. The field that was changed in that commit is computed, which is means it's readonly by default.

opw-3635484

Forward-Port-Of: odoo/enterprise#55500

When a user only has access to a branch of a company, there is a lot of places where AccessError pops up because of how the domain was previously set on them. This commit aims to be a part of frequent small PR in the future to fix these problems. This also includes small style improvement for report's dropdown button for Journal filter, to make it clear that company name is not clickable These PRs fixes: - Unaccessible parent company's fields (now accessible) in  - Sales/Purchase O

When a user only has access to a branch of a company, there is a lot of places where AccessError pops up because of how the domain was previously set on them.

This commit aims to be a part of frequent small PR in the future to fix these problems.

This also includes small style improvement for report's dropdown button for Journal filter, to make it clear that company name is not clickable

These PRs fixes:

- Unaccessible parent company's fields (now accessible) in 
	- Sales/Purchase Orders/Quotation form: product variant, product (product_template), and tax
	- Account Move (invoice/bill/etc) line, when filling product
- Access Error as user with only access to branch when:
	- opening Accounting reports (BS / PL)
	- opening PoS dashboard
	- trying to add product when creating new invoice
- Improves Journal access rules. Instead of making all parent's journal public, base the user access on: (explicitly granted access from user allowed companies) or (all self&parent's journal AND journal type is not Bank/Cash) 
- Improves styling on report's Journal dropdown button's style (in enterprise PR)

community-PR: https://github.com/odoo/odoo/pull/140078
enterprise-PR: https://github.com/odoo/enterprise/pull/49820

[task-id: 3551305](https://www.odoo.com/web#id=3551305&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#55484
Forward-Port-Of: odoo/enterprise#49820

This commit fixes some issues that prevented the user from generating a return label in UPS REST module. To reproduce: Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery. There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16: + `_prepare_shipping_data` is changed, so it does not return `package_names` + `label_binary_data` from `_send_shipping` is changed from a dictionary

This commit fixes some issues that prevented the user from generating a return label in UPS REST module.

To reproduce:
Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery.

There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16:

+ `_prepare_shipping_data` is changed, so it does not return `package_names`
+ `label_binary_data` from `_send_shipping` is changed from a dictionary to a list
+ as `package_names` no longer is there, the log message needs to be adapted.

This PR fixes these issues, so that the return label could be generated.

opw-3689861

Forward-Port-Of: odoo/enterprise#55328

This update improves how subscription invoices are handled when payments are pending. Previously, invoices were posted immediately even when the payment transaction was still pending, which could cause processing issues. Now, invoices remain unposted until the payment is confirmed, ensuring cleaner financial records and preventing duplicate processing attempts.

Before this commit, when a pending transaction was created for a subscription payment, the invoice was posted and the pending_transaction flag remained. After this commit, the invoice is not posted and the flag prevent the cron to process the contract again.

taskid: 3685013

The Sign module now requests high-accuracy GPS coordinates when capturing a signer's location. While this may take 20-30 seconds longer, it provides much more precise location data using built-in device GPS rather than quick WiFi-based estimates. This ensures reliable location records for signed documents, which is more important than speed since signers typically have time to wait before submitting their signature.

The Location API allow developpers to specify options when requesting a device's location - notably, it can request 'high accuracy' positioning.

By default, 'high accuracy' is set to false so that the location API returns a position *quickly*. We can assume that it will return a position based on e.g. WiFi networks it sees around it and an API call to a location provider like Google, Apple, Here, etc. Setting 'high accuracy' to high will make this process much slower (20-30s is not gonna be an exception), but it means that devices with built-in GPS will usually provide an far more precise location.

In Sign, it's rather important to have reliable data rather than a quick process.

Assuming a person signing something for real, it's safe to assume that the browser will have the time to provide a precise position before the user submits their signature. If not, the position will simply not be saved.

opw-3677499

Forward-Port-Of: odoo/enterprise#55588
Forward-Port-Of: odoo/enterprise#55411

This update significantly speeds up the process of generating consolidation journals in Odoo, which can be slow when dealing with large databases containing multiple companies and currencies. By implementing a smart caching mechanism for exchange rates, the system reduces unnecessary database queries. Real-world testing shows dramatic improvements—for example, processing 134,000 account entries that previously took 21.6 minutes now completes in just 3.3 minutes.

In databases with multiple companies, currencies and lots of `account_move_lines`, generating consolidations journals can take a lot of time. There are two bottlenecks for that. The first one comes from `_apply_historical_rates`. The second one is the creation of the `consolidation_journal_lines` records. Nothing can be done about the latter as there are just a lot of records to create. This commit focuses on the former.

To speed up `_apply_historical_rates`, a rate_cache is passed through the context to the `get_rate_for` method of consolidation rates. This method is called a lot of times (once by move_line) with mostly the same values (company_id and chart_id are fixed, only the date changes). Adding a small cache vastly reduces the number of queries on `consolidation.rate`.

#### speedup
Customer database with 2.5M account.move.lines, 2M account.moves, 202 consolidation_periods, 243 consolidation accounts, 0 consolidation_rate, 17 companies, 8512 accounts.

Timing to generate consolidation journals.

| #account_move_lines, #res_currencies | Before PR | After PR |
|:----------------------------------------------------:|:--------------:|:-----------:|
| 1036 amls, 2 currencies | 7s | 1.89s |
| 4329 amls, 7 currencies | 2.2min | 19.3s |
| 15301 amls, 7 currencies | 1.4min | 1.4min|
| 43749 amls, 6 currencies | 22.1min | 2min|
| 134055 amls, 7 currencies |21.6min | 3.3min|

The third entry only contains non-historical consolidation accounts so no visible speedup is expected.

Forward-Port-Of: odoo/enterprise#54030

The Invoice Analysis report now includes two new measures to help businesses better understand their financial performance: a "Margin" measure that shows profit on each invoice line based on product costs, and an "Inventory Value" measure that tracks inventory valuation changes. A new "Inventory Valuation" filter has also been added to view inventory value trends by product and month, providing simplified inventory tracking without requiring the full Inventory app.

In order to better analyze profitability, we added an extra measure to the Invoice Analysis report to show the "Margin" on every invoice line based on the product cost price.

In order to have a simplified inventory valuation without fully using the Inventory app, we also added an "Inventory Value" measure that also uses the product cost price to show the change in inventory value based on incoming and outgoing accounting documents.

An extra filter "Inventory Valuation" was added as well to show the "Inventory Value" values per storable product and per month.

[task-3708415](https://www.odoo.com/web#id=3708415&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

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

Fixed an issue where clicking on amounts in analytic reports would show empty results for all analytic plans except the default "Projects" plan. The fix ensures that all analytic plans now properly display the detailed transactions that make up the reported amounts, improving the auditability and usability of financial reports.

When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount.

This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow searching on all plans, and should hence be used in this context.

Fixed a missing instruction in the Documents module tutorial that guides users to close the document preview after opening it. This ensures the tutorial flow is complete and users receive proper guidance at each step of the process.

Before this commit:
During the execution of this tour, at a specific step, we are required to click a document to open its preview. But the prompt to close the preview is missing as the preview opens.

After this commit:
The user is prompted to close the preview.

task-3537521

Forward-Port-Of: odoo/enterprise#54864
Forward-Port-Of: odoo/enterprise#48917

This update fixes visual styling and display issues in the Account Follow-up report. The report now properly shows styling that was previously missing, displays the current date correctly at the top of the report, and prevents errors when maturity dates are not set. These fixes ensure the follow-up reports appear correctly and function reliably for users.

In 17.0, the style applied in the python side was not used in the template.
This commit will add the style classes, change the template used in the python
side since it isn't there anymore and correct a traceback when the date_maturity
 is not set.

Also, a bug fix is applied:
 - the date was not populated on top of the report because the field today is
 only accessible on lines but not on the report itself.


task: 3695867

This fix resolves a crash that occurred when viewing attendance records for employees with split work schedules (like morning and afternoon shifts). The system was incorrectly trying to process multiple schedule entries at once, causing an error. Now it properly handles employees with complex working schedules.

Steps to reproduce:

1) Set your "Working Schedule" for example like this from Monday to Friday

Morning | Morning | 04:00 | 12:00
Afternoon | Afternoon | 12:00 | 22:00

2)  Create a manual attendance record for any employee who is using the above schedule:
Go to Attendances Tree view -> Click on New -> Add a new attendance record -> Add the record with check in for yesterday(in this example Monday) and don't add the check out.

3) Now go back to home and click on attendance and go back to previous day by clicking on "<-" beside days

4)
Error:
  File "/data/build/enterprise/hr_attendance_gantt/models/hr_attendance.py", line 63, in <listcomp>
    expected_worked_hours[emp.id] = sum([(att[2].hour_to - att[2].hour_from) for att in expected_attendances])
  File "/data/build/odoo/odoo/fields.py", line 1148, in __get__
    record.ensure_one()
  File "/data/build/odoo/odoo/models.py", line 5842, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: resource.calendar.attendance(1, 3)

Solution:

We need to consider multiple resource.calendar.attendance in att[2]

This update modifies the Knowledge module's test suite to accommodate a performance improvement in how urgent saves are handled. The system now uses a more efficient method (sendBeacon) instead of the traditional approach, which required the tests to be updated to match this new behavior. This ensures the tests continue to work correctly with the improved save mechanism.

This commit is the counterpart of odoo/odoo#149944 where we use sendBeacon instead of the classical xhr in the case of an urgent save. As a consequence, a knowledge needed to be adapted.

Task 3537838

Forward-Port-Of: odoo/enterprise#55292
Forward-Port-Of: odoo/enterprise#54634

Users were unable to send WhatsApp messages because the system was incorrectly checking archived (inactive) phone numbers against the blacklist. This fix ensures only active phone numbers are checked when validating blacklist status, allowing users to send messages successfully. The change includes improved test coverage to prevent this issue from recurring.

When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted.

Problem:-

By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller.

https://github.com/odoo/odoo/blob/46d94c4bdaec287615e47aac6597f36f498cf8de/addons/mail/controllers/thread.py#L96

Solution:-

We will forcefully pass the `active_test` with `True` while searching blacklisted phone numbers. Due to this archived records will not be searched and it will let the user send the WhatsApp message using the discuss channel.

Task - 3698511

A bug in Odoo 17.0 was preventing WhatsApp messages from being sent to customers who had previously opted back in. The system was incorrectly blocking all messages from numbers in the blacklist, regardless of their active status. This fix ensures that only customers who have actively opted out (sent 'STOP') are blocked from receiving messages, allowing normal conversations to resume.

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line:

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17.0, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

This time, the Active state is not checked, so regardless of whether it's False or True, the message is blocked. This makes it impossible to have a conversation with a customer in Odoo 17.0

The solution is to add ('active', '=', True) to the line in 17.0

if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

Fixed a bug where customers updating their subscription payment method were not seeing a confirmation message after saving. This fix ensures users receive proper feedback when they successfully change their payment method in their account portal, improving the user experience and reducing confusion about whether their action was completed.

After changing the payment method of a subscription, the confirmation message was not displayed on the subscription.

To reproduce:
- prerequisite: setup a test payment provider with tokenization support
- login in as 'portal' user
- Buy a 'Car Leasing' product, on payment choose the preceding payment provider with tokenization
- go to 'My Account', then click on 'Subscriptions'
- choose the order with 'Car Leasing'
- click "Manage Payment Method"
- click on "Save Payment Method"

=> After page reload we should see a message saying that the payment
   method was successfully changed, but no message are displayed.

Forward-Port-Of: odoo/enterprise#48671

This update fixes a critical issue in the attendance app where work schedules with no break periods (such as split shifts like 8am-12pm and 12pm-5pm on the same day) were causing errors. Users can now properly view their weekly attendance reports without encountering system errors, improving the reliability of attendance tracking.

Steps to reproduce:
- Install attendance app
- Setup working schedule with no break like so (Mon 8-12h), (Mon 12-17h)
- Check attendance for the week

Issues:
Traceback is displayed

opw-3705883
opw-3706118

The monthly declaration tests for Luxembourg payroll were failing because they referenced 2022, which is no longer a valid year in the system. This fix freezes the test date to December 31, 2022, ensuring the tests remain valid and preventing similar issues in the future.

These tests are testing the monthly declaration in 2022. As of today, 2022 is no longer a valid year in the wizard, thus causing the tests to fail.

In order to ensure that such an issue won't happen again, we will freeze the time for these tests to dec 31 2022, so that the year will always be valid.

Forward-Port-Of: odoo/enterprise#55583

This update fixes a bug where menu options for pivot and list properties were incorrectly displayed when a spreadsheet formula referenced a non-existent data source. Users would encounter an error when clicking these menu items. The fix ensures these menu options are now hidden when the referenced data source doesn't exist, preventing confusion and errors.

The menu actions to access the pivot & list properties were visible when the formula was referring to an inexisting datasource. Clicking on the said action would then traceback as ce cannot find a datasource.

Task: 3670824

Forward-Port-Of: odoo/enterprise#55529
Forward-Port-Of: odoo/enterprise#54675

A test in the subscription module was failing when run during the month of February due to date-related logic. This fix ensures the test runs reliably regardless of the current month, improving the stability of our automated testing process.

runbot ticket: 56443

Forward-Port-Of: odoo/enterprise#55622
Forward-Port-Of: odoo/enterprise#55406

This fix ensures that when an analytic distribution is assigned to a bank transaction's counterpart, the analytic column now properly displays in the bank entry preview. This improves visibility and accuracy when reviewing bank reconciliations with analytic allocations.

When an analytic distribution is set on the counterpart of a bank transaction, the analytic column should appear in the preview of the bank entry.

task-3687839

Forward-Port-Of: odoo/enterprise#55354
Forward-Port-Of: odoo/enterprise#54837

Fixed a bug in the Data Cleaning app that caused the application to crash when users applied custom filters on Company fields using "contains" or "not contains" operators. The issue was caused by improper handling of special characters in database queries, which has now been resolved to ensure filters work correctly.

Steps to reproduce:
-------------------
In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator.

Issue:
------
A traceback occurs.
For this line: `res = self._obj.execute(query, params)`, we have `IndexError: list index out of range`.

Cause:
------
There is a mismatch between the `%` in the query and the number of parameters.

The query is constructed by combining subqueries with a template. These subqueries will be determined using the `mogrify` method and will be concatenated to the main query template.
The `'` characters are correctly escaped with `\` , but the `%` characters are not.

Solution:
---------
Don't use mogrify, so that we can keep the subquery parameters
and pass them directly to the main query.
By leaving the values wrapped with `%` in the parameters,
there are no more escape problems.

Note:
This is a better fix than manually escaping the `%` if necessary like:
```py
if operator in ('not ilike', 'ilike'):
	value = f'%{value}%'
```

opw-3668433

Forward-Port-Of: odoo/enterprise#55204
Forward-Port-Of: odoo/enterprise#54287

This fix resolves an issue in the Helpdesk module where customer email addresses were not being saved correctly on support tickets. The email field is now properly set when creating or updating helpdesk tickets, ensuring that support teams can reliably contact customers and maintain accurate customer records.

Forward-Port-Of: odoo/enterprise#55491

This fix resolves an issue where the status bar field (showing project stages) was not updating correctly when switching between projects. The problem occurred because the system was using outdated information when retrieving stage data, causing the wrong stages to display. This fix ensures the status bar always shows the correct stages for the currently selected project.

Steps to reproduce
==================

- Create a new project
- Add a few new stages
- Go back to the project overview
- Select another one
- Open any task
- Click on the new button
- Change the project

The status bar field containing the stages is not correctly updated

Cause of the issue
==================

The StatusBarField uses the useSpecialData hook.
This then uses the useRecordObserver hook which calls the callback after
a new animation frame. By that point, the props are out of date and the
search_read uses the incorrect domain

Solution
========

opw-3693113

This fix addresses an issue where invoices in Kenya were generating final PDFs before being sent to the fiscal device, resulting in missing legal information. The system now generates a proforma invoice when legal information is unavailable, ensuring compliance with fiscal requirements. Users receive a warning when a proforma is generated due to the invoice not being sent to the fiscal device.

With Kenya localization installed
Create an invoice
Send&Print

Issue: The sytem will issue the final pdf before the invoice has been send to the fiscal device, so the legal information is actually missing A solution is to generate a proforma pdf invoice when the legal info is still missing

Removing call to `_hook_invoice_document_after_pdf_report_render` as it seems intended to add a legal layer not needed in proforma invoice

opw-3599869

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

This update makes the automatic save feature more reliable when users close a form with unsaved changes. Previously, changes could be lost if the network connection was poor or the data was large. The system now uses a more dependable method to ensure data reaches the server, and alerts users if the data is too large to send automatically, prompting them to save manually.

In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving.

Before this commit, there could be situations where the changes weren't actually saved. For instance, if they involved an heavy payload for the write rpc, or if the network connection was poor, it might happen that the xhr is killed. Or at least, browsers do not offer any guarantee to wait for those xhr to reach the server.

Instead of a classical xhr, we thus use navigator.sendBeacon which ensures that the data will be sent reliably [1]. There's a drawback though, as its payload is limited. When the payload is too heavy, sendBeacon simply returns false and does nothing. In this case, we prevent the page from unloading and display a notification suggesting the user to manually save his changes before leaving.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

Task 3537838

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#151448
Forward-Port-Of: odoo/odoo#149944

This fix resolves an issue where WhatsApp messages were not being properly blocked when sent to blacklisted phone numbers. In Odoo 17, a system change inadvertently removed the check for whether a number was actively blacklisted, allowing messages to be sent to customers who had requested to stop receiving communications. The fix restores proper message blocking while maintaining other system improvements.

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

I correct it in a PR https://github.com/odoo/enterprise/pull/55498

But if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.

opw-3704136

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

This fix resolves issues with the color picker tool in the project module. Previously, the color picker would open in the wrong direction, either appearing as a dropdown when there wasn't enough space (making it inaccessible) or always opening as a dropup on subsequent uses. Now the color picker intelligently opens upward when space is limited and downward when space is available, ensuring users can always access the full color selection tool.

**Current behavior before PR:**

- In the project module, when a user opens the color picker, it opens as a dropdown even if there is not enough space available, resulting in some parts of the color picker being inaccessible.
- In the project, when a user opens the color picker a second time, it always opens as a dropup, even if there is space available for it to open as a dropdown.

**Desired behavior after PR is merged:**

- Now, when a user opens the color picker, it opens as a dropup when there is not enough space available for the color picker to open as a dropdown.
- The color picker will open as a dropdown when there is enough space available.

task-3608803

Forward-Port-Of: odoo/odoo#151681
Forward-Port-Of: odoo/odoo#144698

This fix resolves a technical error that occurred when confirming multiple sales orders in batch (such as through automated tasks). The system was incorrectly trying to check user permissions on multiple records at once, which caused it to crash. The fix ensures the permission check works properly regardless of how many orders are being confirmed together.

Thanks to changes in 82314364c6029a83 the auto-lock settings also works for public users. But, going from `self.env.user` to `self.create_uid` to check the group leads to a traceback when `self.create_uid` is not a singleton. This is because `has_group` expects a single record.

To fix that, this commits checks the group of the create_uid of the first record in self. Because `sale.group_auto_done_setting` is an implied_group of a res.config.settings parameter, it's enough to only check for the first record in the recordset.

To reproduce:
 - Install sale
 - Create a quotation as Mitchell Admin
 - Create a quotation as Marc Demo
 - Create a cron that searches on all draft sale.orders and confirm them in batch
 - Run the cron -> Singleton Error

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

Forward-Port-Of: odoo/odoo#151903
Forward-Port-Of: odoo/odoo#151789

This fix resolves an issue where data inconsistencies between time off allocations and leave requests would incorrectly block employees from taking time off and affect their dashboard calculations. The update refines the validation logic to only flag issues directly caused by the leave request itself, while still warning about other data problems. Additionally, the fix significantly improves dashboard performance, reducing load time from 0.6 seconds to 0.04 seconds.

Before this commit, discrepancies between
leaves and allocations for an specific employee
and a specific time off type would have prevented
the employee from taking any time off for that
time off type.
It would also affect their dashboard.

__How to reproduce the issue:__
- time off type without negative amount
- create 2 allocations: last year and this year
- create a leave last year
- remove last year allocation from DB
- you cannot take leaves this year
- dashboard amount is affected by last year's leave

__Changes brought with this commit:__
This commit keeps the logic identical for negative time off types. However, for the others, the
check ensuring the allocation validity for the
leave will now check the discrepancies before and after a time off creation or modification. The error
will be thrown if the discrepancies have changed, meaning that the leave had an effect on it. This way, any
other issue will not prevent leave creation.
Those leaves are still noticeable through the warning though, meaning that they can be noticed and dealt with accordingly.


Perf fix:
=======
Before
![image](https://github.com/odoo/odoo/assets/8435879/74332ff8-3dc6-4b9f-9899-89cabde804d1)
After
![image](https://github.com/odoo/odoo/assets/8435879/1f9e0383-6425-4495-8e27-048eac799a72)

This fix improves the Stripe payment form to properly handle and display errors when payments fail due to amount restrictions or other issues. Previously, users would see technical error messages or tracebacks when attempting invalid payments. Now, clear error messages are shown both when the form loads and when users try to submit, providing a better experience for customers attempting to make purchases.

Steps to reproduce:
1) Try to make a payment with the amount less than 0.50$ (minimum amount required in Stripe)
2) Stripe inline form fails to load
3) One can still click pay and see the traceback

After this commit the error are handled and displayed on the form loading and on the form submit.

opw-3634316

This fix ensures that the mobile version of ecommerce checkout steps can be properly translated into different languages. Previously, the way text was formatted in the code prevented translation systems from recognizing these strings. The fix reorganizes how the text is written so that translation tools can correctly identify and translate all checkout step labels for international customers.

Appending strings within a `t-out` for a website template makes it so that it can never be translated. Instead the string should be written like normal text so that it is correctly seen as to be translated and `t-out` only the next step so that it's also correctly matched as to be translated.

opw-3700815

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

The sales portal was displaying the wrong address as the invoicing address—it was showing the main sales order address instead of the actual invoicing address. Additionally, the edit button for updating the customer's main address was appearing incorrectly next to the invoicing address even when the sales order didn't belong to the customer or when the invoicing address differed from the main address. This fix ensures the correct address is displayed and the edit button only appears when appropriate.

The address displayed as 'Invoicing address' was
the main SO address and not the invoicing one.

Also, the pencil icon link to update the customer main address was always displayed next to the invoicing address, even if:

* the so does not belong to the customer
* the invoicing address is different than the customer main address

This commit fixes those two issues.

opw-3653190


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

This fix resolves a bug where the status bar field in task forms would display incorrect stage options when switching between projects. The issue occurred because the system was using outdated information when loading the available stages, causing the wrong stages to appear either immediately or after saving. This fix ensures the status bar always displays the correct stages for the currently selected project.

Before this commit, there was a race condition with the statusbar field, and more specifically with the useRecordObserver.

The issue could be reproduced in the form view of project.task. In an existing task, belonging to a project with some stages, change the project to another project with its own stages. It might happen that the displayed stages weren't the one of the newly set project. If this didn't happen directly, this happened upon saving (i.e. the correct stages are displayed just after switching the project, but as soon as the user saves the record, the former stages are back).

This happens because of useRecordObserver used an outdated version of the props to get the domain (i.e. the props of the component have been updated, but useRecordObserver still used the old version, in particular the old props.domain).

This commit fixes the issue by ensuring that we always use the last version of the props.

opw 3693113

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

This fix corrects the positioning of dropdown menu carets (small arrows) in the Pivot view, which were incorrectly placed after a previous update. A prior change that was needed for Search Bar menus is no longer necessary since those menus were converted to accordions, allowing us to remove it and restore proper caret alignment in dropdowns.

[Commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) introduced necessary change to resolve a layout issues on the caret icon in the Search Bar menus. But at the same time, it introduced a layout issue on dropdowns in the Pivot view: carets were no longer placed on the right.

But since [commit [2]](https://github.com/odoo/odoo/commit/976491e01272336bc34abcdcec2718f83e19c5fc), the Search Bar menus have become accordions instead of dropdown menus. The change made in [commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) is therefore no longer necessary. We can now remove it to fix dropdown menus in the Pivot view.

task-3718186

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-02-02 à 10 00 29](https://github.com/odoo/odoo/assets/80679690/8297220b-9ded-41a5-8948-13338f70c1b0)  | ![Capture d’écran 2024-02-02 à 10 00 01](https://github.com/odoo/odoo/assets/80679690/bd6ae365-8683-40e2-bb24-6d8c50a12f94) | 

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

This fix corrects the positioning of dropdown arrow icons in the Pivot view, which were incorrectly placed after a previous layout change. Since the Search Bar menus were converted to accordions, the original workaround is no longer needed and has been removed, restoring proper dropdown functionality.

[Commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) introduced necessary change to resolve a layout issues on the caret icon in the Search Bar menus. But at the same time, it introduced a layout issue on dropdowns in the Pivot view: carets were no longer placed on the right.

But since [commit [2]](https://github.com/odoo/odoo/commit/976491e01272336bc34abcdcec2718f83e19c5fc), the Search Bar menus have become accordions instead of dropdown menus. The change made in [commit [1]](https://github.com/odoo/odoo/commit/6375ca94cdfe27fc617565ef6bba4826d112e740) is therefore no longer necessary. We can now remove it to fix dropdown menus in the Pivot view.

task-3718186

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-02-02 à 10 00 29](https://github.com/odoo/odoo/assets/80679690/8297220b-9ded-41a5-8948-13338f70c1b0)  | ![Capture d’écran 2024-02-02 à 10 00 01](https://github.com/odoo/odoo/assets/80679690/bd6ae365-8683-40e2-bb24-6d8c50a12f94) | 

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

A bug in the Stripe Express Checkout feature was causing incorrect total payment amounts to be calculated. The system was concatenating the order amount and delivery cost as text instead of adding them as numbers, resulting in wrong totals being charged to customers. This fix ensures amounts are properly converted to numbers before calculation.

The total amount is computed by adding the order amount and the delivery amount. The order amount was provided as a string, and the computation didn't convert it to a number before adding it to the delivery amount. As a result, the amounts were concatenated instead of added, yielding an incorrect result.

opw-3614909
opw-3664682

This fix resolves an issue where the "force post" option was not working correctly in the account move validation wizard. Previously, when users tried to force post an auto-scheduled move, the system would incorrectly reject the action. Now users can successfully override the auto-post setting when needed through the validation wizard.

Force post does not work in the validate account move wizard.

Steps:

- Create a move in the future and set it to be auto post
- On the list view, select the move and select action "post entries"
- On the wizard, check "force" and validate
-> UserError "This move is configured to be auto-posted ..."

Forward-Port-Of: odoo/odoo#152271
Forward-Port-Of: odoo/odoo#152003

This fix resolves a bug in the web editor where deleting completed checklist items would incorrectly mark subsequent uncompleted items as done. Users can now safely delete completed checklist items without affecting the status of other items in the list.

Current behavior before PR:

When in a checklist where first and second checklist are marked done after selecting first and second checklist and deleting it the third checklist would be marked as done.

Desired behavior after PR is merged:

Now deleting previous done checklist would not affect the current checklist.

task-3203889

Forward-Port-Of: odoo/odoo#151778
Forward-Port-Of: odoo/odoo#134619

Innovyou (innoviù Srl) has been added as a corporate contributor to the Odoo project by signing the Corporate Contributor License Agreement (CLA). This legal documentation update allows the company to officially contribute to Odoo's development.

On behalf of: @innovyou info@innovyou.co

Description of the issue/feature this PR addresses:

Added corporate signature for Innovyou (innoviù Srl).