The GSTR return period form now hides the tax unit option when no tax unit is available. This keeps the form cleaner and avoids showing users an irrelevant choice.

In this PR
-------------

**[IMP] l10n_in_reports_gstr: hide tax unit if not available**
- This commits hides the tax unit for gstr return period form if no tax unit is available

task-3679488

The online sales templates for rentals and subscriptions were simplified after related product page caching was removed. This keeps the website sales experience aligned with platform changes and should make future maintenance easier without changing visible business workflows.

Now that the cache has been removed from product page, those templates (or part of) can be simplified.

See also:
https://github.com/odoo/odoo/pull/145532
https://github.com/odoo/upgrade/pull/5422

The point-of-sale order tracking and preparation display apps now use a shared startup process instead of repeated setup code. This makes the apps easier to maintain and should reduce the chance of future inconsistencies, with no expected change for everyday users.

pos*: pos_order_tracking_display, pos_preparation_display

There are multiple owl apps in the pos ecosystem.
For each app we follow a similar pattern of instantiation. This means that code is repeated, which has often lead to a worse developer experience.

In this commit we create a common function that performs all the steps needed when starting an owl app and we adapt the codebase to use it.

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

Task: 3701400

The pivot cell autofill feature has been reorganized so its code now lives in the Spreadsheet Edition app, where the feature is used. This is an internal cleanup that should make future maintenance easier without changing how users work with spreadsheets.

Add a l10n_ph_reports module, adding a new composite report comprised of two sub-reports: Summary List of Sales and Summary List of Purchases. Also add an export for these reports following the format set by the BIR. Task id #3211351 Forward-Port-Of: odoo/enterprise#54908

Add a l10n_ph_reports module, adding a new composite report comprised of two sub-reports: Summary List of Sales and Summary List of Purchases.
Also add an export for these reports following the format set by the BIR.

Task id #3211351

Forward-Port-Of: odoo/enterprise#54908

steps to reproduce: 1. Go to Payroll with Kenya localization 2. Click on Reports > NHIF Report or NSSF Report -> Odoo error because 0 is not a valid month Expected behavior: The wizards should not crash and the default month should be december fix: set the default month to december in january Behavior after fix: The wizards do not crash and the default month is december in january task-3668618 Forward-Port-Of: odoo/enterprise#53647

steps to reproduce:
1. Go to Payroll with Kenya localization
2. Click on Reports > NHIF Report or NSSF Report -> Odoo error because 0 is not a valid month

Expected behavior:
The wizards should not crash and the default month should be december

fix:
set the default month to december in january

Behavior after fix:
The wizards do not crash and the default month is december in january

task-3668618

Forward-Port-Of: odoo/enterprise#53647

Sanitizes phone numbers before using them to build request URIs. This will prevent failure whenever a phone number contains spaces. Task-3689342. Forward-Port-Of: odoo/enterprise#54894 Forward-Port-Of: odoo/enterprise#54535

Sanitizes phone numbers before using them to build request URIs. This will prevent failure whenever a phone number contains spaces.

Task-3689342.

Forward-Port-Of: odoo/enterprise#54894
Forward-Port-Of: odoo/enterprise#54535

Setting higher priority on pos_enterprise setting view to ensure that reinstalling pos_enterprise won't make IoT Box Settings unaccessible. [Reproduce] - run odoo 16 - install pos_enterprise - Go to Settings/Point_of_Sale/Connected_Devices: - check "IoT Box" - No Bug: iot box details are visible - uninstall and install again pos_enterprise - Go to Settings/Point_of_Sale/Connected_Devices: - check "IoT Box" - Bug: iot box details are not visible opw-3606033 Forward-Port-Of: odoo/

Setting higher priority on pos_enterprise setting view to ensure that reinstalling pos_enterprise won't make IoT Box Settings unaccessible.

[Reproduce]
- run odoo 16
- install pos_enterprise
- Go to Settings/Point_of_Sale/Connected_Devices:
	- check "IoT Box"
	- No Bug: iot box details are visible
- uninstall and install again pos_enterprise
- Go to Settings/Point_of_Sale/Connected_Devices:
	- check "IoT Box"
	- Bug: iot box details are not visible opw-3606033

Forward-Port-Of: odoo/enterprise#54304

