Daily updates from Odoo
Tuesday, November 25, 2025
311 changes
17 changes
Enhancements to existing features
This update allows users to backdate Saudi invoices within Odoo, resolving a previous limitation that prevented accurate reporting to ZATCA. By aligning the invoice confirmation date with the invoice date itself, this change ensures consistency and simplifies invoice processing for Saudi Arabia. This improves compliance and reduces potential discrepancies.
Original PR description
Previously, `l10n_sa_confirmation_datetime` represented the time where the invoice was posted, that meant that we could not backdate invoices, since it would cause disparity between what zatca receives and what we consider in odoo (i.e. `invoice_date`) This commit allows us to set the date component of `l10n_sa_confirmation_datetime` to the `invoice_date` so we can safely backdate invoices. task-5009969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236979 Forward-Port-Of: odoo/odoo#229517
Resolved issues and error corrections
This update fixes a bug where composite reports weren't consistently applying filters. Now, enabling a filter on a composite report will automatically enable it on its individual sections, ensuring accurate and complete report results. This aligns with standard Odoo reporting practices and improves user experience.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237003 Forward-Port-Of: odoo/odoo#236893
This update ensures that filters applied to composite reports consistently work across all sections within those reports. Previously, some filters weren't displayed correctly, leading to inconsistent reporting. This change aligns with standard Odoo reporting practices for filter behavior.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100240 Forward-Port-Of: odoo/enterprise#100148
This update resolves an issue where adding attachments to log notes triggered an error when the restrictive audit trail was enabled. The fix allows users to attach files to log notes while maintaining audit trail integrity, improving invoice documentation and record-keeping. It also consolidates related test cases.
Original PR description
To replicate: 1. In Settings, enable Restrictive Audit Trail 2. Create and post an invoice 3. Click on "Log note" and add a PDF attachment to the note 4. Click "Log" 5. Error ("You cannot remove…
To replicate:
1. In Settings, enable Restrictive Audit Trail
2. Create and post an invoice
3. Click on "Log note" and add a PDF attachment to the note
4. Click "Log"
5. Error ("You cannot remove parts of a restricted audit trail.") is raised.
With restrictive audit trail enabled, attachments cannot be deleted and writing to the attachment is restricted. However, when adding an attachment via the log notes, this writes to the attachment, setting the res_model to account.move and raising the error when _except_audit_trail() performs the check for a second time. This second write is triggered in `fix_attachments_on_record()`, introduced in odoo#189979.
This commit fixes that by also comparing the old values of the attachment and the new values to be written. If any of them are different, we proceed as before. Attachments cannot be deleted or changed. But if all values are the same, we do not perform the check, so an attachment can still be added.
In this commit we also move the attachment audit trail tests from l10n_de to account. In odoo#203229, the attachment audit trail checks were moved from to account, but the tests remained in the localization. An additional case covering the attachments in log notes was also added to the tests.
opw-5107912
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the 'Click to Start' navigator wasn't appearing for documents without sign items. The fix ensures the navigator displays when a document has sign items, improving the user experience and making it easier for users to initiate the signing process.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Add multiple documents in sign app. - Add sign item for user in first document and keep second document without any sign item. - Try sign document. Issue: - The "Click to Start" navigator is not visible when signing. - `postRender` runs for all documents and calls `checkSignItemsCompletion`, which then calls `updateDocumentsWithUnsignedItems(false)` for documents without sign items. - This passes false to `controlNavigatorVisibility`, hiding the navigator even though the first document has unsigned items. Solution: - In `controlNavigatorVisibility`, instead of relying only on the `hasUnsignedItems` flag, check if the current document is unsigned and has sign items for the current signer before toggling the navigator. Impact: - The "Click to Start" navigator now appears correctly, helping users start the signing process smoothly. task-5148722
This update fixes a bug preventing users from marking strikethrough and multiline fields as both readonly and mandatory within the Sign app. Now, users can correctly configure these fields without causing sign requests to fail, improving usability and workflow efficiency. This resolves a technical limitation impacting document signing functionality.
Original PR description
**Version:** - saas-18.4 **Steps to reproduce:** - Install the Sign app - Upload a PDF and add a strikethrough or multiline field - Mark the field as readonly and mandatory - Try to sign the document **Issue:** - The sign request cannot be validated if the strikethrough or multiline field is both readonly and mandatory. **Solution:** - For strikethrough fields: use "striked" instead of the item name "strikethrough" to set the correct value when the strikethorugh field is constant. - For multiline fields: when the field is constant, the value doesn’t come through element.value; instead, it’s in element.textContent, so we need to set the value there. **Impact:** - Users can now mark these fields as readonly and mandatory without blocking the validation of the sign request. task-5098750
This update optimizes the performance of our sales order system. By adding an index to a key field, we've reduced the time it takes to search and filter sales orders based on which sales team they're associated with. This results in faster response times and a smoother experience for our sales teams.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves an issue where creating annotations in Arabic language reports would generate an error due to incorrect date formatting. The fix ensures that dates are formatted using the standard Latin numbering system, preventing the error and allowing users to correctly add annotations in Arabic.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493
This update resolves an issue where the Facturae export XML incorrectly displayed negative values for withholding taxes. The fix ensures that withholding tax amounts are always positive, preventing rejection by the FACE system. This improves the accuracy of invoice data sent to tax authorities.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205 Forward-Port-Of: odoo/odoo#235774
This update fixes an issue where only the first CFE was processed from Uruguayan vendor bills. Now, all CFEs within the XML files are correctly handled, and new documents created manually or automatically receive unique suffixes ('-manual' or '-notification') for easier tracking and debugging. This ensures accurate bill processing and simplifies identification of document origins.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355 Forward-Port-Of: odoo/enterprise#99308 Forward-Port-Of: odoo/enterprise#86829
This update resolves a bug where shared Knowledge articles wouldn't display correctly for users accessing them through different website languages. The issue stemmed from a URL rewriting conflict, preventing the website from properly recognizing the article's location. This change ensures that shared articles are accessible to all users regardless of their website language setting.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update resolves an issue where the invoice report incorrectly displayed currency symbols and incorrect total amounts for companies using the 'tax included' tax setting in Kenya. The fix ensures accurate reporting of prices, including tax, for these businesses, improving financial reporting reliability.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update resolves several issues impacting the mobile Kanban view for document management. Specifically, it addresses gaps in folder and document display and scrolling limitations, ensuring a smoother and more functional user experience. This enhancement improves usability and data accessibility for users.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#100134 Forward-Port-Of: odoo/enterprise#90647
This update fixes an issue in the 3-step manufacturing process where production quantity changes weren't correctly triggering replenishment orders when using the MTSO rule. The fix ensures that sufficient component quantities are automatically ordered to meet production needs, improving inventory management accuracy.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871 Forward-Port-Of: odoo/odoo#235125
This update corrects a technical issue related to the calculation of Saudi taxes (QR) within the Odoo accounting system. The original change was accidentally removed during a recent update process. This fix ensures accurate tax reporting for Odoo users in Saudi Arabia.
Original PR description
This change was part of 04a4403 and was accidentally removed during a recent forward port. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237264
This update fixes an issue where website background images would disappear when the width or height was set to 0 in 'Repeat pattern' mode. The fix ensures that background image settings reset to the default 'auto' size, preventing unexpected visual changes and improving the user experience when customizing website backgrounds.
Original PR description
__Current behavior before commit:__ In "Repeat pattern" mode, users can set the background image's width and height to 0px, which doesn't make sense. Additionally, clearing these input fields resets their values to 0px instead of reverting them to `auto`. __Description of the fix:__ Make it possible to clear those fields by setting their default value to `null` and set the minimum value to 1 to prevent the image from disappearing. __Steps to reproduce:__ 1. On the website, drop a `s_cover` snippet 2. Set Background > Image > Position to "Repeat pattern" 3. Delete the content of the "Width" input => The background disappears. task-5094899
This update resolves an issue where timesheet entries linked to reversed invoices were previously uneditable. Now, after reversing an invoice, users can correctly modify timesheet entries associated with that invoice through the recorded hours feature, ensuring accurate time tracking and invoicing.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#236601 Forward-Port-Of: odoo/odoo#201921
27 changes
Enhancements to existing features
This update enhances the Peppol Registration Wizard by streamlining the user experience. Specifically, a warning banner now only appears after endpoint details are entered, and a placeholder has been removed for clarity. This simplifies the process for users registering for Peppol.
Original PR description
In the Peppol Registration Wizard: - Warning banner should only show up when endpoint as been filled - Remove placeholder - ~Remove the "in" migration~ Ref PR for master: odoo/odoo#234088 Task [link](https://www.odoo.com/odoo/project/967/tasks/5170831?debug=assets) task-5170831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235982 Forward-Port-Of: odoo/odoo#234087
This update enables the IoT box to connect without requiring a secure HTTPS certificate. By utilizing Local Network Access (LNA), the system now defaults to HTTP requests, simplifying the connection process and improving reliability. This change ensures consistent functionality for IoT devices.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/100331 **This PR contains 2 commits:** - **[IMP] iot_base: allow use of LNA for IoT requests** Chromium 142 added support for HTTPS -> HTTP…
Enterprise PR: https://github.com/odoo/enterprise/pull/100331 **This PR contains 2 commits:** - **[IMP] iot_base: allow use of LNA for IoT requests** Chromium 142 added support for HTTPS -> HTTP requests on the local network (Local Network Access). This commit adds a flag to the IoT longpolling class to enable LNA support. The flag forces all requests to use HTTP even in an HTTPS environment. It also sets the `targetAddressSpace` option to `local` in the `fetch` request. - **[IMP] point_of_sale: use_lna support for IoT requests** Since https://github.com/odoo/odoo/pull/235702, there is a `point_of_sale.use_lna` system parameter. When it is set, ePOS requests will use HTTP instead of HTTPS, and the `targetAddressSpace: "local"` option is used in the `fetch` request. This bypasses the need for a HTTPS certificate. This commit adds the same functionality to all IoT requests from the POS. This should allow the IoT box to function correctly without a HTTPS certificate. task-5353672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the reliability of IoT devices connected to our Point of Sale system. By supporting HTTP requests instead of HTTPS, the IoT box can now function without requiring a certificate, resolving a previous connectivity issue. A warning message is also displayed if a fallback to the websocket is necessary.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/237147 Since odoo/odoo#235702, there is a `point_of_sale.use_lna` system parameter. When it is set, ePOS requests will use HTTP instead of HTTPS, and the `targetAddressSpace: "local"` option is used in the `fetch` request. This bypasses the need for a HTTPS certificate. This commit adds the same functionality to all IoT requests from the POS. This should allow the IoT box to function correctly without a HTTPS certificate. In addition, we now show a warning message when a request to the Blackbox via HTTP fails and has to fallback to the websocket. task-5353672
This pull request introduces new automated tests for the UrbanPiper integration, ensuring the functionality continues to work correctly. Additionally, several minor fixes have been implemented to improve stability and data accuracy, specifically related to receipt printing and timer display.
Original PR description
## 1. Hoot test
in this commit:
- add HOOT tests for components, model, screen, and service
- added test for methods in `order_info_popup` and `order_display`
- include tests for `pos_order`, `ticket_screen`, and `pos_store`
- add utility to generate UrbanPiper-filled order
## 2. minor fixes
in this commit:
- kept serialized data for receipt printing
- ensure timer does not display negative values
- correct variable usage in ticket screen to fetch proper props for display order
- revamp `getTime` method to use l10n time format
task: 5048312Resolved issues and error corrections
This update resolves an issue in the Odoo Enterprise Peru UBL export that was causing errors due to an incorrect partner reference. The fix removes a problematic code addition, ensuring the UBL XML conforms to Peruvian regulations and avoids export failures. This improves the reliability of our Peru-specific accounting reports.
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043
This update resolves an issue where CFE PDFs weren't being generated correctly after invoice creation and CFE generation in Uruguay. The fix ensures that the PDF from Uruway is consistently linked to the invoice, addressing a gap in the automated CFE process. This improves the accuracy and completeness of invoice documentation.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776 Forward-Port-Of: odoo/enterprise#100128
This update corrects a technical issue where unregistering a Nemhandel user caused it to be lost from the system's user database. Previously, attempting to manually unregister a user would result in an error. This fix ensures that users are properly tracked, preventing data inconsistencies and improving system stability.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236670
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the correct customer receivable account, ensuring accurate reporting for Romanian VAT returns. This resolves a discrepancy identified in the SAFT report output.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update fixes an issue where a product valued by lot would incorrectly use the average value instead of 0 when a lot was assigned with a value of 0. The change ensures that stock valuation layers are accurately set to 0 when a lot with a zero standard price is used, preventing incorrect valuation calculations. This improves the accuracy of inventory accounting.
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671
Forward-Port-Of: odoo/odoo#234764This update fixes an issue where users were incorrectly changing product details on combo item lines. To address abuse of this functionality, a temporary workaround has been implemented requiring users to hide product columns before editing the description. This ensures data integrity within the sale module.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes). Forward-Port-Of: odoo/odoo#236964 Forward-Port-Of: odoo/odoo#235547
This update adds a notification to alert users when they are utilizing the Chorus Pro module without the necessary module installed. This ensures they have access to all required checks and functionality, preventing potential issues and maintaining system integrity. It's a proactive measure to support a smooth user experience.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236856
This update addresses a problem where image resizing within Odoo's Studio reports didn't consistently work. Due to technical limitations with how PDF generation is handled, percentage-based image sizing wasn't correctly translated. The fix disables the image resize option in Studio to ensure accurate PDF output.
Original PR description
Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237088
This update resolves a bug where image resizing within Odoo Studio reports didn't correctly translate to the generated PDFs. The issue stemmed from a limitation of the PDF generation tool (`wkhtmltopdf`) which doesn't handle percentage-based sizing. The fix disables the image resize option in Studio to ensure accurate PDF output.
Original PR description
Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052 Forward-Port-Of: odoo/enterprise#100301
This update corrects a technical issue where stopping ringtone playback caused unnecessary HTTP requests. The fix resets the element's source, preventing the browser from attempting to load a "null" file and improving performance. This ensures ringtones play correctly without impacting system resources.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update fixes an issue where the 'Not Acknowledged' and 'Late Receipt' counters on the Purchase Dashboard incorrectly included completed purchase orders. The fix ensures these counters now accurately reflect only pending acknowledgments and genuinely late receipts, providing more reliable data for tracking purchase orders.
Original PR description
Before this commit: ------------------------- - On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters also included purchase orders whose receipts had already been done. - For…
Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
- Such POs should be implicitly considered acknowledged once their receipts
are done, but they were still shown at the counter.
- Additionally, unacknowledged POs that were locked were incorrectly excluded
from the counter.
- For Late Receipt:
- POs with received products were incorrectly counted as late, even
though their receipts were already done.
- Locked POs with late receipts were also excluded from the counter, which was
an incorrect behavior.
Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
counters and some locked POs that are unacknowledged or have late receipts
are missing from the counters
Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
some locked POs were incorrectly excluded.
After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
unacknowledged POs with completed receipts are automatically marked as
acknowledged and excluded from the Not Acknowledged counter. Locked POs that
remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
receipts are completed and Locked POs with late receipts will now correctly
continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
acknowledgments and genuinely late receipts, helping users track POs in
the correct state.
Task ID: 4874116
Forward-Port-Of: odoo/odoo#224180This update prevents the 'My Drive' folder from automatically unfolding when you open folders within it, like 'Company'. Previously, this behavior caused confusion and an inconsistent user experience. This change ensures folders only unfold when their parent folders are opened.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#93718
This update optimizes the performance of our sales order system by adding an index to a key field. This change speeds up searches and filtering of sales orders based on which sales team is assigned to them, leading to faster response times for users. It addresses a potential bottleneck in our database.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves an issue where reconciliation processes would fail due to a conflict in naming reconciliation models. The fix ensures that new models are uniquely named, preventing errors when using the 'Set Account' feature to reconcile bank statements. This improves the reliability of the reconciliation process.
Original PR description
It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name" Steps…
It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name" Steps to reproduce: 1. Create a current liability, reconciliable account "455010 My Account" 2. Create 2+ with a common labels (TEST RECONCILIATION) 3. Use "Set Account" button to reconcile the first transaction with account 455010. 4. Repeat 2-3 with a shorter label 5. Open Reconciliation models for the Journal and delete the one named "455010 My Account" 6. Repeat 2-3 with an even shorted label Issue: Reconciliation will be blocked by error during automatic creation of reconciliation model Analysis: It occurs because we don't take into account that old reconciliation models may have been deleted, so even if we count a singe record it may have already been labeled "<account_name> (1)" Improved the naming by looking at the existing models and increasing the counter if necessary opw-5184696
This update resolves an issue where importing journal entries targeting inactive accounts would trigger excessive errors. The change now allows importing these items without regard to the account's active status, streamlining the import process and preventing disruptions.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A minor technical correction was made to the Odoo accounting software for Saudi Arabia (l10n_sa) to ensure accurate QR code tax calculations. This fix, which was previously implemented, was accidentally removed during a recent update. The change ensures compliance with Saudi tax regulations.
Original PR description
This change was part of 04a4403 and was accidentally removed during a recent forward port. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where creating annotations in Arabic language reports would generate an error due to incorrect date formatting. The fix ensures dates are formatted using the standard Latin numbering system, preventing the error and allowing users to correctly add annotations in Arabic. This improves the reliability of the general ledger reporting.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493
This update resolves an issue where the exported XML invoices for Spanish VAT (Facturae) incorrectly displayed negative withholding tax values. The fix ensures that withholding tax amounts are always positive, preventing rejection by the FAC (Foreign Agents Control) system. This ensures accurate VAT reporting and compliance.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205 Forward-Port-Of: odoo/odoo#235774
This update resolves an issue where shared Knowledge articles wouldn't display correctly for users accessing them through different website languages. The fix corrects a URL rewriting problem, ensuring articles are accessible regardless of the user's preferred language setting, improving the user experience for all portal visitors.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update resolves a reporting error in the invoice report for Odoo Enterprise when companies use the 'tax included' setting for their taxes. The fix corrects a display issue showing duplicate currency symbols and ensures the 'Total' column accurately reflects prices including tax. This improves the accuracy of financial reporting for Kenyan customers.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update fixes an issue in the 3-step manufacturing process where changing the production rule to MTSO didn't correctly trigger replenishment orders. The fix ensures that sufficient component quantities are automatically ordered when needed, improving production efficiency and preventing stockouts. It corrects a logic error in how procurement is handled.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871 Forward-Port-Of: odoo/odoo#235125
This update streamlines account reporting settings for users in specific countries, ensuring relevant options are displayed based on their reporting needs. Previously, users had to manually determine acceptable fiscal year settings, which has now been automated to prevent confusion and improve the reporting experience.
Original PR description
We're adding several countries to the settings, each time a user from this country has specific fiscal year and does non-monthly reporting. It's cumbersome, as we have to know in which country it's acceptable. At the same time, we don't want to show a setting if it's useless to the user. It will just confuse him. So, we should show this setting as soon as the report will complain: - If it's monthly and he does not start at the beginning of the month. - If he does non-monthly and does not end on 31st of December. We could be even more selective and also compute which months would be valid if in quarterly and other modes but we think it's fine for these cases. Forward-Port-Of: odoo/enterprise#100181
This update fixes an issue where invoice lines were incorrectly reconciled across different customers during POS sessions. Previously, settling payments mixed invoices from various customers, leading to inaccurate reporting. Now, reconciliation is correctly limited to the specific partner within a POS session, ensuring accurate financial records.
Original PR description
Invoice lines to be reconciled are not tailored to the single partner while the session lines do. That causes reconciliation to happen between different partners. To reproduce: Create an invoice of 100 to Customer 1 and an invoice of 200 to Customer 2. In a pos session, go to Customer 1, settle 50 on that invoice. Go to Customer 2, settle 100 on their invoice. Close register. => Lines from different customer are reconciled together. task-5346644
6 changes
Enhancements to existing features
This update automatically notifies users when invoices are canceled due to DGI rejections, preventing unnoticed cancellations and ensuring timely corrections. It also allows users to easily update invoice statuses when DGI acceptance is received, resolving inconsistencies and improving data accuracy.
Original PR description
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify…
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt. - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. **Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** - Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status. - Make 'Update DGI status' button always visible to be able to adjust invoices states. **== Context of the Problem ==** Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued. For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button. **== Automatic Notification Logic ==** With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows: _Scenario 1: Invoice with Internal Followers_ - If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions: - It will post a message in the invoice chatter. - It will tag (@) all internal followers to notify them directly. _Scenario 2: Invoice without Internal Followers_ - If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed: - It will post a message in the invoice chat. - It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager). Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form) Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799) Forward-Port-Of: odoo/enterprise#94502
Resolved issues and error corrections
This update corrects a technical issue where stopping audio playback in the VoIP feature triggered unwanted HTTP requests. The fix resets the audio element's source, eliminating the request and improving performance. This ensures a smoother user experience.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update resolves an issue where opening a folder within 'My Drive' caused the entire 'My Drive' folder to unfold. Now, 'My Drive' will only unfold when its root folder is opened, improving the user experience and preventing unexpected folder expansions.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#93718
This update resolves an issue where creating annotations in Arabic language reports would cause errors due to incorrect date formatting. The fix ensures dates are formatted correctly for PostgreSQL, preventing the application from crashing and allowing users to accurately add annotations to their financial reports. This improves the reliability of the reporting system for all users, regardless of their language settings.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493
This update resolves a bug where shared Knowledge articles weren't accessible to users when the website had multiple language settings. The fix corrects a URL rewriting issue, ensuring articles appear correctly regardless of the user's preferred language. This improves the usability of our knowledge sharing feature.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update fixes an issue where time logs were incorrectly assigned to the current user instead of the assigned employee when marking work orders as complete. This ensures accurate tracking of labor hours and eliminates user confusion regarding who is working on each order. The fix improves data integrity and reporting accuracy.
Original PR description
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the…
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the current user’s employee instead of the assigned one. This behavior caused confusion for the user as the wrong person was shown as working on the order. ## **Steps to Reproduce:** - Create an MO with work orders and confirm it. - Assign another employee to a work order. - Mark the work order as done with the current user from the work order line. - Open the workorder and notice that the time log is created for the current user’s employee. ## **Cause of the Issue:** The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790), where the logic for assigning the main employee was overridden, ignoring the case of an already assigned employee. ## **With This Commit:** The time log is now created for the assigned employee, This resolves the confusion by ensuring the right person is tracked on the work order. TaskID: 4983514
4 changes
Resolved issues and error corrections
This update resolves an issue where shared Knowledge articles weren't displaying correctly for users accessing them through different website languages. The fix corrects a URL rewriting problem, ensuring articles are accessible regardless of the user's preferred language setting, improving website usability and knowledge sharing.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update resolves an issue where the invoice report incorrectly displayed currency symbols and incorrect total amounts when a company's taxes were set to 'included'. The fix ensures accurate reporting of prices, including tax, for all company tax settings, improving invoice clarity and financial reporting.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update resolves several display issues within the mobile Kanban view for documents, specifically gaps in folder layouts and scrolling problems within the 'Recent' folder. These changes enhance the user experience and ensure documents are displayed correctly on mobile devices.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#100134 Forward-Port-Of: odoo/enterprise#90647
A technical issue was preventing users from creating or copying recruitment stage reports. This fix addresses a problem with a specific model within the 'hr_recruitment_reports' module, ensuring users can now successfully duplicate reports. This improves the usability of the hiring velocity reporting feature.
Original PR description
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to create or duplicate a record of that model, It will lead to the above traceback. sentry-7024266324 Forward-Port-Of: odoo/enterprise#99499
16 changes
New functionality added to Odoo
This update introduces a new reporting feature for Ireland, specifically the Return of Trading Details (RTD). This allows Irish businesses using Odoo to accurately track and report their trading activity as required by local regulations. This change supports compliance and provides essential reporting capabilities for Irish users.
Original PR description
WIP This PR adds a new report for Return of Trading Details (RTD) for Ireland task-5184653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This pull request optimizes how Odoo handles employee data, resulting in faster loading times and improved responsiveness when working with employee records. The changes enhance the performance of the HR module, leading to a smoother user experience. This is a general performance improvement.
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
Resolved issues and error corrections
This update fixes a technical issue within our Point of Sale (PoS) system that was generating warnings in the console. These warnings were related to missing widgets during order detail views. The fix adds the necessary configuration to ensure smooth operation and accurate order information display for users.
Original PR description
Steps to reproduce ------------------ 1. In PoS, make a normak order and pay it 2. Go to the "Orders", filter by "Paid" 3. Select the order of step 1 and click "Details" Observed behavior -> Warnings in the console about missing widgets. Fix --- We add those missing widgets to point_of_sale/__manifest__.py opw-5181965
This update optimizes the performance of our sales order system by adding an index to a key field. This change addresses a potential slowdown when filtering sales orders by the sales team assigned to them. By indexing this field, we're speeding up searches and improving overall system responsiveness.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves an issue where multiple expense records were created when using the 'force capture' feature with Stripe. Sending the same Stripe transaction event multiple times resulted in duplicate expense entries. This fix ensures data accuracy and prevents unnecessary expense records.
Original PR description
It's possible for multiples expenses to be created when using force capture. - Setup a company in EU and do the account onboarding - create a card - simulate a test purchase with force capture - after the webhook event issuing_transaction.* is received, an expense should have been created - now send again this event to the server (from the stripe dashboard or any other way) - a second expense will be created with the same transaction_id
This update resolves an issue where pressing Alt+A in the website builder didn't correctly open the translation mode. The fix adds a necessary parameter to ensure the translation features are activated, allowing users to translate website content. This improves the usability of the website builder for multilingual sites.
Original PR description
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A…
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state. __Cause:__ Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A. __The fix:__ Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead. NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway. [1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33 [2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54 task-5125700 Forward-Port-Of: odoo/odoo#236039
This update resolves a payroll error that occurred after the introduction of versioning in the 19.0 release. The issue stemmed from outdated data files that didn't reflect the change of the 'contract' key to 'version', along with a data type error. This fix ensures 'Cadre' employee pay runs can now be processed correctly.
Original PR description
To reproduce: ============= - in FR company create employee with "Cadre" status - in Payroll -> Pay runs, create a new pay run for this employee for a given month -> Error occurs Problem: ======== after intoducing Versioning in 19, `contract` key was changed to `version` but these data files were not updated accordingly. also there was a typo in lines with `company_20id` instead of `company_id` opw-5244193
This update resolves an issue where the Facturae export XML incorrectly displayed negative values for withholding taxes. The fix ensures that withholding tax amounts are always positive, preventing rejection by the FAC (Foreign Agents Control). This improves the accuracy of Facturae submissions.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205 Forward-Port-Of: odoo/odoo#235774
This update significantly speeds up payroll processing, specifically when regenerating work entries for a large number of employees. The change reduces query execution time from 20 seconds to 2 seconds, improving overall system responsiveness and efficiency. This enhancement ensures smoother payroll operations for companies with many employees.
This update allows spreadsheet reports to group data by many2one references, specifically Lead -> Activity relationships. This addresses a request from a partner at OXP, enabling more detailed reporting on activity status linked to Leads. It's important to note that grouping by many2one_reference requires careful consideration to avoid combining data from different models.
Original PR description
This is a feedback from a partner at OXP, he wants to know the number of activities (late or not) linked to some Lead -> activities grouped by res_id. But grouping a pivot by a many2one_reference is currently not supported. This commit adds the support. Note that carelessly grouping by a many2one_reference mixes records linked to different models (same id, but different model). To avoid mixin apples and oranges, you have to either groupby model, *then* by res_id, or add the model to the domain. Task: 5102923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234142 Forward-Port-Of: odoo/odoo#227939
This update resolves an issue where shared Knowledge articles wouldn't display correctly for users accessing them through different website languages. The fix corrects a URL rewriting problem, ensuring articles are accessible regardless of the user's preferred language setting. This improves the usability of our knowledge base for all portal users.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update fixes an issue where the website builder's save button would remain disabled after canceling the language selection dialog. The change introduces a mechanism to ensure after-save handlers are executed only when necessary, improving the user experience when adding or modifying languages.
Original PR description
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these…
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these tests do not trigger a later call to `Rpc.clear`, thus the listener stays registered. This could mess with other unrelated tests that check their own handlers of `beforeunload` are correct. This commit adds a cleanup on the helper used by the problematic tests. task-5138313 ### [FIX] website, html_builder: run after-save handlers if aborted Usually, running the after save handlers is not needed after the save because we are about to close or reload the builder. Thus they are not run as an optimization. But there are a few cases where they are needed: - The saving of the page failed. This case was correctly handled only when clicking on the save button or adding a module - When adding a language, but cancelling the dialog to choose the language This commit changes the save function of the save plugin, to take a async callback to determine whether the after-save handlers should run. The callback is async to be able to wait for the language choice dialog. If the callback returns `true`, then the after-save handlers are run. Steps to reproduce: - Open website builder - Open "Theme" tab - Click "Add Language" - Confirm the first dialog (about save) - Cancel the second dialog (language choice) - Bug: the save button stays disabled with the spinning wheel next to it task-5138313 Forward-Port-Of: odoo/odoo#229843
This update resolves an issue where the invoice report incorrectly displayed currency symbols and incorrect total amounts when a company's tax settings were 'tax included'. The fix ensures accurate reporting of price-included totals, improving invoice clarity and compliance.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update fixes an issue where the stock forecast was incorrectly displaying negative quantities due to how it was calculating demand based on completed stock moves. The fix ensures the forecast accurately reflects the actual available stock by basing calculations on the quantity of the move itself, not the original demand.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
This update resolves several display issues within the mobile Kanban view for documents, specifically in the 'Recent' folder. The changes address gaps in layout and scrolling limitations, ensuring a more consistent and usable experience for users managing documents on mobile devices. This improves the overall efficiency of document access.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#100134 Forward-Port-Of: odoo/enterprise#90647
This update resolves an issue in the 3-step manufacturing process where changing the production rule to MTSO didn't correctly trigger replenishment orders. The fix ensures that sufficient component quantities are automatically ordered when needed, maintaining accurate stock levels and preventing production delays. This improves the efficiency of the manufacturing workflow.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871 Forward-Port-Of: odoo/odoo#235125
19 changes
Resolved issues and error corrections
This update corrects a technical issue where stopping ringtone playback caused unintended HTTP requests to '/null'. The fix resets the element's source, eliminating this problematic behavior and improving performance. This ensures the application functions smoothly without unnecessary network activity.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update corrects an issue where credit notes' XML files weren't properly validated by the FACe system, a Spanish tax authority. The fix ensures compliance by standardizing the 'ReasonDescription' field, aligning with Spanish requirements. Additionally, the reversal wizard has been streamlined for clarity.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update optimizes how sales orders are accessed, specifically when filtering by sales team. By adding an index to the `sale.order.team_id` field, the system now searches more efficiently, reducing delays and improving the speed of reports and data views related to sales teams. This enhances the overall performance of our sales tracking processes.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves issues with concurrent database writes impacting Viva Wallet notifications, preventing duplicate or delayed messages to the POS. The change streamlines data transmission via websocket and adds safeguards to handle failed payment requests and unexpected webhook events, ensuring smoother operation across multiple Viva terminals.
Original PR description
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the…
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the `viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late. This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message. In addition, there are two other minor fixes: - In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error). - The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva. opw-5226966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual issue in the Contacts module where the 'parent_id' field in the new contact form lacked a placeholder. The fix ensures that the placeholder 'Company Name...' is displayed correctly when creating a new individual contact, improving the user experience.
Original PR description
### Steps to reproduce: - Go to Contacts > Contacts > New - Change it to "individual" type #### > The "parent_id" field should have a place holder "Company Name..." ### Cause of the issue: The…
### Steps to reproduce: - Go to Contacts > Contacts > New - Change it to "individual" type #### > The "parent_id" field should have a place holder "Company Name..." ### Cause of the issue: The `parent_id` field of the res.partner form uses the `res_partner_many2one` widget: https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/odoo/addons/base/views/res_partner_views.xml#L164-L166 and is therefore relying on the `PartnerAutoCompleteMany2XField`. However, this template tries to recover its placeholder from the `placeholder` attribute of the Component: https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/partner_autocomplete/static/src/xml/partner_autocomplete.xml#L41-L50 even thought this attribute is not defined and the placeholder should be recovered from its props: https://github.com/odoo/odoo/blob/60e0529b98098b019ade09aad97cc6e359bc0755/addons/web/static/src/views/fields/relational_utils.xml#L35-L38 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where increasing stock quantities didn't accurately reflect the reservation process, leading to incorrect move line creation. Now, the system first checks available quantities before creating the move line, ensuring quantity increases align with the standard stock reservation logic. This improves the reliability of stock adjustments.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit make the increase of quantity mimic the reservation process by getting first the available quants. The move line are then created accordingly. Backport of odoo/odoo#230344 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 resolves an issue preventing the successful installation of the UK Construction Industry Scheme for companies with branches. The previous version created duplicate account codes, resulting in installation errors. Now, the system correctly handles branch companies, allowing for seamless UK reporting installation.
Original PR description
Before this commit: Steps 1) Create a UK localization company 2) Create a branch for that company 3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis) => A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch). After this commit: UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches. opw-5326079
This update streamlines account reporting settings for users in specific countries. It automatically displays relevant settings based on report type (monthly, non-monthly) and fiscal year, preventing confusion and ensuring accurate reporting. This improves the user experience by only showing necessary options.
Original PR description
We're adding several countries to the settings, each time a user from this country has specific fiscal year and does non-monthly reporting. It's cumbersome, as we have to know in which country it's acceptable. At the same time, we don't want to show a setting if it's useless to the user. It will just confuse him. So, we should show this setting as soon as the report will complain: - If it's monthly and he does not start at the beginning of the month. - If he does non-monthly and does not end on 31st of December. We could be even more selective and also compute which months would be valid if in quarterly and other modes but we think it's fine for these cases.
This update fixes an issue where archived users were incorrectly sending out automated follow-up emails for invoices and partners. The change ensures that only active users are designated as the sender, preventing misdirected notifications and improving email reliability. This resolves a bug identified in version 18.0.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159 Forward-Port-Of: odoo/enterprise#98807
This update optimizes how Odoo matches bank transactions with sale orders, resulting in a significant speed improvement. By removing an inefficient query and leveraging an index, the process is now much faster, leading to quicker reporting and improved system performance. This change addresses a performance bottleneck.
Original PR description
Before this commit, finding a match between the bank transactions and sale orders was done via an unoptimized query that is preventing postgres from using any index. This commit removes the unnecessary CTE by simply doing the query directly on the sale_order table. This way we can also use a trigram index on the regex used for matching and postgres will be able to utilize it for faster search. Benchmarks: | Num sale_order | Before | After | | -------------- | ------ | ------ | | 1391909 | 3.88 s | 0.27 s | opw-5139457
This update resolves an issue where subsequent patches weren't consistently applied within the Odoo web module. Specifically, if the object itself isn't utilized, subsequent patching attempts fail. This change ensures that patches are correctly applied, addressing a technical limitation that could impact future updates. The fix was prompted by a related issue and is part of the ongoing maintenance of the Odoo web module.
Original PR description
If we don't use the object itself, we can't get subsequent patches. One example where this is needed: https://github.com/OCA/web/pull/3365 cc @moduon MT-11823 fyi @yajo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where changes to related records weren't consistently reflected across multiple linked data fields. The update ensures that all relevant data is synchronized during updates, preventing data inconsistencies and improving data accuracy. This primarily impacts how data is updated within certain Odoo modules.
Original PR description
Some models have several One2many (some with a domain and another without by example) targeting the same Many2one. In this case, when we create a new record, add new line in one of this One2many and modifying any else that triggers onchange. The onchange will contains the line in one of the sibling one2many but not the other, and then during the `modified`, the ORM may used the one2many that doesn't contains any lines, and that's miss some compute to recompute.... To avoid this situation, we patch the sibling one2many when one of them contains the line during the all onchange process.
This update resolves a bug that caused payments using the 'Own Checks' method in foreign currencies to fail due to an incorrect calculation. The fix corrects a typo in the code, ensuring payments are properly balanced and processed correctly. This improves the reliability of outgoing payments.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228
This update resolves an issue where the 'Select All' button in the document control panel only selected the first 40 files. Now, all files selected through any method (including 'Select All') are correctly included when performing actions like duplication or moving to the trash. This ensures consistent and reliable functionality for managing large document sets.
Original PR description
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3.…
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3. Click the 'Select All' button in the control panel to select all 40+ files. 4. Now, try duplicating or moving them to the trash. => Only the first 40 selected files (on the single page) are considered for action, not all the selected files. Technical ========== For documents control panel action we have custom handling for selecting records and executing action. We use `model.root.selection` which only consider records in current page, case of select all records from other pages is missed here. After this PR ================== - All selected records are considered for the actions - Added custom `getResIds` method to get filtered `resIds` as per domain. Note: `getResIds` in DynamicList doesn't have custom domain feature so create our own as per use case Task-4700841
This update enhances the compatibility of the Enterprise module with newer IoT Boxes (v19.1 and above). The change ensures proper functionality by verifying the 'bb status' within the system's data tracking, resolving a previous issue related to formatting inconsistencies. This update maintains a smooth experience for users utilizing IoT Box integrations.
Original PR description
We now check the bb status in `data.status` in addition to `data.status.status` to ensure compatibility with v19.1+ IoT Boxes. This commit also fixes an issue introduced in [this fw port](https://github.com/odoo/enterprise/pull/100205), where 2 lines where mistakenly unindented
This update resolves an issue where helpdesk ticket assignments were failing due to incorrect resource selection. The fix ensures that only resources within the same company as the helpdesk team are considered, preventing access errors and improving ticket assignment functionality. This improves the reliability of the helpdesk module.
Original PR description
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable…
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable auto assignment on the team - try to create a ticket on that team -> error Problem: ======== When computing working intervals for resources of the team members, we were considering all resources of the user, even those not in the same company as the helpdesk team. Which lead to access errors when trying to read data from the other company. This issue was not caught before as we were never reading data from the resources, until this [commit](https://github.com/odoo/odoo/commit/79a559c9741410ad861c107e395b2fc486da95e8) where we try reading `employee_id` of the resource. Solution: ========= Filter resources to keep only those in the same company as the helpdesk team. P.S: ==== the removed test was trying to test assigning ticket to user that is not in the same company as the helpdesk team, which is not correct so the test was removed. opw-[2749232](https://www.odoo.com/web#id=2749232&view_type=form&model=project.task)
This update resolves an issue where the Gantt view incorrectly grayed out days when flexible working hours were enabled. The fix ensures that all days are treated as working days, accurately reflecting employee availability and improving the view's reliability. This change impacts project scheduling accuracy.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081
This update fixes an issue where the Activity Menu's filtering options (Late, Today, Future) didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these options work consistently and align with other Odoo modules. This improves the user experience for managing approvals.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#99632
This update resolves a problem where the exchange rate was missing from invoices generated with certain currencies in Odoo 18. The underlying issue stemmed from how multiple country templates were linked, causing conflicts. This fix focuses on correcting the display of the exchange rate for invoices, ensuring accurate reporting.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236844
11 changes
New functionality added to Odoo
This update introduces a new automated process for updating branches from the main Odoo repository and creating release tags. This streamlines the release process and ensures forks are kept synchronized. The workflow is scheduled to run daily, improving efficiency and consistency.
Original PR description
This commit introduces a new GitHub Actions workflow that automates the process of updating branches from the upstream repository and creating releases. The workflow can be triggered manually or scheduled to run daily at midnight UTC. It includes options for specifying the branch to update and a description for the release tag. Additionally, the .gitignore file has been updated to ensure that the .github directory and its workflows are not ignored.
This update introduces basic localization support for Mauritania within the Odoo accounting system. It includes translations for key financial reports and data formats, enabling Odoo to accurately handle transactions and reporting requirements specific to Mauritanian businesses. This expands Odoo's global reach and compliance capabilities.
Original PR description
task-4236158 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 adds essential financial reports – Balance Sheet and Profit & Loss – to the Odoo Enterprise system for Mauritania. This allows businesses operating in Mauritania to generate and utilize standard financial reports directly within Odoo, improving financial tracking and reporting capabilities.
Original PR description
Add the Balance Sheet and Profit & Loss to the Mauritanian localization. task-4236158
Resolved issues and error corrections
This update resolves an issue where adding content to the website header would cause unexpected scrolling behavior. The previous system relied on a global variable that wasn't consistently updated, leading to a jumpy header. This change removes the problematic variable, ensuring a smoother and more stable website experience.
Original PR description
Before this commit, the header height was stored in a global variable. This variable wasn't always updated, which led to issues regarding the scroll. When adding elements in the header that increased its height, the scroll would jump and showing / hiding the header. This commit removes the need of the headerHeight variable. Steps to reproduce the bug: - Add a "Text Highlight" inner content above the ContactUs button - Add multiple Title snippets below one another (When adding the third one, the page scroll indefinitely) (The number of snippets to drop may vary depending on the viewport) task-4267249
This update fixes a technical issue that prevented the system from merging certain PDF files, specifically bills. The problem stemmed from errors in the PDF format, which caused a traceback. This change adds a user-friendly error message to guide users when encountering malformed PDFs, ensuring a smoother billing process.
Original PR description
Currently some PDFs cause error in PyPDF (Version 1 and 2) and cannot be merged. Steps to reproduce: - Create 2+ Bills with specific PDF (example found in ticket) - From Bills list view, select both and click Download > Original bills Issue: Traceback will raise `PyPDF2.errors.PdfReadError: Can't read object stream: Stream has ended unexpectedly` Thsi occurs because the version of PyPDF currently in use (2.12.1) cannot recover when working an odd PDF file having wrong length markers. This commit will add a nice error explaining to user what's going on. opw-5142961
This update enhances the stability of the Account EDI Proxy Client by preventing automatic user deletion when the IAP API returns an error indicating a user no longer exists. This resolves previous incidents related to IAP issues, ensuring smoother operation and reducing potential disruptions.
Original PR description
We already have had multiple IAP-side incidents leading to IAP API returning `no_such_user`. This error code should not lead to user deletion client-side. Thus this commit addresses this by avoiding to archive long-standing IAP connections even when `no_such_user` error is received.
This update corrects an error preventing the system from successfully retrieving invoice documents from the Viettel e-invoice API. The issue stemmed from incorrect parameter requirements in the API documentation, which were causing a 'not found' error. This fix ensures seamless document retrieval for Vietnamese e-invoicing.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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 product unit prices remain consistent when a product's fiscal position (and associated taxes) are updated. Previously, changes in taxes triggered an unintended recalculation of the unit price, even when taxes were included in the price. This change corrects the expected behavior, maintaining accurate product pricing.
Original PR description
This reverts commit 8df3d0424b30289d81e15a483dcc779bfe3964ba. What the commit was fixing was not a bug but the expected behaviour. Changing the fiscal position, and with that the taxes, should not change the unit price of products even if the taxes are included in price.
This update fixes a problem where vendor bills in the Saudi Arabia localization displayed negative amounts in the currency conversion section when using different currencies. The fix ensures accurate currency calculations and proper bill formatting, resolving an issue that could impact financial reporting. This change was made as part of a standard bug fix process.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue that occurred during Odoo upgrades where companies were created without a designated subcontracting location. This resulted in errors during subsequent upgrades, specifically impacting the stock module. The change ensures locations are correctly created during the upgrade process, improving overall upgrade stability.
Original PR description
During an upgrade, it could happen that some companies are created before this module is loaded. That means the override of `_create_per_company_locations` is not called and the company is created with an empty `subcontracting_location_id`. That can lead later to issues as that value was not expected to be empty. To reproduce: - On 16, install `onboarding`[^1], `l10n_de`, `mrp_subcontracting` with demo data. - Upgrade to 17. Module `l10n_de` will have created a company with empty subcontracting location. - Upgrade to 18. The upgrade will break during a call to `_create_or_update_sequences_and_picking_types` in `stock` because of the empty value. [^1]: onboarding is necessary to ensure l10n_de is loaded before mrp_subcontracting because of the dependencies.
This update fixes an issue where the 'Late,' 'Today,' and 'Future' filters in the Activity Menu didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these filters now work consistently and align with other Odoo modules.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#99632