This update fixes an issue where month names were being displayed using the user's locale instead of the Odoo environment's language. This ensures that month names are consistently shown in the correct language for each user, improving accuracy and user experience. The fix impacts several payroll and reporting modules.

Month name is using the locale language instead of the env language

Get month name in the env language

Community PR: odoo/odoo#246790

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

Forward-Port-Of: odoo/enterprise#107087
Forward-Port-Of: odoo/enterprise#106175

A recent issue was causing nightly automated tests to fail due to unexpected errors in the system. This update addresses a problem where test configurations were incorrectly overriding internal functions, leading to crashes. The fix adds a check to ensure these functions are properly set before execution, improving test reliability and stability.

Before this commit, in the `TestInvitation` class mocked by VOIP tests, it was possible to override some inner functions by giving undefined values in `receiveInvite`.

This caused the code to crash when it tried to call these undefined values.

This commit fixes this issue by adding a sanity check before calling these methods to ensure they have been set.

This update resolves an issue causing confusing module descriptions during installation. The fix simplifies the code to directly increase the L channel value by 9%, improving installation stability and addressing a warning from the Sass compiler. This ensures consistent and accurate module information.

This update ensures that all date and time information displayed on POS order receipts aligns with the local language and regional settings (l10n). Previously, dates were displayed in a standard format, which could be confusing for users in different countries. This change improves the user experience and ensures accurate reporting.

`l10n_cl_edi_pos`, `l10n_se_pos`, `pos_enterprise`, `pos_planning`, `pos_restaurant_appointment`, `pos_blackbox_be`

### Before this commit: 
- `DateTime` format was hardcoded and did not respect l10n settings in some places.

### After this commit:
- `DateTime` is displayed in l10n date/time format.

Task: 4935692
Related PR: https://github.com/odoo/odoo/pull/218849

This update resolves a bug in the appointment module's Gantt chart tests. The issue stemmed from incorrect timezone handling during testing with demo data, leading to failed assertions. The fix ensures consistent timezone settings for test data, resolving the conflict and improving test reliability.

The tests `test_gantt_resource_unavailabilities` and
`test_gantt_resource_unavailabilities_multi_company` were failing
with demo data due to an extra 1-microsecond interval.

Initially, the resource timezone was derived from its linked resource
calendar, which in turn used the timezone of `base.user_admin`.
In the tests, `base.user_admin` was set to the Europe/Brussels timezone.
The tested duration was defined from 00:00 to 23:00, which, when converted
to Europe/Brussels (GMT+1), became 01:00 to 24:00 and spilled into the next
day. Intervals were computed using min/max datetimes between the requested
timezone and UTC, resulting in a 1-microsecond offset in the final result.
The tests were therefore written to expect this additional microsecond.

After commit [1] and [2], the `tz` field was moved to the company, and the
resource timezone is now taken from its linked company. The company timezone
is initialized at module load time: UTC without demo data and Europe/Brussels
from `env.user` when demo data is loaded. The tests were updated to match
the expectations without demo data, which caused assertion errors when
running with demo data.

This commit fix it by setting `tz` on resource  in the test data to ensure
consistent and unified expected values.

[1] https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be
[2] https://github.com/odoo/enterprise/commit/dbcae3f32deeae0ee784f700264ebdb5d3c22f2e

runbot-238361

This update resolves an issue causing errors when sending monthly tax returns to HMRC. The problem stemmed from incorrect date formatting being passed between the JavaScript and Python components. This fix ensures dates are sent in the correct format, preventing the errors and allowing tax returns to be successfully submitted.

**STEP TO REPRODUCE**
1. Install l10n_uk_reports_cis.
2. Setup hmrc test environment.
3. Try Sending the a monthly tax return to hmrc.
4. You'll have a traceback of the form `expecting only datetimes with no timezone:
'2025-12-05T00:00:00.000+01:00' `

**CAUSE**
The send button for monthly return is a js widget, which get data from the monthly_return_wizard models and then pass it to `action_send_montlhy_return`.
It creates a Luxon datetime in the js for date_from date_to, with a timezone.
When the dates are passed back to the python, the still contains the timezone which leads to the traceback.

opw-5783030

Forward-Port-Of: odoo/enterprise#106952

A test for the Shiprocket delivery module failed due to a default pricelist being applied, incorrectly overriding tax calculations. This update forces an empty pricelist during testing, ensuring accurate tax calculations and resolving the test failure. This improves the reliability of our Shiprocket delivery testing.

Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
    self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`

Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.

-----
Error runbot 232692

Forward-Port-Of: odoo/enterprise#105180

This update fixes an issue where tasks were incorrectly scheduled with shortened durations. The system was re-using previously allocated time slots, preventing tasks from extending into the following month. The fix ensures tasks are now accurately planned with the correct duration, regardless of the start date.

Steps to Reproduce:
1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours.

Source:
When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28).
However, these four days are not enough to cover 40 hours.

The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December.

Solution:
Remove already-used intervals before recomputing the schedule.

opw-5364327

Forward-Port-Of: odoo/enterprise#107043
Forward-Port-Of: odoo/enterprise#101262

This update fixes an issue where the system incorrectly linked statement lines to the 'OdooBot' partner when the partner name was specified as 'ODOO'. This ensures accurate reporting and reconciliation by correctly identifying the source of financial data.

When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot.

no task id

Forward-Port-Of: odoo/enterprise#106933
Forward-Port-Of: odoo/enterprise#106879

This update fixes an issue where holiday allocations weren't accurately reflecting fractional days (e.g., 19.5 days) in the employee's holiday attest. The change adjusts the data types of key fields to allow for decimal values, ensuring correct holiday calculations and reporting. This prevents discrepancies in holiday balances.

Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
The same problem happens if the number of leaves taken is not an integer

Reason : The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.

Fix : Alter fields type to float for those fields : leave_count and leave_allocation_count

task - 5461268

This update resolves an issue where invoice users within Odoo Enterprise were unable to view subscription details. The fix filters user access based on their role, ensuring that only authorized users – specifically those managing subscriptions – can access this information. This improves data visibility and accuracy for subscription management.

Forward-Port-Of: odoo/enterprise#99410

This update corrects a display issue in the salary configurator where the fuel card benefit could incorrectly appear enabled if no company car was selected. The change ensures the field is properly initialized and remains disabled until a company car is chosen, preventing data inconsistencies. This improves the user experience and data accuracy.

On first load of the salary configurator, the fuel-card benefit could appear enabled even when no company car was selected. The dependency logic reacted to in-page changes but did not initialize the field correctly on page load.

Initialize the fuel-card field from the current car selection and keep it non-selectable until a car is chosen to prevent inconsistent packages.

task-5156562

Forward-Port-Of: odoo/enterprise#106312
Forward-Port-Of: odoo/enterprise#105037

This update reorganizes how Odoo handles user sessions, moving the session store to its dedicated module for better organization and maintainability. This change improves the underlying architecture and resolves a technical inconsistency, ensuring smoother session handling within the system.

The session store is a global-ish variable that was set as a lazy
property on the Application singleton. Now that http.py is split, it
really doesn't make sense to have the session store inside Application
inside router.py. It should be inside session.py, that's what this PR
does.

Changing the `@lazy` for a `@functools.lru_cache(1)` makes the decorated
function better typing-wise, but makes it impossible to monkey-patch. As
it was only monkey-patched inside `test_http`, we just adapted that
module to use the real session store.