This pull request updates the localization files (.weblate.json) for the account_accountant_fleet module, adding support for several new languages including Arabic, Spanish, and Finnish. This ensures the Odoo Enterprise application is properly translated and accessible to a wider range of international users.

Forward-Port-Of: odoo/enterprise#117623

This update ensures that new features related to planning templates, specifically the addition of company and worksheet template fields, are thoroughly tested. These tests improve the stability and reliability of the planning module by verifying correct functionality and data handling.

The purpose of this commit is to ensure that the code of the following PR: https://github.com/odoo/enterprise/pull/112198 is properly tested. 
We add tests related to the addition of the `company_id` field on planning.slot.template, as well as the addition of `worksheet_template_id` field.

task-6147827

Forward-Port-Of: odoo/enterprise#115286

This update enhances the user experience of the Odoo portal by standardizing the capitalization of chatter headers. Additionally, the chatter header has been moved to its template, streamlining the design and making future updates easier. This improves consistency and maintainability of the portal interface.

* = planning_field_service, sign

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

This commit improves the portal chatter UX by adapting
the capitalization of the chatter header.

This commit also moves the portal chatter header to its template,
reducing repetitions and making it easier to adapt in the future.

task-6041769

This update removes restrictions on the fiduciary VAT field in the connection wizard for the Codabox BE localization module. This change provides greater flexibility for users managing fiduciary VAT settings, streamlining the connection process. It addresses a previous limitation impacting VAT configuration.

This commit will remove the readonly on the fiduciary_vat in the connection wizard. It will give more flexibility for fiduciary.

task-6148930

Forward-Port-Of: odoo/enterprise#115752

This update cleans up the action menu within the Sales Order module, streamlining the user experience. The action's name has been updated for clarity and consistency. This change improves the overall usability of the sales order process.

In the Action menu (accessed via the gear icon), action has been renamed.

Community PR: https://github.com/odoo/odoo/pull/257925
tasks-6088366

This update allows timesheet managers to approve their own timesheets, streamlining the approval process for self-managers. This change simplifies workflow and reduces the need for manual intervention when a manager approves their own work. It's a minor improvement to the timesheet management system.

Timesheet managers can approve their own timesheets if they have access to all timesheets and they assigned themselves as their timesheet approver

task-4755604

This update fixes a bug preventing users from selecting 'Custom Dates' and 'Specific Date' options when comparing accounting reports. The change aligns the report filter with a recent system update, ensuring the full range of date comparison options are available. This improves the usability of the Profit & Loss reporting feature.

**Problem:**
The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports.

**Steps to reproduce:**
1. Go to Accounting > Reporting > Profit & Loss
2. Click the Comparison dropdown
3. Only "No Comparison", "Previous Period", and "Same Period Last Year" are visible — "Custom Dates" is missing

**Current behavior:**
Custom date comparison options are not rendered.

**Expected behavior:**
"Custom Dates" (for range reports) and "Specific Date" (for single date reports) should appear in the Comparison dropdown.

**Cause of the issue:**
The date filter refactor (40484f985f5) restructured how the date mode is stored in options. Previously, `options.date.mode` held 'range' or 'single'. After the refactor, this key no longer exists — the mode is now stored as a boolean in `options.filter_date.range_mode`.

The comparison filter template still checks
`controller.cachedFilterOptions.date.mode`, which is now undefined, so both the range and single conditions always evaluate to false and the custom comparison options are never rendered.

**Fix:**
The comparison template was the only consumer not updated during the refactor. Aligning it to the new data path restores the options without any behavioral change.

opw-6070402

Forward-Port-Of: odoo/enterprise#117099
Forward-Port-Of: odoo/enterprise#113391

This update corrects a technical issue that prevented accurate payroll calculations when a payrun had no associated payslips. The fix ensures the system functions correctly regardless of the number of payslips generated, improving payroll accuracy and reliability. This change primarily impacts the Australian HR Payroll module.

If the payrun does not have any payslips, the _get_payslip_stp
is called on an empty recordset, which causes the compute to fail.
This commit fixes the _get_payslip_stp compute for empty recordset.

