Daily updates from Odoo
Friday, November 21, 2025
50 changes · 19.0
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
Enhancements to existing features
This change reduces the time needed to validate stock movements by avoiding repeated calculations of the same location data. It improves performance for movements that trigger putaway checks, making large inventory operations noticeably faster.
Original PR description
Previously when validating a movement with a location that is used in a rule, move_dest_ids was set which led to it going to check the putaway strategy. The bottleneck was the computation of the computed field child_internal_location_ids which is the same across all smls. This PR utilizes the fact that the smls in the same stock_move would have the same destination location and by proxy the same child_internal_location_ids Speed up: 1000 stock move lines: Before: 2 mins After: 1 mins --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233467 Forward-Port-Of: odoo/odoo#210142
This change simplifies how Odoo automatically converts database fields during upgrades. It avoids unnecessary recalculation work and keeps database constraints intact, which makes upgrades faster and reduces the risk of unexpected side effects.
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#236299Automatic reconciliation will now pick the most suitable earlier or same-day entry when there are several possible matches instead of stopping without action. This should reduce manual follow-up and make bank statement processing smoother.
Original PR description
When having multiple candidates with the try_auto_reconcile we used to do nothing since there was a doubt. This commit will slightly change that by selecting the move line with the closer prior or equal date. task-5212876
This update makes the manufacturing work order finish process much faster by avoiding repeated calculations and duplicate database updates. As a result, large batches of work orders complete more reliably and with far less memory usage.
Original PR description
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However,…
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However, this filtering was performed inside a loop iterating over all work orders, even though the result of the filtration did not depend on any single work order. Before this commit: - The filtration was executed repeatedly for each work order, despite being deterministic. - This unnecessary repetition caused performance degradation and multiple redundant updates to the `picked` field of the same moves, resulting in fake or redundant database writes. After this commit: - The filtration logic has been moved outside the iteration, ensuring that the update to the moves is performed only once, improving overall performance and preventing redundant updates. - The `end_all` method is now executed on the entire recordset of work orders at once, instead of being called individually for each iteration. The benchmark below is done on a recordset of workorders of size **500** and the number of moves returned from the filter were **100**. It set the picked field to be **True** for every workorder in the recordset, potentially triggering recomputation of some of the fields and doing more redundant SQL queries. opw-5092636 ### Benchmark Results | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **Memory Error** | **After this Commit** | **22 seconds** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235405 Forward-Port-Of: odoo/odoo#233102
The Indian tax reports were updated to remove a section that is no longer needed. This also keeps report output cleaner by hiding lines when they have no value, reducing unnecessary clutter for users reviewing the reports.
Original PR description
Since the `purchase_b2c_regular` GSTR section is no longer required, this commit updates the related domain logic and hides the corresponding report lines when their value is 0. Related PR: https://github.com/odoo/odoo/pull/236241
The Partner VAT Listing now excludes exempt transactions that were previously shown as 0% taxes in some cases. This brings the report in line with Belgian VAT rules by distinguishing exempt operations from taxable ones, even when the tax rate is zero.
Original PR description
Currently, the behavior is wrong and 0% taxes appear in the report (if the cumulative base for a partner is > 250) A distinction needs to be done here. The operations are taxable (even at a zero rate) or exempt. We shall rely on the Tax Category Code (E = Exempt) When a tax belongs to E, it cannot appear in the Partner VAT Listing. It is exempt from taxation. It does not open the right to deduction of vat on purchases. task-5269970
The GST purchase report no longer includes the "purchase_b2c_regular" section because unregistered vendors cannot use regular GST taxes. This simplifies the report and keeps the remaining categories aligned with how these transactions actually work, including overseas cases covered elsewhere.
Original PR description
Unregistered vendors cannot apply regular GST taxes, making the `purchase_b2c_regular` GSTR section unnecessary. Additionally, `purchase_cdnur_regular` will also cover only overseas cases. With this commit, the `purchase_b2c_regular` section will be removed. Relateed PR: https://github.com/odoo/enterprise/pull/99777
This change makes sign template fields easier to extend or adapt in future updates. It helps maintainers and partners add or adjust fields with less risk of breaking existing behavior, improving flexibility for custom setups.
Original PR description
Introduced a dedicated _getTemplateFields() method to make easier to override or extend the fields in patches. Forward-Port-Of: odoo/enterprise#95722
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
This fix prevents the barcode app and quality checks from asking users to handle products that were not actually picked, or lot/serial-controlled items that are not yet fully identified. It makes the quality-check flow match what will really be validated, reducing confusion and avoiding unnecessary steps during receipt processing.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764
Forward-Port-Of: odoo/enterprise#99736
Forward-Port-Of: odoo/enterprise#99565The point of sale integration now checks which version of the Swedish blackbox protocol is supported before sending commands. This prevents receipt registration errors 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
The Point of Sale now opens the product configurator even when a product only has one option, if that option includes a free-text field. This ensures staff can enter customer-specific text for products that require customization instead of being blocked by a missing input screen.
Original PR description
**Steps to reproduce:** - Make a new product, make a single variant with a single value for it - The variant value should have the Free Text checkbox enabled - Go to PoS, click on said product - The product configurator will not be displayed, so there is no way to write on this Free Text field **Why the fix:** Before this commit, we did not display the product configurator if all variant attributes were single choice, because it did not make sense to show it just for the user to click on confirm. But this did not account for the fact that if a Free Text option is enabled, we should still display it, so that the user can write whatever they want on it, even if it is the only option available. We now display the product configurator in all cases where a Free Text field is present, as we need the customer to be able to fill it, even if it is the only available option. opw-5133743 Forward-Port-Of: odoo/odoo#231476
This change prevents browser warning popups from interrupting website test tours when a page redirects or reloads. It also adjusts a few tour selectors so the automated tests run more reliably, reducing delays and false failures.
Original PR description
During page redirection in tours, the browser was showing a warning about unsaved/incomplete data loss. This warning is not relevant in the context of tours. To address this, the expectUnloadPage attribute is added to the tour test. It prevents unnecessary pauses/timeouts caused by the browser’s warning and ensures smooth redirection handling. Additionally, few tour selectors have been corrected to improved. runbot-231587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226102
This change prevents an error that could appear when uninstalling the Databases module. It restores the correct access rule so the uninstall process completes cleanly without leaving behind a broken reference.
Original PR description
Currently an error occurs when user uninstalls the `databases` module. **Steps to replicate:** * Install and uninstall databases **Error:** `ValueError: Invalid field project.project.database_hosting…
Currently an error occurs when user uninstalls the `databases` module.
**Steps to replicate:**
* Install and uninstall databases
**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`
**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.
**Solution:**
* Revert the domain back to the one defined in project module.
[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26
sentry-7035410943This fix ensures that when a manufacturing order’s planned output quantity is changed in Barcode, the related material consumption is correctly updated. It prevents mismatches between what operators enter and what is actually consumed, improving accuracy in production tracking.
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
This change prevents users from generating or updating a Request for Quotation more than once from the same approval request. It avoids accidental duplicate quantities when the action is clicked again from another tab or by another user.
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 fix ensures that sales orders linked to a Point of Sale refund update their invoiced quantity correctly in the backend. It prevents cases where the sales order still showed the original invoiced amount after a refund, which could lead to inaccurate reporting and customer/order tracking.
Original PR description
When doing a refund of a POS order linked to a SO in the backend, the qty_invoiced on the SO line is not updated correctly. Steps to reproduce: ------------------- * Create a SO with 1 quantity of any product * Settle the SO in the PoS * Refund the PoS order from the backend not from the PoS interface * Check the qty_invoiced on the SO line > Observation: The qty_invoiced is still 1 Why the fix: ------------ The method _compute_qty_invoiced was not triggered when the refunding order was paid. So we need to add a new dependency on the function. Note: ----------- In the test we need to flush all before doing the payment of the refund, because if we do not do it, the _compute_qty_invoiced method would be called during the payment. But that is not the case outside of the test. This is just to ensure that the test fails correctly without the fix. opw-4991405 Forward-Port-Of: odoo/odoo#236379 Forward-Port-Of: odoo/odoo#231840
This fix corrects how Maggiorazione (MG) discounts are handled when importing Italian EDI vendor bills and credit notes. It prevents the line total from being flipped to the wrong sign, ensuring invoice totals are calculated 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
This update fixes a website editor issue where shape previews could stay stuck after moving the mouse away, especially when image hover effects were enabled. It ensures the preview correctly returns to the original image so editors see the right shape and settings while working.
Original PR description
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop…
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop a text-image snippet onto the page. - Then add a hover effect to the snippet image. - Open the image shape selector and hover over the shapes. => Bug: the preview is broken; when the mouse leaves a shape, the original shape is not reset. Same issue with other options when there is a hover effect on an image (e.g. "image Filter"). Current flow is: We are previewing shape -> img src is changed -> `originalImgSrc` in `ImageShapeHoverEffect` interaction is changed -> we revert preview -> img src is reverted, but MutationObserver doesn't change `originalImgSrc` immediately, and when reverting a step, we stop the interaction -> destroy is called and image source is set to `originalImgSrc`, but it is the old one with a shape. We want to update the `src` only if it is currently the one that we set as hovering. [commit]: https://github.com/odoo/odoo/commit/80b5db99a3c26c3dd4fb5c55e04b8813dddb5b8d task-5207382 Forward-Port-Of: odoo/odoo#233381
This fix corrects how amounts are handled when converting between invoices and credit notes with storno enabled. After the change, the values stay on the correct debit or credit side and only their sign changes, which prevents wrong accounting amounts from appearing.
Original PR description
This commit fixes the amounts of move lines when converting from invoice to credit note and vice versa when storno is enabled. Previously, when converting from invoice/credit note, the amounts remained negative and switches from debit/credit. The quantities should remain in same debit/credit position and only change sign as I switch from invoice/credit note. task-5226311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234027
This change lets portal users comment on opportunities they can already view. It fixes a case where they could read the record but were blocked from sending a message, improving collaboration and follow-up.
Original PR description
When we want to post a message, we check that the user has access to the thread, i.e. we check access for the `crm.lead` record with the `write` operation. It is therefore necessary for the group portal to be able to post message on the `crm.lead` record (opportunity) he can read by adding `_mail_post_access` with the `read` operation.
This fix ensures the cost of goods sold for kits is calculated using the product’s own base unit of measure, even when the sales order uses a different unit. This prevents inaccurate cost values in accounting when selling the same kit in another unit.
Original PR description
Steps to reproduce: - Make a kit in uom A - Sell that kit in uom B Issue: The cogs price_unit will be computed in the SO line's uom rather than based on the kit's default uom. Harmonize the code so it's clear that `_get_cogs_value()` is always expected to give the unit price in the product's base uom, not in the uom of the account move line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes unwanted decimal noise in editable budget fields in Profit & Loss reports. Users will now see the same rounded amount when editing a budget cell as they do when viewing it, which makes the report easier to use and avoids confusion.
Original PR description
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the…
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the correct rounded value. **Steps to Reproduce:** 1. Go to Accounting → Reporting → Profit and Loss Report 2. Enable Column Budget 3. Enter budget value: 5.00 4. Save → Value displays correctly as: 5.00 ✓ 5. Click to edit the same cell 6. Input field shows: 5.000000000174602 ✗ (instead of 5.00) 7. Save without changes → Display shows: 5.00 ✓ 8. Edit again → Still shows: 5.000000000174602 ✗ **Root Cause:** The frontend reads from cell['no_format'] when populating the edit input field. This field receives the raw column_value which contains floating-point precision errors accumulated during aggregation operations. While the display formatting applies rounding, the edit mode receives the unrounded value. **Solution:** Round column_value using float_round() immediately after detecting an editable budget column, before the value is used anywhere. This ensures both the display path and edit path receive the same properly rounded value based on the company's currency decimal places. opw-5158862
Manufacturing order catalogs will now only show consumable products for components and by-products. This prevents users from adding service-type items that cannot be stocked, consumed, or produced, and removes an unnecessary Services filter from the catalog.
Original PR description
Issue: ====== User can add `service type` products in the MO catalog which is not valid. When we manufacture the products, allowing service products in the MO catalog is not valid. These products are…
Issue:
======
User can add `service type` products in the MO catalog which is not valid.
When we manufacture the products, allowing service products in the
MO catalog is not valid. These products are not stockable or traceable,
and therefore cannot be consumed as raw materials or produced as by-products.
How to reproduce:
=================
1. Install mrp.
2. Create MO.
3. Open catalog for `Components` or `By-Products`.
4. User can add `Service` type products from here.
Cause of the issue:
===================
- Domain for product catalog doesn't contain `('type', '=', 'consu')`.
Solution:
=========
- Added `('type', '=', 'consu')` in product catalog domain.
With this commit, users can now select only consumable products from the
`Add a line` or `Catalog` in the MO `Components` and `By-Products` sections.
Also removed the `Services filter` from the MO catalog, since there are
no service-type products in the catalog, so it doesn’t make sense to
keep this filter.
TaskId : 4904067This fix keeps the preparation display updated when staff transfer, merge, link, or unlink table orders. It also prevents duplicate preparation records from being created when orders are adjusted, helping kitchen screens match the POS more reliably.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/enterprise#98374
This update ensures that restaurant table actions like transferring, merging, linking, or unlinking orders properly update the kitchen preparation screens. It also prevents duplicate preparation records from being created when orders are adjusted, helping keep POS and kitchen information consistent.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/odoo#233630
This update fixes an issue where vendor credit notes could be rejected by MyInvois when the original bill had a custom reference. The system now uses the reference stored with the submitted e-invoice, which helps ensure the reversal document matches what the tax system expects.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference…
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#235026 Forward-Port-Of: odoo/odoo#234199
When a vendor bill email contains multiple image attachments, Odoo now checks whether each attachment group is actually useful before creating additional bills. This avoids creating unnecessary records and helps reduce wasted processing costs and database clutter.
Original PR description
Steps to reproduce: - Set up email alias for Vendor Bill journal - Send email with N images alias Issue: <N> Bills are created, in each one we will attempt to extract the image content to enrich the bill. Analysis: This occurs because we split the attachment list into several groups, each one creating a new invoice (except the first). However we don't take into account if the attachments are actually meaningful. In many cases this behavior will pollute the database and waste iap credits. This commit proposed to evaluate if in each group there is at least a meaningful attachment before creating/extending an invoice opw-5076315 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/5076315) Forward-Port-Of: odoo/odoo#234913
Fixed an issue in website anchor links where the "Open in New Window" option was being ignored. Users will now be taken to the linked section in a new tab, matching the setting they chose and avoiding unexpected same-tab scrolling.
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
This fix prevents a kit bill of materials in one company from incorrectly blocking reordering rule creation in another company. It ensures Odoo only checks kit bills of materials that belong to the same company, or are shared across companies, which avoids unnecessary validation errors.
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 change makes an automated stock picking batch test wait for the correct step to finish before moving on. It prevents the test from failing at random, which helps keep the stock workflow checks stable and reliable.
Original PR description
The commit a4f4d8c7d8e37 made this test fail undeterministicall. This commit enforce the triggers to be sure each step is correctly executed. Runbot : 234227 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the invoice layout change for Argentina more specific so it no longer clashes with a separate accounting-related customization. It helps ensure that reports display correctly without unintended side effects from overlapping updates.
Original PR description
The xpath of the line colspan was not precise enough. Since a change needs to be done in account_intrastat (check enterprise pr), those xpath conflicted. opw-5185296 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
The replenishment info wizard now counts more in-progress stock moves when estimating daily demand. This makes the demand calculation closer to other purchasing views and helps produce more accurate replenishment suggestions.
Original PR description
In the replenishment info wizard, the daily demand based on previous periods of time only takes 'done' moves into account. This is different from the purchase catalog which also takes 'assigned', 'confirmed' and 'partially_available' moves. This PR adds those 3 states in the domain when searching for moves. task 5219526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects the placement of amounts in the Intrastat invoice report when both section lines and the country of origin column are used. It ensures the report layout stays aligned and easier to read.
Original PR description
Before this commit when having section and the country of origin column, the amount was is the wrong place. The solution is to add 1 to the line colspan when display origin is set. opw-5333624
When an e-invoice request is rejected by ETA, Odoo now handles the response more gracefully instead of showing a traceback. This improves the user experience by turning a technical failure into proper error handling.
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 method definitions found in several areas of the codebase. It helps keep the system easier to maintain and reduces the risk of inconsistent behavior in payroll and expense-related features.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
This update makes record access checks use the same rules everywhere, regardless of a specific context setting. It prevents inconsistent access behavior and helps ensure users see and can act on records as expected.
Original PR description
Since https://github.com/odoo/odoo/pull/219703, we ir.rule domain doesn't depend on active_test context key. But `_check_access` is still depending on active_test which is not consistent. Fix it.
Odoo now uses the current official code for Odisha, changing it from the outdated "OR" to "OD". This helps ensure contacts and sales documents use the correct state information for India.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
This update keeps Odoo’s code quality checks compatible with newer pylint/astroid versions and removes a few outdated compatibility paths. It also fixes a couple of test-related false alarms so the validation tools run more reliably across supported environments.
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
Documentation and clarification updates
This change updates the corporate contributor agreement record for Moduon. It is an administrative/legal update and does not change product behavior for users.
Original PR description
@moduon MT-12696 Forward-Port-Of: odoo/odoo#236642
This change updates the Adhoc CLA document to include additional members. It keeps the agreement records current so contributor onboarding and compliance remain accurate.
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
Miscellaneous changes
Some lines were improperly marked for translation. Also delete some extensions that weren't used in the end for cleaner code + to wipe all traces of the improper translation marking. 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
Original PR description
Some lines were improperly marked for translation. Also delete some extensions that weren't used in the end for cleaner code + to wipe all traces of the improper translation marking. 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
Module was added in stable => needs to be manually added to weblate.json file
Original PR description
Module was added in stable => needs to be manually added to weblate.json file