Update the taxes and taxes-related models due to new tax rules. This concerns a few accounts,taxes, tax groups, and the tax report. We also use this occasion to set non-important taxes as inactive by default to reduce slightly the amount of taxes that are shown out of the box. Tax id #3585950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179715

Update the taxes and taxes-related models due to new tax rules.
This concerns a few accounts,taxes, tax groups, and the tax report.

We also use this occasion to set non-important taxes as inactive by default to reduce slightly the amount of taxes that are shown out of the box.

Tax id #3585950

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

Forward-Port-Of: odoo/odoo#179715

JQuery ajax was supporting extra headers sent along with the HTTP request, but this was no longer possible with the new RPC service. With this commit, we reintroduce this feature, so that extra HTTP headers can be specified by the caller. Forward-Port-Of: odoo/odoo#180055

JQuery ajax was supporting extra headers sent along with the HTTP request, but this was no longer possible with the new RPC service. With this commit, we reintroduce this feature, so that extra HTTP headers can be specified by the caller.

Forward-Port-Of: odoo/odoo#180055

This update enables the printing of the delivery challan when the e-way bill is in the pending stage. The E-Way Bill Details section and QR code are omitted for delivery challans, as these details are only available after the e-way bill is generated and moves to the generated stage. Additionally, some minor refinements have been made to the ewaybill_report, including the removal of heading numbers and the unnecessary columns CEWB No. and Multi Veh. Info from the Vehicle Details section. Ta

This update enables the printing of the delivery challan when the e-way bill is in the pending stage. The E-Way Bill Details section and QR code are omitted for delivery challans, as these details are only available after the e-way bill is generated and moves to the generated stage.

Additionally, some minor refinements have been made to the ewaybill_report, including the removal of heading numbers and the unnecessary columns CEWB No. and Multi Veh. Info from the Vehicle Details section.

