Daily updates from Odoo
Navigate
Branch
Saturday, January 17, 2026
47 changes
9 changes
Resolved issues and error corrections
This update ensures that all imported modules are accurately marked as having been installed with demo data. This improvement enhances our ability to reliably test Odoo with demo data in industry scenarios, leading to more consistent and accurate results.
Original PR description
Currently even if a imported module was imported with demo data, the 'demo' field is not set to True. Setting this field proprely will allow to have a better handling of demo data in industry tests. Backport of https://github.com/odoo/odoo/pull/243032 Forward-Port-Of: odoo/odoo#244246
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see accurate Vietnamese labels when using Odoo with Vietnamese chart of accounts, improving the user experience.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#244151 Forward-Port-Of: odoo/odoo#236502
This update fixes an issue where placeholder hint text would awkwardly wrap onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more professional appearance for users across different devices and screen sizes.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244178 Forward-Port-Of: odoo/odoo#243006
This update resolves an issue where the link popover remained open after a snippet was deleted. The fix ensures the popover closes correctly when a snippet is removed, improving the user experience and preventing visual inconsistencies. This change focuses on a technical detail within the HTML editor.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its pointerdown handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document pointerdown listener, but this also triggered when interacting with the link type dropdown and color picker, closing the popover triggers applyCallback and causing nested links to be created.
After this commit:
- Close the link popover from on_will_remove_handlers before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#237679This update fixes an issue where payslip names were not being generated correctly for the Swiss (l10n_ch_hr_payroll) module. The change ensures that payslips display the accurate and required name format, improving reporting accuracy and compliance for Swiss users. This resolves a minor data display problem.
Original PR description
Forward-Port-Of: odoo/enterprise#104376 Forward-Port-Of: odoo/enterprise#104289
This update corrects a technical issue where a warning about eTIMS configuration was incorrectly displayed for companies outside of Kenya. The fix ensures that the validation process only applies to companies operating in Kenya, improving the user experience and preventing unnecessary alerts. This change ensures accurate invoice processing.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update prevents notifications for other recipients from being incorrectly marked as ‘bounced’ when a single recipient’s bounce notification is received. The fix ensures that bounce notifications are accurately associated with the recipient who triggered the bounce, improving email deliverability reporting and reducing potential customer confusion. This resolves an issue where a single bounce email could falsely flag other recipients’ notifications as undeliverable.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170 Forward-Port-Of: odoo/odoo#242650
This update fixes an issue where manually set currency rates on foreign currency invoices were being overwritten at posting time. The change ensures that users retain the rates they manually entered, improving accuracy in invoicing. This primarily affects invoices created using the l10n_de and l10n_hu_edi modules.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update ensures that the 'Activity' column in follow-up level list views only appears when 'Schedule Activity' is enabled. Previously, it incorrectly displayed an activity even when the option was disabled, leading to inconsistent data. This change improves the clarity and accuracy of follow-up level information.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
8 changes
Resolved issues and error corrections
This update resolves a potential error in how accounting calculations handle specific scenarios, particularly when all factors are zero. The change ensures the system correctly distributes amounts, preventing tracebacks and maintaining accurate financial records. This improves the stability and reliability of the accounting module.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
This update ensures that manually set currency rates on customer invoices (specifically for German and Hungarian invoices) are correctly applied during the posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This change maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential disruptions to sales processes.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update optimizes the SQL query used to generate the budget report, resulting in significantly faster performance, especially with large datasets. The change refactors the query to better utilize database optimization techniques, reducing processing time and improving report generation speed. This enhances the overall user experience for this key financial report.
Original PR description
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104531 Forward-Port-Of: odoo/enterprise#104299
This update fixes an issue where placeholder hint text in the HTML editor would awkwardly wrap onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more professional appearance for users.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244178 Forward-Port-Of: odoo/odoo#243006
This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to companies in Kenya, preventing unnecessary alerts and improving the user experience. This change simplifies invoice processing for all users.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update ensures that the 'Activity' column in the Follow-up Levels list view only appears when 'Schedule Activity' is enabled. Previously, it incorrectly displayed an activity even when the option was disabled, leading to inconsistent data. This change improves the clarity and accuracy of follow-up level information.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update enhances the security of our web connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled to utilize these certificates due to limitations in the underlying software. Now, we can properly manage and verify connections, strengthening our overall security posture.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#238717
6 changes
Resolved issues and error corrections
This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate invoice exports and avoids potential rejection by the SII system.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update automatically determines the correct VAT rate for sales orders based on the warehouse location, ensuring compliance with Portuguese tax regulations. Previously, VAT rates were manually set, leading to potential errors and delays. This change streamlines the process and reduces the risk of incorrect invoicing.
Original PR description
Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules. Problem: - The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address. - Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing. task-5088046 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#235887 Forward-Port-Of: odoo/odoo#227994
This update optimizes the SQL query used to generate budget reports, resulting in significantly faster performance, especially with large datasets. The change refactors the query to utilize a more efficient join strategy, reducing processing time and improving report generation speed. This directly impacts user experience and report loading times.
Original PR description
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104531 Forward-Port-Of: odoo/enterprise#104299
This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to companies based in Kenya, preventing unnecessary alerts and improving the user experience. This change simplifies invoice processing for all users.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update ensures that the 'Activity' column in the Follow-up Levels list view only shows when 'Schedule Activity' is enabled. Previously, it incorrectly displayed an activity even when this option was turned off. This change improves the clarity and accuracy of follow-up level data.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update enhances the security of our web connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled to utilize certificate verification effectively due to limitations in the underlying software. This change adds a more robust method for confirming the authenticity of our connections, strengthening overall security.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#238717
5 changes
Resolved issues and error corrections
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the window to remain open and block the display of new pages. The change now automatically folds the chat window after a link click, ensuring users can easily view the linked content. This enhances usability and prevents a frustrating user experience.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503
This update resolves a potential error in how accounting calculations handle specific scenarios, particularly when all factors are zero. The change ensures the system continues to function correctly without generating tracebacks, improving stability and accuracy for financial transactions.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
This update resolves a problem where Odoo invoices for export invoices were being rejected by the SII system due to incorrect decimal formatting. The code now ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential issues with tax authorities.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update removes unnecessary integer rounding from monthly VAT reports for Italian businesses (l10n_it). Previously, rounding was incorrectly applied to these reports, leading to potential inaccuracies. This change ensures accurate monthly VAT reporting, aligning with Italian tax regulations.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from the monthly VAT reports for Italian businesses. The rounding, which was incorrectly applied due to a previous split in the reporting process, has been corrected. This ensures accurate VAT reporting for monthly financial statements.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#103852
9 changes
Enhancements to existing features
This update allows HR users to archive departure reasons that are no longer in use. Previously, HR users could only manage these reasons by their names. This change provides a more organized way to manage departure reasons, preventing confusion and ensuring data accuracy within the HR system.
Original PR description
An HR user has currently no way to prevent use of specific /deprecated departure reason other than specifying it in the name. This commit an active field on `hr.departure.reason` so that an HR user can archive departure reasons that should not be used (as he can't delete them if they are referenced at least once). --- 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 corrects a technical error in the rental pricing calculation process. A mistake in how arguments were handled caused an error, preventing accurate rental prices from being displayed. This fix ensures rental prices are now calculated correctly for all users.
Original PR description
Kwargs were wrongly extracted in an override, leading to a traceback because the same arguments were provided twice to the super call. Forward-Port-Of: odoo/enterprise#104474
This update fixes an issue in the Argentinian VAT summary report where VAT amounts were incorrectly duplicated when multiple IIBB taxes were applied to an invoice. The fix ensures that VAT totals accurately reflect the true tax amounts by restructuring the report's calculation logic. This improves the accuracy of financial reporting.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#98933 Forward-Port-Of: odoo/enterprise#85873
This update fixes an issue where follower list avatars weren't consistently displayed with the correct proportions, particularly for non-square images. The change utilizes a standard Odoo class for avatars, ensuring all images are displayed correctly and maintaining a visually appealing follower list. This improves the overall user experience.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382 Forward-Port-Of: odoo/odoo#244062 Forward-Port-Of: odoo/odoo#243328
This update fixes an issue where formatting applied to text using shortcuts wasn't consistently carried over when adding new content like list items. The change ensures that the cursor remains within the formatting element, guaranteeing that newly typed text always inherits the intended formatting. This improves the user experience when creating and editing formatted content.
Original PR description
#### Description of the issue this PR addresses: - When using shortcuts (e.g. typing '1. ') after applying inline formatting, newly typed text did not inherit the formatting. - This occurred because extracting the shortcut text left the formatting element empty, causing the cursor to move outside it. #### Desired behavior after PR is merged: - Ensure the caret remains inside the formatting element by filling the closest element of `focusNode` when it becomes empty during shortcut handling. #### Steps to Reproduce: - Go to To-Do, Create a new record. - Type formatted text (e.g. Ctrl+[b|u|i]). - Press Enter. - Type '1. ' to create a list. - Type text inside the list item. => The text inside the list does not retain the formatting. task-5468358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243615 Forward-Port-Of: odoo/odoo#242209
This update fixes a problem where Odoo invitees (especially portal users) were sending unnecessary notifications to their invitees. Now, invitees only receive notifications when internal users connect for the first time, streamlining communication and reducing clutter. The notification message has also been updated for clarity.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited…
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users. For portal users, this resulted in unnecessary toast notifications and chat window pop-ups. **Current behavior before PR:** --------------------------------- - The inviter is notified when any invited user connects for the first time. - This includes portal users. - Unnecessary notifications and chat pop-ups are shown for portal user connections. **Desired behavior after PR is merged:** ----------------------------------------- - The inviter is notified **only when an internal user** connects for the first time. - Portal users no longer trigger first-connection notifications. - The notification message is updated to: “[Username] just connected for the first time. Wish them luck!” **Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244110 Forward-Port-Of: odoo/odoo#242235
This update fixes a technical error that occurred when the web application attempted to display specifications without a valid configuration. The fix ensures that the system only attempts to unfold and read groups when a specification is provided, preventing a 'NoneType' error and improving overall stability.
Original PR description
An error occurs when `web_read_group` is called without an unfold specification. **Error:** `TypeError - 'NoneType' object is not iterable` **Cause:** Here the method `web_read_group` unconditionally calls `all_records.web_read(unfold_read_specification)` - [1] However, `web_read` requires a valid read specification. If `unfold_read_specification` is None [2], it fails when trying to iterate over it during record mapping. **Fix:** This commit only unfold and reads group records when `unfold_read_specification` is given. [1] - https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/web/models/models.py#L449-L449 [2] - https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/web/models/models.py#L317 sentry-7112641140 Forward-Port-Of: odoo/odoo#244010 Forward-Port-Of: odoo/odoo#241754
This update ensures that users who have set their status to 'do not disturb' are no longer receiving inbox notifications. Previously, this functionality was inconsistent with push notifications. This change improves user experience by respecting their preference for uninterrupted communication.
Original PR description
Users shouldn't be notified when they set their status as "do not disturb". It's already done for push notifications but inbox messages follow a different path. 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#244120 Forward-Port-Of: odoo/odoo#244059
This update resolves a problem that prevented the tax module from correctly loading after database upgrades. The fix ensures tracking computations are temporarily disabled during module loading, preventing errors and ensuring a smooth upgrade process. This improves stability and avoids delays during module installations.
Original PR description
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.
```py
/home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```
Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.
```py
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
tracking = records.with_context(context)._message_track(fnames, initial_values)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
record._message_log(
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```
This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae
The resulting tracking computation crashes with a KeyError when processing repartition line diffs.
Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.
opw-5467986
upg-3753990
tbg-2380
Forward-Port-Of: odoo/enterprise#1039317 changes
Resolved issues and error corrections
This update resolves a problem where Odoo invoices for export invoices were being rejected by the SII system due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential delays in processing.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update fixes an issue where placeholder hint text wrapped awkwardly on the HTML editor when the screen was narrow. Now, the text is correctly truncated instead of wrapping, ensuring a cleaner and more consistent user experience across different screen sizes. This improves readability and visual appeal.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244178 Forward-Port-Of: odoo/odoo#243006
This update fixes an issue where the link popover remained open after a snippet was removed from the website. The change ensures the popover closes automatically when a snippet is deleted, improving the user experience. This resolves a visual glitch and maintains consistent functionality.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its `pointerdown` handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document `pointerdown` listener, but this also triggered when interacting with the link type `dropdown` and color picker, closing the popover triggers `applyCallback` and causing nested links to be created.
After this commit:
- Close the link popover from `on_will_remove_handlers` before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#244196This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The previous system incorrectly checked eTIMS configuration for all businesses, causing unnecessary alerts. Now, the system only validates eTIMS requirements for companies based in Kenya, improving the user experience.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update fixes an issue where manually set currency rates on foreign currency invoices were being overwritten at the time of posting. This change ensures that users retain the rates they manually entered, improving accuracy and control over invoice pricing. The fix specifically targets the l10n_hu_edi and l10n_de modules.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update corrects a display issue in the Follow-up Levels list view. Previously, an activity was always shown even when 'Schedule Activity' was disabled. Now, the activity column only appears when 'Schedule Activity' is actively enabled, ensuring a cleaner and more accurate view of follow-up levels.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update resolves an issue where users couldn't easily focus on search inputs within views. The change adds a hotkey (ALT+Q) to directly select the search input, improving usability. This fix was triggered by a previous change that removed this functionality.
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
1 change
Resolved issues and error corrections
This update ensures that invoices generated with the Solution Factible PAC in Mexico comply with Mexican tax regulations regarding exchange rate precision. Previously, a bug prevented valid invoices from being processed due to insufficient decimal places in the exchange rate. This fix applies a rounding adjustment to all PACs, resolving this compatibility issue.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#102557
2 changes
Resolved issues and error corrections
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for major carriers like UPS, FedEx, USPS, and DHL. By adding mapping keys, the connector now recognizes these carriers accurately, ensuring proper integration and order processing within the Amazon channel.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings.
This update corrects a bug that occurred when attempting to change a tax lock date to a past date. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves data reliability and prevents disruptions to financial processes.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010