When setting an analytic distribution on an aml line in bank reco widget and switching to exchange diff line (and vice versa), the component is not rerendered, therefore analytic distribution is also set on analytic distribution component. opw-3686867 Forward-Port-Of: odoo/enterprise#55140

When setting an analytic distribution on an aml line
in bank reco widget and switching to exchange diff line
(and vice versa), the component is not rerendered, therefore
analytic distribution is also set on analytic distribution
component.

opw-3686867

Forward-Port-Of: odoo/enterprise#55140

taskid: 3682434 Forward-Port-Of: odoo/enterprise#55135

taskid: 3682434

Forward-Port-Of: odoo/enterprise#55135

The fix proposed in 5d19c678 was not thorough as the pivot formula present in the demo sheet will call `name_get` on given record ids that are likely not existing without the demo data (see [1]). This revision adds a dedicated spreasheet file that goes around that problem and limits the name_get calls to actual data (in this case, rely on the country_ids). [1] https://runbot.odoo.com/runbot/build/54397846 Forward-Port-Of: odoo/enterprise#54973 Forward-Port-Of: odoo/enterprise#51734

The fix proposed in 5d19c678 was not thorough as the pivot formula present in the demo sheet will call `name_get` on given record ids that are likely not existing without the demo data (see [1]). This revision adds a dedicated spreasheet file that goes around that problem and limits the name_get calls to actual data (in this case, rely on the country_ids).

[1] https://runbot.odoo.com/runbot/build/54397846

Forward-Port-Of: odoo/enterprise#54973
Forward-Port-Of: odoo/enterprise#51734

## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but th

## Issue
For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs)

## Cause
A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them.

## Fix
There are 2 types of invoices (boleta/factura), but the POS button "to_invoice" at order checkout was used as a toggle between the types of invoices, instead of a choice to invoice or not. And since the generation of the invoice is strongly coupled with the generation of the pdf, I've added a context key to skip the pdf generation during POS checkout. The user can still "Send & Print" the invoice from the backend. The key is present when we *don't* select the invoice option at checkout (so for boleta invoices), for factura the invoice's pdf is created in sync.

## Affected versions
17.0 up to master

## Reference
opw-3610333

Community PR: https://github.com/odoo/odoo/pull/148159

Forward-Port-Of: odoo/enterprise#53655

This commit modifies the text/plain blob used for the template behavior (now called the Clipboard) because it was using the innerHTML instead of text. This enabled the user to copy a string containing HTML tags instead of just text that was pasted inside of the small chatter. When the user click on the copy button we write inside of the user's clipboard a blob that contains a ClipboardItem. This Object enables us to choose which data should be pasted depending on a MIME Type. Here the `t

This commit modifies the text/plain blob used for the template behavior (now
called the Clipboard) because it was using the innerHTML instead of text.
This enabled the user to copy a string containing HTML tags instead of just
text that was pasted inside of the small chatter.

When the user click on the copy button we write inside of the user's clipboard
a blob that contains a ClipboardItem. This Object enables us to choose which
data should be pasted depending on a MIME Type. Here the `text/plain` and
`text/html` were storing the same HTML.
The issue is that when pasting inside an input that uses the `text/plain` type
the user outputs the HTML as litteral string tags and all. Which is not ideal
for the user as it would prefer to have the text content instead of the HTML.

Now this blob will contain the innerText of the template reverting it to its
default behavior.

task-3691185

Forward-Port-Of: odoo/enterprise#54597

Currently some terms we not being translated besides having the term in the .pot file and the translation in the .po files. Steps to reproduce: ------------------- * Go to **Setting** * Add a language (french for example here) * Enable to translate to your website * Go to **website** * Select apointment * Select any appointment * Change the language of the website You can observe that the line *Select a time* is not being translated. When selecting **Translate**, you can observe th

Currently some terms we not being translated besides having the term in the .pot file and the translation in the .po files.

Steps to reproduce:
-------------------
* Go to **Setting**
* Add a language (french for example here)
* Enable to translate to your website
* Go to **website**
* Select apointment
* Select any appointment
* Change the language of the website

You can observe that the line *Select a time* is not being translated. When selecting **Translate**, you can observe that the line is not highlight in yellow or green.

Why the fix:
------------
When the route `/website/translations` is called, the modules loaded do not include appointment.

opw-3671043

Forward-Port-Of: odoo/enterprise#54377