Task [link](https://www.odoo.com/odoo/project/967/tasks/4149686)
task-4149686

Forward-Port-Of: odoo/odoo#178826

### Steps to reproduce: - Create a storable product with 0 unit in stock - Create and confirm a Sale order for 1 unit fo that product - Create and confirm a Purchase Order for 1 unit of that product and an expected date further than the delivery date. - Click on the chart icon on the pol to be redirected to the forecast ### Expected behavior: The line should be displayed in red since the PO is late just as in 16.0 as the cell has the "".o_grid_warning" class. ### Current behavior:

### Steps to reproduce:

- Create a storable product with 0 unit in stock
- Create and confirm a Sale order for 1 unit fo that product
- Create and confirm a Purchase Order for 1 unit of that product and an expected date further than the delivery date.
- Click on the chart icon on the pol to be redirected to the forecast

### Expected behavior:

The line should be displayed in red since the PO is late just as in 16.0 as the cell has the "".o_grid_warning" class.

### Current behavior:

It is not.

### Cause of the issue:

The `o_report_replenishment` class does not exist in 17.0 and the `table` class is used instead the html of the report so that the css file is not defining the color of the `o_warning` class correctly anymore.

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

Forward-Port-Of: odoo/odoo#179936

Description of the issue/feature this PR addresses: Commit [1] fixed a bug where selecting across two paragraphs separated by whitespace resulted in multiple indented lists. However, this fix introduced a new issue: if a first child of block node was whitespace followed by a `<br>`, the list was not created on the first attempt. Instead, only the whitespace was removed, and the list was created on the second attempt. Commit [2] addressed this issue but introduced a new problem: if a bl

Description of the issue/feature this PR addresses:

Commit [1] fixed a bug where selecting across two paragraphs separated by
whitespace resulted in multiple indented lists. However, this fix introduced
a new issue: if a first child of block node was whitespace followed by a `<br>`,
the list was not created on the first attempt. Instead, only the whitespace was
removed, and the list was created on the second attempt.

Commit [2] addressed this issue but introduced a new problem: if a block node had
whitespace as its first child, the placeholder for that block would enter an
infinite loop, causing the page to become unresponsive.

This commit reverts the changes made in Commit [2] and introduces a new approach
that resolves the list creation issue when a block node had whitespace as its
first child, without causing the placeholder to get stuck in a loop.

[1]: https://github.com/odoo-dev/odoo-editor/commit/58a7fadcaaaa7322c6177276ddc22b62da96d1f5
[2]: https://github.com/odoo/odoo/commit/1e982dab025fb86e759b249433f41619a442b5cf

task-4082867

Forward-Port-Of: odoo/odoo#176178

Added blur on pos display devices and pairing code boxes background to ease readability and improve user experience. Forward-Port-Of: odoo/odoo#179814

Added blur on pos display devices and pairing code boxes background to ease readability and improve user experience.

Forward-Port-Of: odoo/odoo#179814

Steps to reproduce: - Include in your assets a CSS file with invalid formatting. - Translate your website in RTL language. > The website will never load and you will be left with a blank page. Cause of the issue: `rtlcss` never exit with a returncode, consequently our error management there is useless. As from `rtlcss` 4.1.0 [1], an error code is returned but only when using a CSS file. In our case, Odoo pass the CSS payload via the `stdin`. A PR [2] has been opened on `rtlcss` to also

Steps to reproduce:

- Include in your assets a CSS file with invalid formatting.
- Translate your website in RTL language.
> The website will never load and you will be left with a blank page.

Cause of the issue:
`rtlcss` never exit with a returncode, consequently our error management there is useless. As from `rtlcss` 4.1.0 [1], an error code is returned but only when using a CSS file. In our case, Odoo pass the CSS payload via the `stdin`. A PR [2] has been opened on `rtlcss` to also exit with a return code in this scenario (and log details to `stderr`). In the meantime and also for earlier versions, the error management had to be slightly adjusted. As we cannot deduce any informations from the return code (and the `stderr` is completely empty), we can exploit the fact that, in case of errors, `rtlcss` doesn't output anything to `stdout`.

[1]: https://github.com/MohammadYounes/rtlcss/commit/4e625458cb236a4a21cb6d5e54283a9d5244fdc8
[2]: https://github.com/MohammadYounes/rtlcss/pull/342

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

Forward-Port-Of: odoo/odoo#179852
Forward-Port-Of: odoo/odoo#178021

Issue: ====== Duplicate attachmenets are loaded in chatter. Steps to reproduce the issue: ============================= - Go to massmailing, create a new email with a template with images. - Replace the image by uploading a new one, save. - The second and onward uploaded images have two attachments in the tab->chat->attachment. Origin of the issue: ==================== In web_editor, optimized versions of the images are created. In the chatter we load all attachments, original

Issue:
======
Duplicate attachmenets are loaded in chatter.

Steps to reproduce the issue:
=============================
- Go to massmailing, create a new email with a template with images.
- Replace the image by uploading a new one, save.
- The second and onward uploaded images have two attachments in the
  tab->chat->attachment.

Origin of the issue:
====================
In web_editor, optimized versions of the images are created. In the
chatter we load all attachments, original and optimized ones which looks
like we have duplicates.

For .svg images, we create duplicate .png versions in python side.

Spec for Images created from mass_mailing:
===========================================
- For SVG images we show only the png version.
- For non SVG images we show the original version.

Solution:
=========
- For SVG images: If the image doesn't have .png version which means
added directly in the chatter/attach we show it otherwise we show the
.png version.

- For non SVG images: We always show the image which doesn't have
  original_id or their original_id image isn't in the list of
  attachment.

task-3639914
opw-3589477

Forward-Port-Of: odoo/odoo#169176

Download files are restricted to the internal users by acl. This commit adapts the UI so the feature would not be available for non-internal users. Steps to reproduce: - Go to a public channel as a guest - Send a message with multiple attachments - Try to download all of them by clicking on Download Files in the message action menu - It crashes with Forbidden error Forward-Port-Of: odoo/odoo#180109

Download files are restricted to the internal users by acl. This commit adapts the UI so the feature would not be available for non-internal users.

Steps to reproduce:

- Go to a public channel as a guest
- Send a message with multiple attachments
- Try to download all of them by clicking on Download Files in the message action menu
- It crashes with Forbidden error

Forward-Port-Of: odoo/odoo#180109

This commit fixes the record selector's caret positioning (displayed on hover only) by moving to be a sibling of the autocomplete's input. Steps to reproduce: - install Sales - open Dashboard - hover one of the filter in the ControlPanel => the filter's caret is displayed but on a separate line Enterprise: https://github.com/odoo/enterprise/pull/69944 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180046

This commit fixes the record selector's caret positioning (displayed on hover only) by moving to be a sibling of the autocomplete's input.

Steps to reproduce:
- install Sales
- open Dashboard
- hover one of the filter in the ControlPanel => the filter's caret is displayed but on a separate line

Enterprise: https://github.com/odoo/enterprise/pull/69944

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

Forward-Port-Of: odoo/odoo#180046

Before this fix `TestAnalyticMixin` used `product.product`, `account.move` and `account.move.line`, but `analytic` does not have these models in its dependencies. So this test causes `Single App` tests (when tests are run with just concerned modules and its dependencies) to fail. This commit adapts the tests so that they only use `account.analytic.*` models. original fix: https://github.com/odoo/odoo/commit/9d51fa9daee09e5467d38c5a890be7c0392d93f4 runbot error logs: https://runbo

Before this fix `TestAnalyticMixin` used `product.product`, `account.move`
and `account.move.line`, but `analytic` does not have these models in its
dependencies.

So this test causes `Single App` tests (when tests are run with just
concerned modules and its dependencies) to fail.

This commit adapts the tests so that they only use
`account.analytic.*` models.

original fix: https://github.com/odoo/odoo/commit/9d51fa9daee09e5467d38c5a890be7c0392d93f4

runbot error logs: https://runbot.odoo.com/web#id=74493&menu_id=405&cids=1&model=runbot.build.error&view_type=form

Forward-Port-Of: odoo/odoo#178930

- website.snippet documentation Description of the issue/feature this PR addresses: There are some website snippet documentation typos Current behavior before PR: The documentation with some typos Desired behavior after PR is merged: The documentation without any typos --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180058

- website.snippet documentation

Description of the issue/feature this PR addresses:

There are some website snippet documentation typos

Current behavior before PR:

The documentation with some typos

Desired behavior after PR is merged:

The documentation without any typos

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

Forward-Port-Of: odoo/odoo#180058

Steps to reproduce ================== - Install project - Open any task in a form view - Press the alt key => The hotkeys are not displayed. Cause of the issue ================== Since a6876ac03799c1e0626bac54129493155d9eb637 , the toolbar makes use of the useActiveElement() This is not correct since the toolbar is always attached to the DOM, only it's visibility is toggled when we need to show it. Solution ======== Revert the commit since the feature wasn't well supp

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

- Install project
- Open any task in a form view
- Press the alt key

=> The hotkeys are not displayed.

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

Since a6876ac03799c1e0626bac54129493155d9eb637 ,
the toolbar makes use of the useActiveElement()

This is not correct since the toolbar is always attached to the DOM,
only it's visibility is toggled when we need to show it.

Solution
========

Revert the commit since the feature wasn't well supported anyway and
there is no easy workaround.

opw-4175689

Forward-Port-Of: odoo/odoo#179950

In some occasions, Authorize would decline a payment and provide the reason for it, but not mark the payment as in error. The customer would see that their payment is cancelled but not know what to do. That is because error messages were not processed in the case of declined payments. This commit makes eventual error messages (decline reasons) logged on the linked document's chatter and displayed on the /payment/status page. opw-4125895 Forward-Port-Of: odoo/odoo#179805 Forward-Port-Of: o

In some occasions, Authorize would decline a payment and provide the reason for it, but not mark the payment as in error. The customer would see that their payment is cancelled but not know what to do. That is because error messages were not processed in the case of declined payments.

This commit makes eventual error messages (decline reasons) logged on the linked document's chatter and displayed on the /payment/status page.

opw-4125895

Forward-Port-Of: odoo/odoo#179805
Forward-Port-Of: odoo/odoo#178401

Commit bf49460e4a51494fe5b2346d75c4105832e7d412 wrongly forgot to multiply the amount by the quantities to consider the amount in the discount wizard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180083

Commit bf49460e4a51494fe5b2346d75c4105832e7d412 wrongly forgot to multiply the amount by the quantities to consider the amount in the discount wizard.


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

Forward-Port-Of: odoo/odoo#180083

Current behavior before PR: When creating a table in email marketing using the powerbox command `/table`, the table picker would open at an incorrect position. Desired behavior after PR is merged: Now, when using the `/table` powerbox command to create a table in email marketing, the table picker will open at the cursor position. task-4113199 Forward-Port-Of: odoo/odoo#176712

Current behavior before PR:

When creating a table in email marketing using the powerbox command `/table`, the table picker would open at an incorrect position.

Desired behavior after PR is merged:

Now, when using the `/table` powerbox command to create a table in email marketing, the table picker will open at the cursor position.

task-4113199

Forward-Port-Of: odoo/odoo#176712

- Change address format for all reports when a company is established with the country of Ecuador. - Add extra validation when getting the ats code from the contact, in case it is an Final Consumer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179558

- Change address format for all reports when a company is established with the country of Ecuador.
- Add extra validation when getting the ats code from the contact, in case it is an Final Consumer.

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

Forward-Port-Of: odoo/odoo#179558

Adds new Belgian payroll export capabilities so companies can send payroll-related work entry data to social secretariats such as Group S, Partena, and UCM. This reduces manual preparation work and helps Belgian payroll teams exchange data with external providers more efficiently.

Adds support for managing Washington workers' compensation within US payroll. Payroll teams can configure worker compensation details on employee contracts and apply related employee and employer salary rules for more accurate payroll calculations.

This will add a model for handling worker compensation in the state of Washington. It will also add salary rules for the employee and employer based on
 the worker compensation.

 Task: 4132640

A new reporting option lets Egyptian payroll users generate an Excel master report for one or more months. The report lists employees and their earned amounts, making payroll review and period-based reporting easier for HR and payroll teams.

Link to task: [#4177169](https://www.odoo.com/web#model=project.task&id=4177169)

This will add a new Reporting menu for Eygpt to generate a master report. 
- The master report is an Excel file that represents one or more month(s), listing each employee and the amount they earned.
- Done in UAE : https://github.com/odoo/enterprise/pull/61917

A new dashboard has been added for email marketing automation, giving teams a clearer view of campaign performance and related marketing metrics. This helps business users monitor results more easily and make faster decisions from a dedicated reporting view.

…eting dashboard

This commit adds a new module with the new email marketing dashboard.

Task: 4179584

Adds a new Lebanon localization package with a ready-to-use chart of accounts, tax definitions, and fiscal positions. This helps companies operating in Lebanon configure accounting more quickly and align their Odoo setup with local requirements.

Link to task: [#3927914](https://www.odoo.com/web#model=project.task&id=3927914)

Added base localization package with chart of accounts, taxes, and fiscal positions for Lebanon 🇱🇧

Spreadsheet pivot measures can now be shown in alternative formats, such as percentage of a row or column total. This helps users compare results more easily without manually calculating totals outside the spreadsheet.

This commits adds the "Show value as" feature to measures. This allow users to display the value of a measure in a different way, like percentage of column total, percentage of row total, etc.

Task: 4045799

Accounting reports now handle journal filters more accurately when multi-ledgers are used across multiple companies. Users can include journals from all companies while excluding only those specifically blocked by a ledger, and ledgers can also be made visible to all companies.

Improve journal filters on accounting reports, particularly when multi-ledgers are used. Following changes from the community PR, multi-ledgers can now exclude journals from different companies. The company_id field now only indicates which company can view the multi-ledger in the filters.

When a multi-ledger is selected, all journals from all companies are included, except those explicitly excluded by the ledger. Additionally, a ledger can be made visible to all companies.

task-4141521

The recurring revenue report now lets users search or filter by company. This makes it easier for businesses operating multiple companies to review subscription revenue for the right organization.

The timesheet leaderboard now moves below the header only when there is not enough space, instead of switching based on a fixed screen size. This creates a cleaner, more consistent experience across different screen widths and layouts.

This commit will add a small improvement to the leaderboard component ; it will now be displayed on the bottom of the header only when it doesn't fit, whereas before it would be displayed on the bottom when a certain screen size was reached.

task-3765013

Thread action buttons in messaging-related screens have been visually improved for a clearer, more consistent experience. This helps users interact with discussions, knowledge threads, and WhatsApp conversations more easily without changing the underlying workflow.

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

The UAE payroll localization now supports more payroll scenarios, including end-of-service updates, leave provisions, social insurance, overtime, DEWS benefits, unpaid leave, and additional payment or deduction inputs. This helps businesses calculate employee pay and provisions more accurately for UAE-specific requirements.

Link to task: [#4065541](https://www.odoo.com/web#model=project.task&id=4065541)

this is an improvement to the UAE localization hr payroll module which includes the following changes to the rules:
Amendments:
- EOS Calculation Update
- EOS Provision Calculation Update

Additions:
- Basic Salary
- Annual Leave Provision
- Social Insurance
- Overtime
- Sick Leaves
- DEWS Benefits
- Unpaid Leave
- Out of Contract
- Paid Leave Remaining Balance
- Additional Input types

The WhatsApp module now includes demo and sample data to make demonstrations and testing easier. This helps teams validate common WhatsApp workflows without needing to complete a full setup first.

**PURPOSE:**

We have to add demo data for demonstration purposes and populate data to simulate and test specific flows without requiring full configuration.

**SPECIFICAITONS:**

Demo data has been added, and a populate scripts has been added to populate data, replicating testing scenarios and ensuring thorough testing without requiring full configuration.

Task id-3984360

Related Community PR: [odoo/odoo#174183](https://github.com/odoo/odoo/pull/174183)

This change restores timesheet billing targets from percentages back to billable hours, making it easier for managers to see whether employees are meeting yearly expectations. It also adjusts leaderboard and reporting views so performance is measured against each employee's billable time target rather than their working calendar.

This commit will revert odoo#54238, because the changes introduced in this PR makes it difficult for the manager/team leader to know if the mployees in his team reached the yearly target.

- Revert "billing_rate_target" (in %) to "billable_time_target" (in hours)
- Revert the computation of the billable rate in the leaderboard from using the employee's working calendar to using the employee's billable time target

task-4122708

The calculation of amounts still to invoice now follows each sales order line instead of the full order total. This keeps credit limit checks aligned with how Sales considers orders completed, avoiding misleading outstanding balances after price changes or down payments.

In 16.2, the amount to invoice was introduced to effectively compute the total receivable of a partner.
The goal was to take into account the confirmed SOs that are not invoiced yet, in order to trigger the partner's credit limit warning.
Since then:
- The total receivable of a partner = unpaid posted invoices + SOs amount to invoice.
- Where the amount to invoice = SO total - confirmed down payments.

The issue with that method is that we go against the Sales philosophy, which considers that a SOL (Sales Order Line) is invoiced as soon as the invoiced quantity (whatever the invoice status) equals the ordered quantity.
That can lead to incoherent situations.
For example:
Let's imagine a SO with 2 products:
- 3 desks at €100
- 5 chairs at €50.

We invoice 3 desks at 90€ because of a price change and 5 chairs at 50€.
Sales will consider the SO to be done ("nothing to invoice"), whereas Accounting consider that there's still €30 to invoice.
The bottom line is that:
- We should consider the amount to invoice per SOL and not per SO total.
- We should remain consistent with the Sales methodology, to avoid weird cases as demonstrated before.

task-3764582

When invoice scanning cannot match an existing partner, the partner creation form now opens with more suggested details already filled in. This can save time and reduce manual entry by using extracted information such as contact details, tax number, country, and bank information.

With this change if a partner is not found using the ocr, the user when opening up the partner creation form will receive additional default values. The fields that can be added are: phone, mobile, website, email, vat number, country and bank details.

Task-3818879

Performance test expectations for appointment scheduling were adjusted to match recent user settings changes. This keeps internal quality checks accurate without changing how users book or manage appointments.

This commits updates three query counter checks adding three extra queries in order to adapt them to the addition of 1. a new sub query in 'calendar.event' which refers to the 'res.users.settings' table, 2. the fetching of the Default User Template in the 'res.users' model and 3. the search of the current user's 'res_users_settings_id' configuration.

related-to: odoo/odoo#162467
task-3850837

Some pages were generating incorrect links after the move to newer, user-friendly URLs. This update corrects the template errors so appointment and appraisal survey links lead users to the right destinations.

Since the migration from the old URLs to the new user-friendly URLs, some typos were introduced in the templates. The syntax of the parameters of the Qweb dynamic attributes was not respected. This leads to incorrectly generated URLs.

task-id 3820230

Odoo now converts Serbian Latin locale information into a format that browser-based features can understand. This prevents unexpected errors in affected apps when users work with the Serbian Latin language setting.

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This commit adapts the code to use the properly formatted locale, thus avoiding unexpected crashes.

*: sale_timesheet_enterprise, spreadsheet_edition, web_studio

Task-4014022

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

Forward-Port-Of: odoo/enterprise#66287
Forward-Port-Of: odoo/enterprise#66061

The file drop area component was moved out of the messaging area so it can be reused by other parts of Odoo, such as imports. Enterprise tests were updated to follow the new shared naming, with no expected change in user behavior.

In the related community PR, we moved the `Dropzone` component from the `mail` module to the `web` module to ensure that the component can be used in the `base_import` module. This commit will simply remove the `mail` prefix from the classes defined in the `Dropzone` component.

COM PR: https://github.com/odoo/odoo/pull/172623

task-3956293

Starting as from `saas-17.2`, PrinterDriver's default action requires a `print_id`, which was not provided by the longpolling service action method. We added the missing parameter to avoid the traceback created by this error. Forward-Port-Of: odoo/enterprise#69737

Starting as from `saas-17.2`, PrinterDriver's default action requires a `print_id`, which was not provided by the longpolling service action method. We added the missing parameter to avoid the traceback created by this error.

Forward-Port-Of: odoo/enterprise#69737

When the no-content helper is shown and the user clicks on the "New" button to create a new article, the sidebar lists the newly created article in the "workspace" and in the "private" section. This is an undesirable behavior as the newly created article should only appear in the "private" section. When no record is passed to the form view, the form view creates a virtual record. When the user clicks on the "New" button, the system will create a new article and open it using the `openArticle`

When the no-content helper is shown and the user clicks on the "New" button to create a new article, the sidebar lists the newly created article in the "workspace" and in the "private" section. This is an undesirable behavior as the newly created article should only appear in the "private" section.

When no record is passed to the form view, the form view creates a virtual record. When the user clicks on the "New" button, the system will create a new article and open it using the `openArticle` function defined in the component environment.

When calling the `openArticle` function, the function will check if the article has a title and, if it hasn't, it will fetch the first heading of the article and use it as title (see: `ensureArticleName`). If the record is not virtual, the function `openArticle` will then persist the changes made on the current record before opening the new record.

For its part, the sidebar listens to the changes made on the loaded record (using a record observer) and updates its state based on the record changes. When calling the `ensureArticleName`, the title of the virtual record changes and the sidebar detects that change and adds a new entry for the virtual record. The sidebar will then add another entry for the newly created record.

To fix the issue, the `openArticle` function will no longer call the `ensureArticleName` function when the current record is virtual. The virtual record state will hence no longer be updated when opening a new article. As a result, the sidebar will not detect any change and will no longer create an entry for the virtual record.

Note that there was actually no reason to update the title of the virtual record as it gets discarded when leaving Knowledge.

Steps to reproduce the issue:
1. Delete all articles from the database
2. Open the Knowledge editor (you should see the no-content helper)
3. Click on the "New" button

=> There is two entries for the new article: one in the "workspace" section and one in the "private" section.

TO BE: There should only be one entry in the "private" section.

task-4160386

Forward-Port-Of: odoo/enterprise#69438

This commit adds the possibility to disable the month or quarter granularity (or both) for fixedPeriod date filters. Task: [3887844](https://www.odoo.com/web#id=3887844&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#69854 Forward-Port-Of: odoo/enterprise#64964

This commit adds the possibility to disable the month or quarter granularity (or both) for fixedPeriod date filters.

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

Forward-Port-Of: odoo/enterprise#69854
Forward-Port-Of: odoo/enterprise#64964

…g from it How to reproduce: - Install documents_hr - Open Employee -> "Abigail Peterson" -> stats button Documents - Upload a file The document is not linked to the employee record "Abigail Peterson". With this fix, it is and you can see it in the inspector of that document: "Employee Abigail Peterson" Task-4122377 Forward-Port-Of: odoo/enterprise#68959 Forward-Port-Of: odoo/enterprise#68541

…g from it

How to reproduce:
- Install documents_hr
- Open Employee -> "Abigail Peterson" -> stats button Documents
- Upload a file

The document is not linked to the employee record "Abigail Peterson". With this fix, it is and you can see it in the inspector of that document: "Employee Abigail Peterson"

Task-4122377

Forward-Port-Of: odoo/enterprise#68959
Forward-Port-Of: odoo/enterprise#68541

Currently, a traceback is occurring when the user tries to compare `periodically` in account reports having a `fiscal year` of date today. To reproduce this issue: 1) Install Accounting 2) Enable fiscal year from accounting settings 3) Now create a fiscal year record with `start` and `end` dates as today 4) Open balance sheet report 5) Filter the comparison as `Previous Period` Error:- ``` TypeError: can't compare datetime.datetime to datetime.date ``` After the recent cha

Currently, a traceback is occurring when the user tries to compare `periodically` 
in account reports having a `fiscal year` of date today.

To reproduce this issue:

1) Install Accounting
2) Enable fiscal year from accounting settings
3) Now create a fiscal year record with `start` and `end` dates as today 
4) Open balance sheet report
5) Filter the comparison as `Previous Period`

