Daily updates from Odoo
Monday, March 30, 2026
31 changes · saas-18.3
Resolved issues and error corrections
This update corrects an issue where modifying a recurring event's start time caused duplicate events to be created in Outlook, leading to incorrect meeting notifications. The fix ensures Microsoft IDs are preserved when the base event is an exception, resolving this duplication problem and improving Outlook synchronization.
Original PR description
When an attendee syncs a recurring event where the first occurrence (base event) was modified by the organizer, `_write_from_microsoft` falsely triggers the destructive recreation path. This happens because `_has_base_event_time_fields_changed` compares the exception's modified time against the seriesMaster's pattern time, detecting a "change" even though the master hasn't changed. This causes: - All non-base events lose their microsoft_id and ms_universal_event_id - The base event gets recreated without Microsoft IDs - A duplicate event is pushed to Outlook on the next odoo2microsoft sync - Spurious "join the meeting now" notifications are sent to attendees Add a `follow_recurrence` guard so that when the base event is an exception (follow_recurrence=False), the non-destructive else branch is taken instead, preserving all Microsoft IDs. Forward-Port-Of: odoo/odoo#256263 Forward-Port-Of: odoo/odoo#254414
This update prevents a critical error that occurred when users attempted to create scrap orders without a designated scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, leading to a traceback. This fix ensures that scrap orders can now be created successfully, regardless of the scrap location setup.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
This update fixes a problem where PoS orders with additional products prevented successful settlement from the Point of Sale. The system now correctly calculates the total amount based on the PoS order, ensuring sales can be settled properly after down payments and extra items are added. This resolves a scenario where the sale order total was incorrectly calculated.
Original PR description
The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232
This update corrects an issue preventing the export of Profit & Loss reports with footnotes in the Luxembourg localization. The previous export process relied on an outdated model, causing errors. The fix now correctly utilizes the new `account.report.annotation` model for footnote references, ensuring successful XML generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to overflow, making the report visually unclear. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing the report from becoming unreadable. This improves the report's usability and data accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update fixes an issue where invoices created with the 'Pay Later' payment method in the Point of Sale module were missing the necessary QR code for payment. The fix ensures that invoices correctly identify the bank partner, resolving this problem and allowing for proper payment processing. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254892 Forward-Port-Of: odoo/odoo#254117
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected. Previously, new records didn't link to an account, requiring manual setup. This change streamlines the process and improves data accuracy within the analytic accounting module.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256091 Forward-Port-Of: odoo/odoo#255726
This update fixes an issue where chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages sent after the chatbot is restarted are accurately reflected, ensuring ticket descriptions are clean and relevant. This improves the clarity and usability of customer support tickets.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255336 Forward-Port-Of: odoo/odoo#253566
This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices without the necessary shared identifiers. This ensures accurate reporting and compliance for Peruvian businesses.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values.
This update replaces the old iDEAL logo with the new Wero logo for improved brand consistency. The change ensures that customers see the correct payment brand when using the iDEAL payment method within Odoo, enhancing the user experience.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#254901 Forward-Port-Of: odoo/odoo#248506
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when lines share a tax but have varying vehicle IDs, ensuring consistent tax calculations for all expenses.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update resolves an issue where credit notes created via 'Reverse and create invoice' didn't correctly show the original invoice's source information. The fix ensures that the source document is accurately reflected in the generated invoice PDF, improving reporting and traceability. This maintains consistent data across invoices and sales orders.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254290
This update ensures that the system correctly checks archived accounts when creating unaffected earnings accounts. Previously, this caused validation errors, particularly during upgrades with the `l10n_sa` module, due to a search for duplicate account codes including archived ones.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived.
This update resolves an issue where the VAT partner listing report was not displaying all relevant customers. The fix involves adjusting a setting within the report to load all partners, ensuring accurate reporting of financial data. This improves data visibility and reporting accuracy for tax compliance.
Original PR description
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and…
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year. - Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing. - Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear. - Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1. Download the XML again: only the first partner appears (the only that was loaded with the load more limit. This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72 Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89 Ticket [link](https://www.odoo.com/odoo/project.task/6051120) opw-6051120
We've been experiencing an increase in failed payments due to an issue with the Flutterwave payment processor. This change updates how the phone number is sent to Flutterwave, aligning with a recent API update that requires an unformatted phone number. This resolves the 'invalid billToPhone' error and ensures smoother payment processing.
Original PR description
With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error. It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue. So this commit, sanitize the phone number to send it unformatted. opw-6074825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256315
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode lookups. The fix ensures the scanner uses the correct company information, resolving the problem of incorrect product identification.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112006 Forward-Port-Of: odoo/enterprise#111662
A test used in the payroll module (l10n_ch_hr_payroll_elm_transmission) was failing due to an incorrect date calculation. The fix involved adjusting the test's time setting to ensure accurate calculations for future payroll years, preventing a disruption in reporting.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes a labeling issue with the 0% VAT rate for sales outside the EU in Sweden. The tax name has been corrected to '0% EX RS' to accurately reflect its usage, and the associated grid has been updated. This ensures accurate tax reporting and compliance for Swedish customers.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251750
This update fixes an issue where Chrome logs weren't reliably captured during shutdown, particularly when errors occurred. The changes also address Chrome's log buffering behavior and add resilience to ensure a smoother shutdown process, preventing data loss.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256306 Forward-Port-Of: odoo/odoo#256061
This update resolves an issue that prevented the creation of contracts when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The change utilizes modern URL handling techniques for accurate URL construction and display, ensuring correct links are presented to users. This improves the reliability of email communications within Odoo.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#254383
This update fixes an error in the Point of Sale session reports where discount amounts were calculated incorrectly. The fix ensures that discounts are applied accurately after the fiscal position is applied, leading to more reliable financial reporting. This improves the accuracy of sales data and reduces potential discrepancies.
Original PR description
Steps: ---- - Create a fiscal position with 2 different taxes - Add a line in POS - Apply fiscal position and add line discount - Finish the order cycle - Download the session report Issue: ---- - The discount amount was calculated incorrectly in the session report Cause: ---- - The discount amount calculation used taxes before applying the fiscal position Fix: ---- - Used `tax_ids_after_fiscal_position` for tax calculation while computing the discount amount task-5421215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247072 Forward-Port-Of: odoo/odoo#244650
This update resolves an issue where confirming quantities of archived products through the barcode app would trigger an error. The fix ensures that archived products are included in product searches, allowing users to accurately manage and confirm quantities, maintaining consistent functionality.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#109204
A test tour was failing because the test user lacked the necessary security group (`group_production_lot`) to enable line grouping in the stock barcode model. This fix adds the required group, allowing the tour to complete successfully and ensuring proper functionality for lot scanning and packaging.
Original PR description
```js ---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour → Step .o_barcode_line_summary ---------- { 'trigger': '.o_barcode_line_summary', 'run': 'click' },…
```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
'trigger': '.o_barcode_line_summary',
'run': 'click'
},
------------------------------------------------------------------------
```
The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.
**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:
https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53
When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).
The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.
Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.
similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755
---
runbot error:241926This update fixes an issue where the Field Service onboarding tour would stop after redirects to the portal. The change ensures the tour state is preserved in the user's session, allowing the tour to resume seamlessly when returning to the Field Service app. This enhances the user experience for new Field Service users.
Original PR description
**Steps to reproduce:**
1. Go to Field Service app.
2. Check the worksheet template in settings and start the onboarding tour
of Field Service.
**Issue:**
The backend tour is not resuming on the frontend side.
**Fix:**
This commit ensures the tour is enabled and the current tour is added to the frontend session. When the tour resumes, it will fetch the tour enabled and current tour details from the session.
**Technical:**
In the tour service, the tour resumes only if the mode is set to "auto" or toursEnabled is present in the session. To handle this, we added the tour details to the session.
tour_service.js
``` js
if (tourState.getCurrentConfig().mode === "auto" || toursEnabled) {
resumeTour();
}
````
task-4489657
Forward-Port-Of: odoo/odoo#202484This update resolves a bug that prevented the FSM reporting tour from completing correctly when run without demo data. A new worksheet was added to stop the "Explore Worksheets" wizard from appearing, ensuring the tour flows as intended. This improves the user experience for accessing the FSM reporting features.
Original PR description
**Reason for creating the worksheet:** ------------- When the tour runs without demo data, only one worksheet exists, so the **“Explore Worksheets Using an Example Template”** wizard opens and stops the tour. To avoid this, I created an extra worksheet so the wizard does not open and the tour continues normally. https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/industry_fsm_report/models/project_task.py#L122-L135 task-4489657 Forward-Port-Of: odoo/enterprise#81823
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It’s a simple fix to improve user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update resolves a problem preventing invoices from being correctly linked to purchase orders. The fix ensures that price comparisons account for the 'Product Price' precision, which was previously causing mismatches. This resolves a critical issue impacting invoice processing for a major customer.
Original PR description
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is…
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235477 Forward-Port-Of: odoo/odoo#232527
This update corrects a change in the URL required to send e-invoices to the Serbian government. The previous URL was outdated, preventing proper e-invoice submission. This fix ensures compliance with Serbian regulations and allows seamless e-invoice processing.
Original PR description
**PROBLEM** The url to send e-invoice to the serbian government has changed. opw-6055622 Forward-Port-Of: odoo/odoo#256095
This update resolves an issue where Odoo displayed a misleading warning message to users when they didn't immediately set a password during file uploads. The system now correctly checks for a password during the saving process, improving the user experience and eliminating this unnecessary notification.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253834
This update corrects a technical detail by removing outdated tags (<report> and <act_window>) from the Odoo import files. These tags were previously removed in another change, but this commit ensures they are no longer present, maintaining the integrity of the import process. This ensures consistent and reliable data imports.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116