When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account Error:- ``` ValueError: Expected singleton: mail.message(195, 193, 192) File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", line 1732, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/service/model.py", line 133, in retrying re

When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account

Error:-

```
ValueError: Expected singleton: mail.message(195, 193, 192)
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/17.0/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/17.0/whatsapp/models/whatsapp_account.py", line 190, in _process_messages
    channel = self.env['discuss.channel'].sudo().search([('message_ids', 'in', parent_id.id)], limit=1)
  File "odoo/fields.py", line 5118, in __get__
    raise ValueError("Expected singleton: %s" % record)
```

This is because at line [1], we receive multiple parent ids in WhatsApp messages because the value of `context.get()` is none, so at line [1] searches for the message whose msg_uid is not set (messages either in queue or failed).

This commit fixes the above issue by adding the condition that checks the ID is present in the context of the message.

https://github.com/odoo/enterprise/blob/272856993b21d9e7edfb573e33a368f80ba0c9c8/whatsapp/models/whatsapp_account.py#L185

sentry-4745952077

Forward-Port-Of: odoo/enterprise#53500

Because of the renaming of the some lines, it causes conflict. For l10n_pl_small_bs_assets_a_3, we had a shortcut for the expression. We need to nullify it, if not the field stays filled on the model. For l10n_pl_small_bs_assets_a_4, the problem is bigger. We had an aggregation before and we go to a line with groupby. The problem is that we add the groupby before the suppression of expressions. We can't nullify a field to correct it, so we just change the ids back. Linked to runbo

Because of the renaming of the some lines, it causes conflict. 
For l10n_pl_small_bs_assets_a_3, we had a shortcut for the expression. 
We need to nullify it, if not the field stays filled on the model.

For l10n_pl_small_bs_assets_a_4, the problem is bigger. 
We had an aggregation before and we go to a line with groupby. 
The problem is that we add the groupby before the suppression of expressions.
We can't nullify a field to correct it, so we just change the ids back.

Linked to runbot error 55641, 55642, 55643, 55644

Forward-Port-Of: odoo/enterprise#54688

With this commit the kiosk will now print the kitchen tickets. Task: 3553947 Forward-Port-Of: odoo/enterprise#55043 Forward-Port-Of: odoo/enterprise#54288

With this commit the kiosk will now print the kitchen tickets.

Task: 3553947

Forward-Port-Of: odoo/enterprise#55043
Forward-Port-Of: odoo/enterprise#54288

Currently, a public user can't add any product to the cart when using GeoIP and Avatax. ### Steps to reproduce * setup GeoIP[^1] * setup Avatax credentials * enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position * access to the website as a public user with an IP address from the US[^1] * try adding a product to the cart. You should be met with a validation pop. [^1]: This is quite annoying to reproduce on a local database. In cases like these,

Currently, a public user can't add any product to the cart when using GeoIP and Avatax.

### Steps to reproduce
* setup GeoIP[^1]
* setup Avatax credentials
* enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position
* access to the website as a public user with an IP address from the US[^1]
* try adding a product to the cart.

You should be met with a validation pop.


[^1]: 
	This is quite annoying to reproduce on a local database. In cases like these, I find it much easier to directly modify the code in order to emulate the behavior we want. Here, you can simply replace the entire content of `odoo/addons/http_routing/geoipresolver.py` with the following: 	
	```py
	class GeoIPResolver(object):
	    @classmethod
	    def open(cls, fname):
	        return GeoIPResolver()
	    
	    def resolve(self, ip):
	        return {
	            'city': 'New York',
	            'country_code': 'US',
	            'country_name': 'United States',
	            'latitude': 40.7263,
	            'longitude': -73.9818,
	            'region': 'NY',
	            'time_zone': 'America/New_York'
	        }
	```

### Cause

For the Avatax fiscal position to work, we need the partner's country, state and zip code. Usually, this isn't a problem because the fiscal position is set after the Public User enters their address. But, when using GeoIp, the fiscal position is set right when the user lands on the page, based on their location data. This triggers a check for the address, but the Public User hasn't entered one yet, which causes a validation error.

opw-3625410

Forward-Port-Of: odoo/enterprise#53547

Before this commit, the filter for EC Sale List codes was invisible if the report doesn't have a variant. It was caused by the xpath based on a div which can be not present in the DOM. When this div is not present, the filter doesn't appear. no task id Forward-Port-Of: odoo/enterprise#55120

Before this commit, the filter for EC Sale List codes was invisible if the report doesn't have a variant. It was caused by the xpath based on a div which can be not present in the DOM. When this div is not present, the filter doesn't appear.

no task id

Forward-Port-Of: odoo/enterprise#55120

### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatica

### Summary

wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag.

### Steps to reproduce

* install Accounting and the Saudi Arabia localization
* switch the Saudi Company
* language to Arabic
* print the General Ledger

You should see that a few columns do not appear on the PDF. They are out of bounds.

### Cause

The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatically reduce the font size of text in order to fit content within the specified page width. We use this option to help prevent content from overflowing the designated page boundaries. However, it seems that "smart shrink" doesn't take into account the text direction unless it is set on the `body` or `html` tag specifically.

opw-3472357
opw-3567655
opw-3520084
opw-3683210
opw-3684178

Community PR: odoo/odoo#146470

Forward-Port-Of: odoo/enterprise#55107
Forward-Port-Of: odoo/enterprise#50530

Before this commit, credit notes would be calculated to have a negative total amount which is incorrect and prevents posting. New in Odoo 17 is that account_external_tax sets line.price_subtotal on invoices. This was necessary to correctly support price-included taxes for Brazil. A side-effect is that it uncovers an inconsistency in the US integration [1]. Avatax returns negative amounts (both lineAmount and tax) when the record is a ReturnInvoice. In Odoo we don't invert the price_* fields o

Before this commit, credit notes would be calculated to have a negative total amount which is incorrect and prevents posting.

New in Odoo 17 is that account_external_tax sets line.price_subtotal on invoices. This was necessary to correctly support price-included taxes for Brazil. A side-effect is that it uncovers an inconsistency in the US integration [1]. Avatax returns negative amounts (both lineAmount and tax) when the record is a ReturnInvoice. In Odoo we don't invert the price_* fields on account.move.line for credit notes so this commit inverts the sign coming from Avatax in these cases.

[1] PS. in https://github.com/odoo/enterprise/pull/45095#issuecomment-1696102292

opw-3699206

Forward-Port-Of: odoo/enterprise#55094

This update removes two outdated account codes (999001 and 999002) from the Bulgarian financial reports that were previously used to categorize extraordinary income and expenses. This ensures the profit and loss reports now accurately reflect the current chart of accounts structure used in Bulgaria.

999001 and 999002 are no longer used for extraordinary income/expenses.
This commit removes them from the domains of the corresponding report.

Task ID: 3672294

Forward-Port-Of: odoo/enterprise#55022
Forward-Port-Of: odoo/enterprise#54491

This update fixes a bug in the subscription order note search feature. The system was incorrectly processing search results that returned both ID and display name information, when only the ID was needed. This fix ensures the search function works correctly when looking up order notes.

The "Add Document" button in the document upload dialog has been renamed to "Add URL" to better clarify its purpose. This change reduces confusion for users who see both an "Upload Document" button and the URL button side-by-side, making it immediately clear that the button is for adding documents via URL rather than uploading files.

Before this commit the button to add documents from an URL is labeled "Add Document" which is confusing given it is displayed besides an "Upload Document" button.

This commit renames the "Add Document" button into "Add URL" to make its purpose more obvious.

task-3493618

Forward-Port-Of: odoo/odoo#149120
Forward-Port-Of: odoo/odoo#136512

This fix removes the confusing arrow indicator that was appearing in date range fields when they were both empty and set to read-only mode. Users couldn't interact with these fields anyway, so showing the arrow was misleading. The change improves the user experience by only displaying the arrow when users can actually edit the field.

Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear.

The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it.

This commit makes sure to not display the arrow in this case.

task 3690523

This update fixes a bug where email addresses were appearing twice in the project sharing interface when inviting people on mobile devices. The issue was caused by an unnecessary email display setting in the system configuration. Removing this setting resolves the duplicate display and improves the user experience when sharing projects on mobile.

Steps:
- In mobile open project
- Project.project form view
- Share project
- Invite people, the 'email' is displayed twice in the kanban view

Issue:
- In mobile when project share invite people, the 'email' is displayed twice in the kanban view

Cause:
- This will be coming because of the context for show_email

Fix:
- By removing of context show_email it will be working fine.

task-3550702

Forward-Port-Of: odoo/odoo#140920