Error:- 
```
TypeError: can't compare datetime.datetime to datetime.date
```

After the recent changes from this commit https://github.com/odoo/enterprise/pull/48530/commits/4f0432e86de6d6f4e8f78f11dbba1f8f2b4dafe5, this error is occurring. 
Because `period_date_from` is getting from `fiscal_year`, which is a `datetime.date` format.

https://github.com/odoo/enterprise/blob/4c1947963be235f733a56ee3d04b9f8f64d213ea/account_reports/models/account_report.py#L4769-L4775

But here the `comparision_date_from` is of type `datetime.datetime`, 
which leads to a traceback when comparison is done between both.

https://github.com/odoo/enterprise/blob/4c1947963be235f733a56ee3d04b9f8f64d213ea/account_reports/models/account_report.py#L4796-L4797

When the fiscal year record is there we can convert it to datetime.datetime, 
By doing this we can resolve this issue.

sentry-5695535237

Forward-Port-Of: odoo/enterprise#69721

Before this commit: - The budget line tooltips were unclear for some fields. After this commit: - The budget line tooltips have been updated for better clarity. Task-4120878 Forward-Port-Of: odoo/enterprise#69181

Before this commit:
- The budget line tooltips were unclear for some fields.

After this commit:
- The budget line tooltips have been updated for better clarity.

