Wednesday, November 26, 2025
27 changes · saas-18.3
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 working days, leading to inaccurate grayed-out dates. The fix ensures all days are treated as working days, providing a correct and consistent Gantt view experience.
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 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 compared to customer invoices. This improves data consistency and reporting accuracy.
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 corrects a problem preventing Odoo from successfully retrieving invoice documents from the Viettel system. The original issue stemmed from incorrect parameter requirements in the API documentation, leading to errors. This fix ensures accurate document retrieval, improving the functionality of the l10n_vn_edi_viettel module.
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 an issue where the Fedex delivery method would fail when used 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 reliable delivery processing for this common address type. This improves the overall reliability of the delivery process.
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 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 provide a clearer instruction for users. This ensures a better user experience when generating payment links.
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 resolves a bug where automation rules using time-based domains were failing silently due to missing JavaScript functions. The fix ensures that the evaluation context is properly prepared, preventing a 'NameError' and allowing automation rules to trigger correctly. This improves the reliability of scheduled automation tasks.
Original PR description
Steps to reproduce: ------------------- 1. Install `base_automation` and `project` 2. Create a new task with a deadline set to today 3. Create a new automation rule using the operator "today" 4. Set…
Steps to reproduce: ------------------- 1. Install `base_automation` and `project` 2. Create a new task with a deadline set to today 3. Create a new automation rule using the operator "today" 4. Set the trigger to "Based on datetime field" using the `deadline` field 5. Add a filter domain based on the same operator 6. Run the related scheduled action (cron) for automation rules Issue: ------- During cron execution, the automation silently fails with the error: ```python NameError: name 'context_today' is not defined ``` Cause ----- Most of the Time-based domain operators are [introduced from SaaS-18.3 ](1c7c31a)onwards and include values such as [context_today()](https://github.com/odoo/odoo/blob/0a6155ac25aae138bdaa5e2e8a6d39c42acd2fe3/addons/web/static/src/core/tree_editor/condition_tree.js#L84) and `.to_utc()`, which are not present in the Python evaluation context. As a result, safe_eval raises NameError, and the automation rule is never triggered. Solution -------- Prepare the evaluation context with time-based operators and remove unsupported JS-only `.to_utc()` before evaluating the domain in Python's safe_eval, to prevent traceback. opw-5237215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Shift + Click within table cells didn't correctly select text, leading to inconsistent behavior. The fix ensures Shift + Click now functions as expected with standard browsers, providing a more reliable and intuitive text selection experience. Additionally, the fix addresses a related issue where text selections would temporarily disappear when resizing the table.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237168 Forward-Port-Of: odoo/odoo#230716
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 and ensures that saved leave requests correctly show associated files. 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-prThis 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 preventing invoices with specific document types (201-213) in the l10n_ar module from printing correctly. Previously, the system was hardcoded to use Spanish (es_AR), causing errors if that language wasn't installed. Now, invoices with these document types will print correctly 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 resolves an issue with the installation and removal of hooks related to the Account No Followup module. The fix ensures smoother operation of these hooks, improving the overall stability and reliability of the system. This change primarily addresses a technical bug and does not directly impact business users.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term Forward-Port-Of: odoo/enterprise#100350
This update ensures the kiosk ordering system only utilizes payment methods explicitly set up for it. Previously, the kiosk would incorrectly prompt for unavailable payment options. This change prevents errors and improves the kiosk's usability by limiting it to configured payment methods.
Original PR description
pos_self_order*: pos_online_paymnet_self_order, pos_self_order_razorpay, pos_self_order_stripe Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Restrict the kiosk to use only the payment methods explicitly configured in its settings. - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/enterprise/pull/89490 Forward-Port-Of: odoo/odoo#217467
This update prevents kiosks from attempting to use payment methods that haven't been specifically configured for them. Previously, kiosks would incorrectly prompt for online payments even when none were set up. This change ensures a smoother and more reliable kiosk ordering experience for customers.
Original PR description
Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/odoo/pull/217467 Forward-Port-Of: odoo/enterprise#89490
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 change ensures accurate tracking of labor hours on work orders, resolving user confusion and improving data integrity. It corrects a previous bug introduced during a recent development cycle.
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#93378
This update fixes an issue where changing quantities in Point of Sale wouldn't automatically update related items, particularly in combo products. It now ensures that quantity changes are correctly reflected across all related lines, and also improves price calculations to avoid unintended price adjustments when quantities are modified. This ensures accurate order totals and a smoother user experience.
Original PR description
Before this commit, when changing the quantities of a line, we would not automatically change the quantities of the children lines if any. This is now the case. We also handle the prices in a better way such that changing the quantities of a combo product does not affect the price unit of the lines computed previously. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users quickly opened the file viewer multiple times, such as by double-clicking attachments. The fix ensures the file viewer registry is properly cleared before each opening, preventing errors and improving overall stability. This enhances the user experience when accessing attachments.
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 from invoices for certain currencies in Odoo versions 17.0 and 18.0. The underlying issue stemmed from a template conflict across multiple countries, and this fix specifically addresses the most immediate problem with the Saudi Arabia invoice template. This ensures accurate exchange rate display for invoices.
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 coding error that caused an imbalance in the accounting entries. This fix ensures accurate payment processing for international transactions.
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 resolves issues with Viva Wallet integration caused by duplicate notifications and data processing delays. By sending payment information directly via websocket and filtering webhook events, the system now handles concurrent requests more reliably, preventing errors and ensuring smoother transactions. Additionally, the system now avoids unnecessary polling and handles webhook events more precisely.
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 Forward-Port-Of: odoo/odoo#237333 Forward-Port-Of: odoo/odoo#236454
A bug was causing negative amounts to appear in South Africa's EDI bill printouts when using different currencies. This update fixes the underlying code to ensure accurate currency conversion and display of bill totals and subtotals. This ensures correct financial reporting for South African businesses using the Odoo system.
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 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 align with other modules and provide accurate, deadline-based filtering for 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#100113 Forward-Port-Of: odoo/enterprise#99632
This update corrects a visual glitch in the Odoo HTML editor where hint and power buttons remained visible when a block contained a tab. The fix ensures these buttons disappear when a tab is inserted, improving the editor's appearance and usability. This change was made to enhance the user experience and maintain a clean interface.
Original PR description
Description of the issue this PR addresses: - Hint and power buttons are incorrectly shown or hidden in empty blocks when the block contains a Tab or only empty formatting tags (`<strong>, <em>, <u>, <s>`). Current behavior before PR: - Pressing Tab in an empty block leaves the hint and buttons visible. - Empty paragraphs containing only formatting tags do not show the hint and buttons. Desired behavior after PR is merged: - Hint and power buttons are not shown when a block contains a Tab. - Hint and power buttons are correctly visible when a block contains only empty formatting tags. task-5062294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237125 Forward-Port-Of: odoo/odoo#230979
This pull request corrects a technical error within the Odoo POS module'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, preventing potential disruptions to the POS functionality.
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 selecting a document in the list view in dark mode resulted in a white background and unreadable text. The fix replaces hardcoded color values with dynamic theme-aware variables, ensuring clear visibility across all Odoo themes.
Original PR description
**Steps:** - open documents in list view in dark mode - select and deselect a record **Observation:** - the selected record's background becomes white and text was already white - hence nothing can…
**Steps:** - open documents in list view in dark mode - select and deselect a record **Observation:** - the selected record's background becomes white and text was already white - hence nothing can be seen clearly **Cause:** - Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36 [1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7 **Fix:** - instead of hardcoding color, we use already available variable, which adjust the color, according to theme. **Before:** <img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" /> <img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" /> <br><br> **After:** <img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" /> <img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" /> opw-5261669
This update resolves an issue where changes to the ‘analytic.project_plan’ system parameter didn’t properly update related analytic lines in Odoo. Now, when this parameter is modified, the system correctly adds or removes the associated dynamic fields on the analytic lines, ensuring data consistency and accurate reporting. This prevents errors related to duplicate field references.
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. Previously, some companies were created without a designated subcontracting location, leading to errors during subsequent upgrades. This change ensures locations are created correctly during the upgrade process, improving stability and preventing upgrade failures.
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
This update ensures the Sign app meets legal requirements for U.S. companies by notifying users when the sender is based in the U.S. and offering the option to request a paper copy of signed documents. This compliance update strengthens our legal protections and user trust.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918 Forward-Port-Of: odoo/enterprise#100439 Forward-Port-Of: odoo/enterprise#97163