Odoo Changelog — 2025-12-29

Monday, December 29, 2025

90 changes

Branch: saas-19.1

34 changes

Bug Fixes(34)

Resolved issues and error corrections

[FIX] account_reports: prevent error when sending the customer statement

PR #102777

Enterprisesaas-19.1account_reportsMEDIUM

This update resolves an error that prevented users from sending customer statements. The fix ensures the system correctly handles scenarios where a custom email template isn't used, defaulting to the current user's email address to avoid a technical error. This improves the reliability of the customer statement generation process.

Original PR description

Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the…

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

[this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102682
Forward-Port-Of: odoo/enterprise#102219

#reports#customer statements

[FIX] planning: prevent error on missing end date

PR #102915

Enterprisesaas-19.1planning

This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date correctly, preventing a technical error from appearing to users. This improves the stability and usability of the planning module.

Original PR description

Currently an error occurs when user tries to remove end date on slot. Steps to replicate: - Install `planning`. - Create a new planning slot and click on a slot template at the top. - Remove the end…

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slot#end date

[FIX] hr_skills: prevent error when clicking employee skills pie chart report

PR #240857

Coresaas-19.1hr_skills

A recent change to the Employee Skills pie chart report caused an error when users clicked on individual data points. This update corrects this issue, ensuring that users can now properly interact with the report without encountering errors. This fix improves the usability of the HR reporting feature.

Original PR description

Clicking a record in the Employee Skills pie chart report currently triggers a traceback. Steps to reproduce the error: - Install ``hr_skills`` module with demo data - Open any employee > In Resume…

Clicking a record in the Employee Skills pie chart report currently triggers a traceback.

Steps to reproduce the error:
- Install ``hr_skills`` module with demo data
- Open any employee > In Resume tab, Click on TIMELINE
- Switch to Pie chart > click on any record

Traceback:
```py
UndefinedColumn: column hr_employee_skill_history_report.id does not exist
LINE 1: SELECT "hr_employee_skill_history_report"."id" FROM "hr_empl...
```

``hr.employee.skill.history.report`` model is ``_auto=False``,
meaning that no database table is created for this model.
In earlier versions, clicking on the record opens the list view.
In the [commit](https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e), list view was removed.
So, now clicking on the record will lead to the above traceback.

[1]: https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e

sentry-7099766240

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

Forward-Port-Of: odoo/odoo#239416

#reporting#hr#bug

[FIX] pos_urban_piper: wrong payment difference on UrbanPiper orders

PR #102937

Enterprisesaas-19.1pos_urban_piperMEDIUM

This update resolves an issue where UrbanPiper orders were incorrectly showing a payment difference after completion. The fix ensures that the final payment amount accurately reflects the total, improving the reliability of UrbanPiper order processing. This change impacts the UrbanPiper integration.

Original PR description

In this commit,
The amount difference should be 0.0 after the Urbanpiper order has been paid.

task-5441252

Forward-Port-Of: odoo/enterprise#102894
Forward-Port-Of: odoo/enterprise#102872

#UrbanPiper#POS#Payment

[FIX] pos_pine_labs: avoid key error for `plutusTransactionReferenceID`

PR #241384

Coresaas-19.1pos_pine_labs

This update fixes a pop-up error that occurred when users switched back to a previous order after processing a Pine Labs payment. The fix ensures the system only attempts to retrieve payment status when the necessary transaction ID is available, improving order processing reliability for our Indian retail customers.

Original PR description

Steps:
----------
- Install pos_pine_labs and l10n_in module.
- Create a payment method for the Pine Labs terminal in an indian company.
- Configure the config with the Pine Labs payment method.
- Open pos session process order till payment screen.
- Go offline and try to add a Pine Labs payment method.
- Go back online and create a second order using the plus (+) button in the navbar.
- Switch back to the first order.

Issue:
----------
- A pop-up error appears due to a missing `plutusTransactionReferenceID` key when switching back to the first order and trying to get Pinelabs' transaction status.

Fix:
----------
- Ensure the payment status is fetched only when the `plutusTransactionReferenceID` key is available in the payment line.

opw-5176160

Forward-Port-Of: odoo/odoo#233357

#pine_labs#pos#payment

[IMP] knowledge: hide GIF and canned response actions

PR #102935

Enterprisesaas-19.1knowledge

This update hides the GIF and canned response actions within the Knowledge composer, restoring the original design. This change ensures a cleaner and more focused experience when creating Knowledge articles, aligning with user needs. The fix was implemented to address a visibility issue introduced during a recent update.

Original PR description

The GIF picker was previously hidden in Knowledge, but became visible again after the composer actions refactor.

Commit that introduced the change:
https://github.com/odoo/odoo/commit/5e1daafeac231c333ea13369fc208627213d67d4

This commit restores the intended behavior by hiding the GIF action again and also hides the canned response action, as neither feature is relevant when composing content in Knowledge, by applying conditions on the corresponding composer actions.

Task-5163888

Forward-Port-Of: odoo/enterprise#102927
Forward-Port-Of: odoo/enterprise#100585

#knowledge#composer#user experience

[FIX] pos_self_order: improve preparation ticket layout for self-orders

PR #241201

Coresaas-19.1pos_self_order

This update fixes issues with the preparation tickets used for self-orders in Odoo. Specifically, it now includes the table number and configuration name on the ticket, and correctly displays the order reference and time. This ensures clearer and more accurate information for staff processing self-orders.

Original PR description

Before this commit:
===================
- Some details were missing from the preparation tickets, such as the table number and configuration name.
- The order reference and time were not displayed in the correct positions.

After this commit:
==================
- Added the configuration name and table number to the receipt.
- Corrected the placement of the order reference and time.


Task: 5268966

| Before this PR | After this PR |
|--------|--------|
| <img width="511" height="431" alt="before" src="https://github.com/user-attachments/assets/ac5b2c45-5210-4a4e-86c7-953e2ab89eb1" /> |<img width="514" height="448" alt="after" src="https://github.com/user-attachments/assets/f1feb317-d5fe-469a-ab70-cf1dd793dce5" />|

Forward-Port-Of: odoo/odoo#236847

#pos#self-order#receipt

[FIX] pos_loyalty: set customer as gift card's partner

PR #241394

Coresaas-19.1pos_loyalty

This update ensures that gift cards purchased through the Point of Sale system are correctly linked to the customer who made the purchase. Previously, gift cards lacked a customer association, making it difficult to track sales. This fix resolves this issue, providing better reporting and traceability for gift card transactions.

Original PR description

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card. In…

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card.

In [`pos_loyalty/models/pos_order.py`](https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/models/pos_order.py), the `coupon_data` passed to the `confirm_coupon_programs` method does not contain the `partner_id`. This happens because the *Gift Card* program is not considered "nominative", failing the following condition from `pos_loyalty/static/src/overrides/models/pos_store.js`:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L795-L801

In fact, the conditions for nominative programs are defined in the `loyalty` module:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/loyalty/models/loyalty_program.py#L196-L200

This fix uses the customer's id when there's no `partner_id` in the `coupon_data` coming from the Javascript side. If there's no customer selected when buying the gift card from the POS, `self.partner_id.id` evaluates to `False`, leading to the original behavior: a gift card with no partner.

### Steps to reproduce:
1. Install Point of Sale (`point_of_sale`)
2. In Settings > Point of Sale, toggle *Promotions, Coupons, Gift Card & Loyalty Program*
3. In the POS, open a register
4. On the product screen, select the *"Gift Card"* product and click *Payment*
5. On the payment screen, set the Customer to any customer, pay, and click *Validate*
6. In the POS backend, go to Products > Gift cards & eWallet, click the *Gift Cards* program, and click the *Gift Cards (1)* smart button
7. The gift card we just sold in the POS appears in the list, but there's no Partner assigned to it.

opw-5261991

Forward-Port-Of: odoo/odoo#237807

#gift card#pos#loyalty

[18.0][FIX] hr_expense: fix UserError on digitizing expense

PR #241398

Coresaas-19.1hr_expense

This update resolves an issue where users were incorrectly denied the ability to digitize expense receipts. Previously, users needed a specific group permission, but this change now allows all users to digitize receipts in draft expense records. This improves the user experience and streamlines the expense reporting process.

Original PR description

When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.

This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264


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

Forward-Port-Of: odoo/odoo#241348
Forward-Port-Of: odoo/odoo#240401

#expense#receipt#digitization

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102642

Enterprisesaas-19.1delivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, particularly those common in countries like Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct delivery address formatting and reducing potential delivery errors.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#delivery#sendcloud#address

[FIX] l10n_uk_reports_cis: fix accounts codes duplications

PR #102655

Enterprisesaas-19.1l10n_uk_reports_cis

This update resolves a previous issue that prevented the UK Construction Industry Scheme (l10n_uk_reports_cis) from being installed correctly when using branch companies. The fix ensures unique account codes are created, allowing successful installation and proper reporting functionality for UK businesses with branches.

Original PR description

Before this commit:
Steps
1) Create a UK localization company
2) Create a branch for that company
3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis)