Task-4120878

Forward-Port-Of: odoo/enterprise#69181

When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns an error, a traceback will appear. Steps to reproduce the error: - Install ```l10n_ke_edi_oscu``` - Set up Kenya eTIMS Integration - Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron Traceback: ``` KeyError: 'noticeList' File "odoo/tools/safe_eval.py", line 391, in safe_eval return unsafe_eval(c, globals_dict, locals_dict) File "ir.actions.server(909,)", line 1, in <module> File "home/

When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns
an error, a traceback will appear.

Steps to reproduce the error:
- Install ```l10n_ke_edi_oscu```
- Set up Kenya eTIMS Integration
- Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron

Traceback:
```
KeyError: 'noticeList'
  File "odoo/tools/safe_eval.py", line 391, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(909,)", line 1, in <module>
  File "home/odoo/src/enterprise/saas-17.4/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py", line 35, in _cron_l10n_ke_oscu_get_notices
    notice_map = {notice['noticeNo']: notice for notice in data['noticeList']}
ValueError: <class 'KeyError'>: "noticeList" while evaluating
'model._cron_l10n_ke_oscu_get_notices()'
  File "odoo/addons/base/models/ir_cron.py", line 562, in _callback
    self.env['ir.actions.server'].browse(server_action_id).run()
  File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
    res = super().run()
  File "odoo/addons/base/models/ir_actions.py", line 989, in run
    res = runner(run_self, eval_context=eval_context)
  File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
    res = super(ServerAction, self)._run_action_code_multi(eval_context)
  File "odoo/addons/base/models/ir_actions.py", line 821, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self))  # nocopy allows to return 'action'
  File "odoo/tools/safe_eval.py", line 405, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

