Daily updates from Odoo
Friday, November 21, 2025
37 changes · 19.0
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