Daily updates from Odoo
Navigate
Branch
Friday, November 21, 2025
221 changes
8 changes
New functionality added to Odoo
This change adds support for carrying customer and checkout details from the online store into Taiwan e-invoices. It helps ensure invoices are created with the right information automatically, reducing manual entry and the risk of errors.
Original PR description
This module adds extra functions on the website sale for l10n_tw_edi_ecpay, passing values from e-commerce to invoice for creating Taiwan E-invoice task-5122489 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236548 Forward-Port-Of: odoo/odoo#228989
Enhancements to existing features
This change makes Odoo’s automatic database column conversion more conservative and predictable. It avoids unnecessary background recomputation during upgrades, which helps reduce upgrade time and limits the automatic handling to simpler cases that are less likely to cause issues.
Original PR description
The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle…
The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle more complex use cases.
This commit introduces two changes:
### 1. Removal of `drop_not_null` during auto column conversion
Before https://github.com/odoo/odoo/commit/50767ef90eadeca2ed05b9400238af8bdbe77fb3 We dropped the not_null constraint because the original column would be renamed. After that commit, we actually don't need to drop the not_null constraint since the `convert_column` will neither convert a not-null value to `null` nor convert 'null' to a not-null value. Keeping the not_null constraint shouldn't block the column convert.
### 2. Removal of `column.clear()`
When a computed/related Float field is changed from `digits=None` to `digits='xxx'`, the `column.clear()` will trigger ORM recomputation during upgrade which is useless since `double precision` to `numeric` is lossless. The recomputation in ORM is slow and should be avoided. If the rerounding is really needed, a sql script is required for upgrade or installation.
The `column.clear()` was originally introduced to avoid `Missing not-null constraint` warnings in specific scenarios:
Case 1 (Upgrade Warning): from saas-18.4 to 19.0
old database: Selection field `l10n_be.export.sdworx.leaves.wizard.reference_year` upgrade: pre-migrate `util.rename_model(cr, "l10n_be.export.sdworx.leaves.wizard", "l10n.be.hr.payroll.export.sdworx")` new database: Integer field `l10n.be.hr.payroll.export.sdworx.reference_year` The column value which was a required stringified integer is auto-converted to an integer.
Case 2 (Installation Warning):
In pos_urban_piper, the required field `pos.config.name` is overridden from `translate=False` to `translate=True`. The column value which was a required text is auto-converted to `'{"en_US": "text"}'::jsonb`
The not_null constraint was previously lost by the `sql.drop_not_null` in `update_db_column` and is not restored by `update_db_notnull` because of the inconsistency between the variable `column['is_nullable']` and the actual not_null constraint in the database.
Thanks to change 1, we will no longer lose the not_null constraint in `update_db_column`. The constraint can be kept even without `column.clear()`.
By removing the `column.clear()`, we also revert the meaning of the `column` variable, which is the column's configuration (dict) before `update_db` if it exists, or `None`
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236299Resolved issues and error corrections
This fix corrects a configuration error in the Uruguayan e-invoicing stock flow that was causing a build failure. It helps ensure stock-related electronic document processing works as expected and avoids interruptions during deployment and validation.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This fix prevents Odoo from showing an error traceback when the Egyptian e-invoice service rejects a request and returns a response that cannot be read as JSON. Instead, the error is now handled properly, giving users a smoother and more reliable invoicing experience.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update removes duplicate methods in several HR-related components. It helps keep the codebase cleaner and reduces the risk of inconsistent behavior or maintenance issues in these areas.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
This update adjusts Odoo’s internal code checks so they continue to run correctly with the latest pylint and astroid versions. It also fixes a couple of test-related warnings and removes a few false alerts, helping maintainers keep quality checks reliable without affecting normal business use.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives. Forward-Port-Of: odoo/odoo#236530 Forward-Port-Of: odoo/odoo#236258
This change improves compatibility with Swedish cash register blackboxes by checking which protocol version they support during setup. As a result, receipts can be registered without triggering an "unknown message type" error on devices that only support the older protocol version.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
Documentation and clarification updates
This change updates the corporate CLA documentation for Moduon. It is an administrative/legal update and does not affect product behavior or customer workflows.
Original PR description
@moduon MT-12696 Forward-Port-Of: odoo/odoo#236642
7 changes
Resolved issues and error corrections
This fix prevents Odoo from showing an error traceback when the Egyptian ETA service rejects an e-invoice request and returns a response that cannot be parsed as JSON. Instead, Odoo now handles that case gracefully, improving reliability for users downloading e-invoices.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update prevents receipt registration errors with some Swedish black box devices that only support an older communication protocol. The system now checks the device version first and sends only compatible commands, reducing failed transactions at the point of sale.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
This change fixes an issue in the Uruguay electronic invoicing flow linked to stock operations. It prevents a build/runtime error caused by a method being assigned to the wrong field, helping ensure stock transfers work correctly with local e-invoicing rules.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This change prevents errors from appearing when a user opens a partner record after uninstalling one of the e-invoice format modules. It keeps partner data consistent by updating the e-invoice format field during uninstall, avoiding unexpected tracebacks for users.
Original PR description
Before this fix, if you uninstalled this module and navigated to any partner that had a e-invoice format defined by this module, you'd have a traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12168 OPW-5172861 Forward-Port-Of: odoo/odoo#234791 Forward-Port-Of: odoo/odoo#232297
This update keeps Odoo compatible with the latest code quality checking tools used in development. It also adjusts a few test and script files so they no longer trigger false warnings, helping maintain smoother automated checks without changing business functionality.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives. Forward-Port-Of: odoo/odoo#236530 Forward-Port-Of: odoo/odoo#236258
This update cleans up duplicated methods in a few business modules. It does not change the expected user experience, but it helps keep the codebase more reliable and easier to maintain going forward.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
Documentation and clarification updates
This change updates the corporate contributor agreement documentation for Moduon. It keeps the legal records current so collaboration and contribution handling can proceed smoothly.
Original PR description
@moduon MT-12696 Forward-Port-Of: odoo/odoo#236642
3 changes
Resolved issues and error corrections
This update makes the Swedish POS blackbox driver detect which protocol version the device supports before sending commands. As a result, receipts can be registered without triggering "unknown message type" errors on devices that only support the older protocol.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
This update corrects a mistake where a calculated value was linked to the wrong field in the Uruguay electronic stock invoicing flow. It helps prevent build failures and ensures the related stock information is processed correctly.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This update fixes several display issues in the Documents kanban view on mobile. It removes unnecessary spacing, lets folders and documents use the full available width in Recent, and makes it possible to scroll to see all items.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#90647
53 changes
Enhancements to existing features
VoIP now uses Odoo’s official country records instead of hard-coded country codes when showing flags and country names. This improves accuracy for countries and territories with special flag or naming rules, such as Bonaire, Sint Eustatius, and Saba.
Original PR description
Previously, we hard-coded the URL according to the country code to display a country flag. However, this is not the case for all countries. Countries like Bonaire, Sint Eustatius, and Saba use the flag of the Netherlands. Additionally, Bonaire, Sint Eustatius, and Saba are shown as Caribbean Netherlands, which is inconsistent with the data from our res.country model. This commit changes it to use the data from res.country. Task-5207454 Forward-Port-Of: odoo/enterprise#99136 Forward-Port-Of: odoo/enterprise#98756
Brazilian service invoices can now include the delivery address as the place where the service was provided. This helps calculate taxes and generate electronic service invoices more accurately when services are sold in one city but delivered in another.
Original PR description
Purpose: In Brazil, it is common for companies to sell services in one city and provide the services in another city, thus, it is necessary to inform the place of service provision in NFS-e. Users can specify where the service was provided through the delivery addresss on either sale order or invoice. The delivery address will be sent in the request to the tax calculation and edi. Outline of additional attributes being sent: - header.locations.rendered.address.street --> partner_shipping_id.street - header.locations.rendered.address.neighborhood --> partner_shipping_id.street2 - header.locations.rendered.address.zipcode --> partner_shipping_id.zip - header.locations.rendered.address.cityName --> partner_shipping_id.city - header.locations.rendered.address.state --> partner_shipping_id.state_id.code - header.locations.rendered.address.countryCode --> partner_shipping_id.country_id.l10n_br_edi_code task-5124608 Forward-Port-Of: odoo/enterprise#99214
UrbanPiper menu synchronization now clears existing product menu links before rebuilding them. This helps ensure the menu sent from Odoo to UrbanPiper is accurate and avoids stale or mismatched product connections.
Original PR description
Following this commit: - Flush out all existing UrbanPiper product menu linkages and performs a fresh menu sync. task-5231247 Forward-Port-Of: odoo/enterprise#99982 Forward-Port-Of: odoo/enterprise#98994
The softphone keypad now keeps the phone number display at a consistent size while users type. This reduces visual flickering and makes entering longer phone numbers feel steadier and easier to read.
Original PR description
When typing a phone number in the softphone, the font size changes several times as the number entered gets longer. Changing the font size is too much flickering of that field. Here, based on countries numbers length and the behavior of Android, we have decided to pick a fixed font size so that 16 characters maximizes the field box. Task ID: 5189671
Manufacturing planners can now quickly filter the MPS dashboard by product category. This makes it easier to organize production planning, find relevant products faster, and avoid manually creating category filters.
Original PR description
A quick access filter for `Product Category` is added to the `MPS dashboard`. This allows users to easily organize and plan products by category, saving time and eliminating the need to manually create filters for product categories. The change enhances usability and improves efficiency in daily production planning. TaskID-5179615
Point of Sale now loads IoT Box information in advance so connected device requests can keep working when connectivity is limited. This also reduces repeated database calls, improving reliability and efficiency for stores using IoT hardware.
Original PR description
In order to allow iot requests to work offline, and also reduce the amount of orm requests sent to the db, we now preload IoT Box records in the `iot_http` service. Task: 5258886 Forward-Port-Of: odoo/enterprise#99910
Salary attachment estimates now use the expected number and schedule of payslips instead of a simple monthly estimate. This gives payroll teams a more accurate projected end date for salary adjustments, especially when employees are paid on non-monthly schedules.
Original PR description
Instead of having the date estimation of a payslip as months, it will be as payslips. Also calculating the end date by having into account the payment schedule of the payslips. task-5135624
The Colombian electronic invoicing PDF layout now displays the QR code more clearly and consistently. The QR code is included on every page, making invoices easier to verify and reducing confusion when documents span multiple pages.
Original PR description
This commit improves QR display in invoice layout. It also ensures that the QR shows on every page of the PDF. task-5239536
The delivery IoT screen now shows the scale-related information banner in a more relevant place under the hardware scale settings. This makes guidance easier to notice and understand when users configure weighing devices.
Original PR description
With this commit: ----------------- Improved the placement and visibility of the info banner by moving it under `Operation Type > Hardware > Scales` and applying the proper banner styling. task-3836703
This update improves the Six payment terminal integration for Point of Sale by adding an end-of-day balance report command and support for refunds or payment reversals. It also speeds up transaction handling, improves receipt formatting, and updates the underlying terminal libraries for better reliability.
Original PR description
Based on the feedback received from our partners we are missing some features in our Six terminal integration. This PR adds them 1. Send balance command to print end-of-day report 2. Adapt the code to reduce the sleep delay after each transaction 3. Refunds/payment reversals for Six + it also adds some minor code improvements like a) Card brand is now saved in pos payments instead of the card number b) Card number is still being sent to PoS and while not stored in v17 will be stored from v18 c) The code of ctypes_terminal_driver and Six Driver was improved to reuse the buffer size and improve the buffer usage d) Fixes the receipt size for the Six terminals e) updates the Six C libraries used to the latest version to get all the newest fixes Related C PR: https://github.com/odoo/worldline-lib/pull/9 Related community PR: https://github.com/odoo/odoo/pull/236488 Forward-Port-Of: odoo/enterprise#98203 Forward-Port-Of: odoo/enterprise#96748
Calendar events created from appointment types now automatically use the appointment type's location. This keeps booking details consistent for users and reduces the chance of missing or mismatched event locations.
Original PR description
Purpose: Ensure calendar events copy the location from their appointment type. Technical: - Made the `location` field on `calendar.event` computed and stored, depending on `appointment_type_id`, to propagate the location from the related appointment type. - Removed redundant location assignment from `_prepare_calendar_event_values`. Task-5144941
Belgian SODA imports can now use department information from social secretariat files to assign analytic accounts automatically. This helps businesses analyze payroll-related entries by department, while files without department data continue to import as before.
Original PR description
Maps the SODA file's `<Department>` field (from the social secretariat) to an analytic account. This addresses customer requests to use employee department data for analytics. Ignores mapping if the `<Department>` field is absent. task-5126179
Rental schedules now stay cleaner by fully excluding canceled rental orders, even when users adjust the confirmed orders filter. Rental orders created from leads also carry over the lead’s tags, helping teams keep sales context and reporting consistent.
Original PR description
- Completely remove canceled rental orders from the schedule view even when removing the confirmed orders filter. - When creating a rental order from a lead, the tags will be copied similar to what happens when creating a normal sale order. task-4384655
Users can now interact with tags while editing rows in list views, bringing list behavior closer to form views. Depending on configuration, clicking a tag can open its form, open a color selector, or do nothing, making tag management faster and more consistent across apps.
Original PR description
In this commit, we add the feature to edit tags when a row is in edition in list view like form view. We also change API options for many2many_tags. According to the selected on_click option, it opens either the color picker or the form view related to the selected record. on_click option can have : - edit_color : to open the color picker if color_field is filled. - open_form : to open the related form view - do_nothing : to do nothing (by default) task~5163167
The Purchase Order form now places the purchase type field in a more suitable location after recent layout changes. This makes the form clearer and easier for users to navigate when working with partner commissions.
Original PR description
- The position of the purchase_type field on the Purchase Order form has been updated to adapt to community layout changes. - This adjustment simplifies the view, making it easier for users to access and use. Task Id: 4778630
This update simplifies how report date inputs are handled across accounting and local reporting tests. It reduces unnecessary conversions, helping keep report validation consistent and easier to maintain without changing day-to-day user workflows.
Original PR description
`report.generate_options` converts date arguments to string. so it doesn't make sense to convert strings to dates before passing them as arguments. related: https://github.com/odoo/enterprise/pull/99765#discussion_r2538377640
The EC Sales List report has been redesigned to work more consistently across country-specific versions, with clearer grouping of sales by customer and sale type. This improves reporting flexibility, auditability, and return generation for businesses managing EU sales declarations.
Original PR description
The EC Sales List report and its variants have been refactored to use a custom engine instead of dynamic line generators. This change offers several benefits, including the ability to modify grouping…
The EC Sales List report and its variants have been refactored to use a custom engine instead of dynamic line generators. This change offers several benefits, including the ability to modify grouping keys and better integration with the accounting reports engine. The audit of cell has also been implemented. The key improvement is that report now has a single line with a defined grouping key that can be modified as needed. Two grouping systems have been identified across EC sales reports in localizations: Grouping by partner, displaying the sum of EC sales categories (goods, services, etc.) per partner. Grouping by partner and EC sales category, allowing multiple lines per partner. A custom grouping key (partner_id_and_sale_type) handles this scenario. For code clarity, the generic EC Sales Report has been moved to a separate custom handler. Unlike localization-specific reports based on account tags, this report derives its values from taxes. An additional enhancements is the improved options generation for the report, allowing localization variants to easily declare their requirements. Examples of specific declarations by variants include: - Sale types (e.g., goods, services), with localizations defining required categories. Most of the reports use by default the three main categories, i.e. goods, services, and triangular, but some localization (like l10n_si), adds categories to it. It was therefore decided that variants are responsible for defining which categories are required for them. - Custom names for categories in reports grouped by partner ID and EC sales categories. - Options to display or filter specific EC sales categories. - Formatting for partner VAT and changing partner country codes as needed. EC sales list returns generation has also been slightly refactored. Most localizations just need the EC sales returns to be generated if data are present in the report for the corresponding period. Since most modules shared the same code and multiple issues were found, the commit generalize the generation of this type of return based on what was done for Belgium, i.e. creating EC sales return for the past three months if data are found in these period and if no return already exist. Additional notes: - The filter to select specific sale types has been improved to select all types if none are selected, having therefore a similar behavior than other filters. - For Denmark, partner's vat should not contain the country code according to https://info.skat.dk/data.aspx?oid=392&chk=217608. This behavior has been fixed. - For Ireland, changes has been done to add triangular tag and create EC Sales variant report which makes distinctions for goods/services/triangular sales. task-4260016
Website product imports can now handle larger product catalogs more reliably by processing image files in smaller chunks and reducing memory usage. Long-running imports are less likely to time out, and problematic products can be skipped while errors are reported for follow-up.
Original PR description
The goal of these improvements is to support the import of more products as well as making the entire import process more reliable. The first improvement is the stream and live decompression of files that are directly saved as attachment one by one. This reduces the memory footprint of this process which can be substantial given the quantity and size of images being imported. The second is the heavy use of the '_commit_progress' of crons. This is necessary because the importing of products can be very long due to the creation of many records as well as image resizing. This long process often timed out the old cron which would end up being disabled by the orm. Lastly this process is now more reliable, it can now skip products in case of errors and send a crash report to our server.
Resolved issues and error corrections
Opening the warehouse “To Receive” view could crash when many transfers had many quality checks because too much quality-check data was loaded into memory. This change loads only the needed quality-check information, greatly reducing memory use and improving reliability for high-volume warehouses.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162 Forward-Port-Of: odoo/enterprise#98304 Forward-Port-Of: odoo/enterprise#95568
Opening the Documents app no longer fails when it contains an upload request linked to a CRM lead that has since been deleted. The document now safely shows no related record name instead of triggering an error, helping users continue working without interruption.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
The LinkedIn integration now uses a supported API version after the previous version was discontinued. This helps prevent connection or publishing issues for businesses using LinkedIn social features.
Original PR description
This commit updates the linkedin version header so that we can use the version of the API. Our actual version was recently sunset, needing the change of version to be done. task-5271712 Forward-Port-Of: odoo/enterprise#99759
The Helpdesk timesheet total now displays the correct value when the company uses days or half-days instead of hours. This prevents misleading totals, such as showing 160 days instead of 2.5 days, and helps teams review logged work accurately.
Original PR description
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4.…
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4. Open the team’s settings and observe the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the team’s settings and observe the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------ After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed. Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36 For ex: Consider unit_amount = 20 minutes: **Before** Case 1: Encoding method = Hours/Minutes (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 1 = 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 8 = 160 Days --> INCORRECT **After** Encoding method = Days/Half-days (unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor (20 * 1) / 8 = 2.5 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. **NOTE:** Before this change, when the user opened the timesheet sublist view in debug mode and clicked the View button, it opened the default form view of the `account.analytic.line` model instead of the intended timesheet form view. This allowed editing of the Unit of Measure (product_uom_id) field also. To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41). Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related community PR: https://github.com/odoo/odoo/pull/233803 Forward-Port-Of: odoo/enterprise#98545
This fixes an issue in the Belgian salary contract module where the system tried to use a missing calculation function. It now reads the correct work time rate field, helping salary contract information load reliably.
Original PR description
The function _get_work_time_rate doesn't exist, but the information we need is in the field work_time_rate. Forward-Port-Of: odoo/enterprise#99922
The Sign send wizard no longer tries to read another user's saved signature or initials when it is not needed. This prevents access-rights errors in multi-role signing templates with multiple internal users, making document sending more reliable.
Original PR description
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions: - sign.template with signature/initials fields and more than one…
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions:
- sign.template with signature/initials fields and more than one role
- more than one sign user (internal user)
```
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 341, in _compute_only_autofill_readonly
not (item.type_id.name == 'Signature' and request._get_user_signature(user, 'sign_signature')) and
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 323, in _get_user_signature
return user[signature_type]
~~~~^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 6680, in __getitem__
return self._fields[key].__get__(self)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/fields.py", line 1646, in __get__
record._check_field_access(self, 'read')
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 3426, in _check_field_access
raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
```
This commit ensure that we don't try to access the signature/initial field of another user when it is not necessary.
task-5271648
Forward-Port-Of: odoo/enterprise#99940Closing or cancelling helpdesk tickets no longer causes an error when SLA working hours have been cleared or disabled. This keeps ticket workflows running smoothly even when teams do not use working hour policies.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
This fix updates the external tax sales test flow so it stays compatible with recent related changes in the core sales experience. It helps ensure optional product sales scenarios continue to work reliably when external tax calculation is enabled.
Original PR description
See Also: - https://github.com/odoo/odoo/pull/227241 Forward-Port-Of: odoo/enterprise#99188
This fixes an error when signing Mexican electronic invoices through SW Sapiens. A stray space in the request data was removed so the service receives the expected information and no longer rejects the request with a null value error.
Original PR description
On Commit 6c4d07f a space was added to the payload lines in the request to sw sapiens, causing the payload to contain information that it should not have and leading to the error “value cannot be null.” <img width="2914" height="1552" alt="image" src="https://github.com/user-attachments/assets/04047f14-fc21-45fd-ae29-b241dfbbed2a" /> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Swedish point-of-sale blackbox integration now checks which protocol version a device supports before sending receipt commands. This prevents errors with older supported devices and helps businesses continue registering receipts reliably.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
The point of sale now loads only draft delivery orders when a session starts, avoiding unnecessary loading of already paid orders. This improves startup performance for businesses using Urban Piper delivery integrations and removes a minor console warning.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99984
Forward-Port-Of: odoo/enterprise#99904This change reverts a previous adjustment that hid section and note lines in journal item tabs because it caused new journal entry lines to calculate debit and credit amounts incorrectly. Restoring the previous behavior helps ensure accounting entries are created accurately during editing.
Original PR description
This reverts commit 17d0e67106a30a46d608331680e5094dbc44e2e0. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. no-task Forward-Port-Of: odoo/enterprise#99875
Deferred half-day and hourly leaves now keep their actual duration when moved to the next month. This prevents payroll work entries from incorrectly counting partial leave as a full day, improving payroll accuracy for employees and HR teams.
Original PR description
When deferring half-day or hourly leaves to the next month, the work entry was incorrectly replaced with a full day duration instead of the actual leave duration. Now splits the work entry to match the exact leave hours when necessary. task-5258753 Forward-Port-Of: odoo/enterprise#99415
This fix prevents upgrade failures when creating timesheet entries from helpdesk tickets that do not have their own analytic account set. It preserves the correct project account instead of replacing it with an empty value, helping affected customers complete upgrades successfully.
Original PR description
When creating an analytic line from a helpdesk ticket, we assigned the account_id from the project's account_id during the upgrade. However, in the standard code, the account_id is later overridden and updated from ticket.analytic_account_id, which is null. As a result, the constraint "At least one analytic account must be set" is triggered. see: https://github.com/odoo/enterprise/blob/dcfef2cc462631f376a596a7c85ae483826835ad/helpdesk_timesheet/models/account_analytic_line.py#L119 Multiple upgrade request failed due to this. Forward-Port-Of: odoo/enterprise#99209 Forward-Port-Of: odoo/enterprise#99201
The VoIP test setup was corrected to include complete contact data, preventing a validation error during automated test runs. This improves test reliability without changing the user-facing VoIP experience.
Original PR description
Before this commit, running VoIP tests in HOOT results in this error: > Global OwlError: Invalid props for component 'TabEntry': 'title' is not a string, 'phoneNumber' is not a string This is because one of the test is setup with incomplete data (no phone number). After this commit, test data is correctly set with a phone number, fixing the props validation error. Forward-Port-Of: odoo/enterprise#100057
Fixed an issue where invoices could fail for alternative sales orders created from subscription upsells, even after customer payment succeeded. The alternative order now keeps the correct next invoice date, preventing incorrect deferred date calculations and ensuring invoices are issued as expected.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99919 Forward-Port-Of: odoo/enterprise#98983
The approval process now blocks creating a new request for quotation when one is already linked to the approval. This prevents accidental duplicate purchasing and inflated product quantities when users click the action multiple times or work from multiple tabs.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99817 Forward-Port-Of: odoo/enterprise#99706
This update corrects access to car information in the Belgian salary contract flow. Regular users and applicants can now access the car-related details they need, reducing blocked or incomplete contract salary processes.
Original PR description
Normal users and applicant don't have access to car. Forward-Port-Of: odoo/enterprise#99658
Employees who are not HR officers can now request appraisal feedback without running into access errors. The change lets the appraisal feedback flow read the necessary employee information through the public employee mechanism, keeping the process usable for managers and reviewers.
Original PR description
Since we cannot ask a feedback when we are not an HR officer because we don't have acces to employees and we get an access right error when we try to ask feedback. So we use the hr.public.version mecanism to allow too read the employees without rights. Forward-Port-Of: odoo/enterprise#99947
The Documents sharing wizard now properly applies changes when allowing link access. This ensures users' sharing permission updates are retained, reducing confusion and preventing incorrect access settings.
Original PR description
This commit fix the 'action_allow_link_access' method in 'documents.sharing' model by adding the 'WRITE_VALUE_PREFIX' to the updated fields. Otherwise the changes wasn't taken into account. Task-5220965 Forward-Port-Of: odoo/enterprise#98382
VoIP now checks both the main call and transfer call before marking a call as ended unexpectedly. This prevents transferred calls from being incorrectly flagged, improving call history accuracy for users.
Original PR description
Currently, the check for calls that were ended in a wrong way only assumes that there is one call where there might be two calls in case of transfers. This commit fixes this issue by checking for both session, the main session and the transfer session. Task-5208152
IoT boxes now keep their own last received message position when reconnecting, instead of always being moved to the newest message. This helps prevent missed updates after short connection interruptions while still avoiding old stale messages when a device starts fresh.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236843 Before this commit, if an IoT box subscribed to the websocket we would always force its last message ID to be the latest (so no old messages would be sent). However, in the case of a brief disconnection, this could result in a message being missed. After this commit, we only force the last message ID to be the latest if the IoT box does not provide its own last message ID. This way, we still avoid the issue of stale messages on boot, but allow disconnections to not result in missing a message.
Barcode scans for kit components now update the existing reserved line when a different unreserved serial or lot is scanned, instead of creating a duplicate line. This prevents unnecessary backorder prompts and helps warehouse operators complete deliveries accurately.
Original PR description
### Issue: Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that…
### Issue:
Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.
### Steps to reproduce:
- Create a kit product with a kit BOM:
- 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation
### Cause of the issue:
Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does, the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921
### Fix:
In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.
opw-5100026
Forward-Port-Of: odoo/enterprise#99845
Forward-Port-Of: odoo/enterprise#98589Changing the quantity being produced from the barcode manufacturing flow now correctly updates and consumes the related component quantities. This prevents production orders from leaving required materials unconsumed, improving inventory accuracy for barcode-based manufacturing operations.
Original PR description
Steps to reproduce: 1- Create MO 2- Change the `qty_producing` Issue: `stock.move.lines` are not consumed. Because `qty_producing` is not a computed field therefore it has no inverse. It updates the consumption with an on change method and in Barcode we don't have `move_raw_ids` in the xml, so its not stored or saved. To fix the problem, `set_qty_producing` was called manually to keep the barcode's design clean. Task: 5111357 Forward-Port-Of: odoo/enterprise#98184
The VoIP test setup was adjusted so mobile device behavior is only simulated where it is needed. This prevents unrelated tests from being affected, improving confidence in automated test results without changing customer-facing functionality.
Original PR description
Since [1], mockUserAgent was called at the root of the module. In this case, it applies globally. This commit moves user agent mocking in `keypad.mobile.test.js` into `beforeEach` and switch to the platform-based "android" helper so it only applies to this suite. [1]: https://github.com/odoo/enterprise/commit/b118a5ceb7f0773783ca003c625c9ae3cccdebed
When a stock move quantity is increased, the system now adjusts the existing reserved line instead of creating an extra line without tracking details. This keeps barcode manufacturing stock flows more consistent and reduces confusion in inventory handling.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit correct some tests values because increasing the quantity on a stock move will increase the existing move line quantity instead of creating a new one. Forward-Port-Of: odoo/enterprise#96750
Fixed an issue where rental prices could be calculated from the default start date instead of the customer's selected start date when unavailable days were configured. This prevents customers from being charged for the wrong number of nights after changing rental dates.
Original PR description
**Issue:** Price is wrongly calculated on period Night when we have Unavailability days. **How to reproduce:** Product A with Nightly rental period. Let's say price = 100. If you're testing on a Monday, go to the settings of the Rental app. Select Wednesday as an Unavailable days (= day + 2). The next starting default date will be day +1 but the next ending default date won't be day +2. Default dates: Tuesday -> Thursday (skipping Wednesday) = **2 nights**. Computed price: **200**. OK. Select another day where day + 1 is ok for renting. Example, Thursday. Default dates: Thursday -> Friday = **1 night**. Computed price: **200**. NOK. **Reason:** The price computation is based on the default start date instead of the selected start date. Unavailability days can increase the duration, but from a wrong starting date. Issue introduced in 3e257042a9a0774e297c8fd07e651eda4613b902 Forward-Port-Of: odoo/enterprise#100085
Creating a new salary offer from an employee record no longer fails because required offer information is lost during setup. This prevents an interruption in the HR offer workflow and keeps offer generation reliable for users.
Original PR description
To reproduce: 1-Navigate to an existing employee. 2-Create a new offer for the employee using "Offers" smartbutton. -The issue firstly appeared because of this commit: https://github.com/odoo/enterprise/commit/b251408ddc16f5f76dc0dcf1270bd4a8424c7b3b -The issue appears because the form is not populated with the context data. This is because upon offer generation, the context is overridden by recomputation of payslips that happens in write() in hr.version model. -The issue should have appeared earlier, however it didn't happen by luck because the dependency check in the commit mentioned above was too specific. Proposed solution: -Send a flag in the context to avoid recomputation upon open generation. Task-id:5245134
Updated VoIP test setup to use the browser platform mock in the intended way. This helps keep automated checks reliable and reduces the risk of false test results during future updates.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac", "windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/enterprise#100154This update keeps PDF previews working correctly in Documents after a PDF viewer change affected file links. It also keeps Sign form text readable when users or browsers use dark mode.
Original PR description
In the new version of PDF.js (viewer.js) there is these new lines:
```javascript
const queryString = document.location.search.substring(1);
const params = parseQueryString(queryString);
file = params.get("file") ?? AppOptions.get("defaultUrl");
try {
file = new URL(decodeURIComponent(file)).href;
} catch {
file = encodeURIComponent(file).replaceAll("%2F", "/");
}
```
This has an effect in document as the PDF file are not readable anymore
due has URL is not correct anymore.
To avoid malformed URL we removed the options `download=0`.
---
In the Sign app we need tho force the color of cell as now PDF.js
(iframe) enable color scheme:
```css
:root {
color-scheme: light dark;
}
```
So the `fieldtext` value will be white in dark mode, and we don't want
that.
task-5110143Planning analysis reports now only count shifts when they fall within an employee's working hours. This prevents hours from being incorrectly included in a later month when a shift ends after working hours, improving reporting accuracy for timesheets and planning.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This change avoids saving data into a field that is automatically calculated by the system. It helps prevent hidden data inconsistencies that could cause errors during product barcode lookup operations.
Original PR description
The field all_group_ids is computed from other groups, writing on it creates inconsistencies in the cache and may result in errors when invalidating/flushing.
Features or functions removed from Odoo
Support for the older Ingenico payment terminal protocol has been removed. Businesses using Ingenico terminals should configure them through the Worldline CTEP protocol instead, reducing maintenance complexity while keeping supported payment terminal connectivity available.
Original PR description
Ingenico payment terminals can be configured using WorldLine CTEP protocol. We then remove support for ingenico protocol to reduce the amount of code to maintain. Community PR: odoo/odoo#230817
Code cleanup and technical improvements
The Starshipit delivery connector has been cleaned up internally to make its setup and credential handling more reliable. This reduces maintenance risk and helps keep shipping operations stable without changing day-to-day user workflows.
Original PR description
Cleanup of the Starshipit class calls, attributes and methods. Keys lifecycle management via context manager. task-5241578
Miscellaneous changes
Module was added in stable => needs to be manually added to weblate.json file Forward-Port-Of: odoo/enterprise#100130
Original PR description
Module was added in stable => needs to be manually added to weblate.json file Forward-Port-Of: odoo/enterprise#100130
8 changes
New functionality added to Odoo
This update adds support for passing Taiwan e-invoice information from the website checkout flow into the invoice creation process. It helps ensure customer-entered billing details are carried through correctly so invoices can be issued with the right data.
Original PR description
This module adds extra functions on the website sale for l10n_tw_edi_ecpay, passing values from e-commerce to invoice for creating Taiwan E-invoice task-5122489 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236548 Forward-Port-Of: odoo/odoo#228989
Resolved issues and error corrections
The employee contract template activity view now shows only records with assigned activities, instead of listing every contract template. This makes the Activities view accurate and easier for users to work with.
Original PR description
The contract template’s activity view incorrectly displays all contracts, instead of only those with assigned activities. **Steps to reproduce this issue:** 1) Install the hr module. 2) Open Employees → Employees → Contract Templates. 3) Create multiple contract templates and add an activity to one of them. 4) Open the activities from the Activities (top right corner). **Issue:** You will end up in the all contract templates list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied to the view. But in the contract template, we don't have any search filters for the activities. Therefore, it renders all contract records. **Solution:** Add the activity search filters for the contract template records. opw-5209691 Forward-Port-Of: odoo/odoo#234274
This change fixes an issue where invoices could fail to generate for alternative sales orders created from subscription upsells. The system now carries over the needed billing date so customers who have already paid can receive their invoice without errors.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99919 Forward-Port-Of: odoo/enterprise#98983
This change prevents an error that could appear when opening the Project app after the Databases module has been uninstalled. It restores a safe fallback rule so the app continues to work normally even when that module is no longer present.
Original PR description
Steps to reproduce: ------------------- 1. Install the `databases` module. 2. Uninstall the `databases` module. 3. Open the Project app. Issue: ------ A traceback occurred: ``` ValueError: Invalid…
Steps to reproduce:
-------------------
1. Install the `databases` module.
2. Uninstall the `databases` module.
3. Open the Project app.
Issue:
------
A traceback occurred:
```
ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)
```
Cause:
------
The `databases` module updates the `domain_force` of the project record
rule [project.project_project_manager_rule](https://github.com/odoo/odoo/blob/da0333db5d0a0464e39e41e9409810876c56a275/addons/project/security/project_security.xml#L57-L62) to include the field `database_hosting`.
When the module is uninstalled, the `database_hosting` field is removed,
but the record rule remains (it belongs to the `project` module).
Solution:
---------
Update the record rule domain_force with project [domain_force ](https://github.com/odoo/odoo/blob/da0333db5d0a0464e39e41e9409810876c56a275/addons/project/security/project_security.xml#L60)as a safe fallback domain_force.
opw-5321878This fix ensures combo products show the correct total on the self-order success screen. Previously, the combo parent line was counted twice, which could make the displayed price appear doubled; now the total matches the real amount paid.
Original PR description
Steps to reproduce ------------------ In pos self order, choose a combo product and checkout. Notice that the price shown on the "success" screen is double the combo price. Why it's happening…
Steps to reproduce ------------------ In pos self order, choose a combo product and checkout. Notice that the price shown on the "success" screen is double the combo price. Why it's happening ------------------ When displaying the order price, we sum the `price_subtotal_incl` of all its lines. In a combo order, for each combo product, we have a combo parent line and its children lines. We rely on `price_subtotal_incl` of the combo parent line to be 0, and the price thus will be the sum of `price_subtotal_incl` of the children combo lines. After https://github.com/odoo/odoo/commit/9538698f13d5763b49b00f4c06a1a2afc0d6b39e, we are setting the combo line's `price_subtotal_incl` to the sum of the price of its children, so it's no longer 0 making the calculation wrong, i.e. it's summing twice the price. The Fix ------- We now set the `price_subtotal_incl` to `priceIncl` and not to `displayPrice` anymore. Which makes sure a combo parent line has 0 price. opw-5247554
This change updates the packaging Docker setup to use the currently supported Ubuntu Noble base image instead of Bookworm. It also removes unnecessary wait steps that were masking an underlying issue, which should make the build process cleaner and more reliable.
Original PR description
The Dockerfile used for source package is still using the Bookworm distribution as base image. In order to be consistent with the Odoo supported distribution, let's update to Ubuntu Noble. This commit also removes useless `sleeps` that were hiding a real bug. It should help declutter #228456
Fixed an issue where overnight rental prices could be calculated incorrectly when some days are unavailable. The system now uses the actual chosen rental dates, so customers are charged the correct amount even when default dates need to skip unavailable days.
Original PR description
**Issue:** Price is wrongly calculated on period Night when we have Unavailability days. **How to reproduce:** Product A with Nightly rental period. Let's say price = 100. If you're testing on a Monday, go to the settings of the Rental app. Select Wednesday as an Unavailable days (= day + 2). The next starting default date will be day +1 but the next ending default date won't be day +2. Default dates: Tuesday -> Thursday (skipping Wednesday) = **2 nights**. Computed price: **200**. OK. Select another day where day + 1 is ok for renting. Example, Thursday. Default dates: Thursday -> Friday = **1 night**. Computed price: **200**. NOK. **Reason:** The price computation is based on the default start date instead of the selected start date. Unavailability days can increase the duration, but from a wrong starting date. Issue introduced in 3e257042a9a0774e297c8fd07e651eda4613b902
This update prevents an error that could occur when an employee checks out from attendance. It now correctly handles cases where there are multiple attendance entries for the same day, so checkout works reliably instead of failing.
Original PR description
The system raises an error when a user attempts to checkout through any method. Steps to produce: - Install hr_attendance without demo. - Settings > Under Work Organization > set schedule with 0…
The system raises an error when a user attempts to checkout through any method. Steps to produce: - Install hr_attendance without demo. - Settings > Under Work Organization > set schedule with 0 working hours.([Example]) - Employees > Administrator > under settings > set Overtime Ruleset as `Default Ruleset`. - Now to attendance > kiosk > do checkin - checkout server time. Error: `ValueError: Expected singleton: hr.attendance.overtime.line(171, 172, 173)` Cause: - [Here], the system retrieves the attendance duration for today and assumes it exists in only one record. However, multiple attendance records can exist for the same day. Solution: - This fix updates the logic to compute the sum of all attendance durations for that employee for today, instead of expecting a single record. [Example]: https://drive.google.com/file/d/12cdXOHtE11ytCBotVr6FDszK7xHndbm_/view?usp=sharing [Here]https://github.com/odoo/odoo/blob/e387c4a706a7d24b437e75c3d5970e5786626dc9/addons/hr_attendance/controllers/main.py#L46-L47 sentry-7024592646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
Enhancements to existing features
This update corrects how VAT values are calculated in the Indonesian E-Faktur Coretax export so the XML now uses the right tax grouping instead of relying on invoice type in some cases. It also adds a safeguard to prevent invalid tax combinations, helping reduce reporting errors and improving consistency in tax documents.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#233347
The payroll payment report for Swiss companies now defaults to the Swiss ISO 20022 format instead of the generic SEPA option. This makes payroll exports easier to use correctly out of the box and reduces the need for manual selection.
Original PR description
Previously the sepa and iso20022_ch were together in the hr_payroll_account_iso20022 module, but we needed to separate between them so that for the ch localization we have the export format, iso20022_ch, to be the default value when we're on the swiss company. task-5189295
Resolved issues and error corrections
This change prevents website page saves from crashing when an embedded code block is missing required attributes. Instead of failing with an internal error, the system now validates the content and raises a clearer message, making editing more reliable for website users.
Original PR description
Currently, an error occurs when saving a website page that contains an embedded element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes. **Steps to produce:** - Install the…
Currently, an error occurs when saving a website page that contains an embedded
element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes.
**Steps to produce:**
- Install the `website` module.
- Open the `Website` app and click `Edit`.
- Drag an `Embed Code` block and add one of the following examples:
`<span data-oe-field='name' data-oe-model='res.partner' />`
or
`<span data-oe-type='int' data-oe-model='res.partner' />`
- Try to `Save` it.
**Error:**
`TypeError: can only concatenate str (not 'NoneType') to str `
`KeyError: None`
**Root Cause:**
At [1], the code tries to concatenate `'ir.qweb.field.' + el.get('data-oe-type')`,
but when `data-oe-type` is missing, `el.get('data-oe-type')` returns `None`,
causing an `error`.
At [2], when the `data-oe-field` attribute is missing, the code
tries to access `Model._fields[field]`, resulting in an `error`.
**Fix:**
This commit adds validation for missing attributes in the embedded
element, ensuring a clear error message is raised instead of a crash.
[1]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L67
[2]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L71
sentry–6675421840Invoicing-only users in the India localization could hit an access error when creating or posting invoices. This update gives the invoicing group the read access it needs, so invoice processing works smoothly when the related accounting features are installed.
Original PR description
In India localization, invoicing-only users were getting an AccessError on `account.fiscal.year` when creating or posting invoices. This happened when both l10n_in_withholding and account_accountant modules were installed. Added missing read access for the invoicing group to resolve the issue. Reference computation: During computation of TDS/TCS, warning `compute_fiscalyear_dates` method is called https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/l10n_in_withholding/models/account_move.py#L124 In the `compute_fiscalyear_dates` method, it searches for 'account.fiscal.year' records https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/account_accountant/models/res_company.py#L162 As invoicing-only users don't have access to 'account.fiscal.year' records It will raise AccessError Task-5346551
This fix makes website anchor links behave as users expect when “Open in New Window” is enabled. Instead of staying in the same tab and scrolling on the page, the link now opens in a new tab while still jumping to the selected section.
Original PR description
Steps to Reproduce: 1. Create an anchor link for any dropped snippet. 2. Insert the link through the link popover. 3. Enable the "Open in New Window" option. 4. Click on Save. 5. Click on the link. Issue: Even though the "Open in New Window" option is enabled, the page scrolls in the same tab instead of opening in a new window and scrolling to the targeted view. Reason: When an anchor link has target="_blank", `ev.preventDefault()` was still being called, which prevented the browser from performing its default behavior of opening the link in a new tab. Fix: Removed `ev.preventDefault()` for such links, as the expected behavior is to open them in a new tab whenever target="_blank" is set. Additionally, the offcanvas mobile-specific logic has been removed, as it is no longer necessary now that `ev.preventDefault()` is no longer used. task-5104027 Forward-Port-Of: odoo/odoo#228787
This change prevents Odoo from showing an unexpected traceback when Egypt’s ETA rejects an e-invoice download request and the response cannot be read as JSON. Instead, the error is now handled properly, resulting in a smoother and clearer user experience when a request fails.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update fixes a layout issue that could hide or break the exchange rate section on printed invoices when multiple GCC localization apps are installed together. It helps ensure invoices render correctly for affected companies, especially when using a foreign currency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Certification lines now refresh their status color correctly when a certificate passes its end date. This ensures the Certifications report reflects the current situation without requiring any manual change.
Original PR description
**Steps to reproduce:** 1. Install `hr_skills_survey` 2. Go to Employees > Reporting > Certifications. 3. Create a certification line with a future end date → record shows in black. 4. Change the system date to after the end date. **Issue:** - The line color is not updated when time passes. **Cause:** https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/models/hr_resume_line.py#L17 https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/views/hr_employee_certification_views.xml#L7 - The color was based on the stored computed field `expiration_status`, which only depends on `date_end`. Since `date_end` does not change with time, the field value is not recomputed daily. **Solution:** - Introduce a non-stored computed field `expiration_status_ui`, depending on `date_end` and use it in the view to update expiration_status. opw-5065185
Documentation and clarification updates
This change updates the corporate contributor agreement documentation for Moduon. It matters for legal and compliance tracking, but does not affect product behavior for users.
Original PR description
@moduon MT-12696 Forward-Port-Of: odoo/odoo#236642
12 changes
Enhancements to existing features
The Japanese state records have been updated to use their native Japanese names directly, which improves how location names appear to users. The state codes were also aligned with ISO standards to keep the data more consistent and reliable.
Original PR description
Since state names are not handled by translations, storing them directly in Japanese provides a better user experience. This **PR** updates the existing Japanese state records with their native Japanese names. Additionally, it aligns the state codes as per ISO standards. **task**-5345872
The subscription log now labels the previous status as “State Before” instead of “Subscription State.” This makes it easier for users to understand that the value shown is the state before an event happened, reducing confusion when reviewing subscription history.
Original PR description
The sale.order.log model includes a field named subscription state that records the state of the subscription at the moment an event occurs (i.e., the state before the change). To improve clarity for end users, this PR renames the column from Subscription State to State Before. task-5258195
The homepage now checks for updates less aggressively when a browser tab stays open for a long time. This reduces unnecessary traffic to the IoT Box and helps keep it responsive while still refreshing the page periodically.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min.
This change allows invoice confirmation dates to align with the invoice date, instead of always using the posting time. As a result, businesses can safely backdate invoices without creating mismatches between Odoo and the Saudi e-invoicing system.
Original PR description
Previously, `l10n_sa_confirmation_datetime` represented the time where the invoice was posted, that meant that we could not backdate invoices, since it would cause disparity between what zatca receives and what we consider in odoo (i.e. `invoice_date`) This commit allows us to set the date component of `l10n_sa_confirmation_datetime` to the `invoice_date` so we can safely backdate invoices. task-5009969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update prevents an error when a badge is scanned for an attendee who is not linked to any sale order. It ensures the system treats these registrations as free by default, so event staff can scan badges without interruption.
Original PR description
Currently an error occurs when the user is scanning a badge that is not linked to a sale order. Steps to Reproduce: - Install 'event_sale' module. - Go to Events > Registration Desk ; click on Select…
Currently an error occurs when the user is scanning a badge that is not linked
to a sale order.
Steps to Reproduce:
- Install 'event_sale' module.
- Go to Events > Registration Desk ; click on Select Attendee >> New.
- Select any Event and then save it, A pdf having QR code would be generated.
- Now download that pdf.
- Go back to Events > Registration Desk ; click on Scan a Badge(Tap to scan) and
scan your QR Code.
- The error would be generated.
Traceback on sentry:
```
KeyError: False
File "odoo/http.py", line 2150, in __call__
response = request._serve_db()
File "odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1953, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 464, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 435, in _call_kw_model
result = method(recs, *args, **kwargs)
File "addons/event/models/event_registration.py", line 161, in register_attendee
res = attendee._get_registration_summary()
File "addons/event_sale/models/event_registration.py", line 136, in _get_registration_summary
'sale_status_value': dict(self._fields['sale_status']._description_selection(self.env))[self.sale_status],
```
This error arises at [1] when it attempts to access the dictionary with the key
'self.sale_status', but when 'self.sale_status' was False or not set, it
resulted in a KeyError.
This commit fixes the above issue by giving 'free' as the default value of sale
status as there is no sale order available.
Link: [1]-https://github.com/odoo/odoo/blob/c1d250fcbc178eaee1694197b759d3717e3b50e6/addons/event_sale/models/event_registration.py#L136
sentry-4620674401
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents a crash when someone enters an invalid Sendcloud tracking reference. Instead of an unexpected error, users now see a clear message explaining that the tracking code is not valid, which makes the issue easier to understand and resolve.
Original PR description
This traceback arises when the user gives an invalid tracking reference. <h4>To reproduce this issue:-</h4> 1) Install `delivery_sendcloud` 2) Create a new shipping method in `inventroy/configiration` 3) Make the provider `sendcloud` and give any key and secret 4) Now create a `delivery picking` from `Inventory/Operation/Delivery` 5) In `additional Info` select the carries as above created `shipping method` 5) Give any `tracking reference` 6) Click on `tracking` stat button Error:- ``` TypeError: 'bool' object is not subscriptable ``` When the user gives an invalid tracking reference it leads to the above traceback as there will be no `picking.sendcloud_parcel_ref` https://github.com/odoo/enterprise/blob/d91b91626fb488a98d10757142ad14cc9ff7d503/delivery_sendcloud/models/delivery_carrier.py#L188 After applying this commit will resolve this issue by raising a user exception. sentry-5096109840
This update prevents a crash that could happen when a user changes the expression label in the Generic Tax report. It ensures the Tax Report still opens normally even if that label has been renamed, improving reliability for accounting users.
Original PR description
This traceback occurs when the user changes the expression label of the column in the `Generic Tax report`. To reproduce this issue:- 1) Install `account_reports` 2) Open `Generic Tax report` from `Accounting Reports` 3) In `columns` change the `Expression Label` of tax and save the record 4) Open the `Tax Report` from `Reporting` 5) A traceback occurs Error:- ``` UnboundLocalError: local variable 'col_value' referenced before assignment ``` Because `col_value` is assigned based on the `expr_label` if it doesn't match the `if` conditions it leads to a traceback. https://github.com/odoo/enterprise/blob/d154cbf1bd5b4cc104ff0e2443047aff0c05330f/account_reports/models/account_generic_tax_report.py#L920-L932 After applying this commit will resolve this issue by assigning a fallback value of an empty string to col_value. sentry-5307746934
This update prevents an error when opening the restaurant mobile menu if the company has no country set. It helps keep the POS self-order flow working even when that company setting is left blank.
Original PR description
This issue arises when a user removes the `country` from their company and then attempts to open the `mobile menu` for the restaurant using the POS module. Steps to produce : - Install…
This issue arises when a user removes the `country` from their company and then attempts to open the `mobile menu` for the restaurant using the POS module.
Steps to produce :
- Install `pos_self_order` module.
- Navigate to Settings > User & Companies > Companies
- Open your company > Remove the country of your company.
- Now go to POS module open the `mobile menu` for the restaurant.
- Error will be generated.
See traceback :
```
IndexError: list index out of range
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1873, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/pos_self_order/controllers/self_entry.py", line 58, in start_self_ordering
**pos_config._get_self_ordering_data(),
File "addons/pos_self_order_epson_printer/models/pos_config.py", line 11, in _get_self_ordering_data
data = super()._get_self_ordering_data()
File "addons/pos_online_payment_self_order/models/pos_config.py", line 20, in _get_self_ordering_data
res = super()._get_self_ordering_data()
File "addons/pos_self_order/models/pos_config.py", line 335, in _get_self_ordering_data
"country": self.company_id.country_id.read(["vat_label"])[0],
```
This issue occurs because here
https://github.com/odoo/odoo/blob/78cbdc604ec6ef48ef291d354126d7b171eaec64/addons/pos_self_order/models/pos_config.py#L335 when try to access the `country_id` it will not get that because country was not selected in the company and also the country was not a required field.
sentry-4769344261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents backend crashes when a user enters invalid content while editing a report in Studio. Instead of failing silently or generating a server-side error, the editor now shows a user-friendly message so the issue can be corrected more easily.
Original PR description
Currently, an error is generated in backend when editing any reports in studio mode with an incorrect value or syntax. Steps to reproduce(edit a report of 'account' module to generate an error as an example): - Install an 'account' and 'web_studio' module. - Navigate to invoicing / Customers / Invoices and open a web studio mode. - Open reports and click any reports. - Click on 'EDIT SOURCES' to modify the report with incorrect values or syntax and an error will generated in the backend. To resolve the issue, we will add a try-except block at [1] to handle errors. This will ensure that if an error occurs during editing, it will raise a user error message and this error message will be seen in the report editor. link [1]: https://github.com/odoo/enterprise/blob/f94ca3f5ac02e932bb986c4f151733927acdd98c/web_studio/controllers/report.py#L666 sentry-5128667236
This update corrects an issue where the French Balance Sheet could become out of balance for companies using the 2024 chart of accounts. It ensures missing income and expense balances are still included when calculating retained earnings, so financial reports remain accurate and compliant.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well.
This update fixes an issue where clicking the Pack button in the purchase catalog could sometimes stop increasing the quantity, especially for products with decimal packaging sizes. It ensures the quantity is calculated more reliably so users get the expected number of packs every time.
Original PR description
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a…
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a product - Set a vendor "Mom" - Add a packaging of some decimal number, eg 22.68 - Create a new purchase from "Mom" - Open the catalog - Click the product once - Click the "pack" button 4 times (# of clicks required depends on the pack amount) > The last click did not increase the product quantity Cause ----- Javascript floats are sometimes an approximation of the value rather than the value itself. This means that when we do https://github.com/odoo/odoo/blob/0611a74cb52ca639b683ef158f8b4f2f347d08ad/addons/purchase/static/src/product_catalog/kanban_record.js#L33-L34 the flooring might sometimes get a close approximation and end up flooring down the packaging quantity. In our example, `this.productCatalogData.quantity` should be `68.04` but is actually `68.03999999999999`. This leads to `this.productCatalogData.quantity / packaging.qty` == `2.9999999999999996` `Math.floor` then rounds it down to 2 so we end up with 2 + 1 = 3, which is the current packaging quantity so nothing changes. ----- Ticket: opw-5130865
This fix ensures that a call is removed from the VOIP softphone as soon as it is unlinked. It prevents users from seeing outdated calls that have already been deleted, keeping the interface accurate and less confusing.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162