=> A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch).

After this commit:
UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches.

opw-5326079

Forward-Port-Of: odoo/enterprise#99901

#UK Reporting#Accounts#Localization

[FIX] test_l10n_be_hr_payroll_account: tour failing with demo data

PR #102677

Enterprisesaas-19.1hr_payrolll10n_be

This update resolves a problem where a demo tour was failing due to a duplicate job entry within the demo data. The fix ensures the tour correctly identifies the intended job position, improving the demo experience and allowing users to properly test the HR contract setup.

Original PR description

- fixing tour `hr_contract_salary_tour_sign_again`which was failing with demo data because another job was installed in the demo data with name Experienced Developer so it was matching with it instead of the correct job position

task-id: 5413364

#demo#tour#hr#payroll

[FIX] hr_work_entry_enterprise: crash with fully flexible employees

PR #102679

Enterprisesaas-19.1hr_work_entry_enterprise

This update fixes a crash that occurred when generating work entries for employees who are designated as 'fully flexible' (without a resource calendar). The fix ensures accurate unavailability intervals are created, preventing errors when opening work entry and payroll modules. This improves stability and functionality for all employee types.

Original PR description

Steps to reproduce:
- Install hr_work_entry
- create an active employee with a running contract and no resource calendar(fully flexible)
- try to open work entries/payroll
- you get a traceback because of `_gantt_unavailability`

Current behavior:
- when the employee is flexible, the unavailability is set to an empty interval without accessing the calendar(that doesn't exist)
- added `test_gantt_unavailability` to check if the unavailability intervals of employees are generated correctly

task-id: 5408752

#hr#work_entry#employee#availability

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #241426

Coresaas-19.1spreadsheetMEDIUM

This pull request updates the core spreadsheet component within Odoo. It addresses several bugs related to spreadsheet rendering, border issues, and compatibility with Safari's zoom feature. These improvements ensure a more stable and reliable spreadsheet experience for users.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e6313bd89a [REL] 19.1.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e6313bd89a [REL] 19.1.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e46a4ae735 [FIX] borders: merged cell loses adjacent border after import [Task: 5390397](https://www.odoo.com/odoo/2328/tasks/5390397)
https://github.com/odoo/o-spreadsheet/commit/2a5e901dad [FIX] Style: Ignore undefined style in commands [Task: 5439120](https://www.odoo.com/odoo/2328/tasks/5439120)
https://github.com/odoo/o-spreadsheet/commit/25bf5e0a80 [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906)
https://github.com/odoo/o-spreadsheet/commit/7476f37316 [FIX] Spreadsheet: Make zoom work on Safari [Task: 5232092](https://www.odoo.com/odoo/2328/tasks/5232092)
https://github.com/odoo/o-spreadsheet/commit/fa395d8ce9 [FIX] Highlights: Adapt for zoomed spreadsheets [Task: 5232092](https://www.odoo.com/odoo/2328/tasks/5232092)
https://github.com/odoo/o-spreadsheet/commit/2930f8a47c [REL] version 19.1.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5dd3ed7a22 [FIX] tests: remove or fix skipped tests [Task: 5423848](https://www.odoo.com/odoo/2328/tasks/5423848)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#ui#performance

[FIX] project_sale_expense: Keep Analytic distribution when reinvoicing expenses

PR #241441

Coresaas-19.1project_sale_expenseMEDIUM

This update ensures that the analytic distribution linked to expenses is correctly applied when reinvoicing to a customer. Previously, the distribution would shift unexpectedly, leading to inaccurate reporting. Now, the analytic account from the sales order takes precedence, guaranteeing consistent tracking of costs and revenue across all related documents.

Original PR description

Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account…

Steps to reproduce the flow:
- Create an expensable product “Hotel” that can be reinvoiced to a customer
- Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel”
- Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction”
- Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing”
- Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information
- When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong.
- On the vendor bill, the analytic distribution is “Home Construction”

Now:
1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO
2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO.

task-4564463

Forward-Port-Of: odoo/odoo#240762
Forward-Port-Of: odoo/odoo#233794

#analytics#expense#reinvoicing#accounting

[FIX] pos_{loyalty, sale_loyalty}: customer loading while applying code

PR #241302

Coresaas-19.1pos_sale_loyalty

This update resolves a technical error that prevented loyalty cards from being correctly applied during POS transactions. The issue stemmed from a misinterpretation of customer IDs, which has now been corrected to ensure seamless loyalty program integration. This improves the customer experience and accurate tracking of loyalty rewards.

Original PR description

Steps:
------------
- Install pos_sale_loyalty.
- Create a loyalty program of type loyalty, available for both Sales and POS.
- Create a sale order with simultaneous customer creation and confirm it.
- Open POS and enter code of the loyalty card generated from the sale order.

Issue:
------------
- A traceback occurs with: Error: Invalid ids list.

Cause:
------------
- A list of partner IDs was passed, where a single partner ID was expected.

Fix:
------------
- Extract and pass the correct partner ID instead of the full partner ID list.

Task-5388341

Forward-Port-Of: odoo/odoo#241167
Forward-Port-Of: odoo/odoo#239582

#loyalty#POS#customer

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102966

Enterprisesaas-19.1l10n_ke_edi_oscuMEDIUM

This update resolves an issue where sending vendor bills to eTIMS would fail when the eTIMS configuration wasn't properly set up. Specifically, the system requires the 'eTIMS Server Mode' to be configured, otherwise the sending process is skipped. This change ensures the system correctly handles this scenario, preventing errors and allowing bills to be sent to eTIMS.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills. Steps to Reproduce: - Install `l10n_ke_edi_oscu` module without demo data. - Create a New company with `Kenya` as…

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#eTIMS#Kenya#EDI

19.0 hr attendance negative overtime zirah

PR #241340

Coresaas-19.1hr_attendanceMEDIUM

This update restores the ability to track negative overtime (undertime) within the HR attendance module. Previously removed in 19.0, this feature allows for accurate recording of situations where employees work less than their scheduled hours, addressing a previous client concern and improving attendance tracking accuracy.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#240263

#attendance#overtime#undertime#hr

19.0 hr attendance negative overtime zirah

PR #102880

Enterprisesaas-19.1hrMEDIUM

This update restores the ability to generate negative overtime (undertime) in the attendance tracking system. This change, implemented after reviewing the Absence Management settings, ensures more accurate time reporting for clients, addressing a previous removal that caused potential revenue loss.

Original PR description

…time generation

Forward-Port-Of: odoo/enterprise#102271

#attendance#overtime#hr

[FIX] web: Calendar's event dispatch when attached to shadow tree only

PR #241382

Coresaas-19.1web

This update resolves a bug in the calendar functionality that was causing issues with the 'knowledge_calendar_command_tour' tour in Chrome 143 and later. The fix, stemming from a Chromium update, ensures events are dispatched correctly when the calendar element is attached to a shadow tree, aligning with web standards.

Original PR description

Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget…

Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')".

This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2].

To quote the Chromium commit message:
> According to the spec, only if the top node is in a shadow tree, both
> the target and relatedTarget should be cleared.
> However, if the top node is not in a shadow tree and not a document,
> the target and relatedTarget are always cleared. Because the current
> implementation only checks whether the top node is not a document.
> So, this patch fixes the bug by checking whether the top node is in a
> shadow tree.

In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element.

Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...)

