Monday, April 27, 2026
32 changes · saas-19.1
New functionality added to Odoo
This update introduces a new module, 'obox,' designed to connect and manage hardware devices similar to the Odoo FDM. The initial phase focuses on allowing users to register and view basic information (IP address and services) for their Obox devices, paving the way for future device integration.
Original PR description
The Obox (same platform as the Odoo FDM for Belgium) will allow interfacing with hardware devices, and is intended to replace the functionality of the IoT box. This commit only adds the ability to pair an Obox to the database, and see its IP and available services. see odoo/obox#118
Enhancements to existing features
This update enhances the reporting functionality within the Enterprise version of Odoo by making return type menu options consistently available. Previously, these options were restricted to debug mode. Now, they're accessible to authorized users, streamlining the reporting process.
Original PR description
Before, the menu return types in configuration was only available in debug mode. Now it is available for the group `account.group_account_readonly` task-5912751 Forward-Port-Of: odoo/enterprise#114830
Resolved issues and error corrections
This update fixes an issue where staff on leave were incorrectly showing as available for appointments through Google Calendar. The team removed unnecessary code related to scheduling offsets, as appointment slots are now pre-defined in the Google Calendar feeds. This ensures accurate availability and a better user experience.
Original PR description
Resources on leave were still showing as available in BatchAvailabilityLookup responses because unavailabilities were not checked. Also remove the min_schedule_hours offset copied from the frontend logic. It is not relevant for Google Reserve as slots are pre-built in the feeds. Task-6150788 Forward-Port-Of: odoo/enterprise#114793
This update ensures that TicketBai QR codes are correctly generated when a paid order is reprinted after reloading the POS system. Previously, the QR code wasn't being set during the initial loading of historical orders, leading to missing codes. This fix guarantees accurate QR codes for seamless order processing.
Original PR description
When printing a paid order after reloading the POS, the TicketBai QR code was missing. The QR source (l10n_es_pos_tbai_qrsrc) was only set during _postPushOrderResolve after payment, but not when loading historical orders from the backend. opw-6068076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261102 Forward-Port-Of: odoo/odoo#259372
This update resolves an issue where CODA bank statement imports failed due to discrepancies in detail sequence numbers provided by some banks. The fix allows for incremented 3.2 detail sequences, aligning with bank file formats and preventing import errors. This ensures seamless integration of bank statement data into Odoo.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update fixes an issue where invoices generated with Mexican tax settings were incorrectly rounding the total amount. The change reverts to the standard mixed rounding mode for taxes, ensuring accurate invoice totals. This resolves a discrepancy identified during testing and aligns with current tax regulations for Mexico.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_mx. 2. Change the included in price settings to 'Tax included' for a 16% tax and a 53% tax. 3. Create a invoice with a product with a unit price of 360, add the 53% tax and then the 16% tax. 4. Notice the total of the invoice is 360.01 instead of 360. The issue was discussed with (las), l10n_mx_edi should no longer require to override the rounding mode for taxes. opw-5963855 Forward-Port-Of: odoo/odoo#255574
This update corrects a bug that was disrupting the testing process for the l10n_mx_edi module, which handles Mexican tax reporting. The rounding mode was temporarily changed, breaking the associated tests. This fix restores the original rounding configuration to ensure accurate test results and continued functionality of the module.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
This update resolves a technical error that was preventing the point-of-sale system from functioning correctly. The issue stemmed from a previous code change that hadn't been fully integrated into the saas-19.1 environment. This fix ensures the currency testing within the pricelist feature is working as expected.
Original PR description
Fixes runbot error https://runbot.odoo.com/odoo/runbot.build.error/243302 Needed because commit 9674a712d951 (https://github.com/odoo/odoo/pull/252521) is not yet forward-ported to saas-19.1.
This update fixes an issue where product URLs in multilingual websites incorrectly included the category. Now, the canonical URL for products in non-default languages accurately reflects the product itself, without the category prefix. This ensures consistent and correct links for customers browsing in different languages.
Original PR description
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to…
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to the shop in fr. 4- Open the category, then open the product. 5- Open console, and search for canonical. As you see, in the second language, the canonical address includes the category address which is wrong. If you visit in the default lang, the canonical correctly refers to the url without category. Cause: --- This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself. opw-6086206 Forward-Port-Of: odoo/odoo#258834
This update fixes a potential issue where users could falsely validate signatures in draw mode using Firefox and similar browsers. Now, the system requires a visible signature drawing before validation can occur, ensuring signatures are only confirmed when genuinely signed.
Original PR description
On Firefox and similar browsers, it was possible in some cases to validate a signature field in draw mode without actually drawing a signature, allowing the document signature to be confirmed with an empty signature. This change ensures that a signature field in draw mode can only be validated when the signer has effectively drawn a visible signature. task-6117312 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#259100
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, making it easier to understand and interpret.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field data. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unintended changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes focus on enhancing the overall experience and usability of the timesheet management process. The improvements are intended to streamline workflows and reduce potential confusion.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness.
This update fixes a rare crash that could occur when canceling drag sequences in the Odoo application. The issue stemmed from a timing problem with how the system registered and executed cancellation callbacks. This change ensures the callback is available before assignment, preventing the crash and improving overall stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261014 Forward-Port-Of: odoo/odoo#260594
This update corrects a bug where users received duplicate email notifications when submitting the email reminder form for events. The fix ensures that only one notification is displayed, and the form is now correctly embedded within the event page's HTML to prevent unwanted redirects. This improves the user experience and avoids redundant communication.
Original PR description
This PR fixes the email reminder form with multiple commits: - Commit 1 fixes the notifications displayed when the email form is submitted as the messages of those notifications are redundant. - Commit 2 inserts the form inside the HTML body instead of the interaction's HTML since the surrounding HTML of this last one may cause display issues as with the <a> tag redirecting the users on the talks page when they click on the form which should not happen. Task-5347538 Forward-Port-Of: odoo/odoo#251468
A recent update resolved a problem where newly added overtime lines on attendance records would disappear after a page refresh. To fix this, the system now prevents users from adding new overtime lines, ensuring data consistency and accurate work entry synchronization. This improves the reliability of overtime tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#248431
This update corrects a bug that was incorrectly generating overtime entries on previous days due to an issue with how work entries were being regenerated. The fix ensures accurate overtime calculations by considering employee timezones when searching for work entries, preventing incorrect date calculations.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#107266
This update resolves an issue in the HR Holiday module that was preventing accurate holiday calculations. The fix corrects a domain used to filter holiday leaves, ensuring that the system correctly identifies and applies available leave periods. This improves the reliability of holiday scheduling and reporting.
Original PR description
Forward-Port-Of: odoo/odoo#261250
This update fixes a bug that prevented links within 'Button' snippets on the website from being translated. Previously, these links were excluded from the translation process. Now, all button links are correctly tagged for translation, ensuring consistent localization across the website.
Original PR description
Before this commit, links on `Button` inner snippets dropped from the sidebar (not through powerbox) were never translatable. `o_translate_inline` was only added in link insert flows or when already present in snippet template, not when dropping inner button snippets. As a result, dropped button anchors were missing `o_translate_inline` and were filtered out from translatable inline links. Steps to reproduce: - Enter edit mode. - Drag and drop a `Button` inner snippet. - Save. - Switch to translation mode. - Try to edit the button link: it cannot be edited. This commit adds handling on snippet drop to tag dropped anchors with `o_translate_inline`. task-5943645 Forward-Port-Of: odoo/odoo#260423 Forward-Port-Of: odoo/odoo#249019
This update resolves a technical issue causing a '405 Method Not Allowed' error during logout. The change allows both GET and POST requests to the logout route, ensuring a smoother user experience and preventing errors when accessing the logout feature directly from a browser link.
Original PR description
Steps to reproduce: 1. Open a website 2. Go to the signup page and create an account 3. Click on the logout button Issue: A "405 Method Not Allowed" error occurs when logging out. The logout route only accepts POST requests, but in here a GET request is triggered (e.g., redirect flow), causing the error. Before this commit: Accessing `/web/session/logout` could result in a redirect to `/odoo` with a GET request, which is not valid since the route expects POST. After this commit: Allow both GET and POST methods on the logout route: POST requests handle the actual logout operation as expected GET requests are accepted to avoid 405 errors when we write direct on the browser. task-6023075
This pull request updates the core spreadsheet component (o_spreadsheet) to the latest version, ensuring users have the most recent functionality and bug fixes. Specifically, it addresses issues related to data formatting and color synchronization within the spreadsheet, improving overall performance and reliability. This update is a routine maintenance task.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4e3d2038e4 [REL] 19.1.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4e3d2038e4 [REL] 19.1.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d21a87b75b [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) https://github.com/odoo/o-spreadsheet/commit/201f1ba213 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause data inconsistencies and orphaned analytic lines. The fix ensures accurate account updates by disabling inverse methods during editing and explicitly recreating analytic lines upon saving, preventing data errors.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update corrects a visual issue where adding a new shift sometimes resulted in duplicate employee names appearing in Gantt views. The fix ensures that employee display updates correctly, preventing the display of the same employee multiple times. This improves the clarity and accuracy of shift scheduling.
Original PR description
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An…
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have: ``` +--------------+ | Shift1 User1 | +--------------+ ``` Add another shift (Shift 2) with User2. We'll have: ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User1 | +--------------+ ``` instead of ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User2 | +--------------+ ``` Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value. This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by ```html <span>Employee</span><span class="..">(Department)</span> ``` in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it, ```xml <span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/> ``` since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change. Therefore, whenever a component's value changes (in our case, Shift1 becomes Shift2), it is never updated. In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution. To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render. opw-6128168 Forward-Port-Of: odoo/enterprise#115160 Forward-Port-Of: odoo/enterprise#115061
This pull request corrects a visual issue where an empty state was sometimes displayed on the Odoo website. Previously, users might have seen an unexpected blank screen when certain sections were empty. This change ensures a consistent and professional user experience by properly handling empty states, improving overall website usability. This is a minor fix focused on visual presentation.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that the Slovak VAT tax reports generated by Odoo comply with the official Slovak XML format. Specifically, the formatting of editable fields has been adjusted to use the required 2 decimal place precision, as mandated by the Slovak VAT XSD schema. This ensures accurate data exchange with tax authorities.
Original PR description
As per the Slovak VAT XSD schema, editable fields must use a precision of 2 decimal places. So updating here to ensure compliance with the official XML format. Reference: https://ekr.financnasprava.sk/Formulare/XSD/dph2025.xsd
This update resolves a failing test related to WorldLine integration within the self-order system. The fix ensures that both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are present before running the test, preventing errors when the `pos_iot_worldline` module is not installed.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed.
This update resolves an issue where holiday allocations were being unnecessarily approved multiple times, potentially causing delays. The fix removes a redundant approval step and streamlines the process, ensuring holiday requests are processed efficiently. This improves the overall reliability of the holiday request system.
Original PR description
Cause: In this commit https://github.com/odoo/odoo/pull/258520/changes/1b6f3a1335302ca029ab62a25c7bcff0953b99be we accidently added a line to approve allocation which might already be approved. Fix: Remove this line and move the accrual filter right before the first action approve opw-5888023 Forward-Port-Of: odoo/odoo#260158
This update corrects a warning message appearing when using the Cash Basis accounting method with CIS-related transactions. The fix ensures that the CIS inactive check is applied correctly only to purchase-related documents, preventing unnecessary alerts for valid transactions. This improves the user experience and reduces potential reporting issues.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, appearing only in English. The change ensures that contact types are correctly translated to the user's preferred language, matching the translation displayed in the Kanban view. This improves the user experience for international users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/odoo#260815 Forward-Port-Of: odoo/odoo#257539
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, appearing only in English. The change ensures that contact types are correctly displayed in the user's preferred language across all views, improving user experience and consistency.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#114786
This update resolves an issue preventing account return tours from functioning correctly across all Odoo localization versions. The fix addresses a missing tag configuration, which previously caused errors and prevented the tours from running as expected. This ensures consistent functionality for users utilizing different language versions of Odoo.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action.
This update fixes an issue where Odoo was creating purchase orders even when sufficient stock was available for manufacturing orders. The change ensures that stock is accurately considered before generating purchase requests, streamlining the manufacturing process and reducing unnecessary procurement activity. This improves efficiency and avoids potential overstocking.
Original PR description
Steps to reproduce: - Create a product P1 with a BoM containing component C1 - Set C1 route to MTO + Buy: - add any vendor - Have 10 units of C1 in stock - Confirm a Manufacturing Order for 2 units…
Steps to reproduce:
- Create a product P1 with a BoM containing component C1
- Set C1 route to MTO + Buy:
- add any vendor
- Have 10 units of C1 in stock
- Confirm a Manufacturing Order for 2 units of P1
- The MO confirmation triggers the move for C1, which gets assigned from stock
- Increase the quantity_producing on the MO
- This updates product_uom_qty on the move and calls _run_procurement
Expected behavior:
- No Purchase Order should be created since stock covers the demand
Current behavior:
- A Purchase Order is created even though stock is sufficient
- In case of partial stock, the full procurement_qty is used instead of the uncovered delta
Fix:
- Track mts_else_mto moves separately before calling _action_assign()
- After _action_assign(), subtract the newly covered quantity (move.quantity - old_qty)
from the procurement_qty before running the stock rule
- Skip the procurement entirely if the adjusted qty <= 0
opw-6042283
Forward-Port-Of: odoo/odoo#258871