Daily updates from Odoo
Monday, December 29, 2025
35 changes · saas-19.1
Enhancements to existing features
This update adjusts the minimum wage calculation within the Odoo Enterprise system to comply with a recent increase announced by CONASAMI for Mexico. Specifically, the ‘Mexico: Daily Minimum Wage’ parameter has been updated to 315.04, ensuring accurate payroll calculations effective January 1, 2026. This change aligns with legal requirements and maintains payroll accuracy.
Original PR description
According to CONASAMI: https://www.gob.mx/conasami/articulos/incremento-a-los-salarios-minimos-para-2026?idiom=es the minimum wage will increase effective January 1, 2026. It is necessary to update the “Mexico: Daily Minimum Wage” parameter to reflect the new value: 315.04 target: 19.0 task-5412717 Forward-Port-Of: odoo/enterprise#102922
Resolved issues and error corrections
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
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#102762A 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
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
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
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
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
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
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#240401This 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
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
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
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
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>
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
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
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#101319This 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
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
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
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
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
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
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
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" />
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
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
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
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
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
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" />
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
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
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"…
**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