task-6215823

Forward-Port-Of: odoo/enterprise#117198

This update corrects a misleading warning message that appeared when a payslip was cancelled in Odoo Enterprise. The change ensures that users receive accurate information and a cleaner workflow when managing payslips. This improves the overall user experience and data consistency.

. Clear payslip warning after cancelling the payslip
. Add corresponding tests

task-6199148

Forward-Port-Of: odoo/enterprise#117507
Forward-Port-Of: odoo/enterprise#116859

This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. By renaming the duplicate ID, we've ensured that approval rules are applied correctly based on user and manager access levels, improving the reliability of the approval process. This resolves a potential inconsistency in how approvals were handled.

The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`.

This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules.

task-6095010

Forward-Port-Of: odoo/enterprise#113480

This update ensures that all employee groups, regardless of their type, receive the correct employer-paid rent posting account in payroll accounting. Previously, this setup was limited to a single group, leading to inconsistencies. This change maintains accurate and predictable payroll accounting behavior.

Before this commit, the employer-paid rent setup was only applied to one employee group. This could leave other employee groups without the expected rent posting account.

After this commit, the same rent posting setup is applied for each available employee group. This keeps payroll accounting behavior consistent.

Task-6175007

Forward-Port-Of: odoo/enterprise#115781

This update resolves an issue where depositing money in Point of Sale (PoS) orders with presets enabled would incorrectly display a popup asking for a preset selection. The change ensures that PoS orders are correctly identified as 'settling accounts' immediately, preventing this unwanted popup and streamlining the deposit process. This improves the user experience for cash transactions.

Before this commit:
====================
depositing money for a partner in PoS with presets enabled could incorrectly trigger the preset selection popup. This happened because the order was not marked as is_settling_account early enough, so the preset selection logic did not ignore deposit orders.

After this commit:
=====================
is_settling_account is initialized during order setup and seeded immediately when the deposit order is fetched or created. As a result, deposit orders correctly bypass the preset selection flow.

Task-6217580

Related Comm. PR-https://github.com/odoo/odoo/pull/264572

Forward-Port-Of: odoo/enterprise#117378

This update corrects a technical error that was consistently enabling a security feature (LNA) for all longpolling requests. The fix removes a mistakenly reintroduced parameter, ensuring LNA is only enabled when needed, improving system stability and efficiency. This resolves a potential configuration issue.

In odoo/enterprise#104157, the `headers` parameter was accidentally reintroduced to the `rpc` function of the longpolling class. This was causing `post` to be called with the wrong number of arguments, and a side-effect of this is that LNA was being enabled always for poll requests and never for action requests.

This commit removes the headers parameter so that the function is called with the correct number of arguments.

Forward-Port-Of: odoo/enterprise#117584

This update fixes an issue where the CO State Income Tax on payslips was incorrectly showing a positive value. This was due to a misinterpretation of tax withholding rules, aligning with previous fixes for Alabama. The change ensures that state income tax is accurately deducted from employee paychecks as a withholding, reflecting how individuals receive refunds when filing their income.

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#117497
Forward-Port-Of: odoo/enterprise#112724

This update aligns the subheaders and numerical data within Odoo's financial reports, ensuring a more visually consistent and professional presentation. Previously, the alignment of subheaders and figures was inconsistent, and this change standardizes the layout for improved readability and a better user experience.

Before this commit, subheaders of numeric columns were centered, while the figures in the columns were aligned to the end. This commit ensures that both the subheader and the figures are aligned the same way (center or end).

task-6197223

Forward-Port-Of: odoo/enterprise#117477
Forward-Port-Of: odoo/enterprise#116578

This update fixes an error that occurred when generating the Appendix 142 report with no data. It now safely handles empty reports and updates the Vietnamese VAT return type to use a more comprehensive composite tax report. These changes ensure the report generates correctly even with limited data, improving data accuracy and reliability.

This commit addresses an issue where generating the Appendix 142 report with no data would result in an error, and updates the Vietnamese VAT return type to use the overarching composite tax report.

Modifications:
- Added defensive checks to handle empty report lines. If the list is empty, it now safely returns the export HTML with default empty/zeroed contextual variables. Added bounds and existence checks for the base amount and VAT amount indexes to prevent out-of-bounds errors when evaluating purchase lines, sales lines, and section totals.
- Changed the report reference on the Vietnamese tax return type record to use the composite tax report rather than the standalone form 01 report.
- Swapped the data loading order in the module manifest to load tax report data before return data to resolve external ID dependencies.
- Adjusted report sequences so the main Vietnamese Tax Report appears first (sequence 10) and the Purchase/Sale Invoice List appears second (sequence 20).

Task-6216318

This update fixes a potential error in calculating the employment bonus for employees on out-of-contract payslips. Previously, multiple payslips with overlapping worked hours could lead to double-counting, which has now been addressed to ensure accurate bonus calculations based on total workable hours.

In the case of out of contract payslips, we might have multiple payslips with worked day lines for the same month. In that case, we need to be careful to not count these hours twice when computing the employment bonus, which depends on the total "workable" hours for the month.

task-6208125

Forward-Port-Of: odoo/enterprise#116862

This update fixes an issue where the 'step bubble' bar on payruns incorrectly displayed attendance status for employees. The change ensures that payrun bubbles accurately reflect employee tracking methods, resolving confusion and improving the user experience when updating employee settings.

Two bugs stem from the payrun "step bubble" bar (Employees → Time [→ Attendance] → Payslips):

1. When a payrun not containing attendance-tracked employees is opened first and I change one of the employee's tracking method to attendance, going back via breadcrumb I'd see that the Attendance bubble incorrectly appears for the latter. The root cause is that cachePayRunSteps is a Map iterated in insertion order: "attendance" is appended after "payslip" the first time it is encountered, so it always renders last regardless of the server-defined canonical order. Fixed by turning it into an array overridden at every data fetch.

2. When navigating back to the payrun list via breadcrumb after changing the last of an employee's work_entry_source (e.g. removing the last attendance-tracked employee from a payrun), the bubble still shows the previous state. Fixed by marking the payrun as fresh when following specific flow, preventing the reload of the bubbles using instead the previously cached ones.

task-5959087

Forward-Port-Of: odoo/enterprise#117590

This update fixes an issue where the rental report was displaying incorrect dates. The fix ensures that each row in the report accurately reflects the start and return dates of the rental order, providing more reliable reporting data. This improves the accuracy of rental tracking and reporting.

The rental report is a daily report with x rows by rental order, with x the days between the start and return dates.

With generate_series inside the select, the query was creating x rows with the same id, resulting in the date field not being correctly displayed (one unique date, the start date). This fix corrects the generation of the report to display the real date on each row.

opw-5266525

Forward-Port-Of: odoo/enterprise#116948
Forward-Port-Of: odoo/enterprise#104764

This update fixes a potential crash in the Gantt chart caused by incorrect drag initiation. The change reintroduces a safeguard to ensure the chart only initiates a drag when a valid target is available, preventing unexpected errors and improving overall stability.

In https://github.com/odoo/enterprise/pull/113438, it was incorrectly assumed that it would be impossible to initiate a pill drag without a valid target being found.

This commit reintroduces a strict safeguard to handle scenarios where the drag is triggered with no valid cell target. This prevents unexpected crashes encountered during test executions.

runbot-error-242486

Forward-Port-Of: odoo/enterprise#116619

This update fixes an issue where Knowledge articles appeared narrow when printed on large screens. The fix prevents a CSS rule from restricting the article's width, ensuring proper formatting and readability when exporting to PDF or printing. This improves the user experience for viewing and sharing Knowledge content.

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

This change addresses a frustrating user experience where physical expense cards get stuck in a pending state due to shipping delays. Users are now able to manually block these cards, preventing them from remaining indefinitely blocked and improving their ability to manage their expenses. This is a simple fix to improve user workflow.

Expenses created by expense cards can't be deleted for audit reasons.
However, it is frustrating for users not to be able
to clean their expenses afterwards.
It happens that physical cards aren't delivered to cardholders.
The shipping company is supposed to send us the failed shipping state,
but it sometimes doesn't. The user can't therefore do anything besides
activating the card that hasn't been shipped.
He is blocked and the card will stay pending indefinitely.

task: 5904913

This update fixes an issue where file names in the Documents section of the chatter didn't update after a file was renamed. By using the correct 'attachment_name' field, the chatter now accurately displays the latest file name, ensuring users always see the most current document information. This improves data consistency and user experience.

**Before this PR:**
When a file is renamed in Documents, the corresponding attachment in the chatter still displayed the old name.

**Technical reason:**
Renaming a file did not update its related attachment.
Inverse method was removed here: https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e

Therefore, now using `attachment_name` instead of `name` field in form view and `documents_details_panel`.

**After this PR:**
The attachment in the chatter will correctly reflect the updated file name.

Task-5859824

This update resolves an issue where users without write access to the AT Point of Sale (PoS) would receive an access error when attempting to authenticate. The fix simulates a token expiration to reliably trigger the error, ensuring proper access control is enforced for users with limited permissions.

When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error.

Steps to reproduce:
-------------------
* Setup Fiskaly in an AT company
* Open PoS and try to make a sale
* To fake the token expiration I modified the code so that the request always return 401 status code
> Observation: You get an access error

opw-5925203

Forward-Port-Of: odoo/enterprise#115735
Forward-Port-Of: odoo/enterprise#112474

This update resolves an issue where the payroll report would fail if a new employee's start date wasn't provided. The fix ensures the report checks for a start date before attempting comparisons, preventing errors and improving report reliability. This ensures accurate payroll calculations.

If there is no start date on the veriosn, the report will fail as it'll try to compare a bool with a datetime. So we check first that there is a start date

Forward-Port-Of: odoo/enterprise#117534

This update corrects a visual issue with payrun displays within the Odoo Enterprise payroll module. The fix removes unnecessary code and ensures payrun information is aligned correctly, improving the user experience. This ensures accurate and consistent reporting of payroll data.

Remove useless classes and fix alignment

task-6191499

Forward-Port-Of: odoo/enterprise#116528

A test was failing because the test record's name was identical to a demo data record. This change resolves the conflict, ensuring tests run correctly and reliably. This fix improves the stability of the testing process for the IoT module.

Our test record was named the same as a demo data record ("Shop"), making the test fail as it was looking for the test device contained by the test record, but not
contained by the demo record.

runbot-error-937748

This update resolves an issue preventing Payroll Assistant users from accessing the Payroll app. The change corrects a technical error that was causing access restrictions, ensuring all users can now utilize the Payroll functionality. This improves the reliability and usability of the Payroll module.

* = hr_work_entry_attendance

This commit prevents access errors that are triggered when a user with  Payroll Assistant role tries to open the Payroll app.

TaskID-6143823

Forward-Port-Of: odoo/enterprise#115297

This update resolves a problem that prevented the generation of PDF reports for Colombian tax statements. The change adjusts how data is accessed within the report generation process to align with a recent update in the Odoo system. This ensures reports are created correctly and avoids errors.

***Steps to reproduce*:**

- Install `l10n_co_reports` module.
- Create 2 vendor bills with taxes `0% EXEMPT` and `0.966% RteICA`.
- Navigate to Reports -> Colombian Statements -> Certificado de Retención en ICA
- Generate the PDF report.

***Observed behavior*:**

- An error is raised while generating the PDF: 
`AttributeError: 'AccountReportColumnData' object has no attribute 'get'`

***Cause*:**

After commit [1](https://github.com/odoo-dev/enterprise/commit/b92dc397bef029472a40223f51b611cdf5b631dc#diff-e97f74c63a6257470e69eb8122c12d0ce4afa5bc6013176bb69e702849575123) all report lines, columns, and annotations were converted
from dictionaries to custom objects (e.g., AccountReportColumnData). However,
the function `_get_report_values` still uses .get() to access values, which is only valid 
for dictionaries. Calling .get() on these objects raises an error.

***Fix*:**

- Replace the `get()` method usage with `column.name` format to access 
  values from `AccountReportColumnData ' properly.
