Daily updates from Odoo
Navigate
Branch
Wednesday, September 3, 2025
45 changes
13 changes
Enhancements to existing features
The Peruvian electronic invoicing setup has been updated to show Estela as the current provider name, replacing Digiflow references in labels, help text, and translations. This keeps user-facing configuration screens aligned with the provider’s new branding without changing how invoicing works.
Original PR description
This PR updates the Peruvian electronic invoicing configuration to reflect the recent brand change from Digiflow to Estela (formerly Digiflow). Changes: - Updated help texts and string labels in `res_company.py` - Adjusted references in `account_edi_format.py` - Updated translations in `es.po` This change is purely textual and does not affect logic or behavior. It ensures users see the correct branding across the Peruvian EDI settings. Forward-Port-Of: odoo/enterprise#93649 Forward-Port-Of: odoo/enterprise#85934
Payroll administrators can now manage salary inputs through reusable payroll properties, including boolean inputs. This makes payroll configuration more consistent across contracts, benefits, salary adjustments, and country-specific payroll rules, reducing manual setup and improving maintainability.
Original PR description
Task: 4930632
The Budget Report now uses the analytic plan name, such as Project, instead of the generic Account label when grouping information. This makes the report easier for customers to understand and reduces confusion when reviewing budgets.
Original PR description
In this commit: - Change the group by label from `Account` to the analytic plan's name (`Project`) for clarity in the Budget Report. This improves customer understanding and reduces confusion. task-5045530
Resolved issues and error corrections
French payroll settings now include the missing country information needed by the configuration screen. This prevents upgrade validation errors and helps ensure the payroll module updates reliably.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_error-231428
The update clarifies the wording shown for stock accounting settings, helping users better understand what each option does. This reduces confusion when configuring inventory and manufacturing accounting behavior.
This fixes a configuration issue in Lithuanian payroll settings so Lithuania-specific options are shown or hidden correctly. It helps prevent confusing settings from appearing in the wrong country context and supports a cleaner setup experience.
Original PR description
Add a related field in res.config.settings to expose country_code , Then the view condition invisible="country_code != 'LT'" will work. build_error-231410
The website generator now reliably stops its background status checks when users leave or the screen is closed early. This prevents unnecessary repeated server calls and avoids crashes that could interrupt the website creation experience.
Original PR description
In a component lifecycle, it may happen that onWillStart is called but not onWillUnmount. Indeed, if the component is destroyed before being mounted (because the current rendering has been cancelled), onWillUnmount isn't called. As a consequence, in the WebsiteGenerator component, the setInverval might never been called, thus producing an orm call every 10 seconds, when the component is destroyed. These calls lead to crashes ("Component is destroyed").
The solution is to use the onWillDestroy hook instead, which is always called.
Forward-Port-Of: odoo/enterprise#93679The shop floor now restores the user’s last selected work center when they return via breadcrumbs. This prevents confusing changes in the displayed work centers and keeps navigation consistent, while preserving the existing behavior when opening from Manufacturing work centers.
Original PR description
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app:…
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app: https://drive.google.com/file/d/1C1nVdDHgCss7s7zyXDOpbMj0k79HlJBH/view?usp=drivesdk Current behavior before PR: When leaving the shopfloor app via a WO (WO setting -> Open MO), we set the a **context flag workcenter_id** in the the currentCaller.action.context to save the selected workcenter for breadcrumb logic. The same **context flag workcenter_id** is used in the Manufacturing/workcenters view, when clicking on a workcenter. However, the intended use of the **workcenter_id flag** is different: - 1 From Manufacturing: Open shop floor with **only** workcenter_id selected + visible (no other workcenters visible). - 2 From Shopfloor breadcrumb : Go to shop floor with all previous workcenters same as when leaving. Additionally the current logic for setting the workcenter_id flag from the MrpDisplay record currently handles only the selection of isMyWO ([PR](https://github.com/odoo/enterprise/pull/52258)) Desired behavior after PR is merged: Keep the same behavior when coming from Manufacturing/workcenters ([PR](https://github.com/odoo/enterprise/pull/67318)) but make sure the user come back to same view when leaving shopfloor and coming back via breadcrumbs. task: [4629641](https://www.odoo.com/odoo/project/966/tasks/4629641) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#93483 Forward-Port-Of: odoo/enterprise#88073
The Malaysian Statement of Account now correctly converts foreign-currency invoice amounts into the company currency. This prevents customers and accounting teams from seeing misleading balances in the aged receivable PDF report.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#93096
Fixes issues in the salary offer form so users see cleaner messages and the correct contract template name when saving. This reduces confusion during salary offer preparation and review.
Original PR description
This commit contains few fixes for the salary offers form view: - Filter duplicate info messages - Avoid showing wrong name for contract template on save task-5030712
The employee form warning shown when a wage is below the Belgian minimum wage can no longer be edited. This prevents confusion and reduces the risk of accidental changes while still clearly alerting users to the issue.
Original PR description
When an employee’s wage falls below the minimum, the warning displayed on the employee form appeared with editable fields. This was misleading and could allow accidental changes. task-5051879 Forward-Port-Of: odoo/enterprise#93533
The Belgian POS blackbox integration now handles certain error responses from IoT devices more safely after data is pushed. This reduces unexpected crashes for users while a broader error-handling cleanup is planned.
Original PR description
Before this commit, it could happen that an error returned by the iot when contacting the blackbox was not correctly handled and led to a traceback. This commit solves the issue temporaly before finding a solution to harmonize the error handling in the blackbox. Forward-Port-Of: odoo/enterprise#93518 Forward-Port-Of: odoo/enterprise#93468
The website generator now again lets users choose a custom footer template, restoring an option that disappeared after the website builder refactor. This helps businesses keep their preferred website branding and layout when generating or editing website footers.
Original PR description
With the initial [website builder refactor], the possibility to select the custom footer template has been lost. This commit adds it again with a resource. Instead of modifying the view with the list of templates when one is created, it queries the server to know whether there is one [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
32 changes
New functionality added to Odoo
This adds the ability to generate rendered reports through an API, making it easier to connect Odoo reports with external services. Businesses can automate sharing documents such as invoices through different customer communication platforms.
Original PR description
Desired behavior after PR is merged: Allow users to get a render report by API to integrate different services. Ex: Get an invoice report to send to different customer by any platform --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a POS user searches for a customer and finds no match, the Create form now carries over the search text automatically. This reduces duplicate typing and helps staff add new customers more quickly by placing names or phone numbers in the right field.
Original PR description
If a user searches for a partner and no match is found, clicking "Create" will now automatically transfer the search term into the appropriate field (name or phone) in the creation form. The matched input is also auto-focused. Task-4991076 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
Enhancements to existing features
This update makes automated tests for Mail and Live Chat more stable by using clearer page markers instead of visual styling details. It reduces the chance of false test failures when the interface design changes, helping teams validate releases with more confidence.
Original PR description
This commit updates the test selectors to use data-as-tab-id to avoid ambiguity. This change enhances the robustness of the tests by reducing their dependency on CSS classes. Using data-as-tab-id attributes provides a more stable and reliable way to select elements in the DOM for testing purposes. backport - https://github.com/odoo/odoo/pull/224974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attachment uploads in Mail now use a smarter method to identify file types. This helps the system recognize uploaded files more accurately, improving reliability when users share attachments.
Original PR description
Before this PR, the route `/mail/attachment/upload` did not set any mimetype, which lets _compute_mimetype handle it. This PR makes use of `_from_request_file` since it's smarter to determine the mimetype. task-5060707
The Peppol demo bill shown when fetching incoming bills in demo mode has been replaced with a clearer, more representative example. This helps users better understand what to expect from incoming Peppol bills during demonstrations or testing.
Original PR description
Replace Peppol demo bill that you get when fetching incoming bills in demo peppol mode. Forward-Port-Of: odoo/odoo#225086
This change adds a new preparation step in the Point of Sale payment flow before an order is sent to the backend. It helps localization teams apply required country-specific adjustments more reliably at the right moment, reducing custom workarounds.
Original PR description
Hi guys, I hope you could help us with this very simple PR which targets `point_of_sale` module. After implementing PoS localization module for Serbia and working with other teams on implementing countless more, we found that the `point_of_sale` module is missing a good place to perform just in time transformation/operation on the current order before syncing it with the backend. People are managing to implement it in different ways with more or less success in covering some of the flows, but in our humble opinion we have found maybe the best point and it's a simple hook on the payment screen which should be called before the order sync is invoked. Enterprise Support Ticket: 5057437 Cheers, Petar --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo can now send message reactions made by users through WhatsApp, so customers see those reactions in their WhatsApp conversations. This keeps conversations more consistent across Odoo and WhatsApp and avoids missing customer-facing context.
Original PR description
Add support for sending reaction type messages via the WhatsApp API by introducing the `reaction` message type in the WhatsAppApi. This resolves the issue where reactions made by Odoo users are not reflected in the customer's WhatsApp conversation. API Documentation: https://developers.facebook.com/docs/whatsapp/cloud-api/messages/reaction-messages Task-4828394 Forward-Port-Of: odoo/enterprise#88520
Resolved issues and error corrections
The Discuss welcome screen now uses a shared application setting instead of temporary screen state to decide when it appears. This prevents inconsistent display behavior caused by page or component loading order, giving users a more predictable experience.
Original PR description
Before this commit, whether to display the welcome view was based on a component state, so it was dependent on the lifecycle of components This commit changes the condition so that it relies on the store which should prevent inconsistent state. https://runbot.odoo.com/odoo/error/111051
This update speeds up Odoo's internal test loading by avoiding an unnecessary tag check unless it is explicitly needed. It also helps prevent failures in environments where source files are not available, improving reliability for development and release validation.
Original PR description
`get_method_additional_tags` can be slow when there are a lot of test to load while the feature is only needed in rare cases. This commit removes the check if the corresponding tag is not in the config test-tags. This should also solve an issue when the sources are not available. Forward-Port-Of: odoo/odoo#225109 Forward-Port-Of: odoo/odoo#225061
The time off module now calculates mandatory leave days correctly when one or multiple leave requests involve one or multiple employees. This helps HR teams get accurate leave balances and avoid incorrect mandatory day counts.
Original PR description
- Fixed the calculation of leave mandatory leaves to account for one or multiple leaves for one or multiple employees Task-4804618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223349
This fixes a crash that could occur when employees had overlapping time off dates with different public holiday settings. HR teams can now update public holidays without disrupting approved leave records in these cases.
Original PR description
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to…
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to reproduce: ------------------- * Marc demo and Abigail Peterson using the same calendar * Create a "Paid time off" leave for marc demo: June 19 - June 20 * Create a "Extra time off" for abigail: same date * Update Time off type "Extra Time Off" to "Ignore Public Holidays" * Approve both leave request previously created * Create public holidays on June 19 --> traceback Observation: When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561 Why the fix: ------------ Added a new key on work_days_data to avoid the collision of two similar timeoffs. opw-4933820
This fixes a problem where some IoT boxes could be rejected when connecting to older database versions after an automatic version alignment. The system now sends both possible device identifiers, allowing existing boxes to be recognized and updated instead of being treated as a different device.
Original PR description
We are currently experiencing a bug with the image 25_07 build on saas-18.4 In this version the "identifier" used in iot app is the iot box's serial number In versions < 18.4 the identifier used is the iot box's mac address When connecting to a database in version 18.3 or less, the iot box: 1) Calls send_all_devices --> create a new iot box in the database with identifier = serial number 2) Runs git checkout to align itself to the database version 3) Calls send_all_devices again, this time with identifier = mac address 4) The database ignores the request because it considers it a new iot box with a different token This PR fixes the issue by sending both mac address and serial number to the database If the database has an iot box with the corresponding serial number as an identifier, it updates it. Enterprise PR: https://github.com/odoo/enterprise/pull/93657 Forward-Port-Of: odoo/odoo#225043
When a user is archived, their activities are now found and removed even if they belong to a company that is not currently selected. This prevents old user activities from lingering and keeps activity lists accurate in multi-company setups.
Original PR description
**Steps to reproduce:**
- Set up one user with a new company
- With this user :
- Create sale order
- Create activity on the new sale order
- Go back to the admin user
- Disable the new company in the top right menu
- Archive the user
- Activities of the user are still present
**Issue:**
In `activities_to_delete = self.env['mail.activity'].search([('user_id', 'in', self.ids)])`, the access rights of the records used in the activities are checked, which means that the sale order domains are applied. If the given domain doesn't match (for example `('company_id', 'in', company_ids)` when the company_id is manually disabled), the search can miss the activity to unlink.
**Fix:**
Added `.sudo()` to ensure all of the user's activities of any company
are considered, overwriting the current company context.
opw-4716031
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206813Reducing a subcontracted receipt to zero no longer cancels every related manufacturing order. This keeps the subcontracting process recoverable, so users can adjust the receipt again without breaking the purchasing and production flow.
Original PR description
Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
- BoM type: Subcontracting
- Subcontractor: Azure Interior
- Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO → 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt
Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.
Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.
opw-4792379
Forward-Port-Of: odoo/odoo#223858This change restores support for customized website editing permissions used on odoo.com, especially cases where users can edit only certain pages. It temporarily backs out a previous logic change while keeping the related test disabled until a more complete solution is found.
Original PR description
*: test_website This reverts commit [1]. Indeed, while it fixed the bug as intended while keeping the `_check_user_can_modify` feature, it apparently did not keep that one working in all cases: having partial view edition rights for some website.page (see uses in our Odoo.com customizations). While searching for a solution allowing to keep the fix of [1] and the whole purpose of `_check_user_can_modify`, the logic part of [1] is reverted, keeping the test but disabled. [1]: https://github.com/odoo/odoo/commit/8c41c147a4c6a415e7c5bfdde9297edbf40b4239 Forward-Port-Of: odoo/odoo#225160
This update fixes an internal test issue so standalone tests correctly verify the expected time-handling mode. It helps keep Odoo's automated quality checks accurate and reduces the risk of unnoticed test gaps.
Original PR description
Standalone tests don't enter faketime mode. Forward-Port-Of: odoo/odoo#224077
Guided tours now wait for the screen update to finish after an action, such as opening a menu, before moving to the next step. This prevents tours from jumping backward or failing when page content changes quickly, making onboarding and automated guidance more stable.
Original PR description
Step to reproduce: - Create a tour - Add a step that click on a menuitem on the systray with a view already opened - Then add a step that click on the search bar of the view Before this commit, if the step of a tour was triggering an action (e.g.: a menuitem) and that the next step's trigger was finding an element on the view before the action has finished to update the view, then the tour was backwarding because the found element diseppeared when the new action loaded the new view. Now, the tour interactive wait that the action manager finish to update the view to be sure the get the right element for the step trigger. ISSUE: https://github.com/odoo/odoo/issues/214652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a debit note now keeps the chatter history clear by avoiding duplicate log messages. Users will see only the relevant debit note creation message, reducing confusion when reviewing accounting records.
Original PR description
* PROBLEM: install account_debit_note module, add a debit note -> check the log at chatter we will see 2 message, one is 'This entry has been duplicated from ...' and another is 'This debit note was created from..' * Fix by only keep one message log in that case * This continue work of https://github.com/odoo/odoo/pull/214302 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
Installing Accounting with German localization and demo data could fail because cleanup of demo records was incorrectly stopped by audit trail protections. The fix allows the expected chart template unload process to proceed, so new demo databases can install Accounting successfully.
Original PR description
When installing the Accounting app on a new database created with Germany as country and with demo data loaded, the demo loader invokes in `account/demo/account_demo.xml` the `<function name="try_loading">` call which does a wholesale `records.with_context({MODULE_UNINSTALL_FLAG: True}).unlink()`. This cascades into deleting mail.message records, but the audit‑trail hook in only bypasses its check when the `bypass_audit` token is present not when `MODULE_UNINSTALL_FLAG is set causing a “You cannot remove parts of the audit trail” UserError.
Steps to reproduce:
- Created new database, with Germany as country
- Install l10n_de
- Download demo data
- Attempt to install Accounting application ! Receive error message
OPW- 4712364
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSelf-order kiosk table numbers are now preserved when an order is reopened and edited in the Point of Sale. This prevents preparation displays from replacing the customer-entered table number with a generic “IN” label, helping staff route orders correctly.
Original PR description
**Problem:** When making a purchase in the self order and put a table_stand_number, which is the table number you have to fill at the end of the order, it is displayed in the…
**Problem:** When making a purchase in the self order and put a table_stand_number, which is the table number you have to fill at the end of the order, it is displayed in the *pos_preparation_display*. But when loading this said order in the PoS, changing the order (like adding a note) and ordering it again, the table number is replaced by *IN*. **Steps to reproduce:** - Make a purchase in the kiosk - Put a table number at the end of the order - Go to the pos_preparation_display, it is displayed - Go to the PoS session of the Kiosk and load the order - Change the order by adding a note to it and order it again - The table number is replaced by IN in the pos_preparation_display **Why the fix:** The field *table_stand_number* was not given to PoS in any case, which means that when reloading the order and saving it again, it saved it without the *table_stand_number*, as it was never loaded. As it was never loaded, it went back to the fallback, which is writting *IN* if the table_stand_number was undefined. It is now loaded if the pos_self_order is installed, so that we can keep on showing the table number as it should be. opw-4943404 Forward-Port-Of: odoo/odoo#220869
This fixes an issue where changing the scheduled date for one product line on a receipt could unintentionally change the dates for other product lines. The change helps warehouse teams keep individual receipt schedules accurate when delivery features are installed.
Original PR description
### Steps to reproduce: - Install stock_delivery - Create and confirm a receipt for 2 products: - 1 x P1 - 1 x P2 - Modify the scheduled date of P1 to the day before - Save the picking #### Expected…
### Steps to reproduce:
- Install stock_delivery
- Create and confirm a receipt for 2 products:
- 1 x P1
- 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking
#### Expected behavior:
The scheduled date of the picking is updated but not the one of the other move.
#### Current behavior:
The the move scheduled date is also updated.
### Cause of the issue:
Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901
### Note:
This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38
opw-5017423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224986Imported vendor bills created from consolidated inter-company invoices now correctly connect to the related purchase orders. This helps users see the right purchase order links on bills when multiple orders are combined into one invoice.
Original PR description
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated…
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order ## Cause: The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"] https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374 ## Steps to reproduce: - Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies - Create and Confirm two Sales Orders from one company to the other one - Create a Consolidated Bill for both S0 - Send the Invoice (Download) - Switch to the second Company - In Purchase, Confirm both RFQ - In Accounting > Vendor > Bills, Upload the downloaded bill - The Smart Button isn't linked to the PO Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707) opw-4690707 Forward-Port-Of: odoo/odoo#223398
The wishlist checkout test now allows more time to finish, reducing false failures when the process runs slowly. This helps keep automated validation stable without changing the customer-facing wishlist experience.
Original PR description
Increase timeout for wishlist tour. As it was taking too long to complete. runbot-229616 Forward-Port-Of: odoo/odoo#219653
Users can now cancel a deletion confirmation and click delete again on the same item without the dialog getting stuck. This restores expected behavior for deleting items such as project subtasks and product attribute values, reducing confusion and failed deletion attempts.
Original PR description
### Description of the issue/feature this PR addresses: Behavior in <= v17.4: The onclick method for the delete button in the one2many list calls the `onDeleteRecord` method. This is inherited by the…
### Description of the issue/feature this PR addresses: Behavior in <= v17.4: The onclick method for the delete button in the one2many list calls the `onDeleteRecord` method. This is inherited by the model-specific list renderer components to insert the deletion confirmation dialog before calling super which sets the clicked data attribute to be true. In this case, we display the dialog before setting the button as clicked. Behavior in v18: The onclick method for the delete button in the one2many list calls the `onRemoveCellClicked`. This method sets the clicked as True and then calls the `onDeleteRecord` method that is inherited by the various model-specific list renderer components to insert the Confirmation Dialog. In these cases, the dialog is called after we set the 'clicked' data-attribute on the delete button to be True. Hence now we are unable to click on the same button again due to it being in the clicked state. ### Current behavior before PR: [Deletion Dialog does not reopen](https://github.com/user-attachments/assets/29b6c2c7-553b-4745-a20b-26a470952a01) 1. Try to delete a record of Project Subtask or Product Attribute Value 2. This would open the Deletion Confirmation Dialog box 3. Click on cancel 4. Try to delete the same record again Result: Nothing happens and the confirmation dialog does not show up again for the second time ### Desired behavior after PR is merged: If user attempts to delete any record that opens the confirmation dialog and then cancels it, the user is able to delete it as the confirmation dialog box is no longer disabled after spawning once. opw-4731375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Indian e-waybill stock view now shows errors and warnings with the correct alert colors, making important messages easier to understand. Access errors are also handled more reliably, reducing confusion when users encounter permission-related issues.
Original PR description
Before: --- Error and warning colors were mismatched in the e-waybill view. In this commit: --- Fixed the e-waybill view to correctly display error messages - Errors now display in red (alert-danger) :red_square: - Warnings now display in yellow (alert-warning) :yellow_square: AccessError now handled correctly. --- task-5050937 Forward-Port-Of: odoo/odoo#225078
The signature dialog now avoids showing auto-generated and hand-drawn signatures on top of each other. This prevents a confusing visual overlap and makes signing documents cleaner for users.
Original PR description
Fixed an issue where both the auto-generated and drawn signatures overlapped in the signature dialog. This was caused by the system automatically setting the user's default signature to the drawn one when opening the dialog. Now, the dialog no longer defaults to the drawn signature, preventing visual overlap and ensuring a cleaner user experience.
This update fixes an automated Planning app test by using today's date directly when editing schedule data. It helps keep quality checks stable so future changes can be validated reliably before release.
Original PR description
Now the tour use edit with the date of today and not a function runbot build error: 164213
Users no longer encounter an error when trying to link a document to a vehicle or other record type that has no existing records. The system now prevents the unsupported link action instead of opening a wizard that would crash, improving reliability in empty setups.
Original PR description
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet`…
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet` module(without Demo Data). 2) Open Documents App. 3) Upload a file in `Fleet` folder. 4) Select the uploaded file and click on `'Link to a vehicle'` button. Error: `ValueError: invalid literal for int() with base 10: 'False'` Root Cause: The `link_to_record` method attempts to find the first record of the target model to use as a default value when opening the linking wizard. If no records exist, the search returns an empty recordset, and accessing `.id` at [1], on it results in the value `False`. The code then incorrectly constructs a default reference string like `fleet.vehicle,False`. The wizard crashes when it tries to parse this string and convert the `False` part to an integer. Solution: This commit prevents error by ensuring that the user cannot link a document to a model without existing records. [1]- https://github.com/odoo/enterprise/blob/83640d21b2c31ed9d572c48e02a9aeea9eb1607b/documents/models/documents_workflow_rule.py#L113 sentry-6792079496 Forward-Port-Of: odoo/enterprise#91888
Spreadsheet ownership is now restricted so portal users cannot become owners when they are not allowed to edit shared spreadsheets. This prevents permission issues and keeps spreadsheet access aligned with internal user rules.
Original PR description
Following the discussion I had with @flch-odoo regarding https://github.com/odoo/enterprise/pull/92134 , Since Spreadsheets can not be shared in edit mode to non-internal users, we prevent them from becoming owners. opw-4753670
Danish Intrastat and EC Sales List reports now round values to whole units where required for official reporting. Users can still view decimals in the interface when needed, while government export files are consistently rounded for compliance.
Original PR description
This commit will change the options of the reports so that we have a rounding in units since the intrastat and ec sales list report must be rounded. This solution still allows people to have the report with decimals if needed task-4948271 Forward-Port-Of: odoo/enterprise#91268
This update prevents IoT boxes from being treated as new devices when they connect to older database versions after a software image update. By matching both the serial number and MAC address, existing IoT boxes keep their connection and avoid duplicate or ignored registrations.
Original PR description
We are currently experiencing a bug with the image 25_07 build on saas-18.4 In this version the "identifier" used in iot app is the iot box's serial number In versions < 18.4 the identifier used is the iot box's mac address When connecting to a database in version 18.3 or less, the iot box: 1) Calls send_all_devices --> create a new iot box in the database with identifier = serial number 2) Runs git checkout to align itself to the database version 3) Calls send_all_devices again, this time with identifier = mac address 4) The database ignores the request because it considers it a new iot box with a different token This PR fixes the issue by sending both mac address and serial number to the database If the database has an iot box with the corresponding serial number as an identifier, it updates it. community PR: https://github.com/odoo/odoo/pull/225043 Forward-Port-Of: odoo/enterprise#93657
This fix ensures a quality control test has the required serial number printing permission when run without demo data. It prevents false test failures in isolated module runs, improving reliability for maintenance and validation workflows.
Original PR description
## Issue:
The test `test_receipt_validation_triggers_serial_number_label_print` fails when running `quality_control` alone without demo data
## Cause:
The user is missing the group `stock.group_production_lot`, that enable serial number printing
As a result, the condition `self.env.user.has_group('stock.group_production_lot')` in `stock.picking` `_get_autoprint_report_actions()` is not satisfied
The `button_validate()` in `stock.picking` will have an empty report_actions and will not print anything
The Demo data that allow the test to work is in `stock`
https://github.com/odoo/odoo/blob/9b08449f25cd16dc15117d305726380298c313d8/addons/stock/data/stock_demo.xml#L176-L182
## Steps to reproduce:
- Install only `quality_control` (no demo data)
- Run the test `test_receipt_validation_triggers_serial_number_label_print`
related-to: https://github.com/odoo/enterprise/pull/90134
opw-4790427