Daily updates from Odoo
Tuesday, March 31, 2026
35 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document handling system, ensuring documents can now be reliably opened even after being renamed. This improves the overall usability of the documents feature.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110315 Forward-Port-Of: odoo/enterprise#105602
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML files. The fix skips PDF extraction when raw data is missing, ensuring consistent file generation and preventing disruptions to the document processing workflow.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves an issue where a validation check for the suspense line was failing due to a change in how the suspense line is calculated. The update ensures the suspense line is correctly formatted, preventing potential errors in the system's financial reporting. This ensures accurate data processing.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update corrects an issue preventing the SBR tax reports from being submitted correctly. Specifically, it restores the correct date format and ensures the consultant information is displayed concisely, resolving validation errors. This ensures compliance with tax reporting standards.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update fixes an issue where barcode scanning with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves data accuracy and reliability within the stock management system.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671This update resolves a technical issue within the Bank Reconciliation widget that could cause errors when deleting counterpart lines in bank transactions. The fix ensures the system correctly handles data props, preventing unexpected errors and improving the stability of the reconciliation process. This change impacts the Bank Reconciliation feature.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112175
This update fixes a warning related to how work orders consume components in manufacturing. Previously, the system would incorrectly flag a lack of lots when component quantities were specified. The change now correctly generates the necessary serials, ensuring accurate tracking of component usage within work orders. This resolves a potential disruption in production workflows.
Original PR description
This commit update the test since the fix commit introduced a new behavior. Before if the manufacturing had qty_producing, it would not set the move to picked and raise an error because there is no lot. With the fix, when the production has qty_producing. It will generate the missing serial. We prefer this behavior to the old ones so we keep it. Forward-Port-Of: odoo/enterprise#106365
This update resolves an issue where AI conversations within the Odoo AI app were sometimes stuck in a self-chat loop, displaying an OOO banner. The fix ensures that AI conversations correctly identify and interact with agents, preserving the intended agent workflows. This improves the overall user experience and reliability of the AI assistant.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112164 Forward-Port-Of: odoo/enterprise#111736
This update fixes a technical error that prevented users from correctly updating lot numbers on stock move lines. The change ensures that lot IDs are properly linked within the Odoo system, resolving a potential data inconsistency and preventing errors during inventory adjustments. This improves the reliability of stock tracking.
Original PR description
Since ce2a8f9c929, quality.check.lot_id (Many2one) was changed to lot_ids (Many2many), but the write() override in stock.move.line still assigns a raw integer to the field. This causes a ValueError when changing the lot on an MO move line. With this commit, use Command.link() to properly link the record to the Many2many field. Forward-Port-Of: odoo/enterprise#110180
This update resolves an issue where a test tour within the product catalog feature was failing due to a problem with how product selections were being tracked. The fix ensures the correct section ID is always used, preventing the tour from encountering an error and improving the overall user experience.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960 Forward-Port-Of: odoo/odoo#254374
This update fixes an issue where combo prices were incorrect when multiple quantities were selected. The fix ensures that the combo price accurately reflects the total quantity of items, regardless of the customer or preset selected. This improves the accuracy of point-of-sale transactions.
Original PR description
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong…
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong **Why the fix:** Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this function we recompute the combo's children lines' price. Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price. This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485 This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price. We now set the right amount in the free qty based on the parent line's qty. When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line. This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work. The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible. opw-5266483 Forward-Port-Of: odoo/odoo#255898 Forward-Port-Of: odoo/odoo#244940
This update fixes an issue where Italy's chart of accounts was defaulting to incorrect expense and revenue accounts. The change explicitly defines the correct deferred accounts (`190200` and `270200`) within the chart template, ensuring accurate financial reporting for Italian businesses using Odoo.
Original PR description
Italy's chart template did not explicitly define deferred expense and revenue accounts, so deferred accounts fell back to the first `asset_current` and `liability_current` accounts in the chart. That could assign incorrect defaults such as `140100` and `220100`. This patch sets the intended Italian deferred accounts to `190200` and `270200` directly in the template to ensure correct configuration during chart loading. task-6076711 Forward-Port-Of: odoo/odoo#256623
This update automatically sets the correct analytic account when creating new items from the gross margin smart button within analytic accounts. Previously, new records didn't link to an account, leading to data inconsistencies. This change ensures accurate tracking of financial data within the Odoo system.
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#256426 Forward-Port-Of: odoo/odoo#255726
This update resolves an issue where credit notes created through '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#256284 Forward-Port-Of: odoo/odoo#254290
This update resolves an issue where certain XML tags were not properly removed from the Odoo import file. The change ensures that the import process accurately reflects recent updates by deleting the <report> and <act_window> tags from the import_xml.rng file. This improves the consistency and reliability of Odoo's import functionality.
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
This update fixes a configuration issue with default accounting accounts for the Swiss (l10n_ch) version of Odoo. The previous misconfiguration has been corrected, ensuring accurate financial reporting for Swiss businesses using this module. This ensures compliance and reliable financial data.
Original PR description
[IMP] l10n_ch: Set default accounts in Switzerland Some defaults accounts in Switzerland were misconfigured, this commit set clean values by default task-6043978 Forward-Port-Of: odoo/odoo#255350
We've been experiencing an increase in payment failures related to an 'invalid billToPhone' error. This update corrects the way phone numbers are sent to Flutterwave, aligning with a recent change in the Flutterwave API that requires unformatted phone numbers. This resolves the payment errors and ensures smoother transactions.
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#256478 Forward-Port-Of: odoo/odoo#256315
This update automatically checks out employees from attendance records when they are archived. Previously, archived employees remained checked in, leading to data inconsistencies. This change ensures accurate attendance tracking and simplifies the process of managing archived staff.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256083 Forward-Port-Of: odoo/odoo#255524
This update optimizes how the system loads partner data for self-ordering, addressing previous performance issues. By only loading essential information, the system now operates more efficiently, particularly when dealing with partners with extensive data. This results in a smoother and faster self-ordering experience.
Original PR description
Partner data loading for self-ordering was not optimized, leading to performance issues when the partner had a lot of data. This commit optimizes the partner data loading by only loading the necessary fields for self-ordering. Forward-Port-Of: odoo/odoo#256158 Forward-Port-Of: odoo/odoo#253563
This update resolves a potential instability in the testing of one2many fields within the Odoo web application. Specifically, a test was occasionally failing due to an unintended record creation. This fix prevents a second record creation, ensuring the test is more reliable and consistent.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
runbot error~242204
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#256582This update significantly speeds up the Inventory Valuation report by correctly handling date comparisons across timezones. Previously, the report would slow down when the user's local time wasn't aligned with the report's UTC date. The change ensures faster report generation, especially for large inventories.
Original PR description
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:…
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day: https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34 If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy. https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397 The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not. We propose to use the context_today() method instead to get the date from the user's timezone. Benchmark: | No AVCO Products | Before PR | After PR | |------------------|-----------|----------| | 12000 | > 40 s | 3 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255841
This update enhances the process for managing demo transactions in the Point of Sale system. Previously, users were permanently blocked with demo orders. Now, users can easily delete the demo transaction or sync it to the live production environment, providing greater control and flexibility.
Original PR description
Before this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` were readonly when
`l10n_jo_edi_pos_qr` was set. However, we did not take into account the fact
that `pos.order` cannot be reset once `done/paid/invoiced`; thereby blocking
the user with a demo transaction forever without any alternative.
After this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` are readonly when
`l10n_jo_edi_pos_qr and l10n_jo_edi_state == 'sent'`. Additionally, an
onchange is introduced on `l10n_jo_edi_pos_state` to clear
`l10n_jo_edi_pos_qr`. This gives back flexibility to the user to either delete
the demo mode transaction or sync them to the production endpoint.
task-5958427
Forward-Port-Of: odoo/odoo#250808This update fixes a bug in the production process that was causing consumption warnings to appear unexpectedly. The issue stemmed from an incorrect order of operations when setting production quantities, leading to inaccurate tracking of materials. The fix ensures that production quantities are correctly validated, eliminating these warnings.
Original PR description
Usecase to reproduce: - Create a BoM with a finished product and a component - Create a MO for 10 units - Produce all Expected behavior: 10 units produced Current behavior: Consumption warning It happens because the code use this order: - Set the moves raw to picked base on their quantity producing - Set the quantity producing for production without quantity. So it just don't work and the consumption warning is trigger. The fix just invert the order task: 5068382 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#245176
This update corrects an issue where QR codes generated for self-ordering pickup orders included incorrect URLs with table information. The fix ensures QR codes are generated correctly for 'pickup zone' ordering modes, preventing errors in downloaded PDFs and improving the customer experience. This resolves a previous problem with incorrect URL formatting.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254897 Forward-Port-Of: odoo/odoo#247184
This update fixes a problem where PoS orders with additional products would prevent successful settlement from the PoS. The system now correctly calculates the unpaid amount based on the total PoS order amount, ensuring orders with multiple items can be properly settled. This resolves a previous issue preventing users from completing transactions.
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 Forward-Port-Of: odoo/odoo#256590 Forward-Port-Of: odoo/odoo#251387
This update corrects a problem where Odoo couldn't properly validate production orders when lots were consumed during operations, specifically in the Opera browser. The fix ensures that production orders are accurately validated, preventing potential errors in inventory tracking and order fulfillment. This resolves a previously reported issue impacting order processing accuracy.
Original PR description
…tion POC 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#253924
This update strengthens the testing process for right-click editing in the Odoo email module. The test now verifies key actions, making it less reliant on timing and more reliable. This ensures the editing functionality works consistently and reduces the risk of unexpected issues.
Original PR description
This PR is a follow up of https://github.com/odoo/odoo/pull/256063 Use `expect.waitForSteps()` in the right-click editing test to assert the message context-menu flow more explicitly instead of relying only on `animationFrame()`. The test now verifies that: - `onContextMenu()` is triggered - `showRightClickMessageActions()` is not triggered while editing This makes the test less timing-dependent.
This update ensures that sales order sequences correctly use the intended month when generating numbers, resolving an issue where the sequence number was based on the wrong date. The fix addresses a discrepancy between the sequence's prefix/suffix and the actual order date, preventing incorrect sequence numbering. This improves data accuracy and consistency in sales order processing.
Original PR description
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use…
## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.
## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
- Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
- Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
- Add a row for the current month, with *Next Number* set to 1
- Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
- Any Customer
- Any Product
- Set the *Quotation Date* to next month
- Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**
<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />
The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.
## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.
https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216
In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270
**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**
opw-5950028
Forward-Port-Of: odoo/odoo#256320This update corrects a problem where newly added billing addresses were incorrectly appearing in both the delivery and billing sections of the customer portal. The fix removes a technical element that caused the address type to be misconfigured, ensuring accurate address display and management for users.
Original PR description
Versions -------- - 19.0+ Steps ----- - Log in on the portal - Go to "My Account" - Go to "Addresses" - In the billing section uncheck "Same as delivery address" - In the billing section click "Add…
Versions -------- - 19.0+ Steps ----- - Log in on the portal - Go to "My Account" - Go to "Addresses" - In the billing section uncheck "Same as delivery address" - In the billing section click "Add Address" - Fill in address details - Click "Save Address" Issue ----- The newly added address is visible in both the delivery and billing sections, and in the backend the address has type "other" instead of "invoice". Cause ----- This happens because the "Add Address" url in the billing section contains the parameter `use_delivery_as_billing=True`, which supersedes the parameter `address_type=billing`, creating an address with type "other". This is because the "Add Address" url in the billing section is not dynamically updated when the "Same as delivery address" toggle is toggled like with the url in the delivery section. Solution -------- The `use_delivery_as_billing` is completely removed from the url in the billing section, because the button only appears when the toggle is unchecked (i.e. when `use_delivery_as_billing=false`). And by not sending the parameter, it defaults to false in the backend. opw-5880430 Forward-Port-Of: odoo/odoo#256326
This update resolves an issue where Odoo displayed a misleading warning message when users didn't set a password during file uploads. Now, the system correctly checks for a password during saving, eliminating the unnecessary warning and improving the user experience. This ensures consistent behavior and avoids potential confusion for users.
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#256759 Forward-Port-Of: odoo/odoo#253834
This update resolves an issue where a key method was missing in several Odoo stock modules (purchase, sale, and point-of-sale). The fix ensures proper inheritance from parent modules, which is crucial for accurate stock management and reporting. This change improves the stability and reliability of these core Odoo functions.
Original PR description
**Description of the issue/feature this PR addresses:** A new method name was introduced but not fixed in the inherited modules which leads to a missing method in their related super call. **Current behavior before PR:** Missing super method in related super calls in these modules **Desired behavior after PR is merged:** Proper inheritance based on a method removed by accident Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252757
This update fixes a technical issue where syncing cancelled events from Microsoft Calendar would cause an error. Now, when a cancelled event is initially synced, it's correctly handled, preventing errors and ensuring accurate event synchronization within Odoo. This improves the reliability of our calendar integration.
Original PR description
Before this commit, when syncing events from Microsoft, if there was a cancelled event that was not yet synchronized with Odoo, calling browse on event.odoo_id would raise an error as it would be None. opw-5917677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a display issue where tax names were shown in English for Spanish users. Now, all tax names are correctly displayed in Spanish, improving the user experience and ensuring accurate reporting for our Spanish-speaking customers. This change was made to comply with local regulations and provide a seamless experience.
Original PR description
It was a previous dev in which the fw-port failed. Here is the old [PR](https://github.com/odoo/odoo/pull/238857) The tax names were displayed in English, and it's confusing for the Spanish users. Now, the taxes are displayed in spanish task-6041023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256182 Forward-Port-Of: odoo/odoo#255074
Features or functions removed from Odoo
This update removes a misleading tooltip from the account tax scope field. The tooltip provided unnecessary detail that wasn't helpful to users. This simplifies the interface and improves the overall user experience.
Original PR description
Remove the misleading tooltip entirely. No need to have more details on that field right now. Task [link](https://www.odoo.com/odoo/project.task/5946889) task-5946889 Forward-Port-Of: odoo/odoo#256573
Documentation and clarification updates
This update corrects a minor detail in the Optesis documentation by updating the contributor list. Specifically, the name of Ibrahima NIASSE EXT has been added to reflect the most current information. This ensures accurate representation of those involved in the project.
Original PR description
Replaced Mame Abdoul Aziz SY with Ibrahima NIASSE EXT in the contributors list. 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#256563