Tuesday, May 26, 2026
36 changes · saas-19.2
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] ```
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 is a technical fix to improve the efficiency of a core business function.
Original PR description
runbot-163667 Forward-Port-Of: odoo/enterprise#117266
This update resolves an issue where tooltips within the HTML editor were not being translated. The fix moves a key translation call outside the template literal, allowing the exporter to recognize and translate the text. This ensures all tooltips display the correct localized versions.
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 inconsistencies in how Odoo handles HTML parsing, specifically related to older versions of libxml2. The changes ensure consistent HTML output across different versions, improving the reliability of email templates and reports. This fix also addresses stricter type checking introduced in newer lxml versions.
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
This update corrects a display issue where invoices were showing extra decimal places (e.g., 528,000,000.000001). The fix reduces unnecessary precision calculations during invoice printing, ensuring accurate formatting and presentation of monetary values.
Original PR description
Issue: - Create an invoice with a line having a price of `528,000,000.00` - Print the invoice -> pdf displays `528,000,000.000001` Cause: In `value_to_html` from `ir.qweb.field.float`, we compute the maximum precision that we can get from the value, to avoid parasite digits. The maximum is 15, so if a number has 11 digits, we won't ask for a precision higher than 4. But in `float_round`, they multiple the value with its precision, then add `epsilon` (a small value). So we're now working with a 16 digits float, which is what we want to avoid. Solution: Reduce the maximum precision from one digit before calling `float_round`. opw-6012129 Forward-Port-Of: odoo/odoo#265696 Forward-Port-Of: odoo/odoo#260955
This update fixes an issue where portal messages were incorrectly restricted, preventing certain message types from being visible to users. The change expands the visibility of non-internal messages while still hiding internal notes as intended. This ensures a more complete and accurate view of portal communications.
Original PR description
*: test_mail_full Since #138233, portal messages were strictly filtered by the `mt_comment` subtype. This was intended to hide internal notes, but it incorrectly excluded other non-internal message subtypes. Basically we want the share domain (`_get_search_domain_share()`) to apply to all users in the portal. This change ensures internal notes remain hidden while allowing all other non-internal non-comment subtypes to be visible. opw-6031571 Forward-Port-Of: odoo/odoo#264431 Forward-Port-Of: odoo/odoo#263052
This update ensures compatibility with older Odoo databases (v19.0) by correctly including an 'owner' key in event notifications. Additionally, the system now properly manages session data, removing outdated sessions to improve performance. This resolves a potential issue with data integrity and system efficiency.
Original PR description
For compatibility with v19.0 db, we need to keep the owner key in lp events. We do have them in the action direct response thanks to the `handle_message` base response message, but this is not forwarded to the event route. We also take the opportunity to fix the session cleaning, which was keeping only old sessions instead of newer ones.
This update fixes an issue where long task names in the Odoo Calendar's 'to schedule' side panel would overflow, making it difficult to read. Now, task names are automatically truncated with an ellipsis when they are too long, ensuring a cleaner and more user-friendly experience. This improves usability and readability of the calendar.
Original PR description
**Before this commit:** Task names in the "to schedule" side panel of the Calendar view were not truncated, causing them to overflow their container when the name was too long. **After this commit:** Task names in the "to schedule" side panel are now properly truncated with an ellipsis when they exceed the available width. task-6237072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the process of adding bank journals in Odoo. Previously, a bank account number was always required via the Odoofin iframe. Now, the system handles missing account numbers more gracefully, creating the journal directly if sufficient data is provided. This change improves user experience and reduces friction when setting up bank accounts.
Original PR description
Previously, when adding a bank journal via the Odoofin iframe, the bank account number was strictly required. Starting from version 19.2, bank journals can no longer be created from the standard form view. This change forces users to provide an account number immediately via the iframe, even if they intended to synchronize it later. While the form view restriction is a 19.2 change, this improvement is applied to 17.0 because the Odoofin iframe is shared across versions. This is resolved across both environments with the: - Odoofin commit: The account number requirement is removed from the iframe. - Enterprise commit: If the account number is missing, the system no longer returns a setup wizard. It creates the bank directly if all required data is available; otherwise, it creates the journal without an account number. task-6072798 OdooFin PR: https://github.com/odoo/odoofin/pull/539
This update fixes a limitation in the stock delivery process. Previously, when shipping consumables internationally, users couldn't easily record the required HS code. This change now displays the HS code field only when tracking and lot/serial settings are enabled, ensuring compliance for international shipments.
Original PR description
Commit 20c3aa9b618b3 moved the fields `hs_code` and `country_of_origin` to a view block only visible if Lots/Serial setting is activated and if the product is tracked (is_storable=True). This is an issue as we may want to delivery a consumable abroad. An HS code may be required but there is no possibility to fill it. 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#266371
This update resolves an issue where generating a lot in a manufacturing order would incorrectly reset the 'quantity to produce' field to zero. The fix ensures the quantity is saved before lot generation, preventing this unexpected reset and maintaining accurate production tracking. This improves the reliability of the manufacturing process.
Original PR description
Step to reproduce: - Create a MO with a lot tracked product (enable it in settings) and a work center - Put the quantity to produce to more than 1 - Confirm the MO - Use the smart button to go to the Shop floor - Click on the three dots and click on "Register production / serial" - Put the quantity to produce to 1 and click on "Generate lot" - The quantity to produce is updated to 0, which is not correct, it should stay to 1 Cause: The quantity to produce was not saved before generating the lot, so after the reload triggered by the generation of the lot, the quantity to produce was reset to the last saved value, which is 0. Task-6158833 Forward-Port-Of: odoo/enterprise#117067
This update fixes an issue where address autocomplete wasn't working correctly for countries using an extended address format. The change ensures the system correctly identifies and uses the appropriate city information, resulting in more accurate and reliable address suggestions.
Original PR description
Some countries uses the extended version of address, which in particular uses a model to store city information instead of a simple char. In that case, the autocomplete does not work properly as it will try to set that char "city" instead of the Many2one "city_id". task-4588240 Forward-Port-Of: odoo/odoo#265060
This update resolves an issue where report totals were incorrectly duplicated in headers when comparison mode was enabled and totals were displayed. Now, values appear only in the line item when the section is expanded, ensuring a cleaner and more accurate report view for users.
Original PR description
Right now when you expland a section in comparison mode like in the Balance Sheet and P&L, if "Add total below sections" is enabled in the report then it shows in both the header and totals sections. This commit clears up that by only showing the value in the line when it's unexpanded, but once it is expanded it is hidden. task-6190986 Forward-Port-Of: odoo/enterprise#116479
A test was failing because the user account wasn't correctly configured during testing. This change ensures the test environment includes the necessary user group (`stock.group_production_lot`) to display the production lot ID, resolving the test failure and improving test reliability.
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#266320 Forward-Port-Of: odoo/odoo#266052
This update corrects a technical issue preventing invoices from being properly submitted to the Kenyan Revenue Authority (KRA) eTIMS system. The fix addresses a character limit restriction on invoice line descriptions, ensuring compliance and preventing rejection errors. This ensures accurate and timely invoice processing.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129 Forward-Port-Of: odoo/enterprise#118152
Features or functions removed from Odoo
This commit removes a plugin that was no longer needed for translating the website's table of contents. The underlying functionality is now handled automatically, improving website performance. This change ensures a cleaner codebase and reduces potential maintenance overhead.
Original PR description
The plugin `TranslateTableOfContentOptionPlugin` is not needed anymore, the replication between the headers in the content of the `s_table_of_content` and its navbar is now completely handled by the `FieldChangeReplicationPlugin` plugin since a5f1af347b55da8662d6d6802b57e14aab574d78. The test is removed because it is not representative of real edition situation (the nodes it changes are not inside `contenteditable=true` or `o_savable`), and the test added in a5f1af347b55da8662d6d6802b57e14aab574d78 covers this usecase. task-5892636 Forward-Port-Of: odoo/odoo#265951 Forward-Port-Of: odoo/odoo#264325