https://github.com/odoo/enterprise/blob/019a7cdd5a3071c0948656bdcacc95b63c2e8842/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py#L35 When eTIMS API returns an error, data will be empty,
So, it will lead to the above traceback.

sentry-5804573762, 5809459581

Forward-Port-Of: odoo/enterprise#69727

To reproduce: Create an invoice, in foreign currency. Use a withholding tax, like 10% ILA Post the invoice => The rendering of the dte fails It's still using a deprecated method, which has been removed after 16. no task Forward-Port-Of: odoo/enterprise#69769

To reproduce:
Create an invoice, in foreign currency.
Use a withholding tax, like 10% ILA
Post the invoice

=> The rendering of the dte fails

It's still using a deprecated method, which has been removed after 16.

no task

Forward-Port-Of: odoo/enterprise#69769

Currently, the share panel cannot be closed once it has been opened. This commit resolves the issue by preventing the share panel from closing only when the active element is a modal. Steps to reproduce the issue: 1. Open Knowledge. 2. Click on the share button to open the share panel. 3. Click on the share button again to close the share panel. => The share panel remains open. TO BE: The share panel should close. Details: In the `KnowledgeTopbar` component, we added external ev

Currently, the share panel cannot be closed once it has been opened. This commit resolves the issue by preventing the share panel from closing only when the active element is a modal.

