Daily updates from Odoo
Thursday, April 2, 2026
359 changes
2 changes
New functionality added to Odoo
This update adds tests to the Timesheet Dashboard feature, ensuring that the correct data is consistently loaded each time a user accesses the sheet. These tests enhance reliability and data accuracy for sales teams using the dashboard.
Original PR description
add tests for the timesheet dashboard sheet selection to ensure that the right sheet is loaded each time --- task-5956339
Resolved issues and error corrections
This update resolves an issue where removing an EPD line in the bank rec widget incorrectly removed associated invoice lines with tax. Now, only the EPD line and its corresponding tax line are properly removed, ensuring accurate bank reconciliation reporting. This improves data integrity and reduces potential reporting errors.
Original PR description
When removing an EPD line in the bank rec widget, if the invoice line added to the statement line contained a tax, the invoice line was removed aswell. Now, only the EPD line and its tax line are removed. no-task Forward-Port-Of: odoo/enterprise#110669 Forward-Port-Of: odoo/enterprise#110514
6 changes
New functionality added to Odoo
This pull request updates the .weblate.json files to include translations for additional Odoo modules. This ensures that all modules within the Enterprise version are properly localized for international users, improving the overall user experience and supporting global expansion.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#112678 Forward-Port-Of: odoo/enterprise#111141
Resolved issues and error corrections
This update fixes an issue where the Mod 347 BOE export incorrectly used 'X' as an indicator for declarations. The change ensures the correct 'C' for complementary and 'S' for substitute declarations are used, aligning with AEAT specifications and preventing file rejection by the tax authority. This ensures accurate tax reporting for Spanish companies.
Original PR description
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the…
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company` - Navigate to Accounting > Reporting > Tax Report - From the smart button, select `Report: Tax Report (Mod 347) (ES)` - Download the BOE file using the dropdown. - In the wizard: - Enable `Substitutive Declaration` or `Complementary Declaration` - Set `Previous Report Number` (e.g., 123456789) - Click `Generate BOE` - Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required) **Observation:** AEAT does not recognize 'X' as a valid indicator for substitutive or complementary declarations and interprets the file as a standard return. **Root Cause:** At [1], the BOE Mod 347 generation writes 'X' for both substitute and complementary declarations. **Fix:** This commit ensures the file contains correct indicators: - 'C' for `complementary declarations` - 'S' for `substitute declarations` This aligns Modelo 347 with AEAT specifications and ensures consistency with the implementation of Modelo 349 at [2]. Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html [1]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062 [2]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491 opw-6048711 Forward-Port-Of: odoo/enterprise#112566
This update resolves a technical issue where reports were loading indefinitely, causing performance problems. The fix ensures reports stop loading when the component is destroyed, preventing memory buildup and improving system stability. This enhances the overall responsiveness of the reporting feature.
Original PR description
The preloading of sections would never stop, this is an issue since this would prevent the garbage collector from collecting this big class and all it's objects. We fix this by making sure to stop the reploading when the component is destroyed. It's important to do it this way rather than clearing the timeout as the destruction could happened when the report is loading so the timeout would be unset and a new one would be started. Forward-Port-Of: odoo/enterprise#112662 Forward-Port-Of: odoo/enterprise#112628
This update fixes a testing issue in the Italian tax report XML export process. The tests now correctly include required data for validation, preventing failures and ensuring accurate report generation. This improves the reliability of the tax reporting feature.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544 Forward-Port-Of: odoo/enterprise#112629
This update fixes a confusing issue in Odoo's Web Studio mobile interface. Previously, users saw a purple pill on action buttons, leading to accidental clicks instead of button presses. This change removes the pill, streamlining the mobile experience and improving usability.
Original PR description
Steps: - Install `web_studio` - Add an approval rule to any action in any form view (example preview button) - Open this form view - You will have a purple info pill in every action button in the form view This can be confusing for people wanting to click on the button on mobile but instead, they click on the purple pill + we don't even want this opw-5911667 Forward-Port-Of: odoo/enterprise#111770
This update resolves an issue with the Google Gemini integration by standardizing the API base URL. This change ensures consistent communication with the OpenAI-compatible model, improving the reliability and performance of the AI features within Odoo Enterprise. It simplifies the integration process and avoids potential compatibility problems.
Original PR description
This change hardcodes the api version at the base url instead of hardcoding in endpoint url and fixes Google Gemini OpenAI-Compatible base url
43 changes
Enhancements to existing features
This update restores a previous design style (M3.1) for certain views, focusing on a more consistent look and feel across Odoo. It reverts changes made for a previous feature and adapts the template as needed. Further work is needed to ensure icons are consistently visible.
Original PR description
In some view outside the groups we want the boxes anyway so we introduce the o_outlined class. This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * clipboard: more refactoring needed in some case icons are not visible * M3: some class are still present task-6054024 Co-authored-by: Romain Estievenart <res@odoo.com>
This update adds a warning system to alert users when DIMONA payroll declarations don't align with contract versions or have mismatched categories. This ensures accurate reporting for Belgian payroll, reducing potential errors and compliance issues. The change improves the reliability of payroll data.
Original PR description
add warning when DIMONA declarations don't cover the same date ranges as contract versions or when dimona category doesn't match between periods and versions. Task Id: 5951989
This update simplifies the payslip summary widget for pay officers by dynamically hiding worked day lines for certain pay structures (like bonuses). This change reduces confusion and streamlines the information presented, making it easier for pay officers to review payroll data.
Original PR description
In order to improve the experience of pay officers and prevent any confusion, some pay structures will not require the display of individual work day lines such as bonuses. Accordingly, the worked day widgets will be dynamic. Task: 6030842 Forward-Port-Of: odoo/enterprise#111470
This update standardizes the formatting of key reports related to French tax filings (2033C and 2033D). Specifically, section titles have been adjusted to align with a preferred style, enhancing clarity and consistency for reporting. This ensures accurate and streamlined tax reporting.
Original PR description
This commit updates the section titles for the 2033D report to make them consistent with the 2033C. The preferred format is to use a dash. No task ID
This update streamlines the HR payroll reporting by removing outdated views and actions. A key change improves the default measure in the payslip line pivot, now showing 'total' instead of 'amount' for more accurate reporting.
Original PR description
This removes a few views and actions not used anymore. It also changes the default measure for the pivot view of payslip lines from amount to total which is way more relevant. Task: 6032743
This update adjusts Odoo's payroll processing to correctly handle company executives classified under Joint Committee 999 (JC999) in Belgium. It excludes these employees from standard Belgian payroll obligations, simplifying reporting and ensuring compliance with specific legal requirements. Key changes include filtering data for Dimona, social reports, and holiday allocations.
Original PR description
Company executives under Joint Committee 999 (JC999) are not classified as travailleurs under Belgian law, so standard Belgian payroll obligations do not apply to them. This PR introduces the…
Company executives under Joint Committee 999 (JC999) are not classified as travailleurs under Belgian law, so standard Belgian payroll obligations do not apply to them. This PR introduces the necessary exclusions across Dimona, holiday attests, termination flows, social reports, and paid holiday allocation. A new l10n_be_egov3_code computed field (related to l10n_be_joint_committee_id.egov3_code) is added on both hr.employee and hr.employee.departure to expose the JC code in views invisibility conditions. Dimona: No declaration should ever be sent for a JC999 employee. _compute_l10n_be_dimona_next_action short-circuits to False for JC999 versions, and switching a version to JC999 via write() automatically clears the worker code, dimona category, and next action. All Dimona-related UI elements are hidden for JC999: - "Check Dimona" header button - Dimona relation stat button - Dimona next action pill/widget - ONSS group (worker code + dimona category fields) - Dimona debug group End-of-contract: for JC999 on both the employee form and the departure wizard it is shown the standard view bypassing the Belgian-specific termination fee flows. DMFA, social reports, and paid holiday allocation: JC999 payslips and contracts are filtered out of the DMFA XML generation, the social balance sheet (contract list, payslip search, and end-of-period contract list), the social security certificate payslip query and the query in the paid leave allocation wizard.
This update optimizes the Web Studio interface by preventing certain widgets from being used in record set views (like lists). Using these widgets in these views causes significant performance slowdowns. This change improves overall Odoo performance and stability.
Original PR description
Certain widgets such as the form status bar widget are designed to be used on single records. While, it is technically possible to use these widgets on record set views such as the list view, this leads to massive performance issues even for basic selection fields. This commit adds a widget blacklist organised by view type. This allows to blacklist some widget types for some views which are still available in debug mode. task-5194320
Task: 5973879
Original PR description
Task: 5973879
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Original PR description
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
Original PR description
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
task-6020137
Original PR description
task-6020137
No description available.
Resolved issues and error corrections
This update refactors internal code references (t-ref) to align with the upcoming Owl 3 migration. The changes ensure compatibility with the new system semantics and address previously overlooked or recently added references within several Odoo Enterprise modules. This is a necessary step to ensure a smooth transition to the next version.
Original PR description
To prepare the owl 3 migration, we need to open the t-ref directive to the new semantics. This commit fixes a few t-ref that were forgotten or recently added in Odoo Enterprise.
This update resolves a validation error that occurred when generating offers due to a recent change requiring a 'version_id' field. The fix ensures that this 'version_id' is now correctly passed during the salary simulation process, allowing offer generation to proceed smoothly.
Original PR description
-**ISSUE**: Since the "version_id" field in hr.payslip.worked.days model became a required field, the validation error exists. -**FIX**: "version_id" is passed inside the salary simulation payslip. Forward-Port-Of: odoo/enterprise#112602
This update resolves an issue where adding recurring prices to subscription products with multiple companies resulted in an error. It also fixed a bug preventing recurring plans set with a company from appearing in the recurring prices list. The change ensures proper company handling within the subscription product setup.
Original PR description
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their…
## Issues When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears. Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab. ## Steps to reproduce 1. Install *Subscription* (`sale_subscription`) 2. Create a second company 3. Create a subscription product and set a company in the *Company* field (`company_id`). 4. In the *Recurring prices* tab, add a line (any recurring plan, any price) 5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_** For the second issue, after the same 3 first steps: 1. Create a *Recurring Plan* RP with its *Company* field set to the current company 2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP 3. **The Recurring plan RP is missing from the list of available plans.** ## Cause When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases. https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26 By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`: https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173 opw-5981629 opw-6051978 Forward-Port-Of: odoo/enterprise#109403
This update ensures that XML export tests correctly validate tax reports for Italy (l10n_it). A recent change in testing procedures now requires the inclusion of a tax code, which this commit adds to the test setup. This resolves a validation failure and ensures accurate report generation.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544 Forward-Port-Of: odoo/enterprise#112629
This update resolves an issue where confirming quantities of archived products through the barcode app would cause a crash. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#112616 Forward-Port-Of: odoo/enterprise#109204
This update restores the user-friendly display of VoIP call durations, showing times like '9m 12s' instead of numeric values. A previous change attempted a different formatting approach but caused issues, leading to a revert. A new test tour has been added to ensure the duration format remains consistent across views.
Original PR description
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using…
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using the framework util. For the views, the framework field options using that framework util was not possible to use to have the desired format. Instead, the existing "duration_human_readable" field, computed from "duration", which existed already as it is needed in some python text, was used. Commit [2] broke the views format a few days later. That commit refactored the framework util and field options. Doing so, the softphone UI computation was adapted, correctly. However, the views was switched back to using the default "duration" field with the numeric option, probably because of an ignored conflict. This commit restores the use of "duration_human_readable", as the field util still does not allow to have the wanted format. Indeed, switching off the "numeric" option would show 2m 3s as 0h 2m 3s, which we do not want. We could solve that by changing our DB field to be in seconds instead of hours though, but that would be a bigger change to decide. Still, using "duration_human_readable" which is needed either way makes a lot of sense. This commit adds a tour that checks the format does not change in views whatever field is used. [1]: https://github.com/odoo/enterprise/commit/52e24578700fffde05d9d8f767258aea5f185e8d [2]: https://github.com/odoo/enterprise/commit/fa9329a08eb78c6a9cacfd31a9a1f4bc9e9b6030 Related to task-5951753
This update ensures that installment payment terms on customer invoices generated for Peru (l10n_pe_edi) are correctly ordered by their maturity date. Previously, invoices generated with multiple installments could have a mixed-up XML format due to the order in which payment terms were created. This fix guarantees accurate and compliant UBL documents for Peru.
Original PR description
**Steps to reproduce:** * Install `l10n_pe_edi`. * Set SUNAT as the signature provider. * Create a customer invoice. * Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10…
**Steps to reproduce:**
* Install `l10n_pe_edi`.
* Set SUNAT as the signature provider.
* Create a customer invoice.
* Select a payment term with multiple installments (e.g. 50% (15 days) / 30% (10 days) / 20% (5 days)).
* Confirm the invoice and generate the EDI standard UBL document.
**Observed behavior:**
* The XML `<cac:PaymentTerms>` instalment nodes (Cuota001, Cuota002, etc.) are ordered according to the database insertion order of the receivable lines.
* If the payment term lines are created in a non-chronological order, the installments in the XML mix up the `Cuota` ID, amount, and `PaymentDueDate`.
**Cause:**
* `_add_invoice_payment_terms_nodes` iterates over `invoice.line_ids` to generate the installments, but does not sort the receivable account lines by their `date_maturity`.
**Fix:**
* Explicitly call `.sorted('date_maturity')` on the receivable lines before generating the `invoice_date_due_vals_list`.
opw-6035589
Forward-Port-Of: odoo/enterprise#112698
Forward-Port-Of: odoo/enterprise#112162This pull request reverts a previous change that was causing issues with email notifications related to contract salaries within the Enterprise module. The change was rolled back to restore the original functionality and prevent disruptions to payroll processes. This ensures accurate and timely salary communications.
Original PR description
Revert https://github.com/odoo/enterprise/pull/111815 Forward-Port-Of: odoo/enterprise#112632
This update clarifies how the annual leave provision is calculated in the payroll system. Previously, it triggered prematurely and displayed confusing rates. Now, it’s applied only to employees after their first year and uses a clear monthly working days calculation, ensuring accurate reporting.
Original PR description
## Before: - Annual Leave Provision showed a confusing rate value. - It could be triggered too early around the first-year period. - “Excluded from Net” was checked. ## After: - Annual Leave Provision is applied only for active employees after one year. - The amount is based on monthly working days, while the displayed rate stays clear at 100%. - “Excluded from Net” is unchecked. Task-6033568 Forward-Port-Of: odoo/enterprise#111225
This update resolves an issue where sales orders with upsells lacking recurring products couldn't be previewed. The change allows this functionality, aligning with existing constraints within the system. This ensures a smoother sales process for users.
Original PR description
When you have an upsell that does not have recurring products, you cannot preview the SO, so we've allow it in this specific case as it is allowed by the constraint on the model Forward-Port-Of: odoo/enterprise#112453
A bug was preventing demo accounts from fully connecting within the Odoo Enterprise system. This fix temporarily resolves the issue by allowing users to set the business type to 'individual' as a workaround. This ensures users can now properly test the demo feature until a permanent solution is implemented.
Original PR description
Step to reproduce: - Click on Connect (demo) - The accounts stay Restricted (even after 5m) This is due to the requirement `company.verification.document` which is present as a pending_verification even when no document is given. Giving it a document such as `file_identity_document_success` which should "marks that document requirement as satisfied" also doesn't work. A work-around is to set the business type to individual since they dont have this requirement. This is a temporary fix, as we want to keep a flow similar to what would have been done in reality. But this is preventing users from testing the feature in 19.0 up to master. Forward-Port-Of: odoo/enterprise#112612
This update resolves an issue where products were incorrectly being deleted from the website generator when a product template only had one associated product. The fix ensures that product records are only removed when intended, maintaining data integrity and preventing potential data loss.
Original PR description
product.product records were being removed when they should not have been in the case that the product.template only has one product.product record. This commit fixes this issue by accounting for the case where there is only one product.product record. Forward-Port-Of: odoo/enterprise#112519
This update resolves a crash that occurred when printing DIAN support documents. The fix prevents a system error by ensuring that report sections are only generated when a valid DIAN attachment exists, improving the printing process for users. This ensures accurate and reliable printing of these important documents.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#109912 Forward-Port-Of: odoo/enterprise#108645
This update resolves a technical issue related to how binary data is handled in the l10n_be_reports module, specifically impacting Belgian VAT reporting. The change ensures accurate processing of financial data by aligning with a recent update in Odoo's data handling system. This fix improves the reliability of VAT reports for our Belgian clients.
Original PR description
update the intervat code to fit with the new BinaryValue, see https://github.com/odoo/enterprise/pull/104714 no-task
This update resolves an issue where AI conversations within the Odoo Enterprise app were sometimes failing to connect properly with agents. The fix clears the AI conversation correspondent when it resolves to the current user, preventing unwanted self-chat behavior and ensuring agents receive correct communication. This improves the reliability of the AI assistant.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112622 Forward-Port-Of: odoo/enterprise#111736
This update resolves an issue that prevented users from creating contracts when a working schedule had zero hours assigned. The fix prevents a division-by-zero error during hourly wage calculation, ensuring contract creation can proceed smoothly. This improves the reliability of the payroll module for Australian companies.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#112450 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where splitting shifts within a single day resulted in duplicated and incorrect timeframes. Previously, the system forced shifts into standard working hours, causing problems when splitting shifts on a daily basis. Now, shifts are split accurately at the requested time, ensuring correct scheduling.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243 Forward-Port-Of: odoo/enterprise#105991
This update resolves a technical issue related to the EU IoT scale driver. As part of the fix, the checksum associated with the scale certification process has been updated to ensure data integrity and compliance. This change is a routine maintenance task.
Original PR description
As we fixed the scale driver, we need to update the checksum. see odoo/odoo#256816 Forward-Port-Of: odoo/enterprise#112594
This update resolves a crash issue that occurred when starting pay runs through the warning dashboard. The change replaces a problematic context variable with a more reliable structure ID, ensuring pay runs can consistently begin. This improves the overall stability and usability of the payroll system.
Original PR description
Use structure_id instead of the removed schedule_pay context to avoid crashes when starting a pay run from the warning dashboard. task: 6067447
This update resolves an issue where the attendance step in the payrun flow wasn't correctly displaying on smaller screens. The change ensures the attendance step view adjusts properly when the screen size changes, improving the user experience and preventing errors during payrun creation.
Original PR description
. Fix Attendance step view on the payrun flow task-6085093
This update resolves an issue where scanning packaging barcodes didn't correctly associate with related lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes are properly linked to lots during scanning, improving the accuracy of stock management.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#110847 Forward-Port-Of: odoo/enterprise#98701
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu p
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#111240 Forward-Port-Of: odoo/enterprise#109012
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Original PR description
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a s
Original PR description
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a safety check to the fixed_term conditional logic. - The filtering of anterior_versions is now only executed if both fixed_term is True AND contract_date_start is populated. task-6060255
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added
Original PR description
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added in hr_payroll_attendance Task: 6036545
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.re
Original PR description
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.revId and forced the Record component (t-key="state.revId") to be destroyed and recreated. This caused a re-render cascade that destroyed AttendanceActionHelper mid-onWillStart, while its async calls (hasGroup, orm.call) were still in flight. **Solution:** In PayRunMixin, guard updatePayRun() so it only fires when payRunId actually changes, instead of on every render. This prevents unnecessary re-render cascades that were destroying AttendanceActionHelper. **Task: 5972786**
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uni
Original PR description
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uninstall Accounting + Invoice - Set company language to Hebrew - Install accounting (which will install Invoice) Community PR: odoo/odoo#253737 Ticket [link](https://www.odoo.com/odoo/project.task/6001568) opw-6001568
Code cleanup and technical improvements
This update optimizes how Odoo handles the rollback of cron jobs, specifically related to progress tracking. The changes improve the efficiency of these background processes, reducing potential delays and ensuring smoother operation of key business features like order processing and subscription management. This is a routine maintenance update focused on internal performance.
Original PR description
https://github.com/odoo/odoo/pull/257066
Miscellaneous changes
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also ad
Original PR description
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also add some tests related to the data injected in the VSME/CSRD PDF report. task-5882219
4 changes
Resolved issues and error corrections
This update fixes an issue where users were incorrectly prompted for passwords on encrypted PDFs that didn't actually require them. The system now correctly checks if a password is needed before attempting a download, ensuring a smoother and more reliable experience for users accessing signed documents. This resolves a previous bug that blocked downloads.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5400441 Previously, if a user went to download a document, we would check if it was encrypted. If so, we would redirect to ask for a password. But the problem with that is, not all encrypted documents require passwords. In that case, we would ask for a password when none existed, thus blocking the user from downloading the document. Now we check if a password is required to access the document instead of whether the document is encrypted. That way, we won't redirect to ask for a password when there is no password. Docs about PdfFileReader's `decrypt` method, before and after a major change: https://pypdf2.readthedocs.io/en/2.3.0/modules/PdfReader.html https://pypdf2.readthedocs.io/en/2.12.0/modules/PdfReader.html Forward-Port-Of: odoo/enterprise#102602
This update resolves a bug in the Belgian payroll module that prevented time off requests for Laurie Poiret from being correctly processed. The fix ensures demo data uses the correct company calendar, allowing the Payroll app to accurately reflect time off balances. This improves the reliability of payroll calculations.
Original PR description
### Issue: Laurie Poiret has a calendar belonging to another company. This causes issues in the Payroll app. ### Steps to reproduce: - On runbot, switch to a Belgian company - Create a time off for Laurie Poiret, validate it - In Payroll > Work Entries you can see that the time off is not considered ### Cause: The `resource.calendar.leaves` of the time off belongs to another company, which prevents it from being fetched. This is because at its creation it takes the company of the given calendar. ### Solution: Fix the demo data so that Laurie Poiret has a calendar from the Belgian company. Same for Max Durand. opw-6053558
This update resolves a crash that occurred when users attempted to split AES-encrypted PDF files within the Documents module. The fix involves adding error handling to gracefully manage missing dependencies, ensuring the Documents module functions reliably when processing PDFs. This prevents disruptions for users relying on this core functionality.
Original PR description
Currently, an error occurs when splitting an AES-encrypted PDF file in the Documents module if the `PyCryptodome` dependency is not installed. **Steps to Reproduce:** 1. Install Documents module. 2. Upload the sample PDFs in Documents. 3. Split the PDF. Sample File: https://drive.google.com/file/d/1OLl863YZ-QZtzdTpItsDgS7J4y6gsZx5/view?usp=drive_link **Error:** `DependencyError - PyCryptodome is required for AES algorithm` This commit wraps the `OdooPdfFileReader` inside a try-except block to handle any exceptions raised during PDF reading. Ref: https://github.com/odoo/odoo/blob/d2966d5f3624a64bf9740126b2854628b204d2a9/addons/account/models/ir_attachment.py#L56-L62 sentry-7272118595
This update resolves an issue where Documents actions weren't appearing correctly when a language was deactivated. The fix ensures that only the currently active language is used when embedding actions, preventing errors and improving the user experience. This ensures consistent functionality across all supported languages.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Activate a second language (e.g., Arabic `ar_001`). 3. Deactivate the Arabic language by active toggle. 3. Go to the Documents app and open a folder 4. Set the 'Action on Select' (cog menu) to embed a server action. Issue: - Action is not selected. Cause: - The method `action_folder_embed_action` uses `_get_stored_translations`, which returns translations for inactive languages as well. This causes an `Invalid language code` error Solution: - Filter the languages retrieved from the DB to ensure only the currently active languages are used. opw-5380645
4 changes
Enhancements to existing features
This update clarifies French Profit and Loss reports by splitting account 649 into two new accounts (6491 and 6492). This change ensures accurate reporting of social security charges and salaries, aligning with French accounting standards (ANC PCG 2026). The original account remains for legacy systems.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784
Resolved issues and error corrections
This update fixes an issue where Intrastat fields weren't automatically populated when using the vendor bill autocomplete feature. The change ensures that country and transport mode information from previously entered bills is correctly copied to new bills, streamlining reporting for Intrastat compliance. This improves data accuracy and reduces manual effort.
Original PR description
**Steps to reproduce:** 1. Install module `account_intrastat`. 2. Go to Accounting > Vendors > Bills. 3. Create and post a vendor bill: - Set a vendor - Add a reference - Add a product line - Set Intrastat fields (enable them in settings if needed) 4. Create a new vendor bill with the same vendor. 5. Use the autocomplete (select previous bill reference). **Issue:** Intrastat fields (country and transport mode) are not copied from the selected bill. **Cause:** The `invoice_vendor_bill_id` onchange does not propagate Intrastat fields. **Solution:** Extend `_onchange_invoice_vendor_bill` to copy: - `intrastat_country_id` - `intrastat_transport_mode_id` opw-5936869
A bug causing OWL crashes during invoice creation in the Colombian module (l10n_co_edi) has been resolved. The issue stemmed from a duplicate selection value within a field, leading to a JavaScript error. This fix ensures stable invoice creation for Colombian businesses.
Original PR description
The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`:
('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'),
This caused an OWL crash when opening the invoice form:
"Got duplicate key in t-foreach: 23"
__Steps to reproduce:__
1- Install the l10n_co_edi module
2- switch to colombian company
3- Activate the developer mode
4- Go to Credit Note > Create
__NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0.
opw-5969595This update corrects a mapping error that was causing incorrect canton and municipality data to be populated for employees in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). Specifically, the zip code 6010 was incorrectly linked, ensuring accurate Swiss tax and social security reporting.
Original PR description
**Steps to reproduce:**
1. Install `l10n_ch_hr_payroll_elm_transmission`
2. Switch to Swiss company
3. Create an employee and fill in the zip code 6010 under the address section
**Issue:**
- Residence Canton is filled with Nidwalden Instead of Lucerne
- Residence Municipality is filled with 1507 instead of 1059
**Cause:**
- Mapping is wrong in file `hr_payroll_rule_parameters.xml`
**Solution:**
- Set `'6010': ('Kriens', 1507, 'NW')` to `'6010': ('Kriens', 1059, 'LU')`
- Source: https://www.swisstopo.admin.ch/en/official-directory-of-towns-and-cities#Download
opw-5474083