Fixed an access error that prevented users from viewing bank accounts in the Accounting Dashboard when using child companies or branches. This fix enables proper access to child bank journals, allowing multi-company setups to function correctly in the accounting module.

Steps to reproduce:
- Create a child company/branch
- Create a child Bank Journal for the Child Company
- Set on demo use the default company as the child company
- Connect with demo
- In the Accounting Dashboard try to open the Child Bank

Issue:
Access Error

opw-3746324

This update fixes the appearance of account reports when using dark mode, ensuring they look consistent with their light mode versions. Users who prefer dark mode will now see properly formatted and visually balanced financial reports without display inconsistencies.

In this fix we made the account reports in dark mode look similar to their light mode counterparts

task: 3770541

Fixed an issue where tax groups without a country assignment were not appearing in the tax report configuration screen. This ensures that all tax groups are properly visible when setting up new tax reports, improving the user experience during tax report configuration.

Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group.
Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show.

X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a

Forward-Port-Of: odoo/enterprise#58328

This fix resolves errors that occurred when employees clicked "I take it" or "I am unavailable" buttons in the planning interface or planning emails. The issue was caused by permission checks failing during the shift assignment process. The fix ensures these buttons now work smoothly without access errors, improving the employee scheduling experience.

This commit fixes some access rights errors that were occuring when clicking on buttons that would change the resource_id in the planning front-end or from the planning automatic emails.

Behaviour prior to fix:
Clicking on "I take it", "I am unavailable" in the front-end or in the automatic planning emails would lead to a planning rights error.

Cause:
When changing the resource_id from the front-end we do it trough sudo. Apparently, when redirecting the user and fetching the edited slot, the env changes, the sudo is lost, and the slot_properties field is recomputed. The access rights error is raised from the re-computation of that field.

Fix:
We call the field after changing the resource so it is re-computed with sudo. Then, when re-directing, there is no-need for re-computation and thus we don't get an access rights error.

task-3793005

This update restricts the CodaBox module to companies that have an Accounting Firm designated, preventing non-accounting firms from using features that could create unnecessary support tickets. The module now hides CodaBox connection settings and raises errors during installation if no Accounting Firm is configured. Settings section names have also been reorganized for clarity.

This fix ensures that when closing a tax period, the system uses the correct custom report handler associated with the report instead of always defaulting to the standard tax report handler. This resolves issues where reports with custom handlers were not being processed correctly during tax period closure.

If a report uses a `custom report handler`, he might not use the default `account.tax.report.handler`.

We should instead use the `custom report handler`
associated with the report.

task-3757417

This update fixes errors that occur when using Odoo's accounting features on Windows systems. Certain system configuration settings are unavailable on Windows, which was causing the application to crash when users tried to run reconciliation models or perform banking operations. The fix adds proper fallback handling for these missing settings so the system works smoothly on both Windows and Linux.

### Summary

Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741.

### Steps to reproduce

* make sure you're on an instance running on Windows [^1]
* install `account_accountant`
* go to any reconciliation model that has Auto-Validate enabled
* click on 'Run manually'

You should be met with a traceback: `TypeError: '<' not supported between instances of 'int' and 'NoneType'`

### Cause

The system expects `tools.config['limit_time_real_cron']` to be a number. However, on Windows systems, `limit_time_real_cron` and a few other configuration keys are disabled, and always set to `None`.
See https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L488-L497

opw-3752912
opw-3780549

[^1]: For testing on Linux, you can modify these two conditions to behave as if `os.name != 'posix'`:
https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L494-L497
https://github.com/odoo/odoo/blob/7fc9a0bd0a1871b14c508cce73e0f103de9c1283/odoo/modules/registry.py#L50-L57

Forward-Port-Of: odoo/enterprise#57728

This fix resolves an issue where canceling and resetting a renewal quotation to draft would lose the renewal status, causing incorrect transaction logs when the quote is later confirmed. The update ensures that renewal quotes maintain their proper status throughout the cancellation and reset process, preventing missing transfer records in the system.