Steps to reproduce the issue:
1. Open Knowledge.
2. Click on the share button to open the share panel.
3. Click on the share button again to close the share panel.
 
=> The share panel remains open.
TO BE: The share panel should close.

Details:

In the `KnowledgeTopbar` component, we added external event listeners to detect when the dropdown menu is opened, closed, or about to close.

When the dropdown is about to close (i.e., when the `hide.bs.dropdown` event is triggered), we check if the active element is the HTML document. If the focus is on another element, we prevent the dropdown from closing. This mechanism was added to prevent the dropdown from closing when users are adding new members through the invite modal.

Using the `useActiveElement` hook, the active element can change when a component is mounted. When the web editor in Knowledge is mounted, the active element becomes the editor toolbar. As a result, the active element is no longer the HTML document, and the event listener always prevents the dropdown from closing.

To resolve this issue, we will now check if the active element is a modal before preventing the dropdown from closing. This ensures that the dropdown behaves as expected and the share panel can be closed when necessary.

Reference: https://github.com/odoo/odoo/pull/175880

task-4179706

Forward-Port-Of: odoo/enterprise#69861

Not passing the previous_options can have bad consequences, and was clearly not wanted here. Forward-Port-Of: odoo/enterprise#69913

Not passing the previous_options can have bad consequences, and was clearly not wanted here.

