This fix prevents an error when users add an overdue activity to the Call Queue and then open or edit it. It improves reliability in activity workflows by handling cases where an old activity is automatically removed right after creation.

Before this commit, when adding an outdated activity from kanban activity widget, it crashed with the following error:

TypeError: Cannot read properties of undefined (reading 'toLocaleString')

Steps to reproduce:
- on crm lead schedule call activity and make sure that activity is at least 1 month old
- add activity to the Call Queue
- try to access/edit activity

This happens because of adding an outdated activity, this is automatically considered as an old activity, which leads to its deletion immediately after creation. OWL is rendering the template of `ActivityListPopover` while the activity is deleted, which is a problem because activity doesn't exist therefore its fields have been cleared, such as date_deadline that is undefined instead of a DateTime.

task-3945492

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

**Description of the issue/feature this PR addresses:** Go to Blacklist Click create --> Impossible to save --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#128230

**Description of the issue/feature this PR addresses:**
Go to Blacklist
Click create
--> Impossible to save



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

Forward-Port-Of: odoo/odoo#128230

 -According to DECREE 123/2020/ND-CP https://thuvienphapluat.vn/van-ban/Ke-toan-Kiem-toan/Nghi-dinh-123-2020-ND-CP-quy-dinh-hoa-don-chung-tu-445980.aspx (English version required paid to see) the content of invoice need to have amount in word (Article 10 , section D) -> So this commit is to enable it for vn COA by default Description of the issue/feature this PR addresses: Current

