Daily updates from Odoo
Friday, November 14, 2025
96 changes · 19.0
New functionality added to Odoo
This update adds the Spain-specific periodicities and filing deadlines for Intrastat returns. It helps ensure Spanish Intrastat reports follow national rules and stay aligned with other European localizations.
Original PR description
Introduce the country-specific periodicities and deadlines for Intrastat returns in the Spain localization, as part of the new tax return feature added in 18.3. This ensures that Spanish Intrastat reports comply with the national requirements and aligns the localization with other European implementations. Task-4987876
Enhancements to existing features
This update switches several test checks to a more precise text-matching method. It helps make automated tests clearer and more reliable without changing how the product works for users.
Original PR description
This commit replaces all found occurrences where ':contains' (with an exact match regular expression) could be replaced by ':text'. Community: https://github.com/odoo/odoo/pull/234331 Forward-Port-Of: odoo/enterprise#99272 Forward-Port-Of: odoo/enterprise#98772
This change clears the blackbox processing queue whenever point-of-sale data is reloaded. It helps prevent rare situations where queued requests could keep repeating and cause the POS to become unresponsive.
Original PR description
This commit adds a clear of the blackbox queue when reloading data. This could avoid potential unexpected deadloop of calls in the queue. Forward-Port-Of: odoo/enterprise#99252
This update adds a new exact-text selector for automated UI tests, making test expressions easier to read and write. It also updates existing tests to use the clearer form, which improves maintainability without changing business behavior.
Original PR description
This commit adds the ':text()' pseudo-class to the list of supported pseudo-classes in Hoot selectors. Its purpose is the same as ':contains()', with the specificity of being an *exact* match instead of a *partial* one. It effectively replaces ':contains(/^<expression>$/)' by ':text(<expression>)', improving the readability and making the developer experience a bit nicer. Enterprise: https://github.com/odoo/enterprise/pull/98772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235295 Forward-Port-Of: odoo/odoo#234331
This change removes the need for the Sign app to be installed for the accountant knowledge features to work. It simplifies setup and reduces unnecessary dependency between products, while keeping the related templates and embedded signature elements available where needed.
Original PR description
task-5154292
When Do Not Disturb is enabled, incoming calls will no longer open the softphone window, reducing unnecessary interruptions. The call status label also now shows “Calling…” while a call is being placed, making call progress clearer for users.
Original PR description
Before this commit, enabling `Do Not Disturb` mode only muted incoming rings, but the softphone still popped up on incoming calls, which could be distracting. Now, when `Do Not Disturb` is active, the softphone is not displayed at all. task-5262271
The “Pay on Site” payment option is now published automatically when it is created for Click & Collect. This removes a manual step for businesses and helps ensure customers can complete on-site payment without extra setup.
Original PR description
As of commit 397b9c26, the "Pick up in store" delivery method supporting Click & Collect is automatically published when created if existing warehouses are found. However, the associated "Pay on Site" payment provider was enabled but left unpublished, requiring users to manually publish it to allow on-site payment in the Click & Collect flow. This commit auto-publishes the "Pay on Site" payment provider when it is created, even if the "Pick up in store" delivery method could not be published, as customers won't be able to use the former to pay anyway.
The point-of-sale now shows clearer guidance when the fiscal device is disconnected or when a social security number is required but missing. This helps staff quickly understand what went wrong and what action to take, reducing delays at checkout.
Original PR description
We now display an error when the FDM is disconnected, or when the user needs to fill in the social security number. We also advise what to do in such cases. Forward-Port-Of: odoo/enterprise#99319 Forward-Port-Of: odoo/enterprise#99285
Resolved issues and error corrections
This change moves a fleet-related tax report test and its query logic out of the community edition and into the enterprise module where the required vehicle data is available. It resolves a build failure in the community version while preserving the intended fleet reporting behavior for enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/odoo#235339 Forward-Port-Of: odoo/odoo#234095
The Discuss sidebar now shows the right status icon for call participants when they are muted or have deafen enabled. This fixes a confusing display issue so users can quickly understand each participant’s actual call state.
Original PR description
Before this commit, discuss sidebar call participants had wrong status shown, e.g. when participants are muted it shows non-slashed mic icon instead of slashed mic icon. Steps to reproduce: - Start a call without being muted or deafen - Have another person join the call and mute or deafen => icon shows unslashed mic or headphone This happens because the slash variants were coupled with active button state of call actions, so was based on current session rather than target session. This commit fixes the issue by using specific mute and deafen icon when session is either muted or deafen. Before <img width="1277" height="406" alt="Screenshot 2025-11-13 at 12 20 08" src="https://github.com/user-attachments/assets/c570d0a4-0ab6-48d8-bab6-b191531b2cb6" /> After <img width="1276" height="397" alt="Screenshot 2025-11-13 at 12 19 44" src="https://github.com/user-attachments/assets/2d69e942-7726-4c8c-8921-7635df47dc85" />
This fix prevents a front-end error that could happen when a pro forma is sent for an order that was deleted while the request was still being processed. The system now checks that the order still exists before using it, which avoids interruptions and makes the point of sale more reliable.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback. Forward-Port-Of: odoo/enterprise#99248
Message action icons in chat and message views are now larger and easier to read, while using less horizontal space overall. Hover feedback is also more visible, making the controls easier to notice and use in both light and dark modes.
Original PR description
1) increase size, reduce gap Make icons more readable by being bigger. The gap is reduced so overall this actually takes slightly less horizontal area. 2) More visible hover effect Hover effect was…
1) increase size, reduce gap Make icons more readable by being bigger. The gap is reduced so overall this actually takes slightly less horizontal area. 2) More visible hover effect Hover effect was inexistent due to typo in chat window style leaking to message actions, but still the hover effect was to shy, with 75% => 100% opacity. This is increased to 50% => 100% in addition to true black/white on 100%. Before / After (white) <img width="716" height="128" alt="white-before" src="https://github.com/user-attachments/assets/3829b7cb-8e36-4f28-8d20-78ef9aa31a97" /> <img width="723" height="128" alt="white-after" src="https://github.com/user-attachments/assets/79ec373a-c847-4c8a-96da-4582b54bb393" /> Before / After (dark) <img width="717" height="127" alt="dark-before" src="https://github.com/user-attachments/assets/cdaddee6-8025-46c3-a50b-9c85f9108887" /> <img width="716" height="123" alt="dark-after" src="https://github.com/user-attachments/assets/ddd712b0-407b-427b-b4c6-e3d615b91c27" />
This change prevents tracking from crashing when related records do not have a display name. Instead of showing an error, the system now falls back to a safe default, matching the behavior used in similar cases. This improves reliability for users working with tracked one-to-many and many-to-many fields.
Original PR description
Description of the issue/feature this PR addresses: Addresses: https://github.com/odoo/odoo/issues/178883 Same issue is also in 18.0. Is there a separate PR necessary or will this be ported forward? Current behavior before PR: An error is displayed when tracking is activated on one2many and many2many with records without display_name. Desired behavior after PR is merged: Should not crash and use fallback like in other cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214121
Fixed an issue where opening certain dropdowns on the website could accidentally trigger a page reload in some browsers. This improves the experience for visitors and editors by preventing the page from refreshing before a selection is made.
Original PR description
In some browsers, opening a `<select>` triggers a click event. Because of this when the blog's sidebar "Archive" dropdown is opened, it might reload the page before the selection is actually made. This commit solves this by detecting a distinct event when PostLink is activated on `<select>` element. Steps to reproduce: - Using Firefox - Install `website_blog` - Edit the blogs page - Activate the sidebar - Save - Open the "Archive" dropdown => The page was reloaded Forward-Port-Of: odoo/odoo#233202
The fleet tax reporting test and related query were moved into the Enterprise edition, where the required vehicle-linked data is available. This fixes community build failures while keeping the intended fleet reporting behavior available for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#99288 Forward-Port-Of: odoo/enterprise#98650
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#98892 Forward-Port-Of: odoo/enterprise#91344
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund. 4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines. 5. Check the *Tax Report*(account>tax), including the date of this vendor bill. **Obs
Original PR description
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50%…
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund. 4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines. 5. Check the *Tax Report*(account>tax), including the date of this vendor bill. **Observed behavior:** * Tax lines linked to the current asset account are merged. * Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`). * This mismatch triggers an error in the tax report. **Root cause:** The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles. **Solution:** Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error. opw-5013757 Forward-Port-Of: odoo/odoo#232001 Forward-Port-Of: odoo/odoo#228422
This change allows outstanding accounts to be created even when a company does not use a standard chart template. It helps businesses with manually configured accounting setups avoid errors and continue processing expenses normally.
Original PR description
The creation of outstanding accounts when fallback should not require a chart template, since companies may have manually configured their chart of accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when creating a new branch in Indian databases that do not yet have newly introduced taxes. It ensures the correct fiscal mappings are created for both intra-state and inter-state cases, avoiding failures during setup.
Original PR description
In cases, where new taxes are introduced in stable, and for the fiscal mapping are added as well. But for existing dbs, the new tax might not be available and when creating new branch it might lead to traceback because, we create new fiscals for intrastate and interstate --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents a permissions error that could stop sales orders from being confirmed in branch-company setups, especially when dropshipping is enabled. It ensures Odoo checks company-related taxes in a safer way so users only see records they are allowed to access.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a…
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a vendor to a stored product with the Dropship route enabled; 7. log in as a sales user with access to branch C only; 8. add product to a sales order & confirm. Issue ----- > Access Error > Uh-oh! Looks like you have stumbled upon some top-secret records. > Sorry, Marc Demo (id=5) doesn't have 'read' access to: > - Companies, YourBranch (res.company: 3) Cause ----- The error gets thrown during the `_prepare_purchase_order_line` method, specifically on the line which filters `supplier_taxes_id` using `lambda x: x.company_id in company_id.parent_ids`. This passes via the field's `convert_to_record` method, which attempts to access the `active` field of the companies to filter out any that are archived[^1]. [^1]: https://github.com/odoo/odoo/blob/5b911a97a3885283d2f21ac30abb96cb10fe39d9/odoo/orm/fields_relational.py#L608-L612 In previous versions, this wasn't an issue, because the `active` field was still present in cache from the `_compute_parent_ids` which is called with `sudo`, but as of saas-18.4, it attempts to refetch these values, leading to the error. Solution -------- Instead of using `filtered`, use `filtered_domain` using the result of `account.tax._get_company_domain`. opw-5112625 Forward-Port-Of: odoo/odoo#231743
When opening a project from a sales order, the system now automatically focuses on the tasks linked to that specific sales order. This prevents users from first seeing unrelated tasks from the same project, making it easier to find the information they need.
Original PR description
Before this commit, when the user clicks on x projects and x tasks stat button in the sale order form view and that SO is linked to some task and more than one project, the user will be redirected in kanban view of projects and when he will click on a project, he will see all tasks linked to that project instead of seeing the tasks linked to SO inside that project. This commit makes sure a default search is added in the tasks views when the user open a project from an SO to be sure the user will first see the tasks linked to that SO.
This change prevents the chat system from crashing in cases where a member’s profile information is missing. It now uses a more reliable way to identify the current user’s member record, which keeps message tracking working correctly.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
This change prevents the website editor from crashing when it encounters an empty row. It adds a safeguard so the editor skips checks that require columns when none are present, improving stability during page editing.
Original PR description
When a .row div was empty, the _areColsCustomized function was called with an empty HTMLCollection. This caused a traceback when the function tried to access columnEls[0]. This commit adds a safety check to _getNbColumns for avoiding extra calls to _areColsCustomized when columnEls is empty. And we also add a similar check to _areColsCustomized for safety, since it's also being called through the _computeWidgetVisibility. opw-5121738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235555
Opening some activity items from the Activities calendar could fail when the system did not provide enough information to display the record. This fix adds a safe fallback so the correct form view opens instead of showing an error, improving reliability for users.
Original PR description
When opening certain activity items from the Activity Calendar popover,
the backend returns an `ir.actions.act_window` result missing the `views` key.
The frontend attempted to call:
action.views.map(...)
which caused:
TypeError: Cannot read properties of undefined (reading 'map')
This patch adds a safe fallback:
if (!action.views) action.views = [[false, "form"]];
so that the action always has a valid view, preventing a crash and maintaining expected behavior.
Steps to reproduce:
- Go to Activities → Calendar
- Click on different activity items
- Click the "View" button
- JS error occurs for some items
After applying this fix, affected actions open a fallback form view instead of crashing.
This issue also occurs on official demo (demo.odoo.com).This update fixes the Italian e-invoicing setup so share capital is not forced for company types that do not need it. It helps businesses complete their company information more accurately and avoids unnecessary validation errors.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
Saudi invoices could incorrectly show no tax on invoice lines when a Saudi customer was selected. This fix restores the expected tax behavior so invoices calculate and display taxes properly for Saudi Arabia setups.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882 Forward-Port-Of: odoo/odoo#234387
This update fixes two issues in mailing messages: an extra blank paragraph could be added in the email content, and some opened messages could keep expanding the page indefinitely. It improves the reliability of the email editor and makes saved mailings display correctly in read-only view.
Original PR description
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content…
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content should be enclosed inside the `o_layout` block. - when sending such an email (with the wrong paragraph) and consulting the readonly value in the `mass_mailing` Form view, the view started growing indefinitely. How to reproduce: - create a mailing using the basic editor and send the email - open the mailing in readonly Issues: - there is a paragraph outside the `o_layout` element in the DOM - the page scrolls indefinitely because `o_layout` has `min-height: 100%`. Resolution: - don't force `o_layout` to have a `min-height`, which will prevent the infinite scrolling for mailing that were sent with a wrongly placed paragraph. - configure the mailing so that the editable element has `contenteditable="false"`, and the element with `o_mail_no_options` coming from the basic template gets `contenteditable="true"` so that the editor is informed that the user is only allowed to edit the content of that node, not the outside of it, which will prevent the empty paragraph insertion. [commit]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d task-5263045
The signing process test now runs with a regular user instead of only an administrator, which helps catch permission-related mistakes that were previously missed. This prevents a signing error from slipping through when a salesperson field points to the wrong user and a customer tries to sign a document.
Original PR description
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard. The issue is that, on the model `res.partner`, the field `user_id` is the…
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.
When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.
A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:
On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.
You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
Operation: read
User: 5
Groups: allowed for groups 'Role / Administrator'This change ensures the system consistently reports when a WebSocket connection is lost and then recovered, even in a rare edge case where the closing process was incomplete. It helps keep connection status events accurate and also resolves an intermittent test failure in the background service.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This change fixes an issue in the Argentine localization where users could not generate a debit note from an existing credit note. It now lets businesses correct mistakes more smoothly by creating the proper reversing document without encountering an error.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
The hamburger-style website menu now inherits the font size set for the header, so submenu labels stay consistent after you change the navbar format. This fixes a display issue where submenu text could remain at the wrong size and not match the chosen header style.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
This change fixes a build failure affecting payroll tests by removing a field reference from modules that do not always have it available. It helps ensure payroll localizations can be tested reliably without unexpected errors during automated builds.
Original PR description
The issue occurs because the _get_whitelist_fields_from_template() method includes the overtime_from_attendance field, introduced in this https://github.com/odoo/enterprise/pull/92093. This field comes from the hr_work_entry_attendance module, which is not listed as a dependency in all payroll localisations. As a result, the field cannot be found during test execution. Solution: Remove the overtime_from_attendance field from all _get_whitelist_fields_from_template overrides in the localisation modules, and instead include this field by overriding the function in the hr_work_entry_attendance module. build error-243483 task-5169211
This fix brings back report variants that were no longer shown for companies using country-based availability rules without foreign VAT support. It ensures the correct report options appear again, so users can access the right local tax reports as expected.
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/13b28f789e0b1d9c3e266a99aae65c48bb6ce8b6, no variants with the availability condition set to country and not allowing foreign vat were displayed anymore.
This update fixes a rounding problem in DHL shipping data that could cause shipment validation to fail for perfectly normal prices and weights. It helps ensure deliveries can be created smoothly without DHL rejecting the request due to tiny floating-point precision errors.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#99012 Forward-Port-Of: odoo/enterprise#96012
This update aligns an automated website performance test with differences between Community and Enterprise editions. It helps avoid false failures in development and continuous integration while still tracking the key performance measure the test was designed to monitor.
Original PR description
The test is primarily intended to determine the number of requests to ir.ui.view. The information on the website is supplementary but less important. It mainly serves to inform performance considerations during development. Issue on runbot for single app test https://runbot.odoo.com/odoo/runbot.build.error/231557 Forward-Port-Of: odoo/odoo#235358
This update ensures the first line of a bank statement is computed correctly whenever key line details change. It prevents cases where the statement balance could be wrong because an internal index was not refreshed at the right time.
Original PR description
Ensure proper computation of first_line_index when line.internal_index or line.state changes. Previously, the computation of first_line_index was grouped with the date computation. However, due to a specific ORM behavior, the compute method is not triggered when one of the computed fields (in this case, the date) is provided in the create values. As a result, first_line_index could remain falsy, leading to an incorrect balance in the bank journal. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235561
This update makes the self-order IoT component compatible with newer image version formats. It prevents version checks from failing when image numbers use a longer date format, helping devices update reliably.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This change prevents an error that could appear when creating multiple journals of the same type before naming them. Odoo now correctly keeps aliases unique even when no alias domain is set, avoiding a save failure for users.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233101 Forward-Port-Of: odoo/odoo#225537
This change corrects how payment configuration is read so the system can reliably access the needed settings. It helps prevent errors when users work with ISO 20022 bank transfer features.
Original PR description
Forward-Port-Of: odoo/enterprise#99359
The Wave document layout no longer allows a multi-line footer to overlap invoice content when viewed on mobile. This improves the readability and appearance of portal previews and prevents document information from being hidden.
Original PR description
In the Wave layout, a multi-line footer overlaps document information when the portal view is opened from a mobile interface. Steps to reproduce: - Open Settings > General settings > Configure Document Layout - Select Wave layout and add a multi-line footer - Open an invoice, go to portal preview, switch to mobile view Issue: The footer overlaps invoice information. This occurs because the boundaries of the SVG drawing are not well defined and it will unexpectedly shrink. opw-5023032 Forward-Port-Of: odoo/odoo#230230
List views that show sample data will now display it with the same subdued visual treatment even when no help text is available. This reduces the chance that users mistake sample entries for real records.
Original PR description
**Steps to reproduce:** * Create database without demo data. * Open any list view that displays sample data. Ensure the view contains no actual records. Refresh the page to trigger the sample data…
**Steps to reproduce:** * Create database without demo data. * Open any list view that displays sample data. Ensure the view contains no actual records. Refresh the page to trigger the sample data display. * For example: Open the journal items list view in the Accounting module. **Observed behavior:** When the view contains no actual records, the sample data is shown at full visibility, making it look like real data and causing confusion. **Cause:** When a list view displays sample data but has no help content defined, the sample data appears at full opacity, making it indistinguishable from real data and potentially confusing users. The blur effect (radial-gradient) is applied via the o_view_nocontent div, which is only rendered when help content exists. blur effect added in this commit: [https://github.com/odoo/odoo/commit/6ee090c29f1f4e1745c6cae2d50ea77d3324965b](https://github.com/odoo/odoo/commit/6ee090c29f1f4e1745c6cae2d50ea77d3324965b) **Fix:** Added `o_view_nocontent` `div` which, is also rendered when sample data is active, even without help content, so the blur effect is consistently applied. before: <img width="1918" height="657" alt="image" src="https://github.com/user-attachments/assets/1955e459-3ef8-4874-96ee-91f5312f2e47" /> after: <img width="1923" height="682" alt="image" src="https://github.com/user-attachments/assets/7acf539c-27a7-4e19-851c-714cd5258c7d" /> opw-5239503
Employee public pages now display the job title in both the card and form views again. This restores an important piece of information that had disappeared after a recent internal change, helping users quickly identify roles.
Original PR description
Before this commit, the job title is no longer displayed in employee public views since the merge of contract and version. This commit adds the job title in the employee public kanban and form views. task-5264472
Regular users could experience a crash when receiving incoming calls because the system tried to update call details without the needed access rights. This update lets the call handler save the contact link safely, preventing the interruption and keeping incoming calls working smoothly.
Original PR description
In order to prevent users from tampering with their voip.call records, they aren't given direct write access to them. This leads to crashes in the get_contact_info function, which attempts to update the partner_id field of call records. This commit resolves the issue by switching to sudo mode for setting the partner_id.
This update ensures the date picker closes properly when a user leaves a record or goes back to the previous page. It prevents the calendar popup from staying visible on screen after the page or task is no longer open, improving the user experience in the web interface.
Original PR description
Steps to reproduce ================== - Go to project - Open a project - Open a task - Click on the deadline field - Go to the previous page using the browser back button => The datepicker stays open Cause of the issue ================== `datetimePicker.create` was called using three parameters. But since bb1f912f04fbc4b1efe57847bceffce5895ced9b, it only accepts two. Solution ======== `createPopover` should be added to the `hookParams` This allows the popover to be closed when the owner component is destroyed. https://github.com/odoo/odoo/blob/bb1f912f04fbc4b1efe57847bceffce5895ced9b/addons/web/static/src/core/popover/popover_hook.js#L65 opw-4811594 Forward-Port-Of: odoo/odoo#213263 Forward-Port-Of: odoo/odoo#212580
Pasted web links in the message composer now turn into clickable links correctly. This improves the writing experience and helps users share links without needing to reformat them manually.
Original PR description
When pasting a URL in the html composer, the link was not being correctly parsed and converted into a clickable hyperlink. This commit fixes the issue by ensuring that the LinkPastePlugin is included in the composer plugin set, allowing for proper link detection and conversion. Also, this commit forced links to open in a new tab when being parsed with LinkPlugin. task-5259858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where pending bank transactions could stop displaying correctly in the reconciliation view. It also ensures account totals are loaded properly, preventing incomplete or incorrect amounts from appearing to users.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/1691a9d6ec426566b81537544cafe09d9c62ad78 We added a template to inherit BankRecKanbanRenderer, but we forgot to add the extension. By doing that it broke the pending transaction template override. Also this: https://github.com/odoo/enterprise/commit/5d5a7aca4f0abb4492314324631e8b5463a35332 change the getJournalTotalAmount to use a super instead, but it was missing an await otherwise we just have a promise no task id Forward-Port-Of: odoo/enterprise#99066
This change adjusts how test time is allocated so each editor test gets its own share instead of all tests sharing one timer. It helps prevent flaky failures on slower test environments, improving the reliability of the development and release process.
Original PR description
Split the test timer between the four tests rather than applying
a single timer over all of them, for when the runbot is slower.
runbot-233975
Forward-Port-Of: odoo/odoo#235313This fix ensures that customer invoices reflect the real purchase cost when a kit is drop-shipped, even if the purchase order price was manually changed. It prevents understated cost entries in accounting, so profit and inventory reporting stay accurate.
Original PR description
**Problem:** When confirming the invoice of an order delivered via dropship for some kit bom product with fifo/avco comp, if the price was manually set on the purchase order, the invoice lines…
**Problem:** When confirming the invoice of an order delivered via dropship for some kit bom product with fifo/avco comp, if the price was manually set on the purchase order, the invoice lines generated for the cogs are inaccurate **Steps to reproduce:** - In settings enable dropshipping - Create a kit product with one component (both storable). - Set the route as Dropship for the component. - add a vendor in the purchase tab of the component. - set the cost of the component at 2 - and set an on hand quanity - Set the product category to AVCO and perpetual for the component and the product. - Set the cost to 5 on the product. - Create and confirm a sales order with a quantity of 2 for the product. - On the purchase order set the unit price at 20 for the component. - Confirm the purchase order, then validate the delivery and create the customer invoice. - Confirm the invoice **Current behavior:** In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 10 **Expected behavior:** The value should be 40, in accordance with the purchase order **Cause of the issue:** In this forward port, the fix is different. - Prior to this commit https://github.com/odoo/odoo/pull/222169/commits, the cogs of a dropship kit were handled in this way: When _stock_account_prepare_anglo_saxon_out_lines_vals() computes the price_unit, it calls _stock_account_get_anglo_saxon_price_unit(). https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/stock_account/models/account_move.py#L131 For regular kits, the sale_mrp override of this method computes the correct price. But for dropshipped kits, because the moves are generated from the purchase order, they do not have a bom linked, so the variable 'boms' is empty and the override do not modify price_unit. https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/sale_mrp/models/account_move.py#L17-L18 However, the sale_stock override of this method calls _compute_average_price() https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/sale_stock/models/account_move.py#L212 The computation is handled in the mrp_account override, because the product of the moves is different than self (because it's a kit). There, for each component there is a call to _compute_average_price(). https://github.com/odoo/odoo/blob/88043b84f7a017dfff790deeb64510fc62698c96/addons/mrp_account/models/product.py#L73 This time the computation is done in the super method where the value is computed based on the stock.valuation.layer created by the purchase order. So the price taken into account is, rightly so, the one of the purchase order. - But since the commit, there is no more stock.valuation.layers and no more _compute_average_price(). _stock_account_prepare_realtime_out_lines_vals() now calls _get_cogs_value(). In the sale_mrp override of this method ( because the moves are still created from the purchase order), the variable boms is empty and the computation does not happen here. https://github.com/odoo-dev/odoo/blob/2a46a4e2c5a1f0a7848b50f3bf3ac6887a78b2df/addons/sale_mrp/models/account_move.py#L17 The computation happens in the super method where the standard price of the product is returned. https://github.com/odoo-dev/odoo/blob/2a46a4e2c5a1f0a7848b50f3bf3ac6887a78b2df/addons/stock_account/models/account_move_line.py#L65 So now to fix the issue, we can not rely on compute_average_price but we need to modify the sale_mrp override of _get_cogs_values. opw-4985440 Forward-Port-Of: odoo/odoo#229956
We fixed an issue where using Ask AI could crash if more than one AI chat was open for the same user. The update also ensures Ask AI opens a fresh chat and removes a duplicate button from search to avoid confusion.
Original PR description
When multiple AI chat channels existed for the same agent/user, `_get_or_create_ai_chat` could return several records. This caused a singleton error when calling `action_ask_ai` because the code expected a single channel record. This commit filters a single record so that only one channel is returned, preventing the crash. And also 'action_ask_ai' will now always opens a new ai chat. Additionally, the redundant 'Ask AI' button in the search view has been hid, as the same functionality is already available from the systray. task-5107276
This update corrects backward navigation in interactive tours when a warning step appears on the page. It prevents the tour from briefly landing on a step that should be skipped, making the experience smoother and more reliable for users.
Original PR description
Before this commit, the backward wasn't ignoring the warn steps. So, if the backward go to the previous step (warn's one) and the trigger is on the page, the tour interactive put the cursor there. But the step is then ignored and go back the step you came from. Now, the warn's steps are ignored. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235511
When a mail template is duplicated, its attachments are now copied too instead of being shared between templates. This avoids unexpected cross-template changes and helps prevent access and permission issues in future setups with custom rules.
Original PR description
Copying tmeplates should copy their attachments. Otherwise they are
shared, which means
* wrong res_id: ACL check on attachments relies on a specific
template, as res_model / res_id is used in access check;
* propagated changes: changing one attachment changes it on all
duplicated templates;
If custom rules on templates are implemented, this means notably
ACL issues when accessing attachments. It is not the case in standard
Odoo 17 as everyone can read templates but this notably changes in
future versions of Odoo.
While being there, also fix 'default' usage in copy override. User
given values should not be erased by default computation of name.
Task-5128863
Forward-Port-Of: odoo/odoo#234565
Forward-Port-Of: odoo/odoo#232877This change fixes an unreliable automated test in the web interface by waiting until the error dialog is actually shown before checking it. It reduces intermittent test failures and makes the test suite more dependable.
Original PR description
Before this commit, the test sometimes failed because we didn't wait enough before checking the presence of the error dialog. The `unhandledrejection` event being thrown asynchronously, simply waiting for an animation frame isn't enough. We can only wait for the dialog to be displayed. runbot error~234017 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#235464
The manufacturing order overview now values consumed components using the correct unit conversion when the component’s purchase/unit of measure differs from the one used in the bill of materials. This ensures the displayed production cost matches the real quantity used, avoiding inflated cost figures in reports.
Original PR description
…er uom **Problem:** The overview of a produced MO does not take into account the uom of the component for the valuation **Steps to reproduce:** - Create a storable product (the comp) - set the uom…
…er uom **Problem:** The overview of a produced MO does not take into account the uom of the component for the valuation **Steps to reproduce:** - Create a storable product (the comp) - set the uom as L and the cost as 40$ per L - set an on hand quantity - Create a storable product (the final product) - Create a bom for this final product using 100 ml of the comp - Create, confirm and produce a MO for the final product - click on the overview smart button **Current behavior:** the real cost is 4000$ (100*40) **Expected behavior:** it should be 4 (0.1 * 40) **fix** A fix was first introduced in this PR https://github.com/odoo/odoo/pull/230585. But it was closed because this PR had already fixed https://github.com/odoo/odoo/pull/232364. However since this PR the issue is back https://github.com/odoo/odoo/pull/232872. Here is the explanation of the new fix : Inside _get_component_real_cost _get_unit_cost returns the unit cost of the move expressed for 1 unit of the uom of the product (which is correct). But quantity is expressed in the uom of the move so we need to convert it in the uom of the product. https://github.com/odoo/odoo/blob/2ba4998b470236feee3a1636bf6d1807c74eac3a/addons/mrp/report/mrp_report_mo_overview.py#L583-L586
The expense list view no longer shows an extra link to the same attachments. This makes the screen cleaner and avoids confusion when reviewing expenses.
Original PR description
remove an unnecessary link to the attachments of expenses in the list view. task-4684825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a crash in the Live Chat info panel when a customer conversation is still ongoing. It also improves the ordering so the most recently active conversations appear first, making the list more useful for support teams.
Original PR description
Live chat shows recent conversations with a customer in the info panel. Chats are sorted by end date. However, some conversations could still be ongoing. This is not taken into account in the sort function and can lead to a crash. This commit fixes the issue. opw-5263335 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 change fixes an error that could appear when adding a user to a database project if no database was already selected. The user management screen now handles this case correctly, preventing the process from crashing.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Go to Databases; 2. open a new project; 3. enter any name, hosting provider & URL; 4. under User Management, click on "Add a user". Issue ----- Traceback: > `ValueError: Compute method failed to assign databases.manage_users.wizard(<NewId 0x71e8c0d8fd80>,).everywhere_user_ids` Cause ----- The `_compute_everywhere_user_ids` method computes the value of a non-stored field. Consequently, every record in `self` needs have some value assigned to `everywhere_user_ids` during the compute, but currently, if the `database_ids` field is empty, `continue` is used without assigning a value. Solution -------- If the record doesn't have any known `database_ids`, set `everywhere_user_ids` to `None`. opw-5170587
This change brings back the faded visual style for sample data in the web interface. It fixes a display issue that could make sample content appear incorrectly when certain helper elements are not present.
Original PR description
The opacity effect was removed from Sample Data in #233205 and caused issue when sample data are present without an ActionHelper. This commit reverts these changes.
This update fixes a crash that could happen in special folder selection screens, including Studio, when action icons were shown where they should not have been. It now makes sure those icons only appear in the main Documents list, so secondary views work normally without errors.
Original PR description
This commit adjusts a previous fix that was causing a new crash in certain contexts, like studio. The original fix relied on view-specific information to be available, but this information was…
This commit adjusts a previous fix that was causing a new crash in certain contexts, like studio. The original fix relied on view-specific information to be available, but this information was undefined in those edge cases. This new fix adds a safeguard to check that this information exists before trying to access it, preventing the crash. Original fix: Action icons (like 'Open Folder', 'Rename', etc.) were incorrectly appearing in list views outside of the main Documents app, for example, when selecting a folder in a settings menu or a popup dialog. This was confusing and caused a crash when an icon was clicked, as the required functionality was not loaded in those contexts. This fix removes the action icons from these secondary views. To keep the fix stable-proof, the template of the widget was modified, in 19.1 we will fix this in cleaner way. The icons are now correctly restricted to the main Documents list view, where they function as intended. Other views (like folder pickers) now behave as standard selection lists without errors. Task-5258848 Original Task-5166843
This update adjusts who can access several Online Sync actions so they are mainly available to Invoicing & Banks users. A few sensitive actions remain under stricter access rules to reduce the risk of unintended changes to bank transactions and dates.
Original PR description
Most access right for Online Sync related actions should be Invoicing & Banks. Only Duplicate Wizard (because you can delete transactions easily) and Online Account Fields (because can change date without explicit showing) will be with other group. task-5149304
This change prevents Odoo from checking the payment amount and currency during Adyen’s 3D Secure challenge step. It matters because Adyen does not provide those details at that stage, so the payment flow can continue without unnecessary validation errors.
Original PR description
When Adyen request a 3DS challenge for the payment, we should not enforce amount and currency validation at that time (no amount are provided in the Adyen response). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures warehouse putaway rules are applied correctly when products are moved using a different unit of measure than the product’s default. As a result, items packed for receipt are routed to the right storage location, respecting package capacity limits and avoiding incorrect placement of later transfers.
Original PR description
**Problem:** the stock putaway rules do not apply when the uom on the move is different than the base uom of the product **Steps to reproduce:** - set the warehouse incoming shipment as 'two steps' -…
**Problem:**
the stock putaway rules do not apply
when the uom on the move is different
than the base uom of the product
**Steps to reproduce:**
- set the warehouse incoming shipment as 'two steps'
- enable the 'packages' setting
- navigate to 'Operation Types' and select Receipts
- check the 'set package type' box
- create a storable product
- in the sales tab add 'pack of 6' to the packagings
- navigate to 'package types' and create a new one
- navigate to 'storage categories' and create a new one
- In the 'capacity by pacakge' tab set a limit by package to 1 quantity of your new pacakge type
- open 'warhouse management/locations' and create a new one
- set the parent location to stock and the storage category to your new storage category
- open 'putaway rules' and create a new one
- set the 'store to' field as your new loc
- set the 'when product arrives in' field to stock
- set the 'product' field to your product
- create a new receipt for your product
- set the demand as 4 and the unit as 'pack of 6'
- mark as to do
- change the quantity to 2 and click on put in pack
- in the 'package type' field of the widget enter your new package type
- set the quantity to 4 and click on put in pack
- in the 'package type' field of the widget enter your new package type
- validate the picking
- click on next transfer
- validate the picking
- click on the moves smart button
**Current behavior:**
- both moves are going to your new location
**Expected behavior:**
- as there is a one package limit for this package type only the first move should be going
there
**Cause of the issue:**
The problem comes from the fact that there is no
destination package (result_package_id) on the
move lines of the second pick.
As a consequence the limits regarding packages
can not apply.
Here is why there is no result_package_id on those move lines :
when assigning the new move, action_assign
calls check_entire_pack().
https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_move.py#L2013 There, before writing the 'result_package_id'
field of the move lines, the method calls
check_move_lines_map_quant_package inside the
if statement.
https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_picking.py#L1301-L1305 This results in a call to _check_move_lines_map_quant.
Inside _check_move_lines_map_quant, when building
the grouped_ops dictionnary, the quantity of the
move line is expressed in the uom of the line
(here pack of 6) so it will be 2.
Whereas in grouped_quants the quantity used is expressed
in the uom of the quant (here unit) so it will be 12. https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_package.py#L403
As a consequence the diff in the float_is_zero
will not be null and the return value will be False.
https://github.com/odoo/odoo/blob/96264f88e6ea2dc61ba6c546f9f1a03d49df55ea/addons/stock/models/stock_package.py#L405-L406
opw-5154168This change corrects the layout of the snippet visibility option in the mailing editor. When no domain rule is configured, the button now appears next to the Domain label instead of dropping below it, making the interface cleaner and easier to use.
Original PR description
This commit fixes a display issue with the snippet visibility option. When no domain was applied to a section the option would display the button below the Domain label. This is not great to see so it's now besides the domain label if it is actually empty. task-5261955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The OCR process will no longer automatically change a customer invoice into a sales receipt unless the Sales Receipt setting is enabled. This prevents unexpected document type changes and keeps invoice handling aligned with the company’s configuration.
Original PR description
If the "Sale Receipt" setting isn't enabled, the OCR should never automatically switch a customer invoice to a sale receipt. task-[5265382](https://www.odoo.com/odoo/project.task/5265382)
When the Journal Items list has no matching records, Odoo will now stay empty instead of showing example data. This makes accounting screens and reports less confusing, especially when users click into a value that has no underlying journal entries.
Original PR description
Currently, when going into the "Journal Items" menu, if there's no data to display, some sample data are shown. To reproduce: set a filter that won't match any journal item, set it as default filter and refresh the page. It doesn't make sense to have sample data, as you cannot create journal items on the fly. It is particularly confusing going to an accounting report like "Profit & Loss" and clicking on a "0.00" value. As no journal item is present, the sample data are shown. The fix is to remove the attribute `sample="1"` on the list. no-task
The message text in Discuss’s white theme has been adjusted to a softer color. This lowers the visual contrast on message lists, helping reduce eye strain for users while keeping the same content and layout.
Original PR description
Main text color in white theme was increased from gray-700 to gray-900, increasing the overall contrast of the web client [1]. This change, in addition to reducing the color of message bubble, has the effect to increase contrast of message list by a lot in white theme, which leads to complain of eyes being hurt. This commit reduces the black level of message text content color in white theme, to match text color as it was before [1]. [1]: https://github.com/odoo/odoo/pull/209125 Part of Task-5265246 Before <img width="958" height="678" alt="before" src="https://github.com/user-attachments/assets/eee192fd-b24f-450e-85cc-2b97cae28b22" /> After <img width="959" height="680" alt="after" src="https://github.com/user-attachments/assets/1955e515-9f43-4394-b32a-63fbfe213f6f" />
This fix makes sure sales orders are no longer shown as fully invoiced when their linked invoice has been canceled. It keeps the invoice status accurate, which helps teams trust the order and billing information they see.
Original PR description
Since 81f25bc, _compute_qty_invoiced would not reset the field to zero when the linked invoice was canceled, meaning that sale orders would be still be flagged as 'Fully Invoiced'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a helpdesk refund is created from a sales order, the credit note now keeps only the product that was actually selected for refund. This also narrows the product suggestions in the refund wizard to the products linked to the original sales order, avoiding confusion and incorrect refunds.
Original PR description
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we…
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund. Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO. ## Reproduction Steps 1. Create a SO containing 2 different products and confirm it. 2. Create a regular invoice and confirm. 3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams. 4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds". 5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned. 6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund. 7. Click on reverse. ### Expected behavior A credit note containing only the specified product to refund should be created. ### Unexpected behavior The created credit note contains both products originally present on the SO. ## Origin of the issue When issuing a refund from helpdesk_stock_account, this piece of code is called: https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17 which calls the ```reverse_moves``` method in the helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on. Finally, we arrive in the account_move.py file. In the ```_reverse_moves``` of this file, we can see the code: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947 where we simply copy all the lines of the move in the SO without filtering them. As a result, we get the lines of the product we don't want to refund __ opw-5148789 Forward-Port-Of: odoo/enterprise#98771
This fix ensures user presence updates are handled correctly whether they arrive through the web interface or via the websocket connection. It helps keep online status tracking reliable and prevents missed presence updates.
Original PR description
update_presence can both be called in http and with websocket as explained here: https://github.com/odoo/odoo/commit/de6de48deb983be910876c6133c2869907c142f7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes a barcode scanning issue in batch picking so the system correctly waits for the previous processing step to finish. It helps prevent intermittent scan errors and makes the picking workflow more reliable.
Original PR description
Commit bc9247d46225c696842bc7b0e3c883320231ab1b has introduced an override of the `processBarcode` method. However, it does not return nor await the super call. In particular, in the case where the super call should be done the overrides returns "undefine" rather than a promess to await and hence that call is not awaited anymore. Note: This error has been noticed from the fact that the test `test_barcode_batch_scan_lots` sometimes fails on step 29/31. runbot-233631 Forward-Port-Of: odoo/enterprise#99303
This fix ensures purchase orders no longer stay marked as invoiced when the related vendor bill is canceled. The invoice quantity is now recalculated properly, so the order status reflects the real billing situation.
Original PR description
Since 81f25bc57b8433a65bf33950c64dc7582240a229, `_compute_qty_invoiced` was not resetting the field to zero when the linked invoice was canceled, resulting in purchase orders remaining in status `invoiced` even if there was no invoice any more. With this commit, we always write the qty_invoiced on the purchase order line, and the status is recomputed accordingly. Source: post odoo.com migration feedback
Opening the chat icon from an employee’s profile now works correctly instead of showing an error. This fixes a broken user action and ensures employees with linked user accounts can be contacted directly from their form view.
Original PR description
Before this commit, when opening a chat with an employee from the form view it would result in a traceback. Steps to reproduce: 1. Open the form view of an employee that has a user associated 2. Click the "chat" icon next to their name -> traceback This happens because the `getChat` method would insert a Persona record in the Store with a displayName field which has been changed to a setter in [1]. This commit fixes the issue by setting the `name` field instead. [1] https://github.com/odoo/odoo/pull/234702 Forward-Port-Of: odoo/odoo#235279
This fix lets vendor bills and invoices with deferred amounts be reset to draft multiple times, even when audit trail controls are enabled. It removes a restriction that could block users from correcting or reprocessing these documents after an initial reset.
Original PR description
Resetting a vendor bill or invoice with deferred amounts will unlink or reset all existing deferred entries. If the audit trail is enabled, some of these entries must be cancelled instead. [AccountMove.button_draft()](https://github.com/odoo/enterprise/blob/a3f461040cb3443fbcb190c28fddae7044bbd1e7/account_accountant/models/account_move.py#L80-L88) If a protected entry is already cancelled, `AccountMove._unlink_or_reverse()` will still attempt to cancel it. This prevents entries from being Reset to Draft more than once. The current commit removes this restriction. opw-5187737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235223
This change prevents an access error that could appear when opening the Documents app after a company was archived. It ensures folders are only fetched for companies the user can still access, so the app opens reliably without unexpected permission issues.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278 Forward-Port-Of: odoo/enterprise#99043 Forward-Port-Of: odoo/enterprise#96817
Message attachments that are images now display in their full size instead of being cropped into a square preview. This makes it easier for users to understand shared images at a glance without opening them in a separate viewer.
Original PR description
Before this commit, images attached to a message had their preview cropped and forced people to view with file viewer. This square and cropped visual looks good in contexts other than message, e.g. chatter attachment list. In message, however, most of the time people want to share images and be able to see whole content just from preview. This commit fixes the issue by making image preview of message see whole content. Task-5259604 Before <img width="1360" height="788" alt="Screenshot 2025-11-13 at 17 49 30" src="https://github.com/user-attachments/assets/d84c245e-2501-4e5b-9e32-10f0ae882b7e" /> After <img width="1366" height="831" alt="Screenshot 2025-11-13 at 17 49 39" src="https://github.com/user-attachments/assets/ce27f9eb-1f9a-4802-9590-fa69e8c40140" />
The call settings dropdown in the Mail app has been adjusted so its options, icons, and toggles are clearly visible in light mode. This also removes an unwanted border on click and corrects spacing, making the call settings easier and more reliable to use.
Original PR description
**Current behavior before PR:** When opening the dropdown to select input/output devices during calls in light mode, the following issues were observed: - select options had white text on white…
**Current behavior before PR:** When opening the dropdown to select input/output devices during calls in light mode, the following issues were observed: - select options had white text on white background, making them unreadable. - The select's down arrow icon was invisible. - The toggle thumb was barely visible when unchecked. - A border appeared unnecessarily when the dropdown was clicked (in both light and dark mode). - The blur background toggle spacing was incorrect. **Desired behavior after PR is merged:** - select options now have a dark gray background ($gray-700), ensuring proper contrast and readability in light mode. - The select's down arrow icon and toggle elements have consistent visibility. - The extra border on dropdown click is removed. - The toggle spacing is visually corrected. task-5163527 > **Note:** Spotted in Chrome Browser **Before:** <img width="945" height="438" alt="image" src="https://github.com/user-attachments/assets/fdfa24a4-c089-428c-b20d-0cdd4a7fb945" /> <img width="189" height="40" alt="image" src="https://github.com/user-attachments/assets/88a3372e-7ee6-4be5-b224-51c1c998a5e0" /> **After:** <img width="743" height="319" alt="image" src="https://github.com/user-attachments/assets/a06eb60c-88e2-4c75-852b-6e04a06a6336" /> <img width="212" height="51" alt="image" src="https://github.com/user-attachments/assets/602ea08f-edaa-472f-884f-81c36afe1429" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Website SEO dialog no longer opens too early while the page preview is still loading. This prevents a crash on slow connections and makes the editing experience more reliable for users.
Original PR description
Steps to reproduce: - Open Website app and enter edit mode on any page. - Reload the page with a slow connection. - Immediately open "Optimize SEO" from the navbar menu. Before this commit, the dialog accessed the preview document while the iframe was reloading, so reading location.origin raised a TypeError. After this commit, the dialog waits for the iframe to finish loading or returns immediately when it is already complete, preventing crashes. task-5104033 Forward-Port-Of: odoo/odoo#235231 Forward-Port-Of: odoo/odoo#230820
The point of sale receipt now displays the cashier or server name even when a preset like "Eat in" is used. This ensures customers always see who handled the order, improving clarity and accountability at checkout.
Original PR description
Currently cashier name is only shown if no preset is shown or if the present identification is set on name. Steps tot reproduce: -------------------- * Open restaurant * Make sure you use the Eat in preset * Place an order and pay it > Observation: On the receipt the "Served by:" indication is not shown. Why the fix: ------------ The cashier/server information should not depend on the preset used. opw-5154347 Forward-Port-Of: odoo/odoo#234767 Forward-Port-Of: odoo/odoo#231930
This change restores employee lookup results in forms for users who do not have access to the Employees app, including on mobile. It ensures employee records can still be selected when they are used as a related field, so users no longer see an empty result list.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#234806 Forward-Port-Of: odoo/odoo#197575
This update prevents an error that could appear when users clicked the Edit Configuration button on a quotation line after the product name had been removed. It makes the button only available when a configurable product is actually selected, avoiding a broken user experience.
Original PR description
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** -…
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** - Install Sales module - Create a Quotation - Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**. **Error:** `TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()` `missing 1 required positional argument: 'product_template_id'` **Root Cause:** When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered. [1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13 **Solution:** This commit prevents the error by correcting `depends` on the field `is_configurable_product`, which will ensure that edit button will be only present if the configurable product is selected. Sentry-5741581459, 6925770690 Forward-Port-Of: odoo/odoo#217464
This change makes interval processing more reliable by ensuring interval data is normalized before it is merged. It prevents inconsistencies and occasional errors that could appear when different interval types were combined, especially in planning-related operations.
Original PR description
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`.…
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#235233 Forward-Port-Of: odoo/odoo#234352
This update ensures duplicated spreadsheets always load the latest version instead of sometimes reusing an outdated browser cache. It helps users avoid seeing missing or stale changes after copying a spreadsheet tab.
Original PR description
It happens that browser may use a cache if there's no explicit cache control/expiration time: https://httpwg.org/specs/rfc9111.html#heuristic.freshness Steps to reproduce (non-deterministic): - create a new spreadsheet - do some changes, edit a few cells - right click on the tab and hit "Duplicate" => the spreadsheet is not up-to-date on the duplicated tab. The browser loaded the response from "disk cache" instead of fetching the latest data from the server. I'm using Chrom Version 142.0.7444.162 (Official Build) (64-bit) We add an explicit cache control. Forward-Port-Of: odoo/enterprise#99426
The website now only shows the language selector when there is actually more than one language available. This prevents an empty list item from appearing in the header, which could create an unnecessary border or blank space.
Original PR description
This PR calls the language selector placeholder only when multiple languages exist, avoiding an empty header list item that creates an unnecessary border or empty space. task-5150808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234345 Forward-Port-Of: odoo/odoo#231256
The website now correctly updates the displayed price without national taxes when a quantity-based fixed price starts to apply. This ensures shoppers in Argentina see the right tax-free price as they change quantities, avoiding confusing mismatches on product pages.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Have a company with Argentinian localization; 2. in Website settings, enable "Display Price without National Taxes"; 3. add a quantity-based fixed price on the website's pricelist; 4. go to a product page where the fixed price can be applied; 5. increase quantity so the fixed price should apply. Issue ----- The price without national taxes isn't getting updated. Cause ----- In the `_get_additional_combination_info` override, the given `quantity` gets ignored, as well as the pricelist price for product variants, instead defaulting to their `lst_price`. Solution -------- Pass the quantity to `_compute_price_rule`, and use the result for both templates & variants. opw-5040056 Forward-Port-Of: odoo/odoo#232480
Follow-up reminder emails now correctly send any files attached to the email template, including dynamic reports. This ensures customers receive all intended documents with their payment reminders, instead of only seeing them prefilled in the sending wizard.
Original PR description
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the…
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the page "Content", add an attachment by clicking the "Attachments" button - Under the page "Settings", add a dynamic report - Create an overdue invoice for a partner - Go on the form view of the partner, "Accounting" page - Click "Send", make sure the template used is the one with the attachments - Send - The attachments on the template and the dynamic report are not sent ### Cause: The mail template to send the follow-ups is only used to prefill the wizard. ### Solution: Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments. This commit also refactors how the attachments are computed: The previous code was adding the invoices PDFs then removing them. The whole process was confusing. Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments depending on the options. opw-5147736 Forward-Port-Of: odoo/enterprise#99458 Forward-Port-Of: odoo/enterprise#98454
This change ensures invoices sent to ZATCA use the right submission path when the customer belongs to a parent company. Instead of treating these cases as simplified invoices, Odoo now checks the customer’s main commercial entity so company-related invoices are sent through the clearance process as expected.
Original PR description
…earance or reporting api When sending an invoice to ZATCA, if the contact is an individual, the invoice is sent through the reporting API, and if the contact is a company, the invoice is sent through the clearance API. As of now, if the contact has a parent company, the invoice is sent through the report api. However, we need to make sure that in this case, the invoice goes through the clearance api. The fix introduced simply checks the partner_id.commercial_partner_id to decide whether the invoice is a simplified invoice (i.e. through the reporting api) or not. Task-5085142 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#234691
The OEE smart button on workcenter screens now shows the same value as the detailed OEE report. This fixes a rounding mismatch so users see a more accurate and consistent efficiency measure.
Original PR description
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed…
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report. **Expected behavior:** Same values **Steps to reproduce:** 1. Make a workcenter and a BoM with an operation performed at the workcenter 2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration) * example: 0:20 expected, 1:01 actual 3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different **Cause of the issue:** the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values. **Fix:** Don't use the rounded intermediary values in computing `oee`. Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value). opw-4795463 Forward-Port-Of: odoo/odoo#232730 Forward-Port-Of: odoo/odoo#218310
This change prevents users from cancelling purchase orders that have been locked. If someone needs to cancel a locked order, they must unlock it first, which helps protect confirmed orders from accidental changes and keeps records consistent.
Original PR description
Issue before this commit: ========================== Locked purchase orders could still be cancelled, which defeats the purpose of locking them. Steps to reproduce: ========================== 1. Install the `purchase` module. 2. Enable "Lock Confirmed Orders" in the configuration. 3. Create and confirm a purchase order. 4. Lock the purchase order. 5. Try to cancel it → the PO still gets cancelled despite being locked. After this commit: =========================== Cancelling a locked purchase order is no longer allowed. If a user tries to cancel a locked PO, a UserError will be raised instructing them to unlock it first. Locking a purchase order is intended to prevent accidental changes, including edits and cancellations, once the order is confirmed. With this change, users must explicitly unlock a purchase order before cancelling it, ensuring better control and data integrity. TaskId: 4760864 Forward-Port-Of: odoo/odoo#208716
This change makes website image editing tests more reliable by ensuring image-related data and editor resources are loaded before the test continues. It removes timing-related failures, which helps the test suite run consistently and reduces false failures in development and CI.
Original PR description
The goal of this commit is to fix the indeterminate tests related to image editing in the website builder. Problem: ===== Some tests related to image editing on the website fail in an indeterminate…
The goal of this commit is to fix the indeterminate tests related to image editing in the website builder. Problem: ===== Some tests related to image editing on the website fail in an indeterminate manner. This test failure is related to the sidebar's async. When selecting an image, the Image options need to fetch certain data (the original image, etc.). The “html_editor.assets_image_cropper” bundle is also loaded. This loading time can exceed 200 ms, causing the test to fail unpredictably. Solution: ====== 1.Preload the “html_editor.assets_image_cropper” bundle and store it in the cache. 2. Use `waitSidebarUpdated` when selecting an image. `waitSidebarUpdated`` will wait until all the data is loaded and the sidebar is updated. This solution is not optimal, but it will make all the tests deterministic. The best solution: ========= We should mock or preload all the data needed for the tests. This change requires adapting the current production code to make it easily patchable to mock, for example, “.text()” on a response to an image fetch. Error: https://runbot.odoo.com/odoo/error/232956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234312
This change prevents the partner fiscal country list from showing the same country code twice in some cases. It avoids a form display issue and keeps the data cleaner without changing the intended business behavior.
Original PR description
Recently we started considering `country_code` as part of the `fiscal_country_codes` [1]. Because of this, the field can now contain duplicates. If your active company is a US one, and you set United States as the country on the partner you end up with `US,US`. It breaks some (admittedly fragile) invisible conditions on the `res.partner` form view [2]. Although we could fix those conditions, it would require everyone to update the module, and having duplicate country codes in `fiscal_country_codes` field doesn't serve any purpose anyway. [1] https://github.com/odoo/odoo/pull/229584 [2] https://github.com/odoo/enterprise/pull/62615 opw-5248844 opw-5241556 Forward-Port-Of: odoo/odoo#235652
This change fixes an error that could happen when users saved an invoice email as a template and then tried to add an attachment. The send wizard now keeps the correct document context, so attachment uploads continue to work normally.
Original PR description
Currently, an error occurs when trying to add an attachment after saving an invoice email as a template in the `Send wizard`. **Steps to produce:** - Install the `account` module. - Create a new…
Currently, an error occurs when trying to add an attachment after saving an invoice email as a template in the `Send wizard`. **Steps to produce:** - Install the `account` module. - Create a new invoice, fill in all required details, then `confirm` and click `Send`. - Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name, and save the template. - Try to add an attachment. **Error:** `AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'` `AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'` Root **cause:** At [1], the code sets a new `template_id` when the template is saved. This triggers `_compute_model()` at [2], which updates the model field to `account.move.send.wizard` instead of `account.move`, using the `active_model` context, causing the `error`. **Fix:** This commit ensures that after saving a mail template, the wizard retains the correct model, same as [3], and prevents the attachment upload error. [1]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296 [2]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248 [3]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389 sentry-6987172677 Forward-Port-Of: odoo/odoo#234268
This change corrects where rounding is applied in accounting tests and related logic, so amounts are handled more consistently. It also updates outdated test comments and adjusts sample values to better verify the behavior, reducing the risk of small calculation errors.
Original PR description
Also fixes the comments that were wrong. Change some values to better test things 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#235557 Forward-Port-Of: odoo/odoo#234213
When an attendee is created from a free or fully discounted ticket, the confirmation email will no longer display a misleading unit price. This makes the message clearer for customers and avoids confusion about whether payment is still due.
Original PR description
Steps to reproduce: 1. Create a new sale order with an event ticket line 2. Apply a 100% discount on the ticket line 3. Confirm the sale order 4. Check on the new attendee created, the mail sent to the attendee. Current behavior: The email shows the unit price without the discount applied which can be confusing for the customer as it might look like they need to pay that amount. After this commit: The email will just show the confirmation of the registration to the event withouth mentioning the price when the total price is 0. opw-5122776 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235482
Documentation and clarification updates
This change records Raj Gohel’s Contributor License Agreement signature so future contributions can be accepted in Odoo. It is an administrative update with no direct impact on business operations or users.
Original PR description
This commit adds my Individual Contributor License Agreement (CLA) signature. Signed, Raj Gohel <rajgohel2018@gmail.com> https://github.com/Rajgohel0312 This CLA is required to validate my future contributions to Odoo.
Miscellaneous changes
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO file
Original PR description
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO files according to the POT files using `msgmerge` - Added new PO files for missing languages We also updated the `.weblate.json` file to add all the localizations in a separate Weblate project, limited to the languages they support. task-5169642 Related: https://github.com/odoo/odoo/pull/235726 saas-18.4: https://github.com/odoo/enterprise/pull/99189
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO file
Original PR description
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO files according to the POT files using `msgmerge` - Added new PO files for missing languages We also updated the `.weblate.json` file to add all the localizations in a separate Weblate project, limited to the languages they support. task-5169642 Related: https://github.com/odoo/enterprise/pull/99506 saas-18.4: https://github.com/odoo/odoo/pull/235120