[^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/
[^2]: https://dom.spec.whatwg.org/#concept-event-dispatch

Forward-Port-Of: odoo/odoo#240920

#calendar#chrome#bug fix

[IMP] hr_payroll: unlock work entries

PR #102944

Enterprisesaas-19.1hr_payroll

This update ensures that all work entries are consistently set to 'draft' state when updated, regardless of previous settings. Previously, this process could be inconsistent, leading to potential data discrepancies. This change improves data accuracy and reliability within the payroll system.

Original PR description

Problem
----------
the `action_set_to_draft` should set any work entry to draft regardless of the situation.

Solution
----------
If only the state is write to draft, let the whole vals be written

task-5410512

Forward-Port-Of: odoo/enterprise#101891

#payroll#work entry#data accuracy

[FIX] mail: load activity_state in partner kanban view

PR #241293

Coresaas-19.1mailMEDIUM

This update resolves a crash in the Partner Kanban view when editing payments in the mobile POS. The fix ensures that necessary data, specifically `activity_state`, is loaded for the view, preventing errors and improving stability for users.

Original PR description

Steps to reproduce:
===================
- Use the POS in mobile view
- Complete a payment
- Click on "Edit Payment"
- Select customer or Edit customer

Issue:
======
- The partner kanban view crashes in the frontend
- `activity_state` is accessed in the template but not loaded

Cause:
======
- The partner kanban view uses activity-related fields
- `activity_state` was not included in the kanban fields

Fix:
====
- Explicitly load `activity_state` in the partner kanban view

Task:5406890

#frontend#stability#kanban

[I18N] *: prepare and clean up translations for Weblate

PR #241030

Coresaas-19.1account

This update cleans up and modernizes our translation files for Weblate, ensuring they align with the latest version of Odoo (19.1). By updating the PO files and removing outdated or irrelevant files, we've streamlined the translation process and improved the accuracy of our localized content.

Original PR description

We did the following:
- Update the PO files by taking the version from 19.0 and `msgmerge` them with the latest POT file.
- Update the `.weblate.json` file to target the right project.
- Update the `.weblate.json` file to add/remove modules that were changed.

Related: https://github.com/odoo/enterprise/pull/102739
Related: https://github.com/odoo/design-themes/pull/1201
Related: https://github.com/odoo/industry/pull/1460
Related: https://github.com/odoo/documentation/pull/15825

#i18n#translation#Weblate

[I18N] *: prepare and clean up translations for Weblate

PR #102739

Enterprisesaas-19.1account_3way_matchl10n

This update streamlines our translation workflow by updating PO files from the 19.0 release and cleaning up unused translation resources. We've removed outdated and irrelevant files to ensure Weblate focuses on the languages currently supported, improving efficiency and accuracy.

Original PR description

We did the following:
- Update the PO files by taking the version from 19.0 and `msgmerge` them with the latest POT file.
- Update the `.weblate.json` file to target the right project.
- Update the `.weblate.json` file to add/remove modules that were changed.

Related: https://github.com/odoo/odoo/pull/241030
Related: https://github.com/odoo/design-themes/pull/1201
Related: https://github.com/odoo/industry/pull/1460
Related: https://github.com/odoo/documentation/pull/15825

#translation#i18n#weblate

[FIX] im_livechat,mail: do not show IM status in livechat for visitor

PR #240927

Coresaas-19.1im_livechatmail

This update prevents live chat visitors from seeing the IM status of the person they're chatting with. This change was triggered by a recent accidental issue and ensures a cleaner, more focused user experience for live chat interactions. It improves the clarity of the live chat interface.

Original PR description

Before this commit, IM status was visible by livechat visitor.
This issue comes from recent accidental regression [1].

[1]: https://github.com/odoo/odoo/pull/234715

Task-5435992

Before / After
<img width="384" height="129" alt="Screenshot 2025-12-22 at 14 19 14" src="https://github.com/user-attachments/assets/6fb80a49-f04c-4db1-aa9a-254146a313b5" />
<img width="379" height="129" alt="Screenshot 2025-12-22 at 14 19 37" src="https://github.com/user-attachments/assets/10308a02-7370-4818-8bf5-cd1513a1a964" />

#live chat#im status#user experience

[FIX] l10n_hu_edi: e-invoice currency rate date

PR #241246

Coresaas-19.1l10n_hu_ediMEDIUM

This update fixes an issue where e-invoices in the Hungarian localization were incorrectly using the invoice date to calculate currency exchange rates. Now, the system accurately uses the delivery date, aligning with Hungarian tax regulations and ensuring correct e-invoice generation. This resolves a discrepancy impacting financial reporting accuracy.

Original PR description

In the Hungarian localization, the currency exchange rate for invoices
is based on the delivery date.

Steps to reproduce:
- With HU localization setup
- Create an invoice

Issue:
Currently, when issuing the e-invoice, the system would compute the
currency exchange rate using the invoice date.

opw-5126816

Forward-Port-Of: odoo/odoo#240999

#currency#e-invoice#Hungary#localization

[FIX] mail: fix z-index of a avatar in avatar-stack

PR #241472

Coresaas-19.1mail

This update corrects a visual issue where avatars in discussion threads were sometimes incorrectly positioned above other elements. The fix ensures all avatars stack correctly, maintaining a consistent and professional appearance. This improves the overall user experience within Odoo's discussion features.

Original PR description

Before this commit, the avatar's in the avatar stack z-index was derived from the participant’s position in the recordset, resulting in descending z-index values greater than 1. Since .o-mail-DiscussSidebar-top has a z-index of 2, avatars with a higher z-index could incorrectly appear above it when multiple avatars were present.

This commit fixes the issue by assigning a fixed z-index of 1 to all avatars, ensuring a consistent and correct stacking behavior.







task-5417539


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

Forward-Port-Of: odoo/odoo#240189

#UI#Discussions#Avatars

[IMP] hw_drivers: get IP using gateway instead of DNS

PR #241381

Coresaas-19.1iot_drivers

This update enhances the way Odoo retrieves the IP address for IoT Boxes. Previously, it relied on a public DNS server, which failed when the IoT Box was connected through a router without internet access. Now, it uses the gateway's IP address, ensuring reliable operation even in offline scenarios.

Original PR description

To get the local IP address of the IoT Box, we used to create a connection to a public DNS server and parsed the output to get the source of the request (our IP).

In case the IoT Box is connected to a router, but the router isn't connected to the internet, our solution fails. We now create the connection to the gateway instead, so it can work offline.

Forward-Port-Of: odoo/odoo#241312
Forward-Port-Of: odoo/odoo#241051

#IoT#connectivity#offline

[FIX] core: wrong number of arguments in cli.db

PR #240395

Coresaas-19.1cli

This update resolves a technical issue where the Odoo command-line interface (CLI) was receiving an incorrect number of arguments. This fix ensures the CLI functions correctly, preventing potential errors and improving the reliability of database operations. It's a routine maintenance update to maintain the stability of our core system.

Original PR description

Fine-tunning of b86c060c9d5ba03ac13e8ad59cf55731fa50ed59

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

#database#cli#stability

[FIX] web, *: Fix UI of SelectMenu in frontend cases

PR #241521

Coresaas-19.1webwebsite_slides

This update fixes a visual issue with the SelectMenu component, ensuring selected items are clearly displayed and readable across different frontend implementations. The change improves the overall user experience by standardizing the component's appearance and removing unnecessary customizations.

Original PR description

*: website_slides This commit fixes the 'selected' display of the SelectMenu component in some frontend implementations. Previously, the visual style would be broken since the 'active' class was set…

*: website_slides

This commit fixes the 'selected' display of the SelectMenu component in some frontend implementations. Previously, the visual style would be broken since the 'active' class was set on the element, having a blank text and background on selected items.

The right 'selected' class is now used, to avoid difficulties to read the value, while still having some frontend specific styles working as expected. Also, the form-control and form-select classes are set using the togglerClass props. In future versions, we might be able to remove extension of the component in other modules (e.g. hr_contract_salary), ensuring the same style and behaviors accross all places.

Before: 
<img width="1566" height="1115" alt="image" src="https://github.com/user-attachments/assets/6265c615-bd7a-47f6-9353-c503dd934fed" />

After: 
<img width="791" height="350" alt="image" src="https://github.com/user-attachments/assets/939b7109-a32f-4991-a169-13f501f29eb4" />

Forward-Port-Of: odoo/odoo#240576

#UI#frontend#user experience

[FIX] mail: fix some UX issues with new channel 'hide' feature

PR #240716

Coresaas-19.1mail

This update enhances the user experience for managing hidden conversations within Odoo's discussion forums. The changes improve discoverability and usability by adding a dedicated button to view hidden channels and refining the action icons for clarity. This ensures users can easily access and manage their conversations without confusion.

Original PR description

1. Discoverability of "hidden channels" was poor in just ctrl-k
=> Added a new button at bottom of discuss sidebar with "View hidden conversations".

2. When opening a hidden conversation, it's not possible to "undo" the hide.
=> Automatically repin conversation when opening the conversation.

3. Hide action was in same group as "Leaving", which is confusing because the actions are quite different as shown by color.
=> Moved "Hide conversation" action in its own group just above the highly destructive action like "Leave" but below settings actions.

4. Iconography of action is poor with a cross icon
=> use fa-eye(-slash) that matches more the semantics of action.

Task-5431819

<img width="506" height="857" alt="Screenshot 2025-12-19 at 15 34 35" src="https://github.com/user-attachments/assets/453258bb-e83d-49db-986e-9c1c74eafc8d" />

#UX#Discussions#Channels

[FIX] mail: fix some UX issues with new channel hide feature

PR #102594

Enterprisesaas-19.1discuss

This update resolves minor usability issues related to the new channel hiding feature within the WhatsApp app. The changes enhance the user experience by addressing inconsistencies and improving the overall flow when hiding channels. This ensures a smoother and more intuitive experience for users.

Original PR description

Task-5431819

#whatsapp#channel#UX#discuss

[FIX] mail: show warning when no mic permission in systray call menu

PR #235427

Coresaas-19.1maildiscuss

This update fixes a visual issue in the call menu, displaying a warning badge when users haven't granted microphone permissions. This encourages users to grant permissions, improving usability. Additionally, the menu has been refined with color updates, style improvements, and minor bug fixes for a smoother experience.

Original PR description

Call menu now shows a warning badge when mic permission have not been granted like in call action list. The warning is also shown in the call action dropdown list, inciting click to open the permission dialog.

This commit also makes other minor improvements to systray call menu:
- tracked action use active color of action. For example, muted mic uses red colored icon.
- Success actions now has correct style in dropdown mode (was missing, only danger had correct style)
- flash effect of the volume-up icon has been reduced.
- improve readability of the warning badge in all call actions in dark theme.
- Fix a race-condition bug where initial discuss call could show incorrect active tracked call action.
- Systray call menu has been moved to left-most systray item.

Task-5382871

#ui#permissions#call

[FIX] discuss: hide combined mic+camera button when only one permission needed

PR #241561

Coresaas-19.1discuss

This update simplifies video call permissions by hiding the combined microphone and camera button unless both permissions are needed. Previously, users saw irrelevant options, causing confusion. Now, the system only presents relevant permission requests, improving the user experience and reducing potential frustration.

Original PR description

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, when requesting microphone permission in video calls, the "Use microphone and camera" button is shown even though only microphone access is needed, or vice-versa. This creates confusion as users see an option to request permissions that aren't relevant to their current action.

**Current behavior before PR:**
----------------------------------------------
- When clicking the microphone button in a video call, the "Use microphone and camera" button is shown if camera permission is not explicitly denied.
- Users see permission options that don't match what they're actually trying to do (e.g., microphone button shows camera options).

**Desired behavior after PR is merged:**
----------------------------------------------
- The "Use microphone and camera" button is only shown when neither camera nor microphone permissions have been granted yet.
- When users click the microphone button, they only see microphone-related options unless they also need camera permissions.
- When users click the camera button, they only see camera-related options unless they also need microphone permissions.
- Permission dialogs are contextual and only show relevant options for the action being performed.

Task-5367786

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

Forward-Port-Of: odoo/odoo#239241

#permissions#video calls#user experience

Branch: saas-18.4

14 changes

Bug Fixes(14)

Resolved issues and error corrections

[FIX] planning: prevent error on missing end date

PR #102904

Enterprisesaas-18.4planning

This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date gracefully, preventing a technical error from disrupting the planning process. This improves overall stability and usability.

Original PR description

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slot#end date

[FIX] pos_urban_piper: wrong payment difference on UrbanPiper orders

PR #102931

Enterprisesaas-18.4pos_urban_piperMEDIUM

This update resolves an issue where UrbanPiper orders were incorrectly showing a payment difference after completion. The fix ensures that the final payment amount accurately reflects the total order cost, improving the reliability of UrbanPiper transactions within the Odoo Enterprise system. This change impacts the UrbanPiper integration.

Original PR description

In this commit,
The amount difference should be 0.0 after the Urbanpiper order has been paid.

task-5441252

Forward-Port-Of: odoo/enterprise#102894
Forward-Port-Of: odoo/enterprise#102872

#UrbanPiper#payment#accounting

[FIX] pos_pine_labs: avoid key error for `plutusTransactionReferenceID`

PR #241364

Coresaas-18.4pos_pine_labsMEDIUM

This update fixes a pop-up error that occurred when users switched back to a previous order after using the Pine Labs payment method in Odoo. The fix ensures the system correctly retrieves payment status information, preventing disruptions in the order processing workflow. This improves the reliability of the POS system for Indian businesses using Pine Labs.

Original PR description

Steps:
----------
- Install pos_pine_labs and l10n_in module.
- Create a payment method for the Pine Labs terminal in an indian company.
- Configure the config with the Pine Labs payment method.
- Open pos session process order till payment screen.
- Go offline and try to add a Pine Labs payment method.
- Go back online and create a second order using the plus (+) button in the navbar.
- Switch back to the first order.

Issue:
----------
- A pop-up error appears due to a missing `plutusTransactionReferenceID` key when switching back to the first order and trying to get Pinelabs' transaction status.

Fix:
----------
- Ensure the payment status is fetched only when the `plutusTransactionReferenceID` key is available in the payment line.

opw-5176160

Forward-Port-Of: odoo/odoo#233357

#pos#pine labs#payment#error

[FIX] pos_self_order: improve preparation ticket layout for self-orders

PR #241160

Coresaas-18.4pos_self_order

This update fixes issues with the preparation tickets used in self-order systems. It now includes essential details like table numbers and configuration names, and correctly displays order references and times. This ensures clearer and more accurate information for staff processing self-orders.

Original PR description

Before this commit:
===================
- Some details were missing from the preparation tickets, such as the table number and configuration name.
- The order reference and time were not displayed in the correct positions.

After this commit:
==================
- Added the configuration name and table number to the receipt.
- Corrected the placement of the order reference and time.


Task: 5268966

| Before this PR | After this PR |
|--------|--------|
| <img width="511" height="431" alt="before" src="https://github.com/user-attachments/assets/ac5b2c45-5210-4a4e-86c7-953e2ab89eb1" /> |<img width="514" height="448" alt="after" src="https://github.com/user-attachments/assets/f1feb317-d5fe-469a-ab70-cf1dd793dce5" />|

Forward-Port-Of: odoo/odoo#236847

#pos#self-order#ticket#layout

[FIX] pos_loyalty: set customer as gift card's partner

PR #241383

Coresaas-18.4pos_loyalty

This update ensures that gift cards purchased through the POS system are correctly linked to the customer who made the purchase. Previously, gift cards lacked a customer association, making it difficult to track sales. This fix resolves this issue, providing better reporting and traceability for gift card transactions.

Original PR description

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card. In…

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card.

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L795-L801

In fact, the conditions for nominative programs are defined in the `loyalty` module:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/loyalty/models/loyalty_program.py#L196-L200

opw-5261991

Forward-Port-Of: odoo/odoo#237807

#gift card#pos#loyalty

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #241423

Coresaas-18.4spreadsheet

This update ensures the Odoo spreadsheet library is running the latest version, addressing potential bugs and improving performance. It’s a routine maintenance task to keep our spreadsheet functionality stable and reliable. This change was made by a team of developers to ensure continued smooth operation.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6ddac006f1 [REL] 18.4.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6ddac006f1 [REL] 18.4.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f2ed0d183a [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)
https://github.com/odoo/o-spreadsheet/commit/e3832bd5c9 [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#maintenance

[18.0][FIX] hr_expense: fix UserError on digitizing expense

PR #241393

Coresaas-18.4hr_expense

This update resolves an issue preventing regular users from digitizing expense receipts. Previously, users needed specific administrator permissions to bypass the receipt validation process. The change now allows digitization for draft expenses, streamlining the expense reporting workflow. This improves user efficiency and reduces manual intervention.

Original PR description

When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.

This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264


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

Forward-Port-Of: odoo/odoo#241348
Forward-Port-Of: odoo/odoo#240401

#expense#receipt#digitization

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102277

Enterprisesaas-18.4delivery_sendcloud

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#delivery#sendcloud#address

[PERF] point_of_sale: prevent loading product images

PR #241488

Coresaas-18.4point_of_saleMEDIUM

This update streamlines the loading of product images within the Point of Sale (POS) system. Previously, images were unnecessarily loaded and then converted to boolean values, causing performance slowdowns. Now, images are only loaded when needed, resulting in faster POS operations and a smoother user experience.

Original PR description

Before this commit, when loading products in POS, images were loaded and then changed to boolean values. This was causing unnecessary data to be loaded from the database, impacting performance.

This commit modifies the product loading methods to avoid loading images initially. Instead, by setting the 'bin_size' context key to True when loading products, images are not fetched from the database, and the size of binary fields is returned instead.

opw-5392423

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

Forward-Port-Of: odoo/odoo#241239
Forward-Port-Of: odoo/odoo#240420

#performance#POS#optimization

[FIX] point_of_sale: fix orderline merge with higher price precision

PR #241484

Coresaas-18.4point_of_saleMEDIUM

This update fixes an issue where adding the same product multiple times to a Point of Sale order would create duplicate orderlines. The change ensures that prices with varying decimal places are correctly merged, resulting in accurate order totals and a better customer experience. This resolves a rounding error that previously caused inconsistencies.

Original PR description

Before this commit, when a product had a price with more decimals than the currency, adding it multiple times to the order would create multiple orderlines instead of merging them. This was due to rounding issue when comparing the prices of the orderlines.

opw-5341735

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

Forward-Port-Of: odoo/odoo#241096
Forward-Port-Of: odoo/odoo#238639

#point of sale#order accuracy#pricing

[FIX] website_profile: website profile edition check from portal

PR #239789

Coresaas-18.4website_profileMEDIUM

This update fixes a security vulnerability where portal users could modify their country information even when an invoice or sale order was associated with their account. Previously, this restriction was only enforced through the main website portal. Now, users with existing orders cannot change their country details via the profile settings, enhancing data integrity and security.

Original PR description

Steps to reproduce:

1. Install website_forum, website_sale.
2. Confirm a Sale Order for a portal user.
3. Log in as the portal user, go to My Account -> Edit Information.
4. Country is in readonly.
5. Go to Forum -> Profile -> Edit
6. Edit the country
7. Nothing stops the user from doing so.

---

Description of the issue this commit addresses:

If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user.

---

Desired behavior after the commit is merged:

When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore.

---

task-5331916

---

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

Forward-Port-Of: odoo/odoo#237781

#security#portal#profile

[FIX] web: Calendar's event dispatch when attached to shadow tree only

PR #241357

Coresaas-18.4web

A recent update to FullCalendar, a core component of Odoo, has resolved a compatibility issue with Chrome 143 and later. This fix ensures the 'knowledge_calendar_command_tour' tour functions correctly in Chrome, addressing a previous error related to event dispatching within shadow trees. This improves overall user experience and stability.

Original PR description

Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')".

This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2].