- This ensures compatibility with the new structured column data format introduced in v19.2.

opw-6205984

Forward-Port-Of: odoo/enterprise#116902

This update simplifies how product and rental attributes are shown on the website. Previously, attribute values were displayed as confusing integer IDs. Now, they are presented using more readable attribute slugs, improving the user experience and making it easier to filter and select attributes.

On the shop page, the attribute values were encoded as follows:
```
attribute_values={attribute_id}-{attribute_value_1_id},{attribute_value_2_id}
```
On the product page, the attribute values were encoded as follows:
```
attribute_values={attribute_value_1_id},{attribute_value_2_id}
```
The attribute values were not only encoded differently (which is confusing), but also unreadable (since we were showing integer ids).

Now, the attribute values are encoded as follows, both on the shop and product pages:
```
{attribute_slug}={attribute_value_1_slug},{attribute_value_2_slug}
```
This addresses both issues pointed out above.

task-5129517
Community PR: https://github.com/odoo/odoo/pull/235541

This update fixes a visual issue where accounting reports, when filling a full page, would obscure the final row, preventing users from seeing all the data. The fix involves adjusting styling to ensure the complete display of accounting reports, improving data clarity for users.

Problem:
When an accounting report fills a whole page, the final row is not fully
visible

Steps to reproduce:
1- View a tax report that has a lot of entries that would fill the whole
screen
2- Notice how the last line is not fully visible and it isn't possible
to scroll and view the rest of it