Before this commit, when a salesperson canceled a renewal quotation, and reset it to draft, the subscription_state '2_renewal' was lost. It would affect the sale_order_log upon confirmation of that renewal and the sale.order.log would not be correct. In that case, there would be a missign transfer log.

taskid: 3651477

This update corrects the CSV export header format for Danish accounting reports to comply with official government documentation requirements. The header now includes the correct column names (KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131) as specified by the Danish Business Authority, ensuring reports can be properly submitted to the regnskab basis system.

This commit changes the danish csv report's header to match with the correct Danish documentation requirements.

The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website.

We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link:

https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis

Based on the documentation chapter 3 & 4, the top row of the csv file (header) should consists of:

KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131

task-id: None

This fix resolves an issue where UK intrastat reports were not displaying detailed line items when users expanded Dispatch/Arrival sections. The system was using an incorrect country code (XU) instead of the proper code (GB) when looking up related transactions, preventing the detailed breakdown from appearing. The fix ensures the correct country code is used so users can now see all relevant transaction details.

The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code.
The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines.
Now, before we build the ID (that we'll use after to fetch children lines), we change the value for the right country code.

no task id

Forward-Port-Of: odoo/enterprise#58620
Forward-Port-Of: odoo/enterprise#58585

This fix corrects how VAT numbers are processed in the Belgian VAT Listing report. Previously, the system incorrectly removed the first two characters from all VAT numbers, which caused errors when VAT numbers didn't start with "BE". The update now uses a proper conversion function to accurately extract the Belgian company registration number from VAT numbers, ensuring accurate reporting.

The aim of this commit is handling correctly the VAT number in the Partner VAT Listing.

Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE.
This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number.

no task id

Forward-Port-Of: odoo/enterprise#58597
Forward-Port-Of: odoo/enterprise#58563

This update fixes an issue in the Online Appointments feature where a custom appointment link was still being generated even after removing all appointment types. The link is now properly removed when no appointment types are selected, ensuring users don't receive broken or invalid appointment links.

Steps to reproduce:
- Install appointment
- Go in calendar -> Online Appointments
- Click on the link button
- Remove the appointment type

Issues:
We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired.

opw-3749154

Forward-Port-Of: odoo/enterprise#58593
Forward-Port-Of: odoo/enterprise#57240

This fix prevents the Knowledge sidebar from breaking when a user loses access to an article they previously marked as a favorite. Previously, the system would try to display inaccessible articles in the sidebar, causing an error that prevented the entire sidebar from loading. Now, the system properly filters out articles the user can no longer access, ensuring the sidebar displays correctly.

-Before this commit:
 When a user lost access to an article which was a favorite, the sidebar was
 provided with the id of the article anyway, resulting in an error when trying
 to access its fields, preventing the sidebar from being displayed at all.

-After this commit:
 Articles ids are not provided to the sidebar when they have a favorite related
 to the current user but that user currently can not access it.

opw-3700698

Forward-Port-Of: odoo/enterprise#55590

This fix resolves an issue where the attendance count displayed on a payslip didn't match the actual number of attendance records shown when clicked. The problem occurred because the system wasn't properly accounting for timezones when comparing attendance dates. The fix ensures consistent counting by using the same timezone-aware logic throughout the payroll system.

Steps to reproduce:
-------------------
- being in Europe/Brussel timezone;
- create a contract based on attendance from 1st to 31st January;
- create two attendancescfot the employee linked to this contract:
    - 5th January from 8am to 4pm for example (A)
    - 31st January from 00:30am to 8:30pm (B)
- create a payslip for the employee from 1st to 30th January;

Issue:
------
The attendance count on the smart button on the payslip and the number of records on the list view (when the smart button is clicked) are not the same.

Cause:
------
The domain that determines attendance uses a condition on the `check_in` field, which is a datetime field, and compares it with a date. For attendance B, we will compare 2024-30-01 23:30:00 with 2024-30-01 23:59:59.

As a result, attendance B will validate this condition.

Solution:
---------
Make this information consistent by using the same logic and taking account of timezones.

Add a method that allows you to retrieve all attendances linked to a payslip. Use this to generate the domain that will select the correct records (based on their id) in the list view.

Note:
-----
`_read_group` manages timezones and therefore
`check_in:day` for attendance B returns 2024-31-01.

opw-3794161

Forward-Port-Of: odoo/enterprise#58431

Fixed an issue where the event submenu selector was hidden when users were viewing certain event pages like event tracks. The submenu is now always accessible on mobile devices, allowing users to easily navigate between different event sections without being restricted by their current page location.

The recent redesign added a separate submenu selection for the mobile view however it was hidden when outside of one of the submenus.

There is no need to do that, and it prevents users from selecting a different submenu when accessing pages such as event tracks.

The submenu selector now takes on a fallback value when outside of one of the selectable submenu.

task-3695979

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

This fix resolves an issue where search bar input fields became invisible when added to website pages. The search input was blending in with the page background due to matching colors and missing borders. The fix adds a new styling option that lets users choose between a light style (for app-like search bars) or the default input style, with the default style automatically applied when adding new search snippets to prevent visibility issues.

Since this commit [1], the two searchbar snippets are broken.

The search bar input seems invisible because it shares the same color as the default snippet background and has no border. This style matches the search inputs used in apps (like the "/shop" search bar), which isn't affected by the "Input fields" settings in the "Theme" tab.

To resolve this issue, this commit introduces a new option to choose between the "light" style (similar to "/shop" search bars) and the "default input style" for the 2 "Search" snippets.

The "default input style" is automatically applied when the "Search" snippet (excluding saved snippets) is dropped to address the issue caused by the light-on-light color scheme.

Steps to Reproduce the Issue:

- While in Website edit mode, drag and drop a "Search" snippet onto the page.
- Bug: The input appears invisible due to the lack of a border and a background color identical to the snippet's section color.

[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20

task-3662985

This fix corrects a display issue where column values were misaligned with their headers when viewing grouped data in list views, particularly in the Planning app. The problem occurred when certain view options were enabled, causing values to shift one column to the right. The fix adjusts how the system calculates column spacing to ensure values always line up correctly with their headers.

Steps to reproduce:
- Install **planning** app.
- Go to **planning** app, and convert the view to **List**.
- Group by **Resource** -for example-.
- Notice how the Allocated Time column values are mis-aligned with the header label.

Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
	- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
	- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
	- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.

The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
	- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
	- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
	- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
	- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
	- both firstAggregateIndex` = `lastAggregateIndex` = -1
	- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1`
	- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.

opw-3764616

Fixed an issue where the system was incorrectly calculating suggested balance amounts when editing journal entry lines. When users deleted or modified lines and added new ones, the system was not properly accounting for all existing lines, resulting in wrong credit suggestions. This fix ensures the system considers all saved line data when computing balances.

Create a new Journal Entry
Add a 100$ debit line 1
Add a 100$ debit line 2
Add a new line: system will suggest 200$ credit line 3
Save
Delete line 3
Change line 2 amount into 50
Create a new line

Issue: the system will compute a credit amount of 50$
This occurs because in the onchange we work with a new record
representing the set of changes
Commands sent by the orm are:
- DELETE of line 3
- UPDATE of line 2
So in the new record we don't have information on line 1.
A solution is to recover the data from the stored record

opw-3757415

Fixed an issue in the Lunch app where users would encounter a technical error (traceback) when running scheduled email tasks with incorrect settings. Now users will see a clear, user-friendly error message instead, making it easier to identify and fix configuration problems.

Steps to reproduce:
-----
1. Have lunch app activated
2. Settings > Technical > Scheduled Actions
3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email.
** Traceback error **

Changes
-------
The user will see an UserError instead of a traceback.

opw-3751229

Forward-Port-Of: odoo/odoo#156706
Forward-Port-Of: odoo/odoo#156440

This update fixes missing translations for numpad buttons and customer editor form fields in the Point of Sale system. Users in non-English languages will now see these interface elements properly translated, improving usability and consistency across the POS application.

Issue
-----
In a POS session, some buttons of the numpad and some fields in the client editor form are not translated.

**opw-3783252
opw-3756593**