Forward-Port-Of: odoo/enterprise#69913

This fix prevents Odoo-generated spreadsheet files from being automatically deleted by the system's cleanup process. When users upload certain file types, Odoo converts them to spreadsheet format, but these converted files were being incorrectly removed after 24 hours. This update ensures converted spreadsheets are preserved and not lost.

Problem:
Auto-vacuum is incorrectly archiving reformatted spreadsheet documents that were generated from unsupported file uploads. Specifically, when an .xlsx file is uploaded, Odoo creates a new, compatible spreadsheet document. However, this newly generated document is mistakenly deleted during the auto-vacuum process if it is older than 24 hours.

Purpose:
Add a domain to prevent Odoo created spreadsheets from uploads being caught by autocron vacuum from improvement to 17.0 last year

Steps to reproduce bug:
1.) Upload an xlsx file
2.) Click on the xlsx file
3.) It will generate an Odoo file of the same type
4.) Set the date of the new file to older than 24 hours 
5.) The formatted file will be deleted when the autocron hits

opw-4087851

This update reorders how information appears on Swiss payslips to improve readability and visual presentation. The gross salary amount now displays before deductions, making it easier for employees to understand their earnings at a glance.

Gross should come before deductions for aesthetic purposes on the payslip

This fix resolves an issue where PDF attachments were not being included when exporting financial data to Datev format from the general ledger. The system now correctly selects and includes the main attachment from invoices in the exported zip file, ensuring all necessary documents are available for accounting purposes.