![50b560c57402d45c8d13](https://github.com/odoo/odoo/assets/56789189/eb3107cd-95fa-4da6-804a-9c967b47e824)

-According to DECREE 123/2020/ND-CP
https://thuvienphapluat.vn/van-ban/Ke-toan-Kiem-toan/Nghi-dinh-123-2020-ND-CP-quy-dinh-hoa-don-chung-tu-445980.aspx (English version required paid to see) the content of invoice need to have amount in word (Article 10 , section D)
-> So this commit is to enable it for vn COA by default

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

[FIX] Correcting the address format for Sweden. The format should be like this: %(street)s %(street2)s %(zip)s %(city)s %(country_name)s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167479

[FIX] Correcting the address format for Sweden.

The format should be like this:
%(street)s
%(street2)s
%(zip)s %(city)s
%(country_name)s




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

Forward-Port-Of: odoo/odoo#167479

Problem --- In sales, when variants are disabled from the settings, the variant grid entry / variant configurator is disabled as well. In purchase, it is not. Fix --- Adapt the onchanges from the sale module to get consistent behavior, ie: * variants disabled -> grid disabled * grid enabled -> variants enabled Note: the onchanges are adapted from their equivalent for sales in `product/models/res_config_settings.py`: https://github.com/odoo/odoo/blob/11bd6708111f9063e8927be2ee5ea26a8b

Problem
---
In sales, when variants are disabled from the settings, the variant grid entry / variant configurator is disabled as well. In purchase, it is not.

Fix
---
Adapt the onchanges from the sale module to get consistent behavior, ie:
* variants disabled -> grid disabled
* grid enabled -> variants enabled

Note: the onchanges are adapted from their equivalent for sales in `product/models/res_config_settings.py`: https://github.com/odoo/odoo/blob/11bd6708111f9063e8927be2ee5ea26a8b816398/addons/product/models/res_config_settings.py#L37-L52

opw-3884106

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

Forward-Port-Of: odoo/odoo#163740

__Description of the issue:__ The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves. It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employe

__Description of the issue:__
The way that accrual works now is that future leaves are not taken into account for the balance both for the dashboard display and upon taking leaves.
It is then possible to create situation that would lead to issues by taking leaves in a certain order; those issue are avoided with a cron that automatically cancels those issuing leaves. However, if leaves are causing issues and might be cancelled by the cron, a warning should appear on the dashboard of the employee to indicate that issue.

To reproduce the issue:
- Have any kind of accrual plan; the demo seniority for example
- Have a time off type that requires allocation
- Create an allocation for any employee for that accrual plan starting now and manually grant 1 day
- Go on that employee's dashboard
- Create a leave in a few days: it should be possible because one day is available for the employee
- Create another one the day before: the system allows it but it  is a discrepancy in the balance
- Look on the balance for the time off type: no warning is displayed

__Expected behaviour:__
There should be a warning after the creation of the second

__Description of the bugfix:__
This commit fixes the way the excess is detected to make it accurate. Additionally, the different warning messages were previously made incompatible with one another though they're not linked; this commit allows multiple warning messages if multiple are to be displayed.

task-3859558

Forward-Port-Of: odoo/odoo#167388
Forward-Port-Of: odoo/odoo#161107

## Description: Previously, when entering a pivot and applying a filter domain, the pivot formula (without domain field and domain value in function parameter) would return 'FALSE' if it did not match any records. The code now checks the value and returns an empty string if it's 'FALSE'. Task - [3888401](https://www.odoo.com/web#id=3888401&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at w

## Description:

Previously, when entering a pivot and applying a filter domain, the pivot formula (without domain field and domain value in function parameter) would return 'FALSE' if it did not match any records. The code now checks the value and returns an empty string if it's 'FALSE'.

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

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

Forward-Port-Of: odoo/odoo#165976

Go to Accounting > Configuration > Journals Delete the EXCH journal Go to Settings > Companies, open the main company Try to create a new branch Traceback comes up: "ValueError: External ID not found in the system: account.2_exch" This occurs because when setting up the new company we are looking for the ref 'exch'. The system will look for the xmlid `account.<company_id>_exch` but the journal has been deleted so it will not be found. A solution is to avoid blocking the company c

Go to Accounting > Configuration > Journals
Delete the EXCH journal
Go to Settings > Companies, open the main company
Try to create a new branch

Traceback comes up:
"ValueError: External ID not found in the system: account.2_exch"

This occurs because when setting up the new company we are looking for
the ref 'exch'. The system will look for the xmlid
`account.<company_id>_exch` but the journal has been deleted so it will
not be found.

A solution is to avoid blocking the company creation, the user will need
to create the missing journal afterward

opw-3932849

Forward-Port-Of: odoo/odoo#167407

**Current behavior:** Using the Delivery smart button in a rental order and then clicking on a picking listed causes a traceback in some flows. **Expected behavior:** The picking form opens. **Steps to reproduce:** *Install sale_stock_renting* 1. Create a new rental order with some rental product and at least 2 storable products 2. Confirm the order and go to the Schedule overview 3. Click on the new order and then on the stock picking smart button (Delivery) 4. Click on any o

**Current behavior:**
Using the Delivery smart button in a rental order and then clicking on a picking listed causes a traceback in some flows.

**Expected behavior:**
The picking form opens.

**Steps to reproduce:**
*Install sale_stock_renting*
1. Create a new rental order with some rental product and at least 2 storable products

2. Confirm the order and go to the Schedule overview

3. Click on the new order and then on the stock picking smart button (Delivery)

4. Click on any of the pickings listed in the tree view -> Traceback

**Cause of the issue:**
We load the rental order from the Schedule view with some "form_view_ref" context. We still have this context once we navigate to the picking tree view and it results in the incorrect view being loaded and model fields being accessed which don't exist.

**Fix:**
Clean the context in the action before serving the new view.

opw-3813524

Forward-Port-Of: odoo/odoo#166963

Problem --- When creating/editing expenses, if the user doesn't have any access rights to employee, a ValueError is thrown when clicking the employee field. The Error happens because the model used for employees for users without access is `hr.employee.public` instead of the usual `hr.employee` and `hr.employee.public` does not define the `filter_for_expense` field, which is used for searching / filtering employees to set. Fix --- `hr.employee` and `hr.employee.public` both inheri

Problem
---
When creating/editing expenses, if the user doesn't have any access rights to
employee, a ValueError is thrown when clicking the employee field.

The Error happens because the model used for employees for users
without access is `hr.employee.public` instead of the usual
`hr.employee` and `hr.employee.public` does not define the
`filter_for_expense` field, which is used for searching / filtering
employees to set.

Fix
---
`hr.employee` and `hr.employee.public` both inherit from
`hr.employee.base`, therefore we can put the search field and method,
into an `hr.expense` child model of `hr.employee.base`.

Note that (as far as I understand) this will not break stable because
the `filter_for_expense` field is `store=False`.

opw-3858951

Forward-Port-Of: odoo/odoo#164960

Getting link preview on invalid links creates problems (eg: https://..), which results in sms and mail to be stuck in a queue and not being sent. task-3729538 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#167373

Getting link preview on invalid links creates problems (eg: https://..), which results in sms and mail to be stuck in a queue and not being sent.

task-3729538

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

- Re-using results for domains duplicated - Ordering by id instead of default heavy unused order Opening a POS sessions our SQL profiler shows the following query executed too many times: - <img width="770" alt="Screenshot 2024-05-07 at 8 41 09 a m" src="https://github.com/odoo/odoo/assets/6644187/80d7ac19-a042-40bc-a525-063b4074ec0e"> Checking the PY profilers the following method is reported as slow: https://github.com/odoo/odoo/blob/42f5e84eeb1d649feed5e032d65ff74d148b49b8/addons/po

- Re-using results for domains duplicated
- Ordering by id instead of default heavy unused order

Opening a POS sessions our SQL profiler shows the following query executed too many times:
 - <img width="770" alt="Screenshot 2024-05-07 at 8 41 09 a m" src="https://github.com/odoo/odoo/assets/6644187/80d7ac19-a042-40bc-a525-063b4074ec0e">

Checking the PY profilers the following method is reported as slow:
https://github.com/odoo/odoo/blob/42f5e84eeb1d649feed5e032d65ff74d148b49b8/addons/pos_coupon/models/coupon_program.py#L80
  - <img width="1508" alt="Screenshot 2024-05-07 at 8 42 17 a m" src="https://github.com/odoo/odoo/assets/6644187/e46b60f0-cac2-480b-b588-d681f0bc5607">

The reason it is executing the same query too many times with the same domain

So, I have created this change to re-use the result if the domain is repeated

Also, the query generated has heavy `order by`

`order by "res_partner"."type", coalesce("res_partner"."is_company", false) desc, "res_partner"."display_name", "res_partner"."id"; `

Replacing by `order by "res_partner"."id"` it is faster

Before `Execution Time: 104.256 ms`
Now `Execution Time: 31.802 ms`

So, it is ~4x faster for each query and it is re-using data for the same query using a LRU-Cache locally in the method

Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/164771 since the module was renamed and the python code refactored so the bot was not able to forward-port it automatically from https://github.com/odoo/odoo/pull/166447

Also, i didn't find the part of the partners in this new version

Forward-Port-Of: odoo/odoo#166608

If customer returned to confirmation step,by clicking back arrow from already confirmed sale order in portal view, if they would not refresh they would get an error that this Sale Order is not able to be confirmed. Now, in this case, double confirmation is skipped. opw-3819450 Forward-Port-Of: odoo/odoo#161525

If customer returned to confirmation step,by clicking back arrow from
already confirmed sale order in portal view, if they would not refresh
they would get an error that this Sale Order is not able to be confirmed.
Now, in this case, double confirmation is skipped.

opw-3819450

Forward-Port-Of: odoo/odoo#161525

VAT should be accounted for on gift card rewards (when necessary). To allow that, we will start considering the taxes set on the reward product. As it is enforced that no taxes are set on that product on creation, we are sure that if a tax is set on the product, it can safely be applied on the reward line. opw-3817604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164391

VAT should be accounted for on gift card rewards (when necessary). To allow that, we will start considering the taxes set on the reward product. As it is enforced that no taxes are set on that product on creation, we are sure that if a tax is set on the product, it can safely be applied on the reward line.

opw-3817604


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

Forward-Port-Of: odoo/odoo#164391

Before PR: --- If the invoice has already been sent to the government, then it's allowed to change in sequence. After PR: --- The sequence can't be changed once the invoice is created and sent to the government. task ID :- 3254322 Forward-Port-Of: odoo/odoo#167691 Forward-Port-Of: odoo/odoo#123899

Before PR:
---
If the invoice has already been sent to the government, then it's allowed to change in sequence.

After PR:
---
The sequence can't be changed once the invoice is created and sent to the government.

task ID :- 3254322

Forward-Port-Of: odoo/odoo#167691
Forward-Port-Of: odoo/odoo#123899

Currently, an error occurs when creating a stock quant (Pick From) in the 'Detailed Operations' list view. Step to produce: - Install the 'stock' module. - Go to Inventory / Operations / Transfers / Receipts and create a receipt, add 'Receive From', and also add 'Product' and 'Demand' in Operations. - Click on 'Validate' then click on 'Return', and open 'Detailed Operations'. - Now try to create a new stock quant (Pick From) from a list view. ```ValueError: Wrong container value 'WH/

Currently, an error occurs when creating a stock quant (Pick From) in the 'Detailed Operations' list view.

Step to produce:

- Install the 'stock' module.
- Go to Inventory / Operations / Transfers / Receipts and create a receipt, add 'Receive From', and also add 'Product' and 'Demand' in Operations.
- Click on 'Validate' then click on 'Return', and open 'Detailed Operations'.
- Now try to create a new stock quant (Pick From) from a list view.

```ValueError: Wrong container value 'WH/Stock'```

An error occurs when attempting to create or edit a 'picked'(Pick From) in the list view of 'Detailed Operations' and the system raises a value error at [1] as 'product_id takes a string instead of an integer' in default values.

link[1]: https://github.com/odoo/odoo/blob/259cba71690c500c335a4a2c43e4c606697bc817/odoo/fields.py#L3582-L3583

To resolve the issue, restricted to creating a stock quant from the 'Detailed Operations' list view

sentry-5089715517

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

Forward-Port-Of: odoo/odoo#165705

With the popup-styled cookies bar, the cookies policy page is unreadable. It is also the case with all cookies bar with a backdrop. The "discrete" and "classic" bars can also potentially hide the last paragraph(s) of the page. To avoid that, this commit adds a button to toggle the bar on that page. Note that the cookies policy page could be on any URL, but it has to be referenced in the `a.o_cookies_bar_text_policy` link within the cookies bar. task-3733860 Forward-Port-Of: odoo/odo

With the popup-styled cookies bar, the cookies policy page is
unreadable. It is also the case with all cookies bar with a backdrop.
The "discrete" and "classic" bars can also potentially hide the last
paragraph(s) of the page.
To avoid that, this commit adds a button to toggle the bar on that page.

Note that the cookies policy page could be on any URL, but it has to be
referenced in the `a.o_cookies_bar_text_policy` link within the cookies
bar.

task-3733860

Forward-Port-Of: odoo/odoo#167331
Forward-Port-Of: odoo/odoo#162386

Current behaviour before commit: When background color is applied on text, the text becomes somewhat invisible in dark mode. Desired behaviour after commit: Now, when background color is applied on text, opacity of 60% is applied to the color. Due to this text becomes somewhat visible. task-3273315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166325 Forward-Port-Of: odoo/odoo#129700

Current behaviour before commit:

When background color is applied on text, the text becomes somewhat 
invisible in dark mode.

Desired behaviour after commit:

Now, when background color is applied on text, opacity of 60% is applied
to the color. Due to this text becomes somewhat visible.

task-3273315



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

Forward-Port-Of: odoo/odoo#166325
Forward-Port-Of: odoo/odoo#129700

[FIX] base_import_module: fix the tree view Steps to Reproduce: When we click on tree view of industry its showing the error that can't fetch record they might have been deleted. Issue: In Kanban, it works because we passed the context on the xml side, however in the tree view, we can't access those contexts, and because the modules aren't stored, we only get the resId as -1. Fix: So we restricted the click and no redirect on the tree view, and as an alternative, we introduc

[FIX] base_import_module: fix the tree view 

Steps to Reproduce:
When we click on tree view of industry its showing the error that can't fetch 
record they might have been deleted.

Issue:
In Kanban, it works because we passed the context on the xml side, however in 
the tree view, we can't access those contexts, and because the modules aren't 
stored, we only get the resId as -1.

Fix:
So we restricted the click and no redirect on the tree view, and as an alternative, 
we introduced a More Info button that redirects us to the form view.

Task - 3834095

Forward-Port-Of: odoo/odoo#166470

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

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

Salary attachment records now prevent changes to key fields once any related payslip has been completed or paid. This helps protect payroll accuracy by avoiding edits after payroll results have already been generated.

…st view

In salary attachment user can change some fields even after the payslips have been generated
the fields should be readonly when any one of the payslip is done or paid.

so in this commit added a new boolean field and made a compute function to
check the payslip state and made the necessary fields readonly using the boolean field.

task-3794130

Department pages now include a clearer appraisal section, making appraisal-related information easier for HR teams to find and manage. A Swiss payroll setting was also adjusted to stay aligned with the updated employee certificate behavior.

* = hr_appraisal_survey,l10n_ch_hr_payroll

removed ondelete which sets the default value in localization because removed the default value in hr module for certificate

ux improvements in hr module
-add section for appraisal in department form view

Task-3491791

Translated messages now avoid automatic developer-style quoting and instead use consistent curly quotation marks around inserted text. This makes messages clearer for users and easier to adapt correctly across different languages and regions.

While using %r in translation strings to automatically quote strings without having to deal with escaping/choosing the right string delimiters seems like a good idea, it has a few issues:

- This doesn't work for non-string data types.
- Different languages use various quotation marks (e.g., “guillemets” in French, corner brackets in Chinese).
- Even in English, the common typographical recommendations suggest using curly quotes (“”) over straight quotes ("").
- It is not always clear whether it will produce single or double quotes.

For these reasons, this PR removes all instances of %r in translation strings, and replaces them with %s, surrounding them with curly quotes.

Community: https://github.com/odoo/odoo/pull/166859

Task-3942743

Approval request owners are now emailed when their request is approved or refused. This gives requesters faster, clearer feedback without needing to manually check the approval status.

When an approval request is either accepted or refused, the owner is now informed via an email notification. This ensures immediate feedback to the requester about the status of their request.

Task-3497571

The demo employee timesheet data now shows the correct last validated timesheet date. This keeps sample Timesheet records consistent and avoids misleading dates when users explore or test the module.

In the Timesheet Module, we are fixing the data related to the demo employee set, specifically in the last_validated_timesheet_date field. it will result in the last validated timesheet date being returned as 10 days earlier.

task-350454

Working schedule hour values in Payroll are now shown in a cleaner time format instead of raw decimal numbers. This makes required full-time hours and weekly hours easier for HR users to read and reduces confusion when reviewing schedules.

full_time_required_hours and hours_per week are no longer displayed as floats.

task-3888824

An obsolete setting related to spreadsheet date filters was removed from the code. This reduces maintenance overhead and helps prevent confusion without changing how users work with spreadsheets.

There was still reference on global filter's automaticDefaultValue in the code, but automaticDefaultValue isn't used.
This commit removes the dead code.

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

Saudi Arabia payroll salary rules have been adjusted and expanded to better match required payroll calculations. The update also adds supporting employee, leave, and departure reason data so payroll results are more accurate for affected employees.

Ticket ID: [3215965](https://www.odoo.com/odoo/project.task/3215965?cids=14)

Modifications to existing salary rules in KSA payroll + adding some new rules.

Before this commit, when hitting enter while typing in multi-line text, The cursor would move to the next sign item. But it should simply add a new line and remain focused on the multi-line item. This commit aims to fix this issue by preventing jumping to the next item when being at multi-line. Task: 3910934 Forward-Port-Of: odoo/enterprise#63622 Forward-Port-Of: odoo/enterprise#62378

Before this commit, when hitting enter while typing in multi-line text, The cursor would move to the next sign item. But it should simply add a new line and remain focused on the multi-line item.

This commit aims to fix this issue by preventing jumping to the next item when being at multi-line.

Task: 3910934

Forward-Port-Of: odoo/enterprise#63622
Forward-Port-Of: odoo/enterprise#62378

This will fix the file exported for the eco voucher with Monizze. Task: 3895296 Forward-Port-Of: odoo/enterprise#62189

This will fix the file exported for the eco voucher with Monizze.

Task: 3895296

Forward-Port-Of: odoo/enterprise#62189

with the invoice plus PR, some tours and tests are failing on runbot - test_tour_bank_rec_ui: Build Error 66365 - this tour contained a step that depends on account_reports. patch is added to account reports - test_accountant_tour: Build Error 66371 - The bill guide containing button `action_create_vendor_bill` (create vendor bill from sample) is only available on empty Purchase Journals. A new journal is created in the admin user's company Forward-Port-Of: odoo/enterprise#63628

with the invoice plus PR, some tours and tests are failing on runbot

- test_tour_bank_rec_ui: Build Error 66365 - this tour contained a step that depends on account_reports. patch is added to account reports
- test_accountant_tour: Build Error 66371 - The bill guide containing button `action_create_vendor_bill` (create vendor bill from sample) is only available on empty Purchase Journals. A new journal is created in the admin user's company

Forward-Port-Of: odoo/enterprise#63628

This PR fixes two issues with the portal web client of Knowledge: - When a portal user opens an article and clicks on an article of the sidebar, the article id specified in the route url and the session are not updated. The router only updates the url params of the url. When the user loads the page, the client script will load the article specified in the session. As the session is not updated when switching article, the script can load an incorrect article when reloading the page. This PR ai

This PR fixes two issues with the portal web client of Knowledge:

- When a portal user opens an article and clicks on an article of the sidebar, the article id specified in the route url and the session are not updated. The router only updates the url params of the url. When the user loads the page, the client script will load the article specified in the session. As the session is not updated when switching article, the script can load an incorrect article when reloading the page. This PR aims to fix that issue by ensuring that the client script will load the article with the id specified in the url params of the url.
- When a portal user opens an article, clicks on an article of the sidebar and presses the back button, the system updates the url params and set the right id but it doesn't load the corresponding article in the view. This PR aims to fix that issue by ensuring that the web client load the article whenever the url changes.

task-3743416

Forward-Port-Of: odoo/enterprise#63554
Forward-Port-Of: odoo/enterprise#60845

Before this change we were always setting document type for the debit note by default, but this should only apply if from Peru LATAM 1198 Forward-Port-Of: odoo/enterprise#63655 Forward-Port-Of: odoo/enterprise#63099

Before this change we were always setting document type for the debit note by default, but this should only apply if from Peru

LATAM 1198

Forward-Port-Of: odoo/enterprise#63655
Forward-Port-Of: odoo/enterprise#63099

Community: https://github.com/odoo/odoo/pull/167767 Forward-Port-Of: odoo/enterprise#63726

Community: https://github.com/odoo/odoo/pull/167767

Forward-Port-Of: odoo/enterprise#63726

### [IMP] sale_project_forecast: hide planning enable for other tracking This commit hide planning enabled field and related content for not project related type from product form view. ### [IMP] website_appointment_sale: improve filter in booking type computation This commit add more condition in booking type field computation so we only do query for product we that is closest to being booking_type. task-3959899 Forward-Port-Of: odoo/enterprise#63447

### [IMP] sale_project_forecast: hide planning enable for other tracking

This commit hide planning enabled field and related content for
not project related type from product form view.

### [IMP] website_appointment_sale: improve filter in booking type computation

This commit add more condition in booking type field computation
so we only do query for product we that is closest to being
booking_type.

task-3959899

Forward-Port-Of: odoo/enterprise#63447

task-3551627 community: https://github.com/odoo/odoo/pull/166215 Forward-Port-Of: odoo/enterprise#63180

task-3551627

community: https://github.com/odoo/odoo/pull/166215

Forward-Port-Of: odoo/enterprise#63180

Create a branch company In the parent company: - Create a [tax] of type "Group of Taxes" and add a child tax - add [tax] to a [product] record In the branch company: - Create an invoice with [product] - Open journal Reports KeyError will raise It occurs because we fetch the tax data by SQL selecting data belonging to the current company only, without considering parent companies opw-3874824 Forward-Port-Of: odoo/enterprise#63004

Create a branch company
In the parent company:
 - Create a [tax] of type "Group of Taxes" and add a child tax
 - add [tax] to a [product] record

In the branch company:
 - Create an invoice with [product]
 - Open journal Reports

KeyError will raise
It occurs because we fetch the tax data by SQL selecting data belonging
to the current company only, without considering parent companies

opw-3874824

Forward-Port-Of: odoo/enterprise#63004

See also: https://github.com/odoo/odoo/pull/167738 Forward-Port-Of: odoo/enterprise#63708

See also: https://github.com/odoo/odoo/pull/167738

Forward-Port-Of: odoo/enterprise#63708

This fix addresses an issue where cancelling an upsell subscription failed to revert quantity changes made to the parent subscription. When an upsell was confirmed, it would update the parent subscription's product quantities, but cancelling the upsell would not restore the original quantities. The system now properly reverts these changes and provides clearer messaging to users about quantity updates.

To reproduce:
=============
- create a subscription and confirm it
- create the invoice for this subscription
- create an upsell, add some recurring products with qty > 0
- confirm the upsell, you can see that the parent sub has been updated with the qty coming from Upsell
- cancel the upsell afterward -> the parent sub has not been reverted.

Problem:
========
When we cancel an upsell, the changes on the parent subscription are not reverted.
The message in the chatter is improved to notify the quantities on the subscription
may need to be updated.

opw-3269465

Forward-Port-Of: odoo/enterprise#63752
Forward-Port-Of: odoo/enterprise#61678

Fixed a bug that caused the system to crash when users tried to add or edit outdated activities in the CRM module. The issue occurred because required data fields were not being loaded properly. This fix ensures activities can be managed smoothly regardless of their age.

Before this commit, when adding an outdated activity from kanban activity widget, it crashed with the following errors:

`TypeError: cannot read property of undefined (reading `mail_template_ids`)`
`TypeError: Cannot read properties of undefined (reading 'toLocaleString')`

Steps to reproduce:
- on crm lead schedule call activity and make sure that activity is at least 1 month old
- book activity and save it
- try to access/edit activity

This happens because when the `get_today_call_activities` function is called. Function fetches fields during the records formatting, but it doesn't fetch `date_deadline` and `mail_template_ids`, therefore those fields remain undefined, hence the errors rise.

task-3945492

This update fixes the informational message displayed in the CodaBox SODA import wizard for Belgian accounting users. The message text has been updated to match the latest version, ensuring users see the correct and most current guidance when importing bank statements through the CodaBox integration.

Backport codabox soda wizard info text from 17.1

This fix resolves a crash that occurred when users tried to select certain field types (like selection, boolean, or radio fields) while editing forms in Web Studio. The issue was caused by a recent code update that changed how the system accesses field information. Users can now successfully select and work with these field types without encountering errors.

Currently, an error occurs when the user tries to select a selection, boolean, or radio field.

Steps to produce an error:
1. Install web_studio
2. Go to Settings > Users & Companies > Users > Select any user
3. Open studio mode by clicking the studio icon.
4. Try to select the Administration field from the access right page

Error:
```
TypeError: WebStudioController.get_default_value() missing 1 required positional argument: 'field_name'
  File "odoo/http.py", line 2139, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1715, 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 1742, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1943, 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 191, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 717, in route_wrapper
    result = endpoint(self, *args, **params_ok)
```

This is because before the owl refactor of webstudio with https://github.com/odoo/enterprise/pull/37285/commits/e44403193cbfd7893708ff739fd072f8bb1197c6, the code tries
to access the field name from the 'attrs' of the node (see [1]), but after Commit[1],
it tries to access the field name from the 'field' of the node (see [1]), and it works for
normal fields like text, number, etc., but not for grouped fields like selection, boolean, radio, etc.

This commit fixes the above issue by not fetching or changing the
default value of reified fields. Now, after this commit, the default
value box is not showing for the reified fields.

 [1]-https://github.com/odoo/enterprise/blob/1fd7b1182146f1d7e6a7cbb9b725cb4d47281e14/web_studio/static/src/legacy/js/views/view_editor_manager.js#L1029 [2]-https://github.com/odoo/enterprise/blob/50b6e04d2e2f47797ec14bf506a030bd1d9bc797/web_studio/static/src/client_action/view_editor/interactive_editor/properties/field_properties/field_properties.js#L117

sentry-4156923959

Forward-Port-Of: odoo/enterprise#63465
Forward-Port-Of: odoo/enterprise#50249

A scheduled task in the payroll system was incorrectly running monthly instead of hourly. This fix corrects the schedule settings so that PDF generation now runs every hour as originally intended, ensuring timely document processing.

Intended:
Generate pdfs is meant to run in every hour.
It was intention as well at creation and it shows from how nextcall is defined:

<field name="nextcall" eval="(DateTime.now() + timedelta(hours=1))"/>

Current behavior:
But regardless how nextcall is defined, now the cron runs in every month.

This is because interval_type is not explicitly defined on the cron and thus it takes default value - that is 'months'.

To correct the cron behavior, we explicitly define
 interval_number and interval_type

task-3960037

Forward-Port-Of: odoo/enterprise#63565

This update corrects how overtime hours are calculated in the HR system to properly account for individual employee contracts. Previously, overtime computation may not have accurately reflected contract-specific terms. This ensures employees are credited with the correct overtime hours based on their actual contract agreements.

task-3597205

This fix corrects an issue where clicking the partner ledger button from a customer or vendor record was incorrectly displaying transaction details instead of the Partner Ledger report. Users will now see the proper Partner Ledger report view when accessing it directly from a partner record, improving navigation accuracy and user experience.

Fix when opening the partner ledger directly from res.partner button it goes to account.move.line insted of Partner Ledger report


 17.0

This fix addresses an issue where all new batch payments were being displayed in the reconciliation widget. A default filter has been added to hide new batch payments by default, providing a cleaner view of the reconciliation interface. This improves the user experience by reducing clutter and focusing on relevant payment batches.

Before this commit in the reconciliation widget, all new batch payment are show. This PR add a default filter to remove them.

Before : 
<img width="1000" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/a64ab576-00a4-4b46-8af4-5bbac4aac0ff">


After :
<img width="1006" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/57bc21cc-8311-4800-a1f2-fa594b6517b8">

This update corrects how overtime hours are calculated in the HR system to be based on individual employee contracts rather than using a global approach. This ensures that overtime is accurately computed according to each employee's specific contract terms, working hours, and conditions, leading to more precise payroll and attendance tracking.

task-3597205

This fix resolves a system crash that occurred when users tried to add an outdated activity from the activity widget. The issue happened because the system was attempting to access activity information that had already been deleted, causing an error. Users can now safely add and manage outdated activities without encountering crashes.

Before this commit, when adding an outdated activity
from kanban activity widget, it crashed with the following error:

TypeError: cannot read property of undefined (reading `mail_template_ids`)

Steps to reproduce:
- on crm lead schedule call activity and make sure that activity is at
  least 1 month old
- add activity to the Call Queue
- try to access/edit activity

This happens because of adding an outdated activity, this is
automatically considered as an old activity, which leads to its
deletion immediately after creation. OWL is rendering the template of
`ActivityListPopover` while the activity is deleted, which is a problem
because activity doesn't exist therefore its fields have been cleared,
such as mail_template_ids that is undefined instead of a list.

task-3945492

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 update improves the performance of the holiday search feature by description. The change reduces database query size and prevents server overload by using a more efficient query method, ensuring the system runs smoothly when employees search for their leave records.

**Description of the issue/feature this PR addresses:**
fine tuning of https://github.com/odoo/odoo/commit/f8182fb625eb3e20c85388d4c342553af4fe7ab9 to prevent an olverload of postgres.

@thle-odoo @sofiagvaladze I have update the commit. I use 'inselect' to reduce the query size.



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

This update removes an unnecessary rounding factor from the resource calendar calculations. The change simplifies how work hours and scheduling are computed, ensuring more accurate time tracking and resource planning without the previous rounding adjustments that could cause minor discrepancies.

Test (stable version)

This fix corrects how fixed-amount taxes are displayed on invoices. Previously, fixed taxes were incorrectly shown as proportional to the invoice amount. Now, fixed taxes are displayed with their actual fixed amount without any amount-based calculations, ensuring accurate tax representation on invoices.

[FIX] account: exclude on-amount of fixed-tax in invoices

1- When you create a fixed tax and link it to group e.g., X_group.
2- Then, create a percentage tax and link it to another group e.g., Y_group 3- Create an invoice with those two taxes
=> You will see the fix tax proportional to the amount and We don't want any amount to be displayed on Fixed Taxes

Solution: exclude that on-amount if the tax amount_type is fixed

task-id#3964942

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

This fix prevents the system from creating duplicate serial numbers when users perform mass production operations. Previously, the system would attempt to create serial numbers even if they already existed in the database, which could cause errors or data conflicts. Now, the system checks if a serial number already exists before creating it, ensuring cleaner and more reliable production workflows.

When the user performs a mass produce, the generated serial numbers will only be created if they do not already exist in the database.

A contributor named ngquang has signed the Odoo Contributor License Agreement (CLA), which is a legal requirement for all code contributors. This allows their contributions to be accepted into the Odoo project. The CLA signature has been recorded in the project's documentation.

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