Solution:
Correctly style the different < div > elements

opw-6171555

Forward-Port-Of: odoo/enterprise#117663
Forward-Port-Of: odoo/enterprise#116068

This update corrects a bug that prevented users from recreating templates after undoing a previous conversion. The fix ensures that the original project's documents folder is properly restored during the undo process, resolving a user error and improving template management. This prevents data inconsistencies and streamlines workflow.

Steps to Reproduce:
---
1. Create a project with documents.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing template conversion should properly restore original project's
documents folder and clean up template's documents folder.

Fix:
---
- Archive original project's documents folder during template creation
- Implement documents folder unarchival during undo operations

task-4916027

Forward-Port-Of: odoo/enterprise#117670
Forward-Port-Of: odoo/enterprise#91595

This update resolves an issue preventing non-administrator users from viewing the 'Users' settings within the Odoo Enterprise application. The fix allows users to access this critical functionality, improving usability and streamlining user management. This change ensures all users can manage their accounts and database connections.

Steps:
- Create a user X with admin rights
- Connect as X
- Open Settings/Users
- Access right error
```
    Failed to read field res.users.database_user_ids
    You are not allowed to access 'Database User' (databases.user)
```
opw-6209241

Forward-Port-Of: odoo/enterprise#117573

This update removes an outdated 'autosave' option from Odoo Enterprise's user interface, streamlining the system and aligning it with recent core changes. The change ensures that data is only saved when necessary, improving performance and reducing potential data inconsistencies. This affects several key modules within the Enterprise suite.

Following the core changes in `odoo/odoo`, this PR cleans up the enterprise modules by removing the now-obsolete `autosave` option in XML views and updating enterprise-specific widgets (like `CarrierTypeSelection`) to respect the `isInEdition` state.

**Community PR:** odoo/odoo#256598
**Task-5388752**

This update clarifies the installation process for payroll by moving related menu items directly within the core hr_payroll module. Previously, installing a related app would create a misleading impression of payroll being active. This change ensures a cleaner and more accurate user experience.

If you take time off as a one app free, it will install hr_work_entry which contains the root payroll menu item, giving people the impression that payroll was installed.
-> Moving those menu items to hr_payroll.

Task: 6072554

This update clarifies the purpose of a stock field used in forecasting, renaming it from 'location_final_id' to 'forecasted_location_id'. This change simplifies the system and ensures accurate multi-step push route calculations without affecting core inventory operations.

The `location_final_id` field is renamed to `forecasted_location_id` to prevent user confusion. This field is only utilized for forecasting multi-step push routes and does not impact actual inventory operations.