Friday, November 21, 2025
30 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
Resolved issues and error corrections
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…
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 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
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
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 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
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
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
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 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.