Take a demo invoice, print it.
Go to general ledger, print Datev ATCH, the pdf is not attached. 

We should select the message_main_attachment_id, 
as it's the one we want to have in the zip anyway.

opw-4162604

This fix corrects how subscription orders display their invoice status. Previously, subscription orders were incorrectly showing as "fully invoiced" even when there were future invoices still pending. The system now properly checks the next invoice date to accurately reflect whether there are more invoices to generate, ensuring users have the correct visibility into their subscription billing status.

Versions
--------
- 17.0+

Steps
-----
1. Create a subscription SO w/ a subscription product;
2. set recurrence to monthly;
3. set start date to 3+ months ago;
4. confirm & create invoice.

Issue
-----
In the Other Info tab, the Invoice Status is displayed as fully invoiced, despite there still being several months to invoice.

Cause
-----
The `_compute_invoice_status` method doesn't doesn't check `next_invoice_date` to decide whether a line's status should be `invoiced` or `to invoice`.

Solution
--------
Modify the override for `_compute_invoice_status` in sale_subscription, to change the `invoice_status` from `invoiced` to `to invoice` if the `next_invoice_date` is today or earlier.

Also change compute dependency from `order_id.is_subscription` to `order_id.next_invoice_date`. This maintains a transitive dependency to `order_id.is_subscription`.


opw-3849059

Fixed an issue where the bank reconnection button was not appearing when a bank connection's expiration date was set for today. This fix ensures users can promptly reconnect their bank accounts when needed, improving the user experience for online banking synchronization.

The aim of this commit is fixing the connected until widget to show the reconnect bank button when the expiration date is for today.
The right to fix that, is doing the fix in the view but to avoid breaking the stable policy, we decide to make the change in the JS widget.

task-4058051

This fix resolves an issue where appointment types that use only resources (instead of staff members) were becoming unbookable. A recent change to allow organizer modifications in Microsoft Calendar was incorrectly requiring the appointment creator to be listed as an attendee, which doesn't apply to resource-based appointments. The fix adds a condition to skip this check for resource-only appointment types, restoring their functionality.

Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable.

Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users.

This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/162927
opw-3841495

This update fixes a bug that was preventing users from closing the share panel in the Knowledge module. A previous change inadvertently broke this functionality, and this fix reverts that problematic change to restore the ability to close the share panel properly.

This reverts commit a80633d9f713884f3bda063de21c080bc062f6af.

This fix resolves an issue where partially completed production orders would create confusing duplicate component lines when creating backorders. Now when you partially complete a production using barcode scanning and then create a backorder, the remaining components will be consolidated into a single line per product, making inventory tracking clearer and more intuitive.

**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.

**Expected behavior:**
The backorder should have one move for the remaining component
quantity.

**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
     some component -> Confirm

2. Open the production in barcode, add 5 of the final product to
     its line and 5 of the component to its line -> exit the
     transfer view

3. Reopen the production and validate it -> create backorder

4. Open the backorder to see the odd split of the component
     product's moves

**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.

**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.

opw-4148050

A bug in the UK tax reporting system has been corrected where important data (previous options) was not being properly passed through to the underlying system. This fix ensures tax reports are generated correctly without data loss or unexpected behavior.

Not passing the previous_options can have bad consequences, and was clearly not wanted here.

Forward-Port-Of: odoo/enterprise#69913

This fix ensures that invoices from Northern Irish customers are now properly included in the EC Sales Report. Previously, these invoices were being excluded from the report, which could lead to incomplete sales data for businesses operating in Northern Ireland.

### Steps to reproduce

* install `account_intrastat`
* create and confirm an invoice for a Northern Irish customer
* open the EC Sales Report

You will see that your invoice is not included in the report

opw-4123375

Forward-Port-Of: odoo/enterprise#69501

This update corrects the visual appearance of the dropdown arrow (caret) in the Account Reports dashboard filters when users hover over them. The styling was adjusted to match improvements made to similar dropdown elements across the system, ensuring a consistent and polished user experience.

This commit adapts the Account reports's filters styling, following the fix of the record selector's caret positioning made in community.

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