To quote the Chromium commit message:
> According to the spec, only if the top node is in a shadow tree, both
> the target and relatedTarget should be cleared.
> However, if the top node is not in a shadow tree and not a document,
> the target and relatedTarget are always cleared. Because the current
> implementation only checks whether the top node is not a document.
> So, this patch fixes the bug by checking whether the top node is in a
> shadow tree.

In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element.

Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...)

[^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/
[^2]: https://dom.spec.whatwg.org/#concept-event-dispatch

Forward-Port-Of: odoo/odoo#240920

#fullcalendar#chrome#tour#compatibility

[FIX] website: Search suggestions hidden in grid layout snippets

PR #241478

Coresaas-18.4web_editor

This update fixes an issue where search suggestions were hidden behind product categories when using the grid layout in the website. The fix ensures that search suggestions are always visible, improving the user experience when browsing products in a grid format. This change was made to resolve a visual bug impacting product discovery.

Original PR description

Steps to reproduce: =================== - Add a product categories block with a search bar in the inner content of the block, like "s_product_list". - Drag a "Search" snippet inside of the block in…

Steps to reproduce:
===================
-  Add a product categories block with a search bar in the inner content of the block, like "s_product_list".
- Drag a "Search" snippet inside of the block in top of products categories
- Change the layout to "Grid" & Save.
- Type in the search bar to trigger autocomplete suggestions. -> The suggestions appear behind the product categories and are not visible.

Cause:
======
When a searchbar snippet is placed inside a section using grid mode, the autocomplete dropdown was hidden behind sibling grid items. This occurred because the grid layout applies inline z-index to each column (via `_placeColumns` `in grid_layout_utils.js` (See [1])), creating stacking contexts that trapped the dropdown.
So once you change to grid mode layout `_toggleGridMode` function will be triggered which will call  `_placeColumns` that will assign z-index; (See [2])

Solution:
=========
Override the inline z-index on grid items containing a searchbar

[1]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L225

[2]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L138

opw-5392011

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

Forward-Port-Of: odoo/odoo#239607

#website#search#grid layout

[FIX] web_editor: consider background image when toggling grid mode

PR #241465

Coresaas-18.4html_builder

This update resolves an issue where image columns appeared too small in the website editor's grid mode, particularly on mobile. The fix ensures that background images are now correctly considered when calculating grid item sizes, resulting in a more consistent and visually appealing layout.

Original PR description

Steps to reproduce:
===================
- In website edit mode, drop the "Split Intro" snippet.
- Toggle it to grid mode.
  => the image column is smaller than expected.
- Switch to mobile view
  => the image column is really small.

Cause & solution:
=================
When toggling a snippet to grid mode, when computing the size of the
grid items, the padding of a column is taken into account only if it has
a background color (`o_cc` class), in order to look as close as possible
as before. The background images are therefore not considered, so the
size is computed without the padding, resulting in a grid-area smaller
than expected, and the default grid item padding (which is why it is
that small in mobile view).

This commit fixes that by including the background image class
(`oe_img_bg`) in the check used to consider the padding.

opw-5374492

Forward-Port-Of: odoo/odoo#240573

#website editor#grid layout#image sizing

Branch: saas-18.3

12 changes

Bug Fixes(12)

Resolved issues and error corrections

[FIX] pos_loyalty: set customer as gift card's partner

PR #241376

Coresaas-18.3pos_loyalty

Original PR description

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card. In…

When buying a gift card from a POS, the gift card is created without a partner. This is an issue for users who want to see who bought a specific gift card.

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L795-L801

In fact, the conditions for nominative programs are defined in the `loyalty` module:

https://github.com/odoo/odoo/blob/0bf53e6b2ab8c4c1705ebbb776102d493ac7445c/addons/loyalty/models/loyalty_program.py#L196-L200

opw-5261991

Forward-Port-Of: odoo/odoo#237807

#gift card#pos#loyalty

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #241422

Coresaas-18.3spreadsheet

This pull request updates the core spreadsheet library used within Odoo. The changes address several technical issues related to data validation and highlighting, ensuring the spreadsheet functionality remains stable and reliable. These updates contribute to a smoother user experience when working with spreadsheets in Odoo.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1e143e1470 [REL] 18.3.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/1e143e1470 [REL] 18.3.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b718b6079d [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)
https://github.com/odoo/o-spreadsheet/commit/b2f4e15ffd [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#performance

[18.0][FIX] hr_expense: fix UserError on digitizing expense

PR #241386

Coresaas-18.3hr_expense

This update resolves an issue preventing regular users from digitizing receipts attached to expenses. Previously, users needed specific administrator permissions. The change now allows digitization when the expense is in draft status, streamlining the expense reporting process.

Original PR description

When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.

This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264


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

Forward-Port-Of: odoo/odoo#241348
Forward-Port-Of: odoo/odoo#240401

#expense#digitization#user access

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102267

Enterprisesaas-18.3delivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct address data is transmitted to Sendcloud. This improves delivery accuracy and reliability.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#delivery#sendcloud#address

[PERF] point_of_sale: prevent loading product images

PR #241482

Coresaas-18.3point_of_sale

Original PR description

Before this commit, when loading products in POS, images were loaded and then changed to boolean values. This was causing unnecessary data to be loaded from the database, impacting performance.

This commit modifies the product loading methods to avoid loading images initially. Instead, by setting the 'bin_size' context key to True when loading products, images are not fetched from the database, and the size of binary fields is returned instead.

opw-5392423

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

Forward-Port-Of: odoo/odoo#241239
Forward-Port-Of: odoo/odoo#240420

#performance#POS#optimization

[FIX] planning: prevent error on missing end date

PR #102895

Enterprisesaas-18.3planning

This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date gracefully, preventing a technical error and maintaining smooth slot management. This improves the user experience and prevents disruptions to planning workflows.

Original PR description

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slots#error

[FIX] pos_pine_labs: avoid key error for `plutusTransactionReferenceID`

PR #241351

Coresaas-18.3pos_pine_labs

Original PR description

Steps:
----------
- Install pos_pine_labs and l10n_in module.
- Create a payment method for the Pine Labs terminal in an indian company.
- Configure the config with the Pine Labs payment method.
- Open pos session process order till payment screen.
- Go offline and try to add a Pine Labs payment method.
- Go back online and create a second order using the plus (+) button in the navbar.
- Switch back to the first order.

Issue:
----------
- A pop-up error appears due to a missing `plutusTransactionReferenceID` key when switching back to the first order and trying to get Pinelabs' transaction status.

Fix:
----------
- Ensure the payment status is fetched only when the `plutusTransactionReferenceID` key is available in the payment line.

opw-5176160

Forward-Port-Of: odoo/odoo#233357

#pos#pine labs#payment

[FIX] pos*: reward line visibility issue with courses

PR #241007

Coresaas-18.3point_of_salepos_restaurant_loyaltyMEDIUM

This update resolves an issue where reward lines weren't consistently displayed in Restaurant POS orders after switching between the front-end and back-end. The fix ensures reward lines are correctly created and maintained, preventing data loss and improving the order management experience. This impacts users managing orders in the Restaurant UI.

Original PR description

pos*: point_of_sale, pos_restaurant_loyalty

Steps to reproduce:
- Open a table in the Restaurant UI.
- Click the Course button.
- Add products that trigger a reward line creation.

Issues:
- The reward line is not visible in the order.
- After switching to the backend and returning to the POS, no order lines are visible for that order.

Fixes:
- Ensure the reward line is created within the proper course.
- Prevent deletion of the reward line when switching between backend and POS.

Task: 5215920

Forward-Port-Of: odoo/odoo#233919

#POS#Loyalty#Orders

[FIX] web: Calendar's event dispatch when attached to shadow tree only

PR #241338

Coresaas-18.3web

This update addresses a bug in the 'knowledge_calendar_command_tour' that prevented it from working correctly in Chrome 143 and later. The fix, stemming from a Chromium update, ensures FullCalendar events are dispatched properly when attached to shadow trees, resolving a compatibility issue that affected Firefox and Safari.

Original PR description

Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')".

This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2].

