Daily updates from Odoo
Wednesday, May 13, 2026
60 changes · master
New functionality added to Odoo
This update introduces a new report (IR56M) to comply with Hong Kong's payroll regulations for non-employee workers (freelancers, contractors). It also includes adjustments to Chart of Accounts to align with local requirements. This ensures accurate reporting for HK businesses.
Original PR description
task-[5050335](https://www.odoo.com/odoo/my-tasks/5050335) odoo/odoo#263768 odoo/enterprise#116875 odoo/upgrade#10186 --- Preceeding PR Status: #116875 I named named `Taxable Salary` so it aligns with this upcoming change https://github.com/odoo/enterprise/pull/113135 @vin-odoo lmk what this should be tq ### Approach From my observations, all the other ir56 report templates name the variables accordingly to the XML template. I agree with this approach--keeping template dumb and the mapping logic in the python code. This will apply to the case for `AmtOfType2` which is equivalent to `AmtOfCommFee` in B,F,G ### Todo - [ ] squash commits - [ ] commit msg/desc - [ ] rename CE/EE to master- so upgrades work
This update allows users to easily download all attachments associated with bank statements and statement lines in a single zip file. This simplifies the process of accessing and reviewing supporting documentation, improving efficiency and record-keeping.
Original PR description
This commit will add a new server action to download in a zip the attachments of the statement line and also of the bank statement link to it. task-6045430
This update introduces a new widget within Odoo's reporting tools that allows users to group and analyze financial reports by user. This provides greater insight into who is responsible for specific transactions and improves reporting accuracy and accountability.
Original PR description
task-4572646
Enhancements to existing features
This update simplifies filtering of bank reconciliation reports by introducing a new message type for transaction details. This change enhances the user experience by allowing for more precise and efficient filtering of bank statement data within the bank rec widget. It's an improvement to the existing bank reconciliation process.
Original PR description
Following this commit: This commit will introduce a new message type for the transaction details used in the bank rec widget to ease the filtering of those message. task-5932620
This update restricts the 'Flexible Employment' (FLX) category option in the Belgian payroll module for Odoo Enterprise, aligning with specific Belgian labor regulations. It now requires a compatible Joint Committee (CP) and NACE company code to be selected, ensuring compliance and accurate reporting. This change improves data integrity and reduces potential errors related to FLX category selection.
Original PR description
[IMP] l10n_be_hr_payroll: restrict dimona flx category FLX in employee_type is selectable only for certain CPs (Joint Committees) and NACE codes of the company Ref list link:…
[IMP] l10n_be_hr_payroll: restrict dimona flx category
FLX in employee_type is selectable only for certain CPs (Joint Committees) and NACE codes of the company
Ref list link: https://emploi.belgique.be/fr/themes/contrats-de-travail/contrats-de-travail-particuliers/contrat-de-travail-flexi-job#toc_heading_3
1 - I created a new allowed_employee_types_ids M2M field to determine which employee types will be shown in the selection box (or flex will be shown or not)
1.1 - If the egov3 code of the joint committee is one of the determined codes in the ref link, the flex type is shown.
1.2 - Sometimes egov3 code of joint committee and NACE code of the company need to be combined
2 - In hr_version, joint committee field in UI was reseting after changing employee type to Flex or changing type from Flex to False, now it remains unchanged
3 - In employee form view, allowed_employee_types_ids is added as a domain to employee_type_id to show flex type or not
task - 6131721This update enhances the sorting of contacts within the VoIP module to address inconsistencies in how names and numbers are displayed. Specifically, it now correctly handles umlauts in German names and sorts numbers in a more user-friendly, lexicographical order, ensuring contacts appear in the expected sequence.
Original PR description
### German Phonebook In German phonebook sorting, umlauts are expanded to their two-letter equivalents before sorting: - ä becomes ae - ö becomes oe - ü becomes ue - ß becomes ss ### Numbers Sorting numbers in lexicographical order leads to "10" coming before "9", but when browsing a list of contacts, you'd expect "Guest 2" to show up before "Guest 10000". This commit adapts VoIP's contact tab to account for these two aspects.
This update automatically calculates and displays the subscription duration on customer quotes (both PDF and Portal views) when a template has a defined duration. Previously, the duration wasn't visible until a subscription started, leading to a poor customer experience. The changes also improve the reliability of subscription synchronization.
Original PR description
**Why** Currently, when a quotation template has a duration, the end date is only computed and set when the subscription starts. As a result: - The duration is not visible to the customer on the PDF quote. - The duration is not visible to the customer on the Portal. - If a user manually defines a start date on the quote, the end date is not computed automatically. **What** - Made `end_date` a computed field depending on `start_date`. If the start date is set and the template has a fixed duration, the end date is now computed automatically. - Updated the Portal quote view to display the template's duration (Duration + Unit) if no start date is defined yet. - Updated the PDF quote report to display the template's duration if no start date is defined yet. - Refactored confirmation hook to maintain recurrence synchronization safely without redundant loops. **task**: 5969513
This update simplifies the process of canceling old invoices in Mexico's EDI system. When a new invoice replaces an existing one, the system now automatically cancels the original invoice, eliminating the need for manual intervention. This improves efficiency and reduces potential errors related to invoice management.
Original PR description
Triggers the EDI document cancellation method for the substituted invoice when the substitute document is signed, removing the requirement for the user to go back and click cancel again as well as bypassing calling a wizard with no options for the user to select from. task-5927581 Forward-Port-Of: odoo/enterprise#116959 Forward-Port-Of: odoo/enterprise#107541
This update improves how expenses are tracked within Odoo Enterprise by allowing for more detailed configuration. Previously, a generic 'EXPENSE' rule limited expense tracking, but now businesses can define specific input types for product categories, ensuring expenses are handled accurately according to local regulations and business needs.
This update enhances document creation by standardizing chatter messages, providing clear details like author, source, and document name. This improves traceability and reduces user confusion when managing documents, leading to a better overall experience.
Original PR description
Currently, when documents are created, their chatter messages are inconsistent, lack important details, or simply do not exist. This creates confusion and wastes users' time when trying to trace a document's origin. To solve this problem and improve the user experience, this PR introduces a standardized chatter message format that cleanly captures all essential information. Displayed information: - Document Author - Original document name - Document source (e.g., user upload, email, PEPPOL, or an Odoo app) - Notes section (hidden if empty; used to display the related record when saving an attachment from the chatter) Implementation notes: - adapted the tests of `account_invoice_extract` to account for new creation message. - Enabled logs for documents generated from emails. - A recent commit completely rewrote the "Add" document operation but left the old implementation intact. This PR removes that obsolete code. task-5498838
This update aligns the data cleaning views with standard Odoo list views, resolving inconsistencies in mass editing actions. By moving key actions like 'validate,' 'archive,' and 'unarchive' to the header, the user experience is now more intuitive and consistent with other Odoo workflows.
Original PR description
In the deduplication, and field cleaning views, mass selection did not behave consistently with standard Odoo list views and displayed redundant action buttons. This commit moves the validate, archive (discard), and unarchive (undiscard) actions from view buttons to header buttons so they behave like standard mass-edit actions in Odoo and provide a more consistent UX. task-6112028
This update adds a client ID field to the list view for account online links, providing the support team with crucial information. This optional field is hidden by default for customers who don't require it, ensuring a streamlined experience. It improves support efficiency and data accessibility.
Original PR description
The aim of this commit is adding the client id of an account online link into the list view to help the support. The field is added in optional hide for the customers who don't need this information. no task id
This update enhances Odoo's support for Mexican import/export regulations (IMMEX) to align with CFDI 4.0 standards. Specifically, the 'External Trade' field now supports additional trade type codes, and defaults are set based on customer information for improved accuracy. This ensures proper tax reporting for Mexican businesses.
Original PR description
IMMEX is a program created by the Mexican government which enables companies to import goods into Mexico without paying taxes because they will be exported back in a short time. The "External Trade"(`l10n_mx_edi_external_trade_type`) field now includes values 01, 02, 03, and 04 to comply with CFDI 4.0. - Default value is "01 - Does not apply". - The field in `account.move` now defaults based on `res.partner` value. Populate 'External Trade' field in demo records: - Azure Interior: [02] - Definitive - Escuela Kemper Urgate: [04] - Definitive without alienation For `account.move` and `sale.order`, when the partner is a foreign customer, the "CFDI to public" (`l10n_mx_edi_cfdi_to_public`) field is automatically enabled. target: master task: 4819749
This update integrates the EC Sales List into the standard account returns process, streamlining the handling of returns related to online sales. The system now directly associates return information with the account return record, improving data accuracy and reporting. A new safeguard prevents incorrect return status resets when returns have been accepted by Digipoort.
Original PR description
This commit introduces the EC Sales List into the standard account returns flow and refactors the SBR status service to attach its messages directly to the account return instead of the closing entry. Specific changes include: * EC Sales List Integration: The EC Sales List report is now configured to auto-generate. * Status Service Refactoring: The `closing_entry_id` field on the `l10n_nl_reports.sbr.status.service` model has been replaced by `account_return_id`. * Message Processing Updates: The `_process_messages_and_statuses` method is updated to accept a consolidated `message_data` dictionary and apply it directly to the account return. * State Safeguards: A new safeguard (`action_reset_2_states`) prevents the resetting of an EC Sales return if it has already been accepted by Digipoort.
This update fixes inconsistencies in string sorting across different languages, ensuring accurate ordering for users in various locales. The new `localeCompare` function provides a locale-sensitive sorting method, addressing issues with default string comparisons and improving overall user experience.
Original PR description
Alphabetical order differs from one language to another. For example, in Estonian, Z comes after S and before T. This means that the order of strings displayed to the end users needs to be adapted…
Alphabetical order differs from one language to another. For example, in Estonian, Z comes after S and before T. This means that the order of strings displayed to the end users needs to be adapted depending on the current locale. This commit introduces the `localeCompare` utility function, which allows comparing two strings in a locale-sensitive way. ### What's wrong with the default behavior of `Array.prototype.sort`? `Array.prototype.sort` compares strings according to the UTF-16 code unit values of their characters. This results in behaviors that may not be what the end user expects. For example, "Zebra" is sorted before "apple", as uppercase letters come before lowercase letters in the ASCII table. "Élise" is not grouped with "Elise", and two same accented letters with different normalization forms aren't considered to be equivalent. ### Why not just use `String.prototype.localeCompare`? - Our `localeCompare` uses `user.lang` by default, which the string method doesn't - Our `localeCompare` comes with sensible defaults, such as sorting numbers based on their numerical value rather than their position in the ASCII table (i.e. "User 9" should come before "User 10000") - Our `localeCompare` always reuses the same instance of `Intl.Collator`, sparing the theoretical cost of instantiating it every time. Community: https://github.com/odoo/odoo/pull/264047
Resolved issues and error corrections
This update addresses a critical issue where Odoo transactions could leave incorrect tax records with Avalara. By committing Avalara's actions after the initial Odoo transaction, we prevent 'ghost' invoices and ensure accurate tax reporting. Accountants will now receive alerts if issues arise, allowing for quick resolution.
Original PR description
Some flows post an invoice and then perform additional work that may fail or at least delay the database commit (e.g. `_cron_post_process()` on `payment.transaction`). This extra work can raise…
Some flows post an invoice and then perform additional work that may fail or at least delay the database commit (e.g. `_cron_post_process()` on `payment.transaction`). This extra work can raise standard Odoo exceptions, and even without them, concurrent transactions or database deadlocks are possible. The invoice is committed on Avalara's side within `_post()`, so a later rollback of the Odoo transaction leaves a committed ghost invoice on Avalara's side. Accountants need to find these and manually void them to stop Avalara from filing incorrect tax returns. To avoid this, we move the Avalara commit into a postcommit hook. Since `account_external_tax` already calls `_get_external_taxes()` just before `_post()` to calculate taxes, the postcommit call is unlikely to fail. If it does, we log an activity on the invoice to notify the user, who will then need to resolve it manually (either by cancelling on the Odoo side and retrying, or by recreating the entry directly in the Avalara portal). opw-6192702
This update resolves a technical error that prevented users from generating balance sheet comparisons correctly. The fix ensures that date types are consistently handled, allowing the comparison feature to function as intended. This improves the reliability of balance sheet reporting.
Original PR description
Step to reproduce - Install the accountant module. - create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it - Navigate to Accounting > Report > Balance Sheet - Click the…
Step to reproduce
- Install the accountant module.
- create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it
- Navigate to Accounting > Report > Balance Sheet
- Click the `Comparison` smart button and set `Previous Period` to `2 periods`.
Observation:
- we face a traceback
``` File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5739, in _get_annotations
period_date_from = self._adjust_date_for_joined_comparison(options, period_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5695, in _adjust_date_for_joined_comparison
return min(period_date_from, comparison_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'datetime.date' and 'str'
```
Cause:
- `_get_period_dates` return string in case we have date which falls in
`custom_range_match`, when `get_report_information` is called, while
`period_date_from` is of type date
- hence there is mismatch between types
Fix:
- `_get_period_dates` is supposed to return date object always, hence fixed the
return type in case we have match for custom range
opw-6185629
Forward-Port-Of: odoo/enterprise#116350This update simplifies a confusing error message related to GST registrations, specifically for businesses using multiple GST numbers within the same organization. The new message clearly prompts users to verify the connection between their GST username and number, reducing support requests and improving the user experience. This change enhances the reliability of the system for businesses managing multiple tax registrations.
Original PR description
Users operating with multiple GST registrations (GST-wise branches/companies) could encounter a misleading error when the GST username belonged to a different GST number within the same organization. Previously, the system raised an error directly received from the server: [AUTH4041] Invalid Parameter state-cd in request header This message was confusing and led to unnecessary support tickets and false reports, as the issue was actually a mismatch between GST username and number. The error message has been updated to be more explicit and user-friendly: Please confirm that <gst_username> is associated with <gst_number>. Additionally, refactored duplicated logic by extracting the common code into a single helper function and reusing it across all occurrences. task-6041510 Forward-Port-Of: odoo/enterprise#111115
This update resolves an issue where rapid actions triggered duplicate account return check records being created in the database. The fix prevents multiple simultaneous processes from attempting to create the same record, ensuring data integrity. This improves the stability and efficiency of the account reporting feature.
Original PR description
Issue -------------- When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to…
Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.
steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing
When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.
Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999). Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.
Logs to demonstrate the thread execution:
--------
```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
THREAD NAME: odoo.service.http.request.137360481711808 Thread ID: 137360481711808
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360481711808 -------------DATA PREPARING STAGE------------
Thread ID: 137360481711808
Thread ID: 137360481711808 RECORD EXISTING CHECK: None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
THREAD NAME: odoo.service.http.request.137360513177280 Thread ID: 137360513177280
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360513177280 -------------DATA PREPARING STAGE------------
Thread ID: 137360513177280
Thread ID: 137360513177280 RECORD EXISTING CHECK: None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
Thread ID: 137360481711808 DATA to_create: 168
Thread ID: 137360481711808 done process create
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
Thread ID: 137360513177280 DATA to_create: 168
Thread ID: 137360513177280 done process create
```
- OPW: 5917459
Forward-Port-Of: odoo/enterprise#114045This update corrects a technical issue that was causing errors in the MRP Work Order Kanban module. The fix ensures that JavaScript classes are correctly defined within the core MRP module, resolving a runbot error. This improves the stability and reliability of the work order Kanban interface.
Original PR description
js_class defined in mrp_workorder should have been defined in mrp. This solves runbot error 242288 Forward-Port-Of: odoo/enterprise#117036
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard BATCH/<TYPE>/000NN naming convention. The fix ensures batches are automatically named correctly, improving data consistency and reporting accuracy. This resolves a minor operational inefficiency.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320
Forward-Port-Of: odoo/enterprise#115809This update corrects a display issue where the 'Reconnect Bank' button appeared incorrectly when account online consent hadn't expired. The fix ensures the button only shows when a consent expiration date is present, preventing confusion and unnecessary actions. This improves the user experience and data accuracy.
Original PR description
Since this commit 375516ccfd20d3a969c532376d0ba9db195b35fd, the reconnect bank button is displayed when the account online link doesn't have consent expiration date, which is wrong, if the consent doesn't expire, we shouldn't display the button. Why this happens? Because we don't check if expiring_synchronization_date is falsy, we only check if expiring_synchronization_due_day <= 0, which is always true in this case, has the compute set 0 as a fallback value. no-task Forward-Port-Of: odoo/enterprise#117101
This update resolves a technical issue preventing proper display of the employee form within the South Africa (SA) localization. The fix ensures that the employee record view functions correctly for users in the SA region, improving data accuracy and usability. This resolves a previously reported problem impacting SA-based users.
Original PR description
this commit fixes the broken view of employee form in SA localization. task-6205661 Forward-Port-Of: odoo/enterprise#117027
This update resolves an error that prevented users from marking payslips as paid when the 'Include Unpaid' option was selected. The change ensures that the system correctly processes unpaid payslips, preventing a technical error and improving the reliability of the payroll reporting feature. This fix addresses a potential disruption to payroll processing.
Original PR description
Currently, an error occurs when a user attempts to mark a payslip as paid. **Steps to Reproduce:** - Install the `hr_payroll` module without demo data. - Go to `Payslips` and click on `New…
Currently, an error occurs when a user attempts to mark a payslip as paid. **Steps to Reproduce:** - Install the `hr_payroll` module without demo data. - Go to `Payslips` and click on `New Off-cycle`. - Create a record > `Compute` > `Validate`, and Pay. - In the wizard, enable `Include Unpaid` and select `CSV` mode. - Click `Mark as Paid`. **Error:** `UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value` The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. When the wizard is created from here [1], the default unpaid payslips are empty. In this case, the system assigns an empty set of payslips to process [2].and the rows variable is not defined because there are no payslips to work on, which raises the error [3]. This commit ensures that when the wizard is created, the matched unpaid payslips are passed to the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, similar to [4]. The unpaid payslips cannot be empty, as they always include the currently processed payslip. Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit ensures that the rows are created at the end from grouped payments. [1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809 [2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56 [3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97 [4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288 sentry-7436885639 Forward-Port-Of: odoo/enterprise#116787 Forward-Port-Of: odoo/enterprise#115090
This update optimizes the Odoo interface for smaller screens by removing the VoIP icon from the systray when it's not in use. This improves the overall user experience and reduces visual clutter, particularly on devices with limited screen space.
Original PR description
task-5079952
This update resolves a technical error that prevented the system from correctly identifying project documents when the designated folder was not specified. The fix ensures the system functions smoothly regardless of whether a folder is associated with a project, improving document retrieval reliability.
Original PR description
The `_compute_documents()` method was expecting that the `documents_folder_id` field was always set.
However, the field is not required and can be empty.
This is not an issue if the compute is called on a single record, but when called on a recordset with :
- A project with related folder with at least one document
- A project with `documents_folder_id` empty The compute will fail because it calls `startswith()` with a parameter that is `False`.
```python
File "/home/odoo/src/enterprise/19.0/documents_project/models/project_project.py", line 50, in <lambda>
document_ids = documents.filtered(lambda doc: doc.parent_path.startswith(project.documents_folder_id.parent_path))
TypeError: startswith first arg must be str or a tuple of str, not bool
```
Solution:
Check for project-related documents only if the dedicated folder is set.
Forward-Port-Of: odoo/enterprise#117066This update refines how Odoo automatically matches bank statements to invoices. Previously, it prioritized the closest date, which wasn't always accurate. Now, it only matches if there's a single bank statement prior to the statement line's date, ensuring more reliable reconciliation.
Original PR description
Before this pr, we decided that when there was multiple candidates, we would take the one closer to the date of the statement line but it is not always what we want. We decided to change that so that it would match only if there is one candidate prior the date of the statement line. Exemple: Invoice 1 the 10/06 and invoice 2 the 20/06 → Payment the 05/06 → no matching (0 before) → Payment the 15/06 → match with invoice 1 (only 1 before) → Payment the 25/06 → no matching (More than 1 invoice open before) task-6143809 Forward-Port-Of: odoo/enterprise#115888 Forward-Port-Of: odoo/enterprise#115284
This update resolves an issue where setting a maximum package weight in Sendcloud caused rate calculations to fail. The fix ensures that shipments are correctly split into packages based on weight limits, preventing errors when requesting shipping rates. This improves the accuracy of shipping cost estimations.
Original PR description
Issue ----- Putting a max weight on a package type causes getting a rate with Sendcloud to fail. Steps to reproduce ----- - Setup Mondial Relay using Sendcloud - Set a default package type with max…
Issue ----- Putting a max weight on a package type causes getting a rate with Sendcloud to fail. Steps to reproduce ----- - Setup Mondial Relay using Sendcloud - Set a default package type with max weight 2kg - Create a product with a 500g weight - Create a SO with the product - Add delivery - Sendcloud Mondial Relay - Get rate > Impossible to get a rate Cause ----- When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order. https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81 However, when making the rate call, we use the value returned by `_split_shipping` https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91 which is equal to the maximum weight of the package. This is blocking in some cases, like if - the real weight is 750g - the package max is 2kg - Sendcloud returns a shipping method for [500g;1kg] Asking a rate for this method & a 2kg package will fail (rightfully so). Solution ----- The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one. Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight. ----- Ticket: opw-5947199 Forward-Port-Of: odoo/enterprise#116909 Forward-Port-Of: odoo/enterprise#108315
This update fixes an issue preventing accurate translation exports from the web studio's interactive editor. The problem stemmed from a formatting error in template strings that caused incorrect code extraction. By removing problematic formatting, the system now correctly exports and applies translation messages, improving the overall translation workflow.
Original PR description
It seems that the Babel Javascript tokenizer is not able to correctly parse a template string starting with a backslash and a newline. This caused it to extract pieces of code coming after it. The code excerpts would be exported in the POT file, but not applied to the JS code of course. The original message was not exported though, so it was not possible to translate it. This commit rewrites the template string to not use a backslash and a newline. This way the string is properly extracted and the code after it is not. Change was introduced by this commit[^1]. [^1]: https://github.com/odoo/enterprise/commit/56a2d9c4c2cc655af0469038d4c483581ac78864 Forward-Port-Of: odoo/enterprise#116927
This update fixes a recurring issue where Odoo would repeatedly retry sending eTIMS transactions, leading to an error (924). The change improves reliability by intelligently handling network interruptions and ensuring that invoice numbers are correctly tracked, preventing duplicate attempts and improving data accuracy for Kenyan e-invoicing.
Original PR description
When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already…
When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists). For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry. For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing. opw-6105693 Forward-Port-Of: odoo/enterprise#115649
This update resolves an issue where the table number on the kitchen display was being cut off when the order title exceeded a certain length. This prevented kitchen staff from quickly identifying the correct table, leading to potential delays. The change has been reverted to ensure the table number is always fully visible.
Original PR description
**Steps to reproduce:** - Download the German language - Set the restaurant to QR + Ordering - Set the Service at Table, pay after each order - Set the language to German - Go to the Self and order…
**Steps to reproduce:** - Download the German language - Set the restaurant to QR + Ordering - Set the Service at Table, pay after each order - Set the language to German - Go to the Self and order something while the language is German - Chose table 12 - Go to the kitchen display - The title is truncated, meaning we can't see the table number **Why the fix:** If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display. We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number. Before: <img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" /> Afer: <img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" /> opw-6096111 Forward-Port-Of: odoo/enterprise#116594 Forward-Port-Of: odoo/enterprise#114859
This update resolves an issue where the barcode scanning feature wasn't accurately updating inventory quantities when scanning pack-in-pack items. The fix ensures that quantities are correctly recorded during inventory counts, improving the reliability of stock tracking. This resolves a problem preventing accurate inventory updates.
Original PR description
### Steps to reproduce: - In the settings enable "Packages" - Create a storable product A and put 1 unit in a package P in stock - Inventory > Products > Packages > open your package P - Set a parent…
### Steps to reproduce: - In the settings enable "Packages" - Create a storable product A and put 1 unit in a package P in stock - Inventory > Products > Packages > open your package P - Set a parent package PP as container - Inventory > Operations > Adjustments > Physical Inventory - Select you product line for A > Request a count (from the control panel button) - Enable Show Expected Quantity and confirm - Go to the barcode app > Count Inventory (1) - scan your parent package PP #### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false' ### Cause of the issue: When the Package scan is processed, we loop over all quants related to it: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617 And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423 This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627 Fix: We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133 Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom: https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54 opw-5864591 Forward-Port-Of: odoo/enterprise#116715
This update fixes a bug that occurred when users tried to reschedule marketing activities, specifically within automated campaigns. The change prevents errors related to missing parent information, ensuring campaign scheduling functions reliably. This improves campaign stability and reduces potential disruptions for users.
Original PR description
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the…
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the activities to occur some number of days after the other activity and save - Modify the child activity by changing the number of days after its parent that it should run and save - An error will be thrown **Issue:** The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line: `base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date` **Fix:** Prevent the activity hierarchy to be modified on started campaigns. We also change the indexing to avoid further out of range issue and properly default on the participant create value. Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could impact the behavior between test and actual executions. opw-5362978 Forward-Port-Of: odoo/enterprise#107556
This update resolves several issues within the AI Fields module, primarily related to error messages and how the AI agent retrieves and displays web sources. The fixes ensure more reliable AI functionality and prevent misleading error notifications for users.
Original PR description
This commit fixes the following bugs: - In 99f76c1, tools.py was moved from ai_fields module instead ai_fields_tools in the ai module. However, the 'odoo.addons.ai_fields.tools.UnresolvedQuery' error which is caught in _computeAiField method wasn't changed to reflect the new file path which made the error appear to the user instead of just being a toaster message. - When performing web_grounding, the URL citations are replaced by [WEB_SOURCE:<id>] to prevent LLM hallucinating sources during the agentic_loop. These placeholders are replaced again by the actual URLs before sending the responseback to the user. However, this wasn't done in the case of _get_direct_response when the web_grounding completion option was set to True and was only done if the custom web_search tool was used. This caused these placeholders to appear in AI Fields. task-6209766
This update resolves a visual flicker issue in the timesheet timer display, particularly when saving data. By validating record data before saving, the system avoids rounding errors that caused brief, distracting flashes. Additionally, the commit adjusts the visibility of the delete button to prevent a related flicker.
Original PR description
before: The timer value is rounded to the record, then the saving attempt is made. This makes the timer flicker to the rounded value for a split second if the saving operation failed (ex. missing data) after: The record is updated with the rounded value if the saving operation is valid. We check the record validity before saving or updating the record. --- task-6120567 Forward-Port-Of: odoo/enterprise#114502
This update fixes a potential issue where users could create multiple checks for the same tax return due to a delay in the system's data refresh process. The change implements a database constraint to ensure only one check is created per return, regardless of multiple clicks or delays, improving data accuracy and reliability.
Original PR description
It is possible to have duplicate checks in a return. To reproduce: delay the function refresh_checks by adding for example import time; time.sleep(5) in a fresh database, create the tax returns. while it's still loading (due to the delay), click on a tax return -> This will trigger refresh_checks again for that return and you end up with duplicate checks (see video attached) Obviously, this shouldn't happen The change replaces the python constraint with sql constraint disallowing the user from creating multiple checks for same return even when the user clicks multiple time in the case of a delay. task: 5951345
This update fixes issues with the Sign template list by preventing one-shot requests and obsolete versions from appearing. It ensures the list remains clean and accurate, improving the usability of reusable templates for users.
Original PR description
Fix multiple issues affecting the Sign templates list: - Hide one-shot sign request templates from the archived templates list. - Treat PDFs uploaded from external records as one-shot sign requests, instead of adding them to the active templates. - Exclude obsolete template versions from the templates view by archiving and hiding them when a template document is updated. This keeps the templates list clean and avoids mixing one-shot requests and outdated versions with reusable templates. task-5493551
This update resolves inaccuracies in the data used for calculating Belgian HR payroll through Prisma. Specifically, it addresses missing codes related to leave types (LEAVE280, LEAVE115, LEAVE231) and ensures accurate calculations for various work accident and occupational disease scenarios. This ensures payroll calculations align with Belgian regulations.
Original PR description
Issue: ---------------------------------------- Some prisma codes are wrong. Solution: ---------------------------------------- Change the data files. There are some subtilities that were not implemented: - LEAVE280: 0304 (if less than a year) and 0345 (if more) - LEAVE115: 0820 (Work accident) and 0830 (Occupational Disease) opw-6090081 Forward-Port-Of: odoo/enterprise#116808 Forward-Port-Of: odoo/enterprise#112949
This update streamlines the work order planning process by reordering and renaming menus for better usability. Specifically, the 'Plan MO' button has been added, and the Gantt chart now filters employee displays based on assigned work orders, resolving a previous issue of showing all employees. The update also restores previously removed views for enhanced planning options.
Original PR description
Some ui fixes for the new workorder planning Task: 6143389 Forward-Port-Of: odoo/enterprise#115477
This update resolves an issue where the CUFE (Contribution Fiscal Electronica) information wasn't appearing on invoices generated as PDFs for the CO_DIAN localization. The fix reordered the invoice PDF layout, ensuring this critical data is now correctly included. This ensures accurate reporting and compliance for CO_DIAN customers.
Original PR description
**STEP TO REPRODUCE** 1. Setup DIAN. 2. Create an invoice. 3. Send it to dian. 4. Notice the cufe doesn't appear on the pdf. This fix moves the CUFE div before the informations div. Before the fix, it was placed at the top of the xml which appears to not render starting from 19.2. opw-6182706 Forward-Port-Of: odoo/enterprise#116245
This update fixes a minor issue where the 'Plan' button appeared in the Gantt view even when no Sales Order Lines were available to plan. The change ensures the button only appears when there's a valid Sales Order Line to work with, streamlining the planning process and preventing unnecessary dialogs.
Original PR description
Steps to reproduce: === - Go to Planning → Gantt view. - Click on an empty cell where no Sale Order Line (SOL) exists. - Observe that the Plan button appears in the multi-selection toolbar. Issue: === The Plan button is shown even when there are no SOL to plan, and clicking it opens the planning form dialogue, which should not happen in this scenario. Cause: === The visibility of the Plan button relies solely on whether `onPlan` is defined. There is no built-in validation to check whether any SOL actually exists for the selected cell before exposing the 'onPlan' action. Fix: === Introduce a new reactive prop `hasAvailableSOL` and compute it before `onPlan` is used. The Plan button is now shown only when an SOL actually exists. task- 5163638 Forward-Port-Of: odoo/enterprise#99517
This update fixes an issue where the timesheet reporting incorrectly included public holidays from other companies, leading to inaccurate planned hour calculations. The fix ensures that only public holidays related to the employee's company are considered, improving the accuracy of the planning analysis report.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#117015 Forward-Port-Of: odoo/enterprise#116263
This update resolves a bug that prevented regular users from accessing sales order details, regardless of whether they were inter-company transactions. Previously, users would encounter access errors when validating sales orders, disrupting the sales process. This fix ensures all sales order information is accessible.
Original PR description
When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047
This update prevents the VoIP icon from appearing in the system tray on small screens when the user's VoIP configuration is incomplete. Previously, users without a valid configuration would see an error icon. Now, the icon is hidden, improving the user experience and preventing confusing error messages.
Original PR description
Avoid displaying the VoIP icon in the systray on small screens. There isn't much space in the systray, so we decided to hide the VoIP icon when it's not configured. Before this commit, if the user did not have a correct VoIP configuration (the user could not place or receive a call), the icon was still shown and clicking it produced an error message: "Oops! Something went wrong... with a blabla about the error." Now on small screens like a smartphone, we simply avoid displaying the icon if the user's configuration cannot handle calls. task-5079952
This update resolves an error that occurred when calculating overtime deductions for employees with specific filing statuses (beyond 'single' or 'jointly'). The fix ensures the system correctly handles a wider range of filing status values, preventing a crash. This improves the accuracy of overtime calculations for affected employees.
Original PR description
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter…
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs. Cause: ---------------------------------------- `l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)). When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56 Solution: ---------------------------------------- In the custom Python condition, we first check if the key is there. The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it. Also fixed indentation of test 069. opw-6129657 Forward-Port-Of: odoo/enterprise#116913 Forward-Port-Of: odoo/enterprise#115754
This update resolves several errors that could occur when the system processes NOTI files for Belgian payroll. The fix ensures accurate and reliable calculation of social security contributions, minimizing potential discrepancies and compliance issues. This improves the overall stability and accuracy of the HR payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#116871
This update resolves a technical error in the core payroll accounting tests. Removing a specific salary rule reference prevented test failures across multiple internationalizations. The change ensures consistent test execution and stability for all supported localizations.
Original PR description
`hr_payroll_account` common file test is used in several tests in several localizations. Adding a reference to a `l10n_be` salary rule is not valid and would trigger an error when running the tests in other localizations since no fallback is used. This commit removes the reference to the salary rule in the common file test and does not move it to `l10n_be` modules that depend on `hr_payroll_account` since the safeguard is not valid in the first case (the salary rule is only applied for `l10n_be_joint_committee_302`)
This update resolves a problem preventing accurate delivery status updates from Amazon through the Shiprocket integration. The team added specific carrier sub-category names (like Xpressbees) to the Amazon carrier mapping, which is essential for the integration to function correctly in India. This ensures reliable tracking of orders on Amazon.
Original PR description
Fixing Amazon delivery status update failure via Shiprocket integration. See also: - Community PR: https://github.com/odoo/odoo/pull/262751 OPW:5959762
This pull request addresses a technical issue within the Odoo Enterprise payroll module. Specifically, a misconfigured reference has been removed, ensuring accurate accounting and reporting. This resolves a previously identified problem impacting payroll calculations.
Original PR description
follow-up task-6036647
This update ensures that all order lines, including those with zero quantity, are retained when an order is validated. Previously, zero-quantity lines were removed, potentially leading to incomplete order records. Now, managers have a complete view of the order history and can accurately track all items sold.
Original PR description
When validating an order, orderlines with a zero quantity were being removed. This could result in creating an order without any lines. By keeping zero-quantity lines, an order always retains its context and managers can see exactly what happened. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6185664
This update corrects a visual issue in the Project Gantt view where flexible employees were incorrectly marked as unavailable during weekends and off-hours. The fix ensures that flexible employees only appear grayed out for their approved leaves and public holidays, providing a more accurate representation of their working times.
Original PR description
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out…
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out Current Behavior --- Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view. Expected Behavior --- Flex employees should have no grayed-out days except approved leaves and public holidays. Issue --- When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered. Fix --- Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`. Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 task - 5063071 Forward-Port-Of: odoo/enterprise#117100 Forward-Port-Of: odoo/enterprise#113247
This update fixes an issue where secondary colors weren't being applied to labels on Mexican pro-forma invoices. The change ensures that all labels, including 'Usage:', consistently use the configured secondary color, improving invoice presentation and compliance. This resolves a visual inconsistency impacting the user experience.
Original PR description
Issue: When configuring a secondary color in the document layout, labels of Mexican-specific fields in the pro-forma report remain black instead of using the configured color Cause: In the view…
Issue:
When configuring a secondary color in the document layout, labels of Mexican-specific fields in the pro-forma report remain black instead of using the configured color
Cause:
In the view `report_saleorder_document_proforma`,
the labels in the information block are defined using `<span>` elements, which do not inherit the styling applied to labeled fields
As a result, the `secondary_color` is not applied
One option is to use strong:
The file `asset_styles_company_report.scss` specify that secondary color should be used for a specific company
when it's a strong inside an informations block
```scss
.o_company_4_layout #informations strong {
color: #ff0000;
}
```
But to be more stable, we can just specify the color style
Steps to reproduce:
- Install `l10n_mx_edi_sale` and `sale_management` with demo data
- Switch to company ZAPATERIA
- In Settings > Sales, enable `Pro-Forma Invoice`
- Go to Settings > Configure Document Layout
- Change the secondary Color (e.g., to red) and save
- Create a new Sale Order (Customer: INMOBILIARIA CVA)
- Click on `Send PRO-FORMA Invoice`
- Open the generated invoice and check `Usage:` label's color The label should use the `secondary_color`, consistent with other fields (e.g., `Issued Date`)
opw-6145489This update fixes a frustrating issue where clicking 'Discard' in the Sign Template would cause the page to reload and flicker. Now, the discard process happens directly within the existing sign template, providing a smoother and more reliable user experience. This eliminates unnecessary page reloads and improves efficiency.
Original PR description
Before this commit, clicking Discard in Sign Template reloaded the action/PDF iframe, which caused flicker. The discard flow was also more complex than needed and field normalization was noisy. After this commit, discard now happens in place: we fetch fresh sign items/radio sets, reset fields inside the existing iframe, and keep the page mounted with no reload. task-6121560 Forward-Port-Of: odoo/enterprise#116766 Forward-Port-Of: odoo/enterprise#113853
This update fixes an issue where Swedish financial data files were not importing correctly, resulting in incorrect account names. The fix ensures the data is interpreted using the correct CP437 encoding, accurately displaying Swedish characters like 'Ö' in imported financial records.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408 Forward-Port-Of: odoo/enterprise#117032 Forward-Port-Of: odoo/enterprise#116722
This update addresses a persistent issue with the General Ledger report, ensuring it consistently displays accurate cumulated balances. Improved testing procedures have been implemented to prevent future disruptions. This enhancement focuses on reliability and data accuracy for financial reporting.
Original PR description
I hate this feature, it's always broken. Now it's tested so it shouldn't break as easily.
This update resolves a visual bug where the timesheet dropdown menu was hidden behind the sticky 'Total' footer. The fix adjusts the layout to ensure the dropdown is always visible when editing timesheets, improving user experience. This change prioritizes correct display of critical timesheet data.
Original PR description
**Steps to reproduce:** - Open Timesheets > Assistant menu. - Click a row near the bottom of the "My Timesheets" section to open the edit form. - Open the Project or Task dropdown menu. **Issue:** The dropdown menu is hidden underneath the sticky "Total" footer. This happens because both the edit form and the footer share the same stacking context priority. **Fix:** Update .o_activitywatch_sync_timesheet_edition_form to manage its own stacking context. It now defaults to z-index: 1 to ensure standard scrolling behavior, but jumps to z-index: 3 on hover or focus-within. This ensures that when a user interacts with the form, its dropdowns correctly float above the sticky footer. task-6105369 Forward-Port-Of: odoo/enterprise#113377
This update ensures that accountants are only notified about account tax changes within the correct company. Previously, the system incorrectly alerted all accountants, leading to unnecessary notifications and potential confusion. This change improves efficiency and reduces noise for accounting teams.
Original PR description
The original improvement could notify every accountant in the database. opw-6192702
Features or functions removed from Odoo
This update removes alarms from all-day calendar events by default. Previously, these events displayed reminders in the system tray, which wasn't the intended behavior. Now, alarms are only added if explicitly set, streamlining the calendar experience for users.
Original PR description
Removing alarms from all day events by default as they're not supposed to be present in the systray meetings reminders for the day by default, but only if explicitly set. Task-6067427
Code cleanup and technical improvements
This update simplifies how the Documents module interacts with related records. The previous custom widget is no longer needed due to recent changes allowing direct configuration of default views for Many2One fields. This streamlines the system and reduces potential complexity.
Original PR description
Historically, standard Many2One fields defaulted to opening the form view. To bypass this and open a folder's Kanban or List view, the Documents module relied on a custom documents_folder_many2one widget. A recent refactoring addressed this limitation, allowing the default target view to be configured directly on standard Many2One fields. Changes: - Rename get_formview_action to get_record_default_action: Updated the method name in ir_ui_view.py to accurately reflect that M2O fields frequently open views other than just form views. - Remove documents_folder_many2one: Deleted the now-redundant custom widget and replaced it with the standard Many2One widget across the Documents module and its bridges. - Clean up _get_access_action: Removed the override in Documents to eliminate redundancy, leveraging the newly renamed get_record_default_action instead. Task-6068437
This update replaces partner data with user data within member-related flows across several Odoo Enterprise modules. This change enhances data accuracy and simplifies user management, aligning with best practices for user identification and access control. It impacts modules like Frontdesk, WhatsApp, and AI Livechat.
Original PR description
\* = ai_livechat, frontdesk, whatsapp Enterprise counter-part. task-5946571 https://github.com/odoo/odoo/pull/249517