Friday, November 21, 2025
26 changes · saas-18.3
Enhancements to existing features
This update corrects how tax values are calculated in Indonesian Coretax e-faktur files so they match the right tax groups instead of relying on invoice type in some cases. It also adds a validation to block invalid tax combinations when generating the XML, reducing the risk of incorrect tax reports and exports.
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#236821 Forward-Port-Of: odoo/odoo#233347
This change clears out existing UrbanPiper menu connections and rebuilds them with a fresh synchronization. It helps ensure the menu data sent to UrbanPiper stays accurate and avoids issues caused by outdated links.
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#98994
The customer subscription portal now reads available billing periods dynamically instead of relying on a fixed list. This prevents errors when businesses use custom billing periods, such as daily subscriptions, and makes the portal more resilient to future configuration changes.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#99207
The system now waits longer between homepage data updates when a browser tab stays open, instead of checking too frequently at first. This reduces unnecessary requests to the IoT Box and helps keep it more responsive over time.
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. Forward-Port-Of: odoo/odoo#236664
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
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
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
This change stops users from creating the same request for quotation more than once when they have multiple tabs open or when several people view the same approval. It prevents duplicate purchase quantities and avoids errors caused by accidentally updating an RFQ that already exists.
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
When creating a restaurant booking from the point of sale, all tables chosen on the form are now saved correctly. This fixes an issue where only one selected table could end up attached to the booking, which could cause seating mismatches and confusion for staff.
Original PR description
Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved. Steps to reproduce: ------------------- * Open the restaurant * Open booking tab…
Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved. Steps to reproduce: ------------------- * Open the restaurant * Open booking tab * Create a new booking for 3 people * Select 2 tables of 2 capacity * Save > Observation: Only one table resource is saved Why the fix: ------------ By having the context key `default_resource_total_capacity_reserved` we would recompute the resources for the booking. It was recomputed in a way that we just une the minimum resources needed in regards of the resource capacity. For example if we had 3 tables of 2 and we are booking for 3, we wouldn't need the 3rd extra table. In our case the capacity was always set to 2, as the point of sale form actually uses the field `waiting list capacity`. Since most table are usually for at leat 2 people only 1 would be needed. Removing `default_resource_total_capacity_reserved` from the context gives more freedom upon reservation and does not compute resources, it uses those selected on the form. opw-5109501 Community: https://github.com/odoo/odoo/pull/230920
This change fixes the annual corporate tax return so it uses the company’s actual fiscal year dates, even when the fiscal period is longer than one year. As a result, the dashboard now shows the correct annual closing and deadline, avoiding incorrect entries for the wrong year.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432
This update corrects a display issue in the Documents app where some controls could overlap, making the file details area harder to read and use. It also hides an action in the activity view that was no longer functioning, improving overall usability and reducing confusion for users.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112
This change fixes an issue in the point of sale localization tests that could cause automated checks to fail during builds. It helps keep localization-specific POS features validated reliably, reducing unnecessary runbot failures.
Original PR description
Fix runbot issue runbot-233183 Forward-Port-Of: odoo/enterprise#99832 Forward-Port-Of: odoo/enterprise#99370
This update removes a fragile step from the generic Point of Sale localization test where the PoS was being closed at the end. That closing step was often unstable and slow in larger setups, so removing it makes the test run more reliably and finish faster.
Original PR description
backport of : https://github.com/odoo/odoo/pull/231884 Remove the closing of the PoS in the tour as it is really unstable and fail a lot. It's mostly due to the fact that the PoS take a long time to close with a lost of modules installed. This will also make the tour faster. runbot-233183 Forward-Port-Of: odoo/odoo#236372 Forward-Port-Of: odoo/odoo#234310
This update fixes the calculation of line totals when importing Italian EDI vendor bills or credit notes that include a Maggiorazione (MG) discount. It prevents the amount sign from flipping incorrectly, so totals are now shown and computed correctly.
Original PR description
Since commit #206238, discounts of type "MG" (Maggiorazione) caused the line total amount sign to flip, leading to incorrect calculations of the total amount. **Steps to reproduce:** - Import a vendor bill/credit note XML (Italian EDI). - Include a line with a Maggiorazione discount. - The line total amount currently appears with the wrong sign and/or amount. Ticket [link](https://www.odoo.com/odoo/project.task/5220218) opw-5220218 Forward-Port-Of: odoo/odoo#236300
The stock forecast now uses the actual completed quantity of a transfer instead of the originally planned quantity when a move is marked done. This prevents incorrect negative or leftover quantities from appearing in the forecast after receiving less or more than expected.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
Anchor links with the “Open in New Window” option enabled now correctly open in a new tab instead of staying in the same page. This fixes the browsing behavior users expect and makes website links work consistently across desktop and mobile views.
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#236783 Forward-Port-Of: odoo/odoo#228787
Planning and timesheet analysis reports now correctly respect employees’ working hours when calculating planned time. This prevents shifts that cross into a new month outside working hours from being counted in the wrong month, improving report accuracy.
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
The vendor on-time rate now uses the original purchase order quantity instead of a recalculated stock move quantity. This fixes a mismatch between the smart button and the graph, so vendor performance figures are accurate and consistent.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#236779 Forward-Port-Of: odoo/odoo#225529
This update corrects how the mail module simulates browser platforms in its tests. It ensures the test setup uses the expected platform value, which helps keep automated checks accurate and reliable.
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/odoo#236837This change allows users to create reordering rules for a product in one company even if that product has a kit bill of materials in another company. It prevents an incorrect validation error and makes multi-company behavior more consistent.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
This update restores the missing date filtering on certain Balance Sheet lines in the Syscohada reports. It helps ensure the report shows figures for the selected period consistently, reducing the risk of confusing or incomplete financial output.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
This change updates the Adhoc Contributor License Agreement documentation with new members. It matters because it keeps the legal records current for contributor onboarding and project governance.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227891