To quote the Chromium commit message:
> According to the spec, only if the top node is in a shadow tree, both
> the target and relatedTarget should be cleared.
> However, if the top node is not in a shadow tree and not a document,
> the target and relatedTarget are always cleared. Because the current
> implementation only checks whether the top node is not a document.
> So, this patch fixes the bug by checking whether the top node is in a
> shadow tree.

In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element.

Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...)

[^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/
[^2]: https://dom.spec.whatwg.org/#concept-event-dispatch

Forward-Port-Of: odoo/odoo#240920

#FullCalendar#Chrome#Tour

[FIX] website: Search suggestions hidden in grid layout snippets

PR #241477

Coresaas-18.3web_editor

This update fixes an issue where search suggestions were hidden behind product categories when using the grid layout in the website. The fix ensures that search suggestions are always visible, improving the user experience when searching for products within grid-based sections. This change was made to address a visual bug and enhance usability.

Original PR description

Steps to reproduce:
===================
-  Add a product categories block with a search bar in the inner content of the block, like "s_product_list".
- Drag a "Search" snippet inside of the block in top of products categories
- Change the layout to "Grid" & Save.
- Type in the search bar to trigger autocomplete suggestions. -> The suggestions appear behind the product categories and are not visible.

Cause:
======
When a searchbar snippet is placed inside a section using grid mode, the autocomplete dropdown was hidden behind sibling grid items. This occurred because the grid layout applies inline z-index to each column (via `_placeColumns` `in grid_layout_utils.js` (See [1])), creating stacking contexts that trapped the dropdown.
So once you change to grid mode layout `_toggleGridMode` function will be triggered which will call  `_placeColumns` that will assign z-index; (See [2])

Solution:
=========
Override the inline z-index on grid items containing a searchbar

[1]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L225

[2]: https://github.com/odoo/odoo/blob/d4411c27b469e5dcc526b5b1f8ea4498f2b08567/addons/web_editor/static/src/js/common/grid_layout_utils.js#L138

opw-5392011

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

Forward-Port-Of: odoo/odoo#239607

#website#search#grid layout

[FIX] web_editor: consider background image when toggling grid mode

PR #241453

Coresaas-18.3web_editor

This update fixes an issue where image columns appeared too small in the website editor's grid mode, particularly on mobile. The fix ensures background images are correctly accounted for when calculating column sizes, resulting in a more consistent and visually appealing layout.

Original PR description

Steps to reproduce:
===================
- In website edit mode, drop the "Split Intro" snippet.
- Toggle it to grid mode.
  => the image column is smaller than expected.
- Switch to mobile view
  => the image column is really small.

Cause & solution:
=================
When toggling a snippet to grid mode, when computing the size of the
grid items, the padding of a column is taken into account only if it has
a background color (`o_cc` class), in order to look as close as possible
as before. The background images are therefore not considered, so the
size is computed without the padding, resulting in a grid-area smaller
than expected, and the default grid item padding (which is why it is
that small in mobile view).

This commit fixes that by including the background image class
(`oe_img_bg`) in the check used to consider the padding.

opw-5374492

Forward-Port-Of: odoo/odoo#240573

#UI#Layout#Grid

[FIX] hr_holidays: only skip future leave if more accrual possible

PR #241198

Coresaas-18.3hr_holidaysMEDIUM

This update fixes an issue where employees with past accrual allocations weren't correctly reflecting available vacation days on their Time Off Dashboard. Now, future leaves are only excluded from available days if an employee can still accrue more vacation time before the leave date, ensuring accurate tracking of time off.

Original PR description

Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb.…

Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#238977

#hr#time off#accrual

Branch: saas-18.2

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102258

Enterprisesaas-18.2delivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct delivery address formatting and preventing potential delivery errors.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#delivery#sendcloud#address

[FIX] planning: prevent error on missing end date

PR #102883

Enterprisesaas-18.2planning

This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date correctly, preventing a technical issue that could disrupt planning workflows. This improves the stability and usability of the planning module.

Original PR description

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slot#end date

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102579

Enterprisesaas-18.2l10n_ke_edi_oscuMEDIUM

This update resolves an error that prevented vendor bills from being correctly sent to eTIMS. The issue stemmed from a missing eTIMS configuration setting in new company setups, which was causing a critical process to be skipped. Now, the system correctly validates the eTIMS setup and allows bills to be sent.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#ke_edi#etims#vendor_bills

Branch: master

15 changes

Bug Fixes(15)

Resolved issues and error corrections

[FIX] account_reports: prevent error when sending the customer statement

PR #102786

Enterprisemasteraccount_reportsMEDIUM

This update resolves an error that occurred when sending customer statements. Previously, the system would fail if a user removed the email template during the sending process. Now, the system correctly uses the email template if one is provided, or falls back to the current user's email address, ensuring reliable statement delivery.

Original PR description

Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the…

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

[this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

Forward-Port-Of: odoo/enterprise#102682
Forward-Port-Of: odoo/enterprise#102219

#reports#statements#email

[IMP] knowledge: hide GIF and canned response actions

PR #102940

Enterprisemasterknowledge

This update restores the intended behavior for the Knowledge composer by hiding the GIF and canned response actions. These features were previously visible after a recent system update, but this fix ensures they are hidden when creating content in Knowledge, streamlining the composing process. This improves the user experience for creating knowledge articles.

Original PR description

The GIF picker was previously hidden in Knowledge, but became visible again after the composer actions refactor.

Commit that introduced the change:
https://github.com/odoo/odoo/commit/5e1daafeac231c333ea13369fc208627213d67d4

This commit restores the intended behavior by hiding the GIF action again and also hides the canned response action, as neither feature is relevant when composing content in Knowledge, by applying conditions on the corresponding composer actions.

Task-5163888

Forward-Port-Of: odoo/enterprise#102927
Forward-Port-Of: odoo/enterprise#100585

#knowledge#composer#UI

[FIX] planning: prevent error on missing end date

PR #102919

Enterprisemasterplanning

This update resolves an error that occurred when a user removed the end date from a planning slot. The fix ensures the system handles the absence of an end date gracefully, preventing a technical error and allowing users to correctly manage their planning slots. This improves the overall stability of the planning module.

Original PR description

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slots#error

[FIX] l10n_uk_reports_cis: fix accounts codes duplications

PR #100555

Enterprisemasterl10n_uk_reports_cis

This update resolves an issue preventing the successful installation of the UK Construction Industry Scheme (l10n_uk_reports_cis) when using branch companies. The fix prevents the creation of duplicate account codes, ensuring the module installs correctly and reliably for all UK company setups, including those with branches.

Original PR description

Before this commit:
Steps
1) Create a UK localization company
2) Create a branch for that company
3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis)

=> A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch).

After this commit:
UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches.

opw-5326079

Forward-Port-Of: odoo/enterprise#99901

#UK Localization#Reporting#Accounts

[FIX] pos_urban_piper: wrong payment difference on UrbanPiper orders

PR #102941

Enterprisemasterpos_urban_piper

This update resolves an issue where payment differences were incorrectly calculated for UrbanPiper orders after payment. The fix ensures that the final payment amount is accurately reflected as $0.00, improving the reliability of financial reporting for these orders. This change impacts the UrbanPiper integration.

Original PR description

In this commit,
The amount difference should be 0.0 after the Urbanpiper order has been paid.

task-5441252

Forward-Port-Of: odoo/enterprise#102894
Forward-Port-Of: odoo/enterprise#102872

#payment#urbanpiper#pos

[IMP] hr_payroll: Payslip Work Days Lines Report

PR #102199

Enterprisemasterhr_payroll

This update fixes an issue where the Payslip Work Days Lines report displayed data for both Indian and Belgium payrolls. The team added a filter to ensure the report only shows data for the currently selected company, improving data accuracy and usability.

Original PR description

**Steps to reproduce:**
- Install Indian and Belgium payroll.
- Go to Payslip Work Days Lines report.
- Employee data of both companies are shown.

**Issue:**
- Payslip Work Days Lines Report Should Show Only Selected Company’s Data.

**Cause:**
- Filtering was missing to set the data according to selected company

**Fix:**
- Added domain in view to show data according to the current selected company.

task-5407727

#payroll#reporting#company selection

[FIX] l10n_de_pos_cert: set fiskaly tax mapping properly

PR #102891

EnterprisemasteraccountposMEDIUM

This update resolves an issue where tax mappings weren't correctly set when upgrading to version 19.0 or higher for companies registered with Fiskaly. The fix ensures accurate data transmission to Fiskaly during session closing, preventing errors related to company names or cash move reasons containing hyphens. This upgrade automatically corrects existing issues and ensures future sessions function correctly.

Original PR description

Steps to reproduce: ------------------------- - Upgrade from lower version to 19.0 or higher. - Start a fiskaly registered company's session. - Close the session after transactions. Issue: ------- -…

Steps to reproduce:
-------------------------
- Upgrade from lower version to 19.0 or higher.
- Start a fiskaly registered company's session.
- Close the session after transactions.

Issue:
-------
- Tax mapping used to send data to fiskaly is not set.
- If have `-` in company name or cash move reason and try to do cash move will give a tb.

Cause:
---------
- When the user's database is upgraded, the taxes already exist and the company is already registered. As a result, `l10n_de_vat_export_data` is never set, and since no tax changes occur, `l10n_de_vat_definition_export_identifier` is also not generated. This leads to incorrect values being sent to Fiskaly during the session closing request, causing errors.
- The cash statement name uses - as a separator, the current structure is `{session_name}-{move_type}-{statement_type}-{move_reason}` set from `_prepare_account_bank_statement_line_vals()` If move_reason or company name contains additional `-` splitting the whole name breaks the expected structure.

Fix:
-----
- We have added a check to identify any taxes that are missing their tax mapping If such taxes are found, we filter them and trigger the logic to set their mappings. However, if the main mapping reference value l10n_de_vat_export_data is not set, we first retrieve and update it. Once this reference is available, we update all taxes that were previously unset and then prepare the correct tax data.
As a result, the first session closing after the upgrade will automatically correct all issues both for customers who have already upgraded and for those who upgrade in the future.
- We first remove the `{session_name}-` prefix, then split the rest. Since move_type and statement_type never contain -, we take them directly not user inputs, and then rejoin everything from index 2 onward to reconstruct the correct move_reason.

Additional fixes:
--------------------
- Some places the limit of characters may exceed than what fiskaly is asking than it can give us an error so restricted all places where needed.
- We don't have check if the settlement is present if not getting id directly may cause error.

help ticket: 5362897, 5367425

Forward-Port-Of: odoo/enterprise#102855
Forward-Port-Of: odoo/enterprise#101468

#fiskaly#vat#germany#tax

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102324

Enterprisemasterdelivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct delivery address formatting and preventing delivery errors.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#address#delivery#sendcloud

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102969

Enterprisemasterl10n_ke_edi_oscuMEDIUM

This update resolves an error that prevented vendor bills from being successfully sent to eTIMS. The issue stemmed from incorrect eTIMS configuration during company setup. Now, the system will correctly handle sending bills to eTIMS when the eTIMS settings are properly configured.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#ke_edi#etims#vendor_bills

[FIX] hr_contract_salary_payroll : Fix Salary Calculation not displayed

PR #102371

Enterprisemastercurrency_rate_liveHIGH

This change resolves an issue where currency rate conversions for the UYU BCU were failing due to rates being created on incorrect dates. This prevented accurate financial reporting for users operating in Uruguay. The fix ensures rates are created on the correct date, guaranteeing accurate currency conversions.

Original PR description

This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set. Steps to Reproduce : First Change to either…

This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set.

Steps to Reproduce :
	First Change to either the default company (MyCompany) or Demo Belgian company
	Payroll -> Employee -> Salary Calculator -> choose an employee.

Bug : All fields in the Salary Calculator view are empty (evaluated as False).

Root Cause :

Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using:

`payslip.version_id.write(new_payslip_vals)`

Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False.

Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation.

Task - 5387155

#currency#finance#UYU#BCU

[FIX] appointment_hr_recruitment: fix traceback when qualifying applicant

PR #100711

Enterprisemasterhr_recruitmentMEDIUM

This update resolves an issue where recruitment officers couldn't correctly schedule interviews due to limited access rights. The fix grants them the necessary permissions to create appointment types and slots, ensuring a smooth process for qualifying applicants and sending out interview invitations.

Original PR description

Problem:
Recruitment officers don't have the rights to create appointment.type nor appointment.interview, Hence when they move an applicant to the qualified stage an error is raised during rendering the body of the mail template `email_template_data_applicant_schedule_interview`.

Fix:
Grant recruitment officers the access they need in that flow:
- Create/Read "anytime" appointment type.
- Create appointment slots/invites associated with an "anytime" appointment type.

Task-5262936

#recruitment#appointments#workflow

[FIX] hr_work_entry_enterprise: crash with fully flexible employees

PR #102980

Enterprisemasterhr_work_entry_enterpriseMEDIUM

This update resolves a crash that occurred when using fully flexible employees in payroll and work entry modules. The fix ensures that employee unavailability is correctly generated, preventing errors and improving the stability of these key processes.

Original PR description

Steps to reproduce:
- Install hr_work_entry
- create an active employee with a running contract and no resource calendar(fully flexible)
- try to open work entries/payroll
- you get a traceback because of `_gantt_unavailability`

Current behavior:
- when the employee is flexible, the unavailability is set to an empty interval without accessing the calendar(that doesn't exist)
- added `test_gantt_unavailability` to check if the unavailability intervals of employees are generated correctly

task-id: 5408752

Forward-Port-Of: odoo/enterprise#102679

#payroll#flexible employees#stability

[FIX] test_l10n_be_hr_payroll_account: tour failing with demo data

PR #102979

Enterprisemasterhr_payroll

This update resolves a problem preventing a key demo tour from running correctly. The issue stemmed from duplicate job entries within the demo data, causing a mismatch during the tour's execution. This ensures the demo tour functions as intended, providing a reliable experience for users.

Original PR description

- fixing tour `hr_contract_salary_tour_sign_again`which was failing with demo data because another job was installed in the demo data with name Experienced Developer so it was matching with it instead of the correct job position

task-id: 5413364

Forward-Port-Of: odoo/enterprise#102677

#demo#tour#bug

[IMP] l10n_be_hr_contract_salary: add account holder name field to salary config

PR #101923

Enterprisemasterhr_contract_salaryl10n_be_hr_contract_salaryMEDIUM

This update adds a field to the salary configuration to require the correct bank account holder name. This is a security fix to prevent payment delays and manual confirmations, ensuring accurate bank transfers. Related tests and a user tour have been added for clarity and verification.

Original PR description

Law is now more secure and you need to have the correct name on the bank account holder otherwise payment need to be manually confirmed everytime. Therefore a field is added to the salary config to allow the user to set his account holder name separately from his actual name in case it is different.

Task-5222712

[Related PR](https://github.com/odoo/odoo/pull/233965)

Forward-Port-Of: odoo/enterprise#98572

#payroll#payments#account management#Belgium

19.0 hr attendance negative overtime zirah

PR #102984

Enterprisemasterhr

This update restores the ability to generate negative overtime (undertime) in the attendance system. This feature, previously removed to minimize financial losses, is now re-enabled based on specific Absence Management settings. This allows for more accurate tracking of employee hours and reduces potential revenue discrepancies.

Original PR description

…time generation

Forward-Port-Of: odoo/enterprise#102880
Forward-Port-Of: odoo/enterprise#102271

#attendance#overtime#hr

Branch: 19.0

5 changes

Bug Fixes(5)

Resolved issues and error corrections

[FIX] pos_urban_piper: wrong payment difference on UrbanPiper orders

PR #102932

Enterprise19.0pos_urban_piper

This update fixes an issue where UrbanPiper orders were incorrectly displaying a payment difference after completion. The change ensures that the final payment amount is accurately reflected as $0.00, resolving a potential discrepancy and improving order accuracy for UrbanPiper transactions.

Original PR description

In this commit,
The amount difference should be 0.0 after the Urbanpiper order has been paid.

task-5441252

Forward-Port-Of: odoo/enterprise#102894
Forward-Port-Of: odoo/enterprise#102872

#UrbanPiper#POS#Payment

[FIX] planning: prevent error on missing end date

PR #102909

Enterprise19.0planning

This update resolves an error that occurred when users removed the end date from a planning slot. The fix ensures the system handles the absence of an end date correctly, preventing a technical error and maintaining smooth slot management. This improves the user experience and prevents disruptions to planning workflows.

Original PR description

Currently an error occurs when user tries to remove end date on slot.

Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.

Error:
```
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
    if slot._different_than_template():
 File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
    slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].

Solution:
- Returned from the function call when `end_datetime` is false.

[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426

[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438

No ID

Forward-Port-Of: odoo/enterprise#102762

#planning#slots#error

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102600

Enterprise19.0l10n_ke_edi_oscuMEDIUM

This update resolves an error that prevented vendor bills from being successfully sent to eTIMS when the eTIMS configuration wasn't properly set up. Specifically, the system was failing to recognize the necessary eTIMS settings, leading to a blank error. This fix ensures that vendor bills without tax can now be correctly transmitted to eTIMS.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#eTIMS#Kenya#vendor bills

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102284

Enterprise19.0delivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct delivery address formatting and preventing potential delivery errors.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#address#sendcloud#delivery

[FIX] hr_appraisal: handle error on clicking appraisal smart button

PR #99662

Enterprise19.0hr_appraisal

This update resolves an issue where users with basic employee management rights couldn't access employee appraisals. The fix ensures that only appraisers and administrators can access this feature, preventing errors and improving stability. This change aligns with security best practices by restricting access to sensitive appraisal data.

Original PR description

An error occurs when a user with `Employee Management` rights, but without any appraisal rights, tries to open an employee’s appraisals. **Steps to Reproduce:** 1) Install Appraisals App.(with Demo).…

An error occurs when a user with `Employee Management` rights, but without any appraisal rights, tries to open an employee’s appraisals.

**Steps to Reproduce:**
1) Install Appraisals App.(with Demo).
2) Log in as admin, open Marc Demo in Settings > Users & Companies > Users,
   and set `Employees: Officer (Manage all employees)` under HR section.
3) Log in as Marc Demo and open any employee profile (e.g., Anita Oliver).
 4) Click on `Appraisals smart button`.

**Error:**
`IndexError: tuple index out of range`

**Root Cause:**
When a user has only employee management rights, `self.appraisal_ids` received in the method at [1] becomes an empty tuple. Accessing `self.appraisal_ids[0].id` therefore raises an `IndexError`.

**FIX:**
If no `appraisal_ids` are available, return the list view of appraisals, matching the behavior from previous versions.

[1]- https://github.com/odoo/enterprise/blob/3ee1df0b806f9c73d79b8b55fcc7d55b530d9e6b/hr_appraisal/models/hr_employee.py#L169-L180

sentry-7032734789

#appraisals#user access#permissions

Branch: 18.0

6 changes

Bug Fixes(6)

Resolved issues and error corrections

[FIX] delivery_sendcloud: parse address numbers with multiple dashes

PR #102234

Enterprise18.0delivery_sendcloud

This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change updates a key pattern to accurately capture address numbers with multiple separators, ensuring correct address formatting and delivery processing. This improves the reliability of our Sendcloud integration.

Original PR description

Issue
-----
When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed.

Examples:
Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13)
7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A)

Fix
-----
Update part of the regex pattern from

`\d+[-\/]?\d*`

to

`\d+(?:[-\/]?\d+)*`

in order to match multiple occurences of one of '-', '\' or '/' followed by some number.

-----
Ticket:
opw-5366863

Forward-Port-Of: odoo/enterprise#101594

#delivery#sendcloud#address

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #241420

Core18.0spreadsheet

This update ensures the Odoo spreadsheet functionality is running on the latest version, addressing potential bugs and improving performance. It’s a routine maintenance task to keep our spreadsheet capabilities reliable and up-to-date. This change focuses on internal improvements to the spreadsheet library itself.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7ca8390462 [REL] 18.0.53 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/7ca8390462 [REL] 18.0.53 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/ba1270ea46 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)
https://github.com/odoo/o-spreadsheet/commit/22244de194 [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#maintenance

[FIX] hr_expense: prevent autobalancing line analytic company-paid expense

PR #233841

Core18.0hr_expenseMEDIUM

This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that the expense entry is correctly processed as a payment, preventing incorrect accounting and ensuring accurate tax calculations. This improves the reliability of expense reporting for company-paid expenses.

Original PR description

Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…

Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line.

## Steps to reproduce
1. Create an expense paid by the company.
2. Confirm and generate the expense report.
3. Reset the expense’s journal entry to draft and add an analytic account on the first line.
→ An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited.

## Cause
For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*.
In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes.

However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`.
This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines.
As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate.

## Solution
Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`.

**opw-5166707**


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

#expenses#accounting#payments

[FIX] test_mimetypes: xlsx 2025 mimetype detection test without libmagic

PR #241285

Core18.0test_mimetypes

This update resolves an issue where tests for XLSX file type detection were failing due to differences in how the system determined the file's type. The change simplifies the test by ensuring consistent mimetype results regardless of whether the system's file analysis tools are available. This ensures accurate file type identification for XLSX files.

Original PR description

Following commit [^1] increasing bytes passed to mimetype guesser, the differentiation made in test between whether python-magic bindings are present or not isn't relevant anymore, as both use case now returns the same mimetype.

Note: while the regular runbot builds doesn't have the python-magic bindings installed, the ones for nightlies' DistroBuilds does (and obviously broke in this case).

runbot-234738

[^1]: https://github.com/odoo/odoo/commit/72e8a29dd0edb0ca3d464142ce869f38f96c730a

#file type#detection#xlsx

[FIX] l10n_ec_edi_pos: fix typo

PR #102202

Enterprise18.0l10n_ec_edi_pos

A minor bug in the l10n_ec_edi_pos module was causing the incorrect 'Consumidor Final' customer type to be selected during refund processing for specific partners like 'Deco Addict'. This fix corrects a simple typo in the code, ensuring accurate customer type selection and proper refund functionality.

Original PR description

Step to reproduce:
-  install l10n_ec_edi_pos
- start pos and settle order with specific partner(ex. Deco Addict)
- process the refund for this order

Observation:
- on product screen, "Consumidor Final" is selected instead of Deco addict.

Cause and Fix:
- Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id`

opw-5412346

#refund#pos#ec_edi

[FIX] stock: break move_dest_ids link upon cancellation

PR #237890

Core18.0stockMEDIUM

This update resolves a problem where delivery pickings remain 'Waiting Another Operation' after cancelling a related manufacturing order (MTO). The fix ensures that stock quantities are correctly reserved when an MTO is cancelled, particularly in multi-step manufacturing processes. This prevents delays in order fulfillment.

Original PR description

Issue ----- After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step. Steps…

Issue
-----
After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step.

Steps to reproduce
-----
- Enable multi step routes
- Set WH to 3-step manufacturing
- Create a product
	- empty bom
	- MTO & manufacturing routes
	- 5 in stock
- Create a SO for the product
- Cancel the linked MO
- Open the delivery picking
- Click "Check Availability"

> The product is not getting reserved from stock

> The delivery picking is still "Waiting Another Operation"

Cause
-----
The problem happens in `action_cancel`

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995

In 1-step case, `move.propagate_cancel` is false so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021

where `move_dest_ids` is the move of the delivery picking.

This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931

instead of going into the `else` part

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949

In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014

which lacks the swap to MTS and unlink `move_dest_id` logic.

Solution
-----
We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by

https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012

This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754

and since it was set to MTS, it goes into the `else`part of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216

-----
Ticket:
opw-5124380

#stock#manufacturing#delivery

Branch: 17.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] web_editor: open a popover for inline document download

PR #241121

Core17.0web_editor

This update fixes a previous issue where documents uploaded via the /image feature couldn't be downloaded. Now, a popover appears allowing users to directly download the document without editing options. The attachment toolbar is also hidden for a cleaner user experience.

Original PR description

Before this commit: the document uploaded by /image cannot be downloaded
on clicking.

After this commit: we open a popover for document without the editing
buttons. The user may download the document by clicking the link. Also
the toolbar is hidden for attachments.

task-3648796



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

Forward-Port-Of: odoo/odoo#236705

#download#attachments#user experience