Daily updates from Odoo
Tuesday, May 26, 2026
160 changes
32 changes
Resolved issues and error corrections
This update restricts the AI button's functionality within the website builder to only 'website.page' records. Previously, it was available across all website pages, leading to potential misuse. This change improves the website builder's usability and ensures AI features are applied appropriately.
Original PR description
Previously, the AI button was enabled across all pages in the website builder, including contexts where its usage is not applicable. This PR introduces the following changes: 1. Disable the AI button for pages not linked to "website.page" records with a tooltip explaining the restriction. 2. Hides the AI button when the sidebar is open in translation mode. task-6148588
This update resolves an issue where downloading signed documents through the Sign app would occasionally fail due to a compatibility problem with the pypdf library. The fix moves the document compression step to the correct object, ensuring compatibility with newer versions of pypdf and preventing errors. This improves the reliability of document downloads.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#266223 Forward-Port-Of: odoo/odoo#265304
This update simplifies the process of inserting dynamic fields within Odoo's Powerbox editor. It adds a familiar keyword, 'dynamic placeholder,' allowing users accustomed to the older method to easily locate and utilize the Dynamic Field command. This enhances usability and reduces potential confusion.
Original PR description
This PR adds a search keyword so users who were used to dynamic placeholder to insert the Dynamic Field command can still find it in powerbox. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266021
This update ensures that WhatsApp channel avatars in the sidebar accurately reflect the members who are part of the channel. Previously, adding a member would display a default avatar instead. This fix corrects a bug where the system wasn't correctly identifying the WhatsApp member for channels, improving the user experience.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#118012 Forward-Port-Of: odoo/enterprise#115745
This update fixes an issue where empty cells within styled tables weren't properly recognized during selection using the HTML editor's move handle. Now, all table cells, even those with placeholder content, are correctly identified and selectable, ensuring consistent and reliable table manipulation.
Original PR description
#### Description of the issue this PR addresses: - Empty `.o_table` cells containing only placeholder ZWS content were not considered visible - Full table selection via move handle failed to apply `o_selected_td` on styled empty cells #### Desired behavior after PR is merged: - Consider `.o_table` table cells visible Steps to reproduce: - Insert a table - Select it via move handle - Apply any color - Click the move handle again to select the table All table cells should have class `o_selected_td` task-6208949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263836
This update resolves an issue where PDFs with multiple XML attachments (using the /Kids structure) weren't being correctly extracted. Now, all XML attachments within these PDFs will be processed, ensuring bills and reports are complete. This improvement addresses a data accuracy problem.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#255798 Forward-Port-Of: odoo/odoo#252523
This update fixes a technical error that prevented users from correctly applying the 'Ship Later' option in the Point of Sale system. The issue stemmed from how the system handled date formatting, and the fix removes unnecessary conversions and adds validation to ensure correct date handling. This ensures the 'Ship Later' feature functions reliably.
Original PR description
Steps: = - Enable Allow Ship Later in POS configuration. - Open POS and add any product. - Proceed to the Payment screen. - Click Ship Later, clear the date field, and confirm Issue: = - A traceback occurs: `TypeError: this.state.shippingDate.toISODate is not a function` Reason: = - Here, shippingDate is a Luxon DateTime object when provided. when cleared, it becomes null, so converting it to ISO format is casung the error. Fix: = - Removed unnecessary conversion using `.toISODate()`. - Removed unnecessary hoot test. - Added validation on shippingDate to prevent selecting a past date. task-5406969 Forward-Port-Of: odoo/odoo#265822 Forward-Port-Of: odoo/odoo#239827
This update fixes a visual issue in the website builder where color options were missing for images with shapes. The fix ensures that users can now customize the colors of images with shapes when using the 's_cta_mockups' or 's_closer_look' snippets, enhancing the design flexibility.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#265465 Forward-Port-Of: odoo/odoo#246249
This update fixes an error that occurred when the automated payroll update process ran after a customer contact was deleted. Specifically, the system was unable to find a reference to the deleted contact in a key data file. This prevented the payroll update from completing successfully, and this fix ensures the process continues to function correctly.
Original PR description
Currently, a traceback occurs when the cron "Payroll: Update data" runs after a referenced partner record has been deleted. Steps to reproduce the error: - Install ``l10n_us_hr_payroll`` module with…
Currently, a traceback occurs when the cron "Payroll: Update data" runs after a referenced partner record has been deleted. Steps to reproduce the error: - Install ``l10n_us_hr_payroll`` module with demo data - Switch to ``My US Company`` - Go to Contacts > Delete ``Internal Revenue Service (IRS)`` contact - Run the cron ``Payroll: Update data`` Traceback: ```py ValueError: External ID not found in the system: l10n_us_hr_payroll.res_partner_irs ``` ```py ParseError: while parsing /home/odoo/src/enterprise/ saas-19.3/l10n_us_hr_payroll/data/hr_salary_rule_data.xml:322, somewhere inside ``` https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/l10n_us_hr_payroll/models/hr_payslip.py#L12-L21 The issue occurs because the cron ``Payroll: Update data`` calls ``_get_data_files_to_update`` method, which loads the ``data/hr_salary_rule_data.xml`` file containing a reference to the deleted partner record at [1]. Since the external ID no longer exists, loading the XML file raises the traceback. [1]: https://github.com/odoo/enterprise/blob/21477b333f7a33cb582cd806236e4f9f8346d022/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L484 sentry-7496380516
This update corrects a restriction in the Hong Kong payroll module that was preventing employers from using multiple MPF account numbers under the same registration number. The change allows for valid multi-account configurations by validating duplicates based on the combination of registration number and employer account number. This ensures accurate tracking of employer MPF contributions.
Original PR description
An employer can legitimately hold multiple employer account numbers under the same MPF registration number. The previous constraint rejected any two MPF schemes sharing the same registration number, blocking valid multi-account configurations. Fix the validation to only restrict the duplicate based on the combination of registration number and employer account number. task-6232561 Forward-Port-Of: odoo/enterprise#118109
This update ensures that when a Cashdro payment line is cancelled, it's also fully deleted from the system, as expected. Previously, cancelled payments remained in a 'retry' state without being removed. This change improves data accuracy and simplifies Cashdro payment management.
Original PR description
Before this commit, if you tried to cancel and delete a Cashdro payment line by clicking the x, the payment would be cancelled but the line would not be deleted, just left in the 'retry' state. After this commit, the payment line is deleted after being cancelled as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265772
This update resolves an issue where the undo function wouldn't work correctly after inserting a table of contents in the HTML editor. The fix prevents unnecessary history steps from being added, ensuring that users can reliably undo actions like inserting a table of contents without impacting other editing functions.
Original PR description
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base…
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes. In the table of content case, this creates a loop: - Attributes are cleared and a history step is added. - Undo restores only the cleared attributes. - The selection falls back into the empty paragraph after the table of content. - `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step. As a result, undo never reaches the previous user action. Solution: Avoid adding a history step in `SelectionPlaceholderPlugin.onSelectionChange` when the current step is not modified by any user interaction. Steps to reproduce: - Write some text. - Insert a table of content using `/toc`. - Press Ctrl + Z. - Observe that nothing happens and the previously typed text cannot be undone. task-6216910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264743
A previous test in our meeting functionality was intermittently failing due to a timing issue. This update ensures the initial 'mark as read' action completes before subsequent steps, making the test reliable and preventing potential disruptions to the meeting workflow. This improves the overall stability of our messaging system.
Original PR description
The `test_04_meeting_view_tour` test sometimes fails. A race condition occurs between the initial mark as unread action, which may or may not be triggered depending on whether the thread composer has time to gain focus before the meeting view is opened, and the later mark as unread action triggered during the test. This commit ensures the initial mark as read action is completed before proceeding to the mark as unread steps, thus resolving the issue. runbot-239936 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#264662
This update resolves an issue where the VIES validation process was incorrectly triggered during tax return creation, leading to errors. The fix ensures that VIES validation only occurs for tax returns associated with partners requiring VAT, improving the accuracy of financial reporting. This prevents unnecessary errors and ensures compliance.
Original PR description
Vies validation should only occurs with moves having fiscal position with vat required Steps: - With base_vat, and european l10n like BE installed - Make a bill for a partner with no vat or invalid vat - Create a tax return - Open the return -> the 'check_partner_vies' fails opw-6200246 Forward-Port-Of: odoo/enterprise#117913
This update resolves an issue where the 'Caption' button within the HTML editor was not properly translated, preventing international users from accessing captions. This fix ensures all text within the editor is localized, improving the user experience for global customers.
Original PR description
Currently the "Caption" button in the HTML editor is not translatable. This commit fixes that. Forward-Port-Of: odoo/odoo#266002
This update resolves an issue where stock transfer widgets incorrectly displayed 'No package' tags for certain transfer types. The fix ensures accurate package identification, particularly after recent database upgrades, by providing a fallback mechanism when package history is unavailable.
Original PR description
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field…
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field is used in the `stock_package_m2m` widget to append a `No package` tag when a move has this field set. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L266-L269 https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/static/src/widgets/stock_package_m2m.js#L9-L24 This works fine when package history exists, as it accesses the `package_ids` field to generate the tags. However, for recently upgraded databases, no package history is available. When the `_compute_package_ids` method runs, it attempts to access data from an undefined history record, triggering a traceback. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L271-L278 # The fix The fix is straightfoward: in `_compute_package_ids`, if a move is in the `done` or `cancel` state and has no package history, we fallback and populate `package_ids` using the same logic applied to states other than `done` or `cancel`. This behavior specifically targets and fixes issue for databases recently upgraded to v19. task: 6070541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265032
This update fixes an issue preventing users from importing emissions data within the ESG module. The change allows the 'import' action to appear in the COG menu, even with the 'create' attribute disabled in the list view. This ensures users can easily access and manage their emissions data.
Original PR description
Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1 Forward-Port-Of: odoo/enterprise#118004
This update corrects a bug where portal users could inadvertently delete documents they didn't own. The fix ensures that portal users can only delete documents they own, preventing unintended data loss during the standard cron archiving process. The change simplifies the code and improves stability.
Original PR description
Reproduce: with rpc call as portal user, you can archive documents you have access to. This is not desired as this may lead to records being deleted when the cron collects the trash, but we only wanted to support portal users deleting only records they own. What we did when calling toggle_active should be done for all calls to `write` with `active`. It also removes the need for `_raise_if_unauthorized_archive` and `_unlink_except_unauthorized`. Task-6205627 Forward-Port-Of: odoo/enterprise#118055 Forward-Port-Of: odoo/enterprise#116886
This update resolves an issue where Odoo branches were incorrectly inheriting VAT settings from their parent companies, leading to manual VAT adjustments. The change now defaults branches to no VAT, ensuring the parent company remains the key provider and simplifies branch operations. Key settings are also restricted to the base group for improved security.
Original PR description
Branches copied the parent's VAT, which made them their own signing entity and forced users to clear the VAT so the branch would reuse the parent's keys. Default branches to no VAT so the parent remains the key provider. Setting a VAT on a branch still exposes the key settings for the rare case separate keys are needed. Also restrict the key settings to base.group_system task_id - 6087168 Forward-Port-Of: odoo/enterprise#117986
This update resolves an issue where constant fields within signing documents were failing to populate correctly, leading to signing errors. The fix ensures that empty values from auto-field calculations are preserved, preventing the 'Some required items are not filled' error and improving the signing process. This ensures documents are properly populated during the signing workflow.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign template. - Add a sign item with read only true and linked model and auto_value field set. - Send document for signing. - Try to sign the document. Issue: - Signing fails with "Some required items are not filled". - Constant readonly fields become empty during signing flow. Cause: - In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`. - When no reference document was set, `_get_auto_field_value() `returned an empty string. - This caused an empty value to be stored in `sign.request.item.value`. Solution: - Keep the default field value when auto-field resolution returns an empty string. - Only replace the value when a valid auto-field value is found. task-6229776 Forward-Port-Of: odoo/enterprise#118298 Forward-Port-Of: odoo/enterprise#117880
This update resolves an issue where a system error was incorrectly triggering a fallback mechanism in the IoT service. The fix ensures that errors related to failed longpolling requests are only flagged when the request wasn't intentionally aborted, improving system stability and reliability. This prevents unnecessary service interruptions.
Original PR description
In odoo/odoo#260931, new logic was added to raise an 'unreachable' error in the case where a longpolling listen request failed. This error was then used by the IoT HTTP service to fallback to a websocket listener. However, due to an oversight this 'unreachable' error was also being triggered whenever the longpolling listen request was aborted, which happens whenever a new listener is added. This commit fixes the issue by checking the error type and only sending the 'unreachable' error if the request was not aborted. opw-6175686 Forward-Port-Of: odoo/enterprise#117947 Forward-Port-Of: odoo/enterprise#117905
This update resolves a problem where users couldn't link invoices to the chatter feature in Odoo. The fix prevents a security check from failing when copying attachments, ensuring users with appropriate permissions can successfully link documents. This improves the usability of the chatter feature for sales and accounting teams.
Original PR description
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now…
**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now go back to the SO, and try to link the INV document to the chatter. **Cause:** When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document. **Solution:** Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework. opw-5916364 Forward-Port-Of: odoo/enterprise#107723
This update resolves an issue where Odoo's Google Calendar sync process would silently fail when updates were made to recurring events, specifically when new attendees were added or start times were changed. The fix prevents errors from occurring and ensures more reliable synchronization between Odoo and Google Calendar, improving overall event management.
Original PR description
When a recurrence is updated in Google Calendar simultaneously with a new attendee and a changed start time, Odoo silently logs MissingError during the post-commit Google API callback Steps to reproduce: 1. Have a recurring event already synced between Odoo and Google Calendar 2. In Google Calendar, open the recurrence and edit "all events": - Add a new attendee - Change the start time 3. Trigger a Google Calendar sync 4. MissingError exceptions appear in server logs, one per event in the recurrence opw-6024835 Forward-Port-Of: odoo/odoo#265247
This update eliminates a persistent warning message related to background workers in the Odoo system. The warning was deemed confusing and redundant, as a new user interface design already addresses the underlying issue. This change improves the overall user experience and reduces potential confusion.
Original PR description
Those warning are considered as cumbersome and new tabs will work anyway. Forward-Port-Of: odoo/odoo#266060
This update corrects a bug where calls were not accurately reflecting open tickets associated with their parent partners. Previously, a call's ticket count didn't include tickets linked to child partners. Now, all open tickets related to a call, including those on child partners, are correctly counted, providing a more complete view of support activity.
Original PR description
Unlike most of *_count fields on res.partner, for example ticket_count, open_ticket_count didn't take into account of its child partners. To reproduce: 1. create parent parent P and child partner C 2. create a ticket for partner C and put it in a unfold stage 3. call partner P and open form view of this call the open ticket count on the smart button is 0 instead of 1 In this commit, we change it that when a child partner has open tickets, they will also be counted as parent partner's. Forward-Port-Of: odoo/enterprise#118102 Forward-Port-Of: odoo/enterprise#115303
This pull request addresses minor inconsistencies in the Polish e-invoice (l10n_pl_edi) export format, specifically related to a flag that must always be '1'. It also clarifies that the 'KursWaluty' (currency course) field is optional when it matches the standard PLN currency. These changes ensure compliance with Polish tax regulations.
Original PR description
Legal ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf
- KursWaluty is optional and doesn't need to be included if it's the same as PLN.
- The following flags accept only "1" as a valid value.
See their type being etd:TWybor1:
http://crd.gov.pl/wzor/2025/06/25/13775/schemat.xsd
http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2020/07/06/eD/DefinicjeTypy/ElementarneTypyDanych_v7-0E.xsd
```xsd
<xsd:simpleType name="TWybor1">
<xsd:annotation>
<xsd:documentation>Pojedyncze pole wyboru</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:byte">
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
```
Forward-Port-Of: odoo/odoo#262462This update corrects a previous issue where CSV imports incorrectly used locale-specific separators. Now, CSV files automatically use the correct separators based on the user's locale, while other file types revert to standard English formatting. This ensures consistent and accurate data import across all users.
Original PR description
Fixes an issue from https://github.com/odoo/odoo/pull/248233 where locale-based separators were incorrectly applied to all file imports. The model-wide defaults have been restored to English formatting. To handle edge cases where a user re-uploads a file without triggering a model reset, the system now explicitly resets and recalculates the separator options on every upload (applying locale settings for CSVs, and English defaults for others). opw-6233955
This update fixes an issue where long text in m2m avatar fields was being cut off, creating a poor user experience. The change adds a 'truncate' class to ensure text is neatly cut off with an ellipsis when it exceeds the display area, improving visual consistency.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 Before: <img width="322" height="189" alt="c5f23b6aee6f63982f530c2e6a641d21" src="https://github.com/user-attachments/assets/b50fc70d-4d21-4023-8838-460f060a98fb" /> After: <img width="310" height="167" alt="5ccf4bb07603a3d8c50d3763bd112f6d" src="https://github.com/user-attachments/assets/fa7e4167-98d8-47d7-a1e2-6639da8e5d05" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265947 Forward-Port-Of: odoo/odoo#256817
This update fixes an issue where long text in m2m tags' avatar fields would overflow and be cut off. By adding a 'truncate' class, text now automatically displays with an ellipsis when it exceeds the available space, providing a cleaner and more user-friendly experience.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 https://github.com/odoo/odoo/pull/256817 Forward-Port-Of: odoo/enterprise#118113 Forward-Port-Of: odoo/enterprise#112590
This update optimizes how Odoo tracks subscription usage, leading to faster reporting and a smoother experience for users managing subscriptions. The change addresses a performance bottleneck related to query counts, ensuring the system remains responsive under normal usage. This improves the overall efficiency of the subscription module.
Original PR description
runbot-163667 Forward-Port-Of: odoo/enterprise#117266
This update resolves a visual bug in email templates where the horizontal padding on a banner block was lost after saving and reloading the template. The issue stemmed from how the system processed CSS styles, specifically with variable references. By using explicit longhand padding properties, the padding is now consistently applied, ensuring the banner looks correct.
Original PR description
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline`…
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline` processes the content via `_normalizeStyle`, which iterates over `CSSStyleDeclaration` using index-based iteration. This only yields longhand properties (e.g. `padding-left`, `padding-top`), never shorthands like `padding`. When the shorthand contains `var()` references (e.g. `padding: var(--y) var(--x)`), the browser cannot resolve the longhands and leaves them empty, so they are silently dropped during style extraction. Adding shorthand support to the iterator was not viable, as the rest of the pipeline expects longhand-only styles, and safely converting `padding: var(--y) var(--x)` to longhands is not possible without first resolving the variables. Solution: Replace the `padding` shorthand in the banner template with explicit longhand properties (`padding-top`, `padding-bottom`, `padding-left`, `padding-right`). Steps to reproduce: 1. Open an email template 2. Add a banner/info block 3. Save the template 4. Reload the page 5. Observe horizontal padding is lost and icon is misaligned task-6230530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265756
This update resolves an issue preventing users from editing tracker codes within the website. The previous code used an outdated styling method that hid the buttons, rather than the intended 'd-none' class. This change ensures the buttons are correctly displayed and functional.
Original PR description
When interactions were introduced, the buttons for link tracker edition were no longer hidden by inline style, but with the class "d-none". Since there was still "display: none" as an inline style in the .xml, the buttons were never shown and the user could not edit the link code. This commit replaces the inline style by the class d-none, since it is a better practice. task-4531974 Forward-Port-Of: odoo/odoo#242481
21 changes
Resolved issues and error corrections
This update fixes a visual issue in the website builder where color options were missing when customizing images with shapes. The change ensures that images with shapes now correctly display color pickers, allowing for more flexible design options. This improves the user experience and design capabilities within the website builder.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#265465 Forward-Port-Of: odoo/odoo#246249
This update resolves an issue preventing employers from correctly managing multiple MPF account numbers under a single registration. The change relaxes a previous restriction, allowing valid multi-account configurations while still ensuring uniqueness based on the combination of registration and account numbers. This improves data accuracy for Hong Kong payroll processing.
Original PR description
An employer can legitimately hold multiple employer account numbers under the same MPF registration number. The previous constraint rejected any two MPF schemes sharing the same registration number, blocking valid multi-account configurations. Fix the validation to only restrict the duplicate based on the combination of registration number and employer account number. task-6232561 Forward-Port-Of: odoo/enterprise#118109
This update resolves a visual bug in email templates where banner padding would disappear after saving and reloading. The fix replaces shorthand padding styles with explicit longhand styles to ensure consistent rendering across different email clients. This improves the appearance and alignment of email banners.
Original PR description
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline`…
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline` processes the content via `_normalizeStyle`, which iterates over `CSSStyleDeclaration` using index-based iteration. This only yields longhand properties (e.g. `padding-left`, `padding-top`), never shorthands like `padding`. When the shorthand contains `var()` references (e.g. `padding: var(--y) var(--x)`), the browser cannot resolve the longhands and leaves them empty, so they are silently dropped during style extraction. Adding shorthand support to the iterator was not viable, as the rest of the pipeline expects longhand-only styles, and safely converting `padding: var(--y) var(--x)` to longhands is not possible without first resolving the variables. Solution: Replace the `padding` shorthand in the banner template with explicit longhand properties (`padding-top`, `padding-bottom`, `padding-left`, `padding-right`). Steps to reproduce: 1. Open an email template 2. Add a banner/info block 3. Save the template 4. Reload the page 5. Observe horizontal padding is lost and icon is misaligned task-6230530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265756
This update ensures that when a Cashdro payment line is cancelled, it's also completely deleted, as expected. Previously, the line would remain in a 'retry' state. This change improves data accuracy and simplifies Cashdro payment management.
Original PR description
Before this commit, if you tried to cancel and delete a Cashdro payment line by clicking the x, the payment would be cancelled but the line would not be deleted, just left in the 'retry' state. After this commit, the payment line is deleted after being cancelled as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265772
This update resolves an issue where the undo function wouldn't work correctly after inserting a table of contents, specifically when no text followed it. The fix prevents unnecessary history steps from being added, ensuring the undo operation functions as expected and allows users to revert changes accurately.
Original PR description
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base…
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes. In the table of content case, this creates a loop: - Attributes are cleared and a history step is added. - Undo restores only the cleared attributes. - The selection falls back into the empty paragraph after the table of content. - `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step. As a result, undo never reaches the previous user action. Solution: Avoid adding a history step in `SelectionPlaceholderPlugin.onSelectionChange` when the current step is not modified by any user interaction. Steps to reproduce: - Write some text. - Insert a table of content using `/toc`. - Press Ctrl + Z. - Observe that nothing happens and the previously typed text cannot be undone. task-6216910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264743
This update fixes a visual issue in the termination fees report for the Belgian payroll module. The report layout was misaligned when termination slips were generated with fewer lines of information. The fix dynamically adjusts the layout to ensure proper alignment and formatting, improving the report's appearance.
Original PR description
**Steps to Reproduce:** 1. Generate a termination slip for an employee 2. The generated payslip pdf layout looks clumsy and misaligned. **Bug Cause:** 1. The notice duration has rowspan="3" expecting 3 lines. When there are less than 3 lines, the following rows are affected and misaligned. 2. The border is missing. **Solution:** Added dynamic sizing for notice duration instead of static rowspan="3". Used index instead of line_count for both notice duration and banks to stay consistent and simple. Added table-bordered class as borders are not automatically applied like in previous versions. **Task:** 6193558 Forward-Port-Of: odoo/enterprise#116627
This update corrects a display error in the employee attendance Gantt view, specifically when public holidays are created. The issue occurred when employees with flexible schedules were assigned contracts before a certain date, leading to incorrect holiday representation. The fix converts all timezones to UTC to ensure accurate holiday scheduling.
Original PR description
[FIX] hr_attendance_gantt: fix gantt view with public holidays Bug reproduction: 1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026 2 -…
[FIX] hr_attendance_gantt: fix gantt view with public holidays
Bug reproduction:
1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)
Bug cause:
1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.
Bug solution:
1 - I converted the timezone to UTC to solve the problem.
task - 6067070
Forward-Port-Of: odoo/enterprise#112493This update resolves an issue where the VIES validation process incorrectly flagged invoices without VAT during tax return creation. The fix ensures that VIES validation only applies to tax returns where a fiscal position with VAT requirements is present. This prevents unnecessary errors and ensures accurate tax reporting for European customers.
Original PR description
Vies validation should only occurs with moves having fiscal position with vat required Steps: - With base_vat, and european l10n like BE installed - Make a bill for a partner with no vat or invalid vat - Create a tax return - Open the return -> the 'check_partner_vies' fails opw-6200246 Forward-Port-Of: odoo/enterprise#117913
This update resolves a problem where sending invoices with year-range sequences (like INV/2025-2026/00001) to MyInvois was failing. The fix corrects a technical error in how the system processes these invoice numbers, ensuring invoices are now correctly transmitted.
Original PR description
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi`…
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi` modules (with demo data). 2. Switch to "MY Company"(Malaysian company). 3. Enable "_Quick Encoding_" for Customer Invoices in Settings. 4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice. 5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again. 6. Open the invoice list view and click **"Send to MyInvois"**. **Error:** `ValueError: not enough values to unpack (expected 4, got 2)` The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1]. [1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146 Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263 sentry-7320998540 Forward-Port-Of: odoo/odoo#266221 Forward-Port-Of: odoo/odoo#253237
This update fixes an issue where links within HTML emails weren't properly formatted, leading to broken internal links. The change ensures that all email links, regardless of composer type, are correctly enriched and functional, improving email communication and user experience. This resolves a technical inconsistency in how internal links are handled.
Original PR description
HTML composer bodies are posted as existing markup, so internal /mail/message/<id> links were not enriched like links typed in the plain text composer. Normalize HTML composer content before posting by trimming editor-only empty boundary blocks and applying mail link enrichment while preserving the original markup. Existing anchors pointing to internal mail messages now receive the o_message_redirect metadata needed by the message renderer. task-6217103
This update fixes a visual issue where the reply composer remained visible after a live chat conversation ended or a channel became read-only. Now, the composer automatically disappears when replying is no longer possible, ensuring a cleaner and more consistent user experience. This improves usability and prevents confusion.
Original PR description
***=im_livechat** **Steps to Reproduce: [Livechat case]** - Start a Live Chat conversation between an Operator and a Visitor. - From the operator side, click Reply on a visitor message. - From the…
***=im_livechat** **Steps to Reproduce: [Livechat case]** - Start a Live Chat conversation between an Operator and a Visitor. - From the operator side, click Reply on a visitor message. - From the visitor side, close the conversation. - Return to the operator side. - Observe that the replyToMessage composer is still visible even though the live chat has ended. **[Channel Read-only case]** - Create a channel between two users. - Ensure the channel is writable initially. - From one user's side, click Reply on another user's message. - While the user is in reply mode, make the channel read-only from the admin side. - Return to the replying user's side. - Observe that the reply-to-message composer is still visible even though the channel has become read-only. **Current behavior before PR:** Before this PR, the reply composer could remain visible after the conversation became unavailable for replying, such as when a channel turned read-only again or when a livechat conversation ended. **Desired behavior after PR is merged:** After this PR, the reply composer is automatically dismissed whenever replying is no longer possible, keeping the composer state consistent with the conversation state. task-[6208973](https://www.odoo.com/odoo/project/1519/tasks/6208973) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Caption' button within the HTML editor was not properly translated into different languages. The change ensures all button labels are translatable, improving the user experience for international users. This is a minor fix to enhance localization capabilities.
Original PR description
Currently the "Caption" button in the HTML editor is not translatable. This commit fixes that. Forward-Port-Of: odoo/odoo#266002
This update resolves an issue where stock transfer tags were incorrectly displayed for 'done' transfers without package history, particularly after database upgrades. The fix ensures that the system correctly identifies and tags transfers without package history, improving data accuracy and reporting. This addresses a recent upgrade issue impacting a subset of users.
Original PR description
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field…
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field is used in the `stock_package_m2m` widget to append a `No package` tag when a move has this field set. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L266-L269 https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/static/src/widgets/stock_package_m2m.js#L9-L24 This works fine when package history exists, as it accesses the `package_ids` field to generate the tags. However, for recently upgraded databases, no package history is available. When the `_compute_package_ids` method runs, it attempts to access data from an undefined history record, triggering a traceback. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L271-L278 # The fix The fix is straightfoward: in `_compute_package_ids`, if a move is in the `done` or `cancel` state and has no package history, we fallback and populate `package_ids` using the same logic applied to states other than `done` or `cancel`. This behavior specifically targets and fixes issue for databases recently upgraded to v19. task: 6070541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265032
This update resolves an issue where Odoo branches were incorrectly inheriting VAT information from their parent companies, leading to manual VAT adjustments and potential key management problems. The change ensures branches default to no VAT, maintaining the parent company as the key provider and simplifying operations. Key settings are now restricted to the base group system.
Original PR description
Branches copied the parent's VAT, which made them their own signing entity and forced users to clear the VAT so the branch would reuse the parent's keys. Default branches to no VAT so the parent remains the key provider. Setting a VAT on a branch still exposes the key settings for the rare case separate keys are needed. Also restrict the key settings to base.group_system task_id - 6087168 Forward-Port-Of: odoo/enterprise#117986
This update resolves an issue preventing users from correctly applying deductions on receipts, such as for self-employed individuals. The change removes a validation error that would have been triggered in these scenarios, ensuring accurate accounting record-keeping. A new test case confirms the updated behavior aligns with vendor bill processing.
Original PR description
As using deductions on receipts is a plausible accounting situation, such as in the case of self-employed person booking a ticket, there shouldn't be a validation error raised in this case. task-6037582 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254371
This update resolves an issue where Odoo's Google Calendar syncing process would silently fail when updates were made to recurring events, specifically with new attendees or start time changes. The fix prevents errors from appearing in server logs, ensuring more reliable synchronization between Odoo and Google Calendar. This improves the overall stability of the calendar integration.
Original PR description
When a recurrence is updated in Google Calendar simultaneously with a new attendee and a changed start time, Odoo silently logs MissingError during the post-commit Google API callback Steps to reproduce: 1. Have a recurring event already synced between Odoo and Google Calendar 2. In Google Calendar, open the recurrence and edit "all events": - Add a new attendee - Change the start time 3. Trigger a Google Calendar sync 4. MissingError exceptions appear in server logs, one per event in the recurrence opw-6024835 Forward-Port-Of: odoo/odoo#265247
This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored the test data to ensure the tests continue to run successfully, maintaining the stability of the Italian reporting module. This prevents disruptions to the reporting process.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#117275 Forward-Port-Of: odoo/enterprise#112794
This update fixes an issue where calls were not accurately reflecting open tickets associated with their parent partners. Previously, open tickets on child partners weren't counted. Now, all open tickets linked to a call's parent partner are correctly displayed, providing a more complete view of related support requests.
Original PR description
Unlike most of *_count fields on res.partner, for example ticket_count, open_ticket_count didn't take into account of its child partners. To reproduce: 1. create parent parent P and child partner C 2. create a ticket for partner C and put it in a unfold stage 3. call partner P and open form view of this call the open ticket count on the smart button is 0 instead of 1 In this commit, we change it that when a child partner has open tickets, they will also be counted as parent partner's. Forward-Port-Of: odoo/enterprise#118102 Forward-Port-Of: odoo/enterprise#115303
This pull request addresses minor inconsistencies in the Polish VAT (FA3) export format. Specifically, it clarifies that a single flag must always be '1' and simplifies the handling of currency data, making it optional if it matches the standard PLN currency. These changes ensure compliance with Polish tax regulations.
Original PR description
Legal ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf
- KursWaluty is optional and doesn't need to be included if it's the same as PLN.
- The following flags accept only "1" as a valid value.
See their type being etd:TWybor1:
http://crd.gov.pl/wzor/2025/06/25/13775/schemat.xsd
http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2020/07/06/eD/DefinicjeTypy/ElementarneTypyDanych_v7-0E.xsd
```xsd
<xsd:simpleType name="TWybor1">
<xsd:annotation>
<xsd:documentation>Pojedyncze pole wyboru</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:byte">
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
```
Forward-Port-Of: odoo/odoo#262462This update resolves an issue where the field selector popover was hidden behind the field creation popover in Email Marketing, making it difficult to add dynamic fields. The fix removes an unnecessary offset setting, ensuring the field selector appears correctly and improves the user experience.
Original PR description
Problem: In Email Marketing, the field selector popover is displayed behind the field creation popover. Cause: `useOverlayServiceOffset` offsets all `MassMailingIframe` overlay sequences by `+1000` (default sequence `50` becomes `1050`). The field selector popover was using the default sequence, causing it to appear below the main popover. Solution: remove the `useOverlayServiceOffset` hook as it is not needed anymore. Steps to reproduce: - Create a new Email Marketing record. - Try to add a dynamic field. - Open the field selector. - Observe that the selector popover appears behind the main popover, making field selection difficult. opw-6203734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where an empty value in a key within the reporting data caused an error. The fix ensures that the system now correctly handles empty values, preventing a crash and improving the reliability of reports. This change ensures data is consistently retrieved and processed.
Original PR description
When the key exists external_ids with an empty, the get method returns the empty list instead of defaulting to [None]. code and their output for empty list ``` (Pdb) (external_ids.get(self[5].id) or [None])[0] (Pdb) external_ids.get(self[5].id, [None])[0] *** IndexError: list index out of range (Pdb) external_ids.get(self[5].id) [] (Pdb) external_ids.get(self[5].id,[None]) [] (Pdb) external_ids.get(self[5].id) or [None] [None] ```
15 changes
Resolved issues and error corrections
This update fixes a visual issue in the website builder where users couldn't change the color of images with shapes. The fix adds the necessary configuration to allow users to select colors for these images, enhancing the design flexibility within the builder. This ensures consistent and visually appealing website designs.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#265465 Forward-Port-Of: odoo/odoo#246249
This update fixes an issue preventing employers from correctly managing multiple MPF account numbers under the same registration. The change allows for valid multi-account configurations by validating duplicates based on the combination of registration and employer account numbers, ensuring accurate payroll processing for Hong Kong businesses.
Original PR description
An employer can legitimately hold multiple employer account numbers under the same MPF registration number. The previous constraint rejected any two MPF schemes sharing the same registration number, blocking valid multi-account configurations. Fix the validation to only restrict the duplicate based on the combination of registration number and employer account number. task-6232561 Forward-Port-Of: odoo/enterprise#118109
This update resolves a visual bug where horizontal padding was lost in email banners after saving and reloading. The issue stemmed from how the system processed CSS styles, specifically when using variable references for padding. By replacing shorthand padding with explicit longhand properties, the banner now displays correctly across email templates.
Original PR description
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline`…
Problem: In email templates, adding a banner/info block and saving then reloading causes the horizontal padding to be lost and the icon to become misaligned. Cause: During save, `convert_inline` processes the content via `_normalizeStyle`, which iterates over `CSSStyleDeclaration` using index-based iteration. This only yields longhand properties (e.g. `padding-left`, `padding-top`), never shorthands like `padding`. When the shorthand contains `var()` references (e.g. `padding: var(--y) var(--x)`), the browser cannot resolve the longhands and leaves them empty, so they are silently dropped during style extraction. Adding shorthand support to the iterator was not viable, as the rest of the pipeline expects longhand-only styles, and safely converting `padding: var(--y) var(--x)` to longhands is not possible without first resolving the variables. Solution: Replace the `padding` shorthand in the banner template with explicit longhand properties (`padding-top`, `padding-bottom`, `padding-left`, `padding-right`). Steps to reproduce: 1. Open an email template 2. Add a banner/info block 3. Save the template 4. Reload the page 5. Observe horizontal padding is lost and icon is misaligned task-6230530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265756
This update resolves an issue where inserting a prompt banner using the `/prompt` command prevented users from undoing the action. The fix ensures that history commands function correctly even when a prompt banner is present, improving usability and preventing data inconsistencies.
Original PR description
Problem: After inserting a prompt banner, undo does not remove it. Cause: History commands were ignored when the selection was inside the prompt banner, preventing undo from handling banner insertion. Solution: Handle history commands even when the selection is inside the prompt banner. Steps to reproduce: - Insert a prompt banner using `/prompt` + Enter. - Press Ctrl + Z. - Observe that the banner is not removed. task-6230530 Forward-Port-Of: odoo/enterprise#117845
This update ensures that deleting a Cashdro payment line now correctly removes it from the system after cancellation. Previously, canceled payments remained in a 'retry' state. This change improves data accuracy and simplifies Cashdro payment management.
Original PR description
Before this commit, if you tried to cancel and delete a Cashdro payment line by clicking the x, the payment would be cancelled but the line would not be deleted, just left in the 'retry' state. After this commit, the payment line is deleted after being cancelled as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265772
This update resolves an issue where the undo function wouldn't work correctly after inserting a table of contents. The fix prevents unnecessary history steps from being added, ensuring that users can reliably undo actions like inserting a table of contents without impacting other text editing features.
Original PR description
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base…
Problem: Undo does not work correctly after inserting a table of content when no paragraph follows it. Cause: `SelectionPlaceholderPlugin.onSelectionChange` clears attributes from the next base container and adds a history step whenever the selection changes. In the table of content case, this creates a loop: - Attributes are cleared and a history step is added. - Undo restores only the cleared attributes. - The selection falls back into the empty paragraph after the table of content. - `SelectionPlaceholderPlugin.onSelectionChange` runs again and adds another history step. As a result, undo never reaches the previous user action. Solution: Avoid adding a history step in `SelectionPlaceholderPlugin.onSelectionChange` when the current step is not modified by any user interaction. Steps to reproduce: - Write some text. - Insert a table of content using `/toc`. - Press Ctrl + Z. - Observe that nothing happens and the previously typed text cannot be undone. task-6216910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264743
This update resolves an issue where the VIES validation process was incorrectly triggered during tax return creation, leading to errors. The fix ensures that VIES validation only occurs for tax returns associated with invoices that require a VAT number. This improves the accuracy of tax reporting and prevents unnecessary errors.
Original PR description
Vies validation should only occurs with moves having fiscal position with vat required Steps: - With base_vat, and european l10n like BE installed - Make a bill for a partner with no vat or invalid vat - Create a tax return - Open the return -> the 'check_partner_vies' fails opw-6200246 Forward-Port-Of: odoo/enterprise#117913
A recent test failed because the system wasn't correctly assigning user permissions for displaying production lot information. This change ensures that the necessary user group (`stock.group_production_lot`) is automatically included in test environments, preventing similar errors and improving test reliability. This primarily impacts the MRP module.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Run `test_reservation_method_for_outgoing` without demo data. Issue ----- > AssertionError: 'lot_id' was not found in the view Cause ----- The `lot_id` field is only rendered if the current user has the `stock.group_production_lot` group. This is only default when demo data is installed. Solution -------- Add the group to the current user in `setUpClass`. runbot-243588 Forward-Port-Of: odoo/odoo#266164 Forward-Port-Of: odoo/odoo#266052
This update resolves an issue where the 'Caption' button within the HTML editor was not properly localized for different languages. This ensures consistent and accurate translations across all Odoo SaaS environments, improving the user experience for international users.
Original PR description
Currently the "Caption" button in the HTML editor is not translatable. This commit fixes that. Forward-Port-Of: odoo/odoo#266002
This update ensures that conversations hidden until new messages are received accurately reflect the 'Hide Until New Message' feature. Previously, unread messages remained unread on hidden conversations. The fix updates the system to mark the user as read before applying the unpin date, maintaining consistent behavior and improving the user experience.
Original PR description
When hiding a Discuss conversation until new messages arrive, the conversation is unpinned but the user remains a member. Existing unread messages could therefore stay unread on a hidden conversation. Mark the current member as read before applying the unpin date when handling `/discuss/channel/pin` with `pinned: false`. This keeps the "Hide Until New Message" behavior consistent: only future messages should bring the conversation back.
This update resolves an issue where stock transfer records with missing package information incorrectly displayed 'No package' tags. The fix ensures accurate package tagging, particularly for recently upgraded databases that may lack historical package data. This improves the reliability of stock transfer reporting.
Original PR description
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field…
# The bug When accessing a done transfer with two lines where one line has a result package ID and the other does not, the computed field `has_lines_without_result_package` returns `True`. This field is used in the `stock_package_m2m` widget to append a `No package` tag when a move has this field set. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L266-L269 https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/static/src/widgets/stock_package_m2m.js#L9-L24 This works fine when package history exists, as it accesses the `package_ids` field to generate the tags. However, for recently upgraded databases, no package history is available. When the `_compute_package_ids` method runs, it attempts to access data from an undefined history record, triggering a traceback. https://github.com/odoo/odoo/blob/eaa6c4352aec2be8519360c282f3f6504a2f263c/addons/stock/models/stock_move.py#L271-L278 # The fix The fix is straightfoward: in `_compute_package_ids`, if a move is in the `done` or `cancel` state and has no package history, we fallback and populate `package_ids` using the same logic applied to states other than `done` or `cancel`. This behavior specifically targets and fixes issue for databases recently upgraded to v19. task: 6070541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265032
This update resolves an issue where Odoo branches were incorrectly inheriting VAT settings from the parent company, leading to manual VAT adjustments and potential key management problems. The change now defaults branches to no VAT, ensuring the parent company remains the key provider and simplifies operations. Key settings are also restricted to the base group system.
Original PR description
Branches copied the parent's VAT, which made them their own signing entity and forced users to clear the VAT so the branch would reuse the parent's keys. Default branches to no VAT so the parent remains the key provider. Setting a VAT on a branch still exposes the key settings for the rare case separate keys are needed. Also restrict the key settings to base.group_system task_id - 6087168 Forward-Port-Of: odoo/enterprise#117986
This update resolves an issue preventing translations from appearing in the HTML editor's move tooltip. The fix moves a key translation call outside of the template literal, allowing the exporter to correctly identify and translate the text. This ensures all users see translated tooltips.
Original PR description
Currently the move tooltip in the HTML editor is not translated because the exporter can't see `_t()` calls in tagged template literal. This commit fixes the issue by moving the call outside of the template literal. Forward-Port-Of: odoo/odoo#266186 Forward-Port-Of: odoo/odoo#265991
This update resolves an issue where the system incorrectly flagged deductions on receipts, such as those made by self-employed individuals. The change removes a validation error, allowing users to accurately record deductible expenses on receipts. A new test has been added to ensure consistent behavior.
Original PR description
As using deductions on receipts is a plausible accounting situation, such as in the case of self-employed person booking a ticket, there shouldn't be a validation error raised in this case. task-6037582 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254371
This update fixes a technical issue where Odoo experienced errors during Google Calendar synchronization when recurring events were modified with new attendees or start time changes. The fix prevents these errors from occurring, ensuring smoother and more reliable syncing of events between Odoo and Google Calendar. This improves the overall stability of the integration.
Original PR description
When a recurrence is updated in Google Calendar simultaneously with a new attendee and a changed start time, Odoo silently logs MissingError during the post-commit Google API callback Steps to reproduce: 1. Have a recurring event already synced between Odoo and Google Calendar 2. In Google Calendar, open the recurrence and edit "all events": - Add a new attendee - Change the start time 3. Trigger a Google Calendar sync 4. MissingError exceptions appear in server logs, one per event in the recurrence opw-6024835 Forward-Port-Of: odoo/odoo#265247
4 changes
Resolved issues and error corrections
A technical issue where a test was incorrectly marked as commented instead of updated has been resolved. This fix ensures that the test accurately reflects the functionality of the l10n_be_coda module within the Odoo Enterprise system. The change improves the reliability of the accounting processes for Belgian businesses.
Original PR description
Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none Forward-Port-Of: odoo/enterprise#118068 Forward-Port-Of: odoo/enterprise#117924
This update ensures that work entry data exported to Acerta adheres to their specific formatting requirements. The export now correctly pads the external reference number to 17 digits with spaces and formats the work entry type code to 4 digits with spaces, resolving potential issues with data processing by the Acerta system. This ensures accurate data transmission and integration.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106 Forward-Port-Of: odoo/enterprise#118124
This update ensures that sales of services from European companies to Northern Ireland are correctly excluded from the EC Sales List report. This change aligns with regulations regarding services and triangular transactions, which are now accurately accounted for. The update was specifically developed for the Belgium localization.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
This update corrects a technical issue in the FAIA report export that caused incorrect references to suppliers. The system incorrectly identified partners without open balances as suppliers, leading to validation errors. This fix ensures the report accurately reflects supplier relationships as defined by the system's criteria.
Original PR description
## Steps to reproduce: 1. Install `l10n_lu_reports`, swap to the LU company 2. Look at the partner Azure Interior. 1. They have no open balances on `asset_receivable` or `liability_payable` accounts.…
## Steps to reproduce:
1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
1. Azure Interior is listed under /MasterFiles/Customers/Customer.
2. There are no /MasterFiles/Suppliers.
3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.
Video: [2]
## Explanation
This is one of several errors found with the FAIA export. See PR #113316 for more.
It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].
This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.
The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4]. This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.
The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.
The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.
> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate
[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173
opw-6107107
Forward-Port-Of: odoo/enterprise#1177998 changes
Resolved issues and error corrections
This update corrects a display issue where placeholder text in website translations was incorrectly rendered as HTML spans. The fix ensures that placeholder text is displayed as plain text, regardless of the language being used, improving the user experience for multilingual website content. This resolves a visual inconsistency and ensures accurate content presentation.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#265575 Forward-Port-Of: odoo/odoo#263320
This update resolves an error that occurred when creating bank accounts using the 'l10n_br' module. Specifically, the system was failing when a user entered a blank value for the 'Proxy Type' field. This change ensures the bank account creation process functions correctly, preventing data entry issues.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264995
A recent test failed because the user account wasn't properly configured to display information about production lots. This change ensures that the necessary group (`stock.group_production_lot`) is added to the test user, allowing the test to run correctly and accurately reflect the system's behavior. This resolves a technical issue that could have impacted future test results.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Run `test_reservation_method_for_outgoing` without demo data. Issue ----- > AssertionError: 'lot_id' was not found in the view Cause ----- The `lot_id` field is only rendered if the current user has the `stock.group_production_lot` group. This is only default when demo data is installed. Solution -------- Add the group to the current user in `setUpClass`. runbot-243588 Forward-Port-Of: odoo/odoo#266164 Forward-Port-Of: odoo/odoo#266052
This update corrects a bug in how Odoo searches for records using property fields. Previously, a filter on a property field sometimes returned incorrect results due to an issue with how boolean values were being interpreted during the search process. This fix ensures that property filters work as expected, accurately returning only the intended records.
Original PR description
# How to reproduce - Go to the Form view of a model to which you can Add Properties (e.g. Project > Tasks) - Click on the gear icon > Add Properties - Create a property field with : - Name : X -…
# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
- Name : X
- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)
# The problem
We see both records even tho we should only see one
# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589
In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601
The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.
opw-6224811
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265835This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with extensive sales order data. The change ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and improving the overall installation process.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118008
This update removes an unnecessary 'external' tag from a test class within the delivery module. Previously, errors were only detected during nightly builds, not during the standard Continuous Integration process. This change ensures that all tests are executed consistently, improving the reliability of our delivery system.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#114394 Forward-Port-Of: odoo/enterprise#111660
This update fixes an issue where the timesheet form view wasn't correctly displayed after refreshing a page. Previously, a generic form view was shown instead of the specific timesheet view. Now, the system automatically loads the correct form view, ensuring users always see the relevant timesheet details when refreshing.
Original PR description
…m view * Go to Timesheets > My Timesheets > switch to Grid view. * Hover over a cell with a timesheet entry and click the magnifier (search) icon. * The list opens; click a record to open its form view. * Observe the URL: `/odoo/timesheets/account.analytic.line/<id>`. * Refresh the page (F5). Before this commit, the generic form view was shown instead of the timesheet-specific form view. This occurred because, when reloading a page with a dynamic action and a resId, a generic view layout [false, "form"] was requested instead of the action-defined view. Now, the dynamic action is properly restored on refresh, ensuring the correct specific view is loaded for the form. opw-6133602 Forward-Port-Of: odoo/odoo#265815 Forward-Port-Of: odoo/odoo#265552
This update fixes a minor issue in the HTML editor where color selections weren't always correctly reflected. The change adds a verification step after color selection to ensure the color indicator is updated, preventing test failures. This ensures consistent and accurate color formatting within the HTML editor.
Original PR description
Before this commit: the test `cell's selected color should be shown in toolbar (3)` could fail when the bd color indicator isn't updated before the checking After this commit: we add another tick after the selection change to ensure the bg color indicator is properly updated. runbot-937780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This update corrects a display error in the employee attendance Gantt view. Specifically, it resolved a situation where public holidays weren't correctly marked, allowing employees to potentially work during those times. The fix involved standardizing time zone calculations to ensure accurate holiday representation.
Original PR description
[FIX] hr_attendance_gantt: fix gantt view with public holidays Bug reproduction: 1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026 2 -…
[FIX] hr_attendance_gantt: fix gantt view with public holidays
Bug reproduction:
1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)
Bug cause:
1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.
Bug solution:
1 - I converted the timezone to UTC to solve the problem.
task - 6067070
Forward-Port-Of: odoo/enterprise#112493This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module, particularly on databases with extensive sales order data. By ensuring newly created fields default to null during installation, the module now handles large datasets more efficiently and reliably.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118008
This update resolves an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key data fields like 'Folio' and 'Serie'. Swapping these values ensures the documents comply with Mexican regulations and prevents generation of invalid invoices. This change does not impact existing, valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738 Forward-Port-Of: odoo/enterprise#116955
This update ensures that service sales from European companies to Northern Ireland are correctly excluded from the EC Sales List report. This change aligns with regulations and accurately reflects sales transactions. The update was specifically developed for the Belgium localization to accommodate the handling of tax tags instead of taxes.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
4 changes
Resolved issues and error corrections
This update fixes a technical issue in the Gantt view that prevented users from correctly filtering work orders when grouping by work centers. The fix ensures consistent functionality and prevents errors related to incorrect data interpretation, improving the overall planning process.
Original PR description
Before this commit: ------------------------- - When planning work orders in the Gantt view, applying a Group By on Work Center and then adding another grouping (e.g., Manufacturing Order or Status)…
Before this commit: ------------------------- - When planning work orders in the Gantt view, applying a Group By on Work Center and then adding another grouping (e.g., Manufacturing Order or Status) caused a traceback when clicking grouped rows in the panel. Steps to reproduce: ------------------------- 1. Install the `mrp_workorder` module. 2. Create and plan a Manufacturing Order. 3. Open the Planning Gantt view 4. Apply Group By → Work Center. 5. Add another group by (e.g., Manufacturing Order or Status) 6. Click on one of the groups (MO or Status) in the side panel. Cause of the issue: ------------------------- - Rows grouped by Work Center -> Manufacturing Order attempted to access a Work Center record that does not exist, leading to the error: `TypeError: Cannot read properties of undefined (reading 'display_name')` - Rows grouped by Work Center -> Status incorrectly treated the status value as a Work Center ID, leading to the error: `psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer` After this commit: ----------------------- - Rows created directly from the Work Center grouping are now correctly linked using their corresponding `workcenterIds` and remain clickable. - Rows created by additional groupings after Work Center (e.g., Manufacturing Order or Status) are no longer clickable. - This ensures a consistent interaction flow in the Gantt view and prevents the previous errors during filtering. Task ID: 6132396 Forward-Port-Of: odoo/enterprise#114565
This update fixes an issue where WhatsApp channel avatars were incorrectly displaying the default Discuss avatar after a member was added. Now, avatars are correctly pulled from the channel's WhatsApp member, ensuring accurate representation and a better user experience for WhatsApp channel communication. This improves the visual consistency and reliability of the WhatsApp sidebar.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#118012 Forward-Port-Of: odoo/enterprise#115745
A test was failing related to employee departures within the ESG HR module. This change corrected the test by ensuring that departures are only processed for employees with active contracts, aligning with business requirements. This resolves a technical issue preventing accurate reporting.
Original PR description
This test was failing due to the new changes at https://github.com/odoo/odoo/pull/264906 Departures can not be on an employee without a contract, hence the change from employee 3 (without a contract) to employee 1 (with a contract) in the test. task-6223154
This update resolves an issue preventing employers from correctly managing multiple MPF accounts linked to the same registration number. The change relaxes a previous restriction, allowing valid multi-account configurations while still ensuring uniqueness based on the combination of registration and account numbers. This improves data accuracy for Hong Kong payroll.
Original PR description
An employer can legitimately hold multiple employer account numbers under the same MPF registration number. The previous constraint rejected any two MPF schemes sharing the same registration number, blocking valid multi-account configurations. Fix the validation to only restrict the duplicate based on the combination of registration number and employer account number. task-6232561 Forward-Port-Of: odoo/enterprise#118109
3 changes
Resolved issues and error corrections
This update corrects a technical issue that could cause errors in the generation of payroll reports (DMFA). By adding a validation check to ensure only numerical characters are used, the system now reliably produces these reports without interruption. This ensures accurate and consistent payroll reporting.
Original PR description
Added a validation error in the _get_code function in case the code contains non-numerical characters. This prevents non-numerical characters input from breaking the DMFA report PDF generation. Task: 6231125
A bug was preventing users from confirming shipments when the destination province was outside of the supported areas (USA, Canada, and Vietnam). This update ensures that UPS province codes are limited to a maximum of 5 characters, aligning with the UPS API requirements and preventing errors during shipment validation.
Original PR description
Issue ----- Users cannot confirm shipments depending on the destination's province. Steps to reproduce ----- - Set up UPS - Create a contact in Philipines - Province: Cebu - Create a delivery - Validate the delivery > Error message Cause ----- Codes can only be 5 characters long, as per the API https://developer.ups.com/tag/Shipping?loc=en_US#operation/Shipment According to the doc, the field is only useful for USA, Canada and Vietnam. ----- Ticket: opw-6149404
This update optimizes how Odoo tracks subscription usage, leading to faster reporting and a smoother experience for users managing subscriptions. The change addresses a performance issue related to query counts, ensuring the system remains responsive even with a large number of subscriptions. This improvement focuses on internal system efficiency.
Original PR description
runbot-163667 Forward-Port-Of: odoo/enterprise#117266
8 changes
Resolved issues and error corrections
This update resolves a bug where double-clicking an image in the Media Dialog triggered multiple actions, leading to performance issues. A simple flag has been added to ensure that the media flow is only processed once during a single click event, improving the user experience.
Original PR description
Before this commit: When double-clicking an image in the Media Dialog, the onClickAttachment method was executed twice, causing the media flow to be processed multiple times. After this commit: The issue is fixed using a boolean flag: isProcessingClick. Initially, the flag is set to false. When the first click starts, it is updated to true. If another click occurs during the same flow (e.g during a double click), isProcessingClick is already true, so the function immediately returns and prevents the action from being executed multiple times. task-6033320
This update resolves an issue where error handling for API responses was failing due to inconsistencies in how the Requests library parses JSON data. By adjusting the error handling, the system now reliably catches and manages potential JSON parsing errors, ensuring smoother operation of Odoo's integrations.
Original PR description
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349 Forward-Port-Of: odoo/odoo#264303
This update fixes a visual issue in the project Kanban view where status colors weren't rendering correctly due to a mismatch between the frontend and stylesheet. The fix ensures that project updates are displayed with the intended color codes, improving the user experience.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106 Forward-Port-Of: odoo/odoo#256023
This update fixes a technical issue where Odoo experienced errors during Google Calendar synchronization when recurring events were modified with new attendees or start time changes. The fix prevents silent errors from appearing in server logs, ensuring smoother and more reliable synchronization of events between Odoo and Google Calendar. This improves the overall stability of the integration.
Original PR description
When a recurrence is updated in Google Calendar simultaneously with a new attendee and a changed start time, Odoo silently logs MissingError during the post-commit Google API callback Steps to reproduce: 1. Have a recurring event already synced between Odoo and Google Calendar 2. In Google Calendar, open the recurrence and edit "all events": - Add a new attendee - Change the start time 3. Trigger a Google Calendar sync 4. MissingError exceptions appear in server logs, one per event in the recurrence opw-6024835 Forward-Port-Of: odoo/odoo#265247
This update resolves an issue where foreign currency amounts in reports (Partner Ledger, General Ledger) weren't consistently displaying the currency code in the exported XLSX files. The fix ensures the 'Currency Code' column is always included after the 'amount_currency' column, regardless of the report generation method, improving report accuracy and clarity.
Original PR description
Step to reproduce: 1. Generate an invoice with a foreign currency (different from the company currency) 2. Go to ‘Partner Ledger’ or ‘General Ledger’ 3. Export the XLSX The bug happens because in the function _add_xlsx_currency_codes_columns we did not take into account dynamic lines. With this fix, a column ‘Currency Code’ will be added after the column ‘amount_currency’ if such column exists in the report, no matter the engine used to create the lines. opw-6150600
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a node (like a table), the cursor automatically adjusts to the start of the moved content, preserving selections within the moved node. This ensures a smoother and more intuitive editing experience.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the default URL code for new languages didn't always align with existing configurations, causing errors during database upgrades. The fix ensures that if an ISO code conflicts with a pre-defined URL code, the system now uses the language's 'code' field as the default, preventing these errors and maintaining proper language setup.
Original PR description
Steps to reproduce the issue: 1. Create a fresh DB 2. Remove the language `base.lang_es` 3. Upgrade the `base` module This would throw an error because, when recreating the record, the default value for the `url_code` field is [taken from the `iso_code` field], which is `es` in this case. However, the `es` url_code is the value defined for `base.lang_es419` [here]. Proposed fix: When creating a new language, check if the `iso_code` would create a conflict with an existing `url_code`. If so, use the `code` field as default. [taken from the `iso_code` field]: https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/odoo/addons/base/models/res_lang.py#L337-342 [here]: https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/odoo/addons/base/data/res_lang_data.xml#L3
This update resolves inconsistencies in HTML parsing caused by recent updates to libxml2 and lxml. Specifically, it ensures consistent HTML output across different versions, improving the reliability of how Odoo renders web pages. This change also enhances error handling for type checking related to lxml and libxml2.
Original PR description
## [FIX] core: lxml compatibility v2.14.0+ (HTML parsing) In version 2.14.0, libxml2 fixed a long standing quirk in its HTML handling where it always implies `<p>` start tags [1]. As a result, there…
## [FIX] core: lxml compatibility v2.14.0+ (HTML parsing) In version 2.14.0, libxml2 fixed a long standing quirk in its HTML handling where it always implies `<p>` start tags [1]. As a result, there is a difference in behavior between pre and post 2.14.0 produced HTML when no start tag is provided: - pre: always has a `<p>` tag - post: depending on the case, could have either a `<span>` or `<p>` tag. This commit introduces a monkeypatch of the lxml's HTML parser when built with libxml2 2.14.0+ to maintain a similar behavior with older versions. [1]: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8cf6129bbd836e666e7eda8c9e61c00387ae388b ## [FIX] base,l10n_it_edi: catch TypeError/ValueError for lxml 6+ compat Updates exception handling to account for stricter type checking introduced in lxml 5/6 and libxml2 2.12+. Note: Ubuntu 26.04 (Resolute) provides lxml 6.9.2/libxml2 2.15 while Debian Trixie has lxml 5.4.0/libxml2 2.9.14. Don't be fooled by the version `2.12.7+dfsg+really2.9.14-2.1+deb13u1` which actually means that Debian has reverted/held back the core engine to 2.9.14 while adding commits from 2.12.7. Forward-Port-Of: odoo/odoo#259348
1 change
Resolved issues and error corrections
This update resolves a minor typo in the name of the Sendcloud website delivery module. The incorrect display name ('Sendcould') has been corrected to the accurate 'Sendcloud'. This ensures consistent and correct module identification within the Odoo Enterprise system.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003