Wednesday, November 26, 2025
35 changes · saas-18.4
Resolved issues and error corrections
This update resolves a visual glitch in the Gantt view when flexible working hours are enabled. Previously, the system incorrectly estimated unavailable days, leading to random grayed-out dates. The fix ensures all days are treated as working days, providing a more accurate and reliable Gantt view.
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 Forward-Port-Of: odoo/enterprise#100385
This update corrects an error preventing the l10n_vn_edi_viettel module from successfully retrieving invoice documents from the Sinvoice system. The previous issue stemmed from incorrect parameter requirements in the API documentation, which caused a 400 error. This fix ensures accurate document retrieval, improving the functionality of Vietnamese VAT invoice processing.
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 Forward-Port-Of: odoo/odoo#236628
This update resolves a bug that caused errors when using the FedEx delivery method with addresses in Hong Kong, specifically those with a 'Hong Kong Island' state. The fix ensures that the system correctly handles state code splitting, preventing a traceback and ensuring accurate delivery processing for this common address type. This improves the reliability of the FedEx delivery option.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes an issue where channel names weren't displaying correctly in the invite dialogs accessed from the sidebar. The change ensures that channel names are accurately shown, improving the user experience when inviting members to channels. This resolves a visual inconsistency.
Original PR description
Before this commit, certain channels whose names were computed on the client side did not appear correctly as the title of the invite dialog when opened via the sidebar actions. This commit resolves the issue by using the channel’s displayName instead of the thread.name to ensure the correct title is shown in the invite dialog. task-5357104 Forward-Port-Of: odoo/odoo#237278
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The button label has been updated to 'Generate and Copy Payment Link' to match the intended functionality, ensuring users clearly understand how to create and copy a payment link. This improves the user experience and reduces potential confusion.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update corrects a bug where opening a folder within 'My Drive' would automatically unfold the entire 'My Drive' folder. Now, 'My Drive' only expands when its root folders are opened, improving the user experience and preventing unintended 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#100213 Forward-Port-Of: odoo/enterprise#93718
This update resolves a minor UI issue within the Documents app, specifically fixing overlapping elements and addressing a broken feature in the activity view. The change ensures the Documents app displays correctly and reliably for users.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112 Forward-Port-Of: odoo/enterprise#86436
This update fixes an error in the Peru tax return reports (RVIE Sales 14.4) that incorrectly included credit note amounts in the VAT columns. The fix ensures the report accurately reflects SUNAT regulations for credit note reporting, improving data accuracy for tax compliance.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466 Forward-Port-Of: odoo/enterprise#96146
This update resolves an issue where invoices using specific document types (201-213) within the l10n_ar module couldn't be printed correctly. The fix ensures the report template correctly handles different Spanish language settings, allowing users to print invoices regardless of the installed language.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228125
This update fixes an issue where vendor bill payment statuses remained incorrect after deleting or resetting payments. The change ensures that the vendor bill's status accurately reflects the payment's state, resolving a discrepancy between vendor and customer invoice updates. This improves data accuracy and reporting.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772 Forward-Port-Of: odoo/odoo#234725
This update resolves an issue with the account follow-up hook installation and uninstallation process. The fix ensures the hooks function correctly regardless of whether the module is installed or not, improving stability and reliability. This change addresses a minor technical problem that could have impacted account management workflows.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term Forward-Port-Of: odoo/enterprise#100350
This update fixes an issue where group chats weren't displaying the correct welcome message and subtitle. The change ensures all channel types receive the appropriate start message, enhancing the user experience for group communication. A new test has been added to verify this fix across all channel types.
Original PR description
Before this commit, The start message subtitle condition was incorrect for group chats, this commit corrects that condition and also add a test to cover all the channel types to show correct start message and subtitle. Before: <img width="625" height="109" alt="image" src="https://github.com/user-attachments/assets/830f9574-573f-4448-b54f-b70c8a4685ef" /> After: <img width="640" height="133" alt="image" src="https://github.com/user-attachments/assets/bcba270a-88fc-446d-9015-1125872c5748" /> Forward-Port-Of: odoo/odoo#237292
This update resolves an issue where importing journal entries targeting inactive accounts previously caused errors. The change now allows these imports to proceed without regard to the account's active status, streamlining the import process. This ensures that all journal data can be imported, regardless of account status.
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 Forward-Port-Of: odoo/odoo#237271
This update resolves a display issue within the journal items tab of Odoo, preventing sections and notes from being hidden. The change was necessary due to an outdated database field name ('journal_line_ids') still being used, which caused errors when updated to the new standard ('line_ids'). This ensures consistent and accurate reporting of financial data.
Original PR description
Steps to reproduce: --- - Revert the commits - Install `account` module - Undo revert commits and install `l10n_pe_edi` module This error occurs because the field name was changed in stable from `journal_line_ids` to `line_ids`. We cannot do this in a stable version, as older databases still reference the old field name, and renaming it in stable will cause errors. Followup of: https://github.com/odoo/enterprise/pull/99875, https://github.com/odoo/odoo/pull/236457 sentry-7059309576, 7059890988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a display issue where sections and notes were hidden in the journal items tab. The root cause was a change in database field names that created compatibility problems with older versions. This fix ensures correct display of journal items across all versions.
Original PR description
Steps to reproduce: --- - Revert the commits - Install `account` module - Undo revert commits and install `l10n_pe_edi` module This error occurs because the field name was changed in stable from `journal_line_ids` to `line_ids`. We cannot do this in a stable version, as older databases still reference the old field name, and renaming it in stable will cause errors. Followup of: https://github.com/odoo/enterprise/pull/99875, https://github.com/odoo/odoo/pull/236457 sentry-7059309576, 7059890988
This update resolves an issue where rapidly opening the file viewer (like double-clicking attachments) caused the system to crash. The fix ensures the file viewer component is properly cleaned up between uses, preventing registration errors and maintaining stability.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update resolves a problem where the exchange rate was missing on invoices for certain currencies in Odoo versions 17.0 and 18.0. The fix addresses a design conflict within a shared invoice template used across multiple countries, ensuring accurate exchange rate display. This improvement impacts invoicing accuracy for users in Saudi Arabia.
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#237193 Forward-Port-Of: odoo/odoo#236844
This update resolves a bug that prevented payments using the "Own Checks" method in foreign currencies from posting correctly. The issue stemmed from a minor typo in the code, which caused an imbalance in the accounting entries. This fix ensures accurate payment processing for users utilizing the l10n_latam_check module.
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 Forward-Port-Of: odoo/odoo#236768
This update fixes a problem where vendor bills in the South Africa (SA) 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 have impacted 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 Forward-Port-Of: odoo/odoo#236654
This update streamlines Odoo's logging by reducing the volume of data captured from websocket messages. Previously, full messages were logged, leading to overly detailed and difficult-to-manage logs. Now, only the message type and device are logged at the 'info' level, providing more focused and actionable information.
Original PR description
Before this commit, we logged the full websocket messages received at 'debug' level, and the action device at 'info' level. Logging the whole message causes the logs to be flooded with large base64 print data. After this commit, log the message type and device both at 'info' level. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237337 Forward-Port-Of: odoo/odoo#236651
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 limited to the specific partner within the 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 Forward-Port-Of: odoo/enterprise#100131
This update resolves an issue where the website tour feature wasn't consistently displayed. By ensuring the tour's iframe loads correctly before applying settings, the problem is fixed, guaranteeing a reliable user experience for website visitors. This improves the overall quality and usability of the Odoo website.
Original PR description
In this commit, we fix a non deterministic behavior by ensuring the iframe is loaded before set and attribute on iframe content element. runbot-error-id~233039 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 a bug where the 'lock document' option wasn't consistently appearing in the document previewer's action menu. The fix ensures the document's data is properly loaded, updating the action menu to reflect available options. This improves the user experience when managing document access.
Original PR description
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical…
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical =========== - The action menu, which we are using inside the file previewer, is passed explicitly inside the FileViewer component of the document. We were using the `record.load()`, which will not have any effect on the FileViewer component and that's why the action menu was not updating. - Updated the `Lock action availability and check` test because, as in our fix we load the model, and so that's why the `folder` variable used earlier was causing reference mismatch when targeting the element. After this commit ================== - Used the `this._notifyChange()` method, which closes the preview and loads the model to align with the same behaviour as other actions. Task-4988116 Forward-Port-Of: odoo/enterprise#99787 Forward-Port-Of: odoo/enterprise#91760
This update fixes a reporting issue on the Purchase Dashboard by ensuring the 'Not Acknowledged' and 'Late Receipt' counters accurately reflect only pending acknowledgments and genuinely late receipts. Previously, completed receipts were incorrectly included, leading to misleading data. This change improves the dashboard's reliability for tracking purchase order status.
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#237176
Forward-Port-Of: odoo/odoo#224180This pull request corrects a technical error within the Odoo POS system's tour tests. Specifically, the tests were failing due to an incorrect company name being used. This fix ensures the tour tests run reliably and accurately, improving the quality assurance process for the POS module.
Original PR description
There was an error in the generic hooks, the company name was not the correct one. runbot-234336 Forward-Port-Of: odoo/enterprise#100311
This update fixes an issue where time logs were incorrectly assigned to the current user instead of the assigned employee when marking a work order as complete. Previously, this caused confusion about who was working on orders. Now, the time log accurately reflects the assigned employee, ensuring accurate tracking of work hours.
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 Forward-Port-Of: odoo/enterprise#100467 Forward-Port-Of: odoo/enterprise#93378
This update fixes a minor issue where the Finnish translation for a key report name was incorrect. Adding the `@fi` suffix ensures that all reports are properly translated for Finnish users, improving the accuracy of reporting data. This ensures consistent and correct reporting in the Finnish language.
Original PR description
In this commit [[1]], we wrongly set the name for the translation in Finnish. Indeed, we should add @fi at the end to make sure it's translated properly. This commit adds the `@fi` when necessary. no task id [1]: https://github.com/odoo/enterprise/commit/4ae3c4d2bdb0ef05ffb53930b31f2bf15fd422ee Forward-Port-Of: odoo/enterprise#100364 Forward-Port-Of: odoo/enterprise#100304
This update reverts a recent change that caused incorrect pricing calculations for products with multiple plans and variants. By restoring the previous logic, we ensure accurate pricing is displayed for these products, resolving a critical issue impacting sales accuracy.
Original PR description
This commit reverts the modifications introduced in the one-time sale [PR](https://github.com/odoo/enterprise/pull/77981). Those changes caused incorrect pricing behavior for products with variants, as the necessary logic for handling multiple plans and variants was removed. By reverting, we restore the correct price computation for products that have both multiple plans and variants. opw-5224319
This update fixes an issue where sale order previews incorrectly displayed down payment percentages after changing online payment settings. The fix ensures the preview accurately reflects the currently active payment percentage, improving the user experience and preventing miscommunication about payment amounts. This resolves a visual inconsistency in the sales process.
Original PR description
****Behavior:**** **Current:** When setting the online payment percentage to something else than 100% and then turning off the setting. The preview of sale orders still show a down payment with the percentage set previously. This is caused because there is no check on wheter the setting is activated or not in the template. ****Steps to reproduce:**** - In Settings->Sales: activate Online Payment. - Set it to somethings else than 100% then save. - Turn the setting off then save. - Create a Sale Order. - There will be a down payment of 0€ with the percentage you set in parentheses. opw-5254575
This update addresses a technical issue where duplicate methods were introduced in the Odoo Enterprise system. This was a result of a missed custom build process, and the fix ensures the system's stability and efficiency. The change impacts the HR and Payroll modules.
Original PR description
Followup of #100053 because I forgot to run the custom build, and thus missed newly introduced duplicate methods.
This update improves the speed of the website builder, specifically when adding and managing forms. Previously, rendering complex forms took over a second, which was frustrating for users. Now, the process is significantly faster – just a few hundred milliseconds – thanks to optimizations in the BuilderList component.
Original PR description
Before this commit, rendering BuilderList with many elements caused noticeable delays. How to reproduce: ======================= - Use a runbot with all demo data - Switch to edit mode in the website builder - Add a form - Link the form to the Contact model - Add the "State" field Before this commit: The options related to the "State" field took more than one second to render. After this commit: Rendering is several hundred milliseconds faster. Additional commits will follow to further improve the situation. Reason for the slowdown: ======================= BuilderList is not optimized to render several thousand records (about 1900 in this example). This commit addresses the identified bottlenecks to reduce rendering time. 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 where attachments weren't consistently displayed on leave request forms after saving. The fix addresses a technical limitation in how Odoo handles attachments linked to leave requests, ensuring that attachments are always visible when a request is viewed. This improves the user experience for creating and managing leave requests.
Original PR description
to reproduce: ============= - from form view, create a leave request with an attachment - save the leave request - the attachment is not displayed on the form (reloading the page shows it correctly)…
to reproduce:
=============
- from form view, create a leave request with an attachment
- save the leave request
- the attachment is not displayed on the form (reloading the page shows it correctly)
Problem:
========
- When sving the leave request, we call `web_save` which will handle the creation, then calls `web_read` to read the updated data back from the server.
- Even though `web_read` and `web_save` are called in the same transaction, but `web_read` doesn't see `attachment_ids` because of the limited implementation of Many2oneReference (ir.attachment.res_id):
- Its `_update_inverses` won't be called when the value is changed when `field.write`
- when `record.attachment_ids = attachment`, the ORM won't automatically set `attachment.res_model = record._name`
Solution:
=========
as work arround, we can call `invalidate_recordset` for leave requests after setting `attachment_ids` in `_inverse_supported_attachment_ids` so that `web_read` will read the correct value from database.
opw-5157790
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233003This update adds a notification to inform users who are utilizing the Chorus Pro module without the necessary module installed. This ensures they are aware of potential missing checks and can take the appropriate action to maintain system functionality and compliance. It's a preventative measure to avoid disruptions caused by incomplete configurations.
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 resolves an issue where changing the 'analytic.project_plan' system parameter didn't properly update related fields in the accounting system. The fix ensures that dynamic fields are correctly created and removed when this parameter is modified, preventing data inconsistencies and errors. This improves the accuracy of project accounting.
Original PR description
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan`…
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.
So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.
Steps:
1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`
We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.
Ticket [link](https://www.odoo.com/odoo/project.task/5069381)
opw-5069381
Forward-Port-Of: odoo/odoo#234987
Forward-Port-Of: odoo/odoo#231981This update fixes a problem that occurred during Odoo upgrades where new companies were created without a designated subcontracting location. This caused subsequent upgrade steps to fail, leading to instability. The change ensures locations are correctly created during upgrades, improving overall system reliability.
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. Forward-Port-Of: odoo/odoo#236149