Wednesday, June 17, 2026
31 changes · saas-19.2
Enhancements to existing features
This update introduces a new automated process that runs every Sunday to reset configuration settings related to development tools (devtools). This ensures that features disabled for production are automatically re-enabled at the start of the week, streamlining the update process. It's a routine maintenance task.
Original PR description
We add a new cron to re enable disabled features by unsetting devtools keys in configuration. This cron is meant to run every sunday at the end of the day, right before the monday update.
Resolved issues and error corrections
This update fixes a visual issue where portal cards on the customer portal lacked a background color. The problem was caused by an initial setting of 'null' for the card's color, which prevented styling. Now, all portal cards will display with a default background color, improving the overall user experience.
Original PR description
Steps to reproduce: 1. Go to the "/my" or "/my/home" page. Issues: Portal cards do not have a background color by default. Cause: The `portal-card` color variable was initialized with a `null` value, preventing any default background color from being applied to portal cards. task-6250258 Forward-Port-Of: odoo/odoo#269574
Code cleanup and technical improvements
This update streamlines the account module's code by creating reusable JavaScript classes and removing unnecessary conditional statements. These changes enhance the system's efficiency and stability, ensuring consistent behavior across different account processes.
Original PR description
Made some generic JS classes that can be used between account move and account bank statement and removed some if statements that are no longer needed from account_tree controller because they were used to bypass default behavior if used by a model other than the intended one. This issue was fixed in: https://github.com/odoo/enterprise/pull/117476 task-5892419 Forward-Port-Of: odoo/odoo#264775
This update resolves an issue where the Mail Composer would fail when sending emails with a large number of leads (over 500) selected. The fix prevents a technical error related to data processing, ensuring the Mail Composer functions correctly regardless of the number of records being addressed. This improves stability and usability for users managing large customer lists.
Original PR description
Steps to reproduce: 1. Install `crm` 2. Create leads more than 500. 3. Select all and try to send email 4. Not close the wizard by "X" Issue: - Traceback occurs: `Uncaught Promise > Unexpected end of JSON input` Cause: - res_ids is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of `active_ids` exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails while dismissing the wizard at `onCloseWizardModal` Solution: - Fallback to context.active_ids when res_ids is not available opw-5891862 Forward-Port-Of: odoo/odoo#252670 Forward-Port-Of: odoo/odoo#248406
This update resolves an issue where users without accounting permissions would encounter an error when duplicating Manufacturing Orders. The fix prevents the duplication of related accounting data, ensuring a smoother workflow for all users. It addresses a technical detail related to access controls within the Odoo system.
Original PR description
Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised. ## Steps to produce: - Install Manufacturing and Accounting with…
Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised. ## Steps to produce: - Install Manufacturing and Accounting with demo data. - Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing - Login as Marc Demo - Create an MO and try to duplicate it. ## Observed Behavior: An Access Error is displayed saying failed to read mrp.production.wip_move_ids ## Root cause: After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised during record duplication. During duplication, `copy_data` is called, and the error occurs when invoking the super method at [2], because the user does not have read access to the `wip_move_ids` field on account.move. **Why does this error not occur in 19.3+?** Commit [3] prevents the `wip_move_ids` field from being copied, which avoids triggering the access check and therefore prevents this error. [2]- https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1135-L1137 ## Solution: Prevent copying the `wip_move_ids` fields because, as noted in commit [3], it does not make sense to carry over work-in-progress journal entries from a previous Manufacturing Order to a newly duplicated one. WIP entries represent accounting values for partially completed goods tied to the original Manufacturing Order, so duplicating those links is both functionally incorrect and can trigger the access error described above. [1]: https://github.com/odoo/odoo/pull/217277 [3]: https://github.com/odoo/odoo/pull/251731/changes/27b5d5551cc772f238695768478a448da75cac61 Related enterprise PR: https://github.com/odoo/enterprise/pull/118950 opw-6204049 Forward-Port-Of: odoo/odoo#264925
This update corrects a technical issue where removing a subformula in the Swiss reporting module (l10n_ch_reports) didn't properly reset its value. This prevented errors when processing financial records. The fix ensures subformula values are set to False, resolving the problem and maintaining accurate reporting.
Original PR description
The subformula was [removed](https://github.com/odoo/enterprise/pull/117601) without resetting its value to False, leaving existing values in the database. This causes errors when processing records that still contain a subformula value. ```.py Invalid subformula in expression "balance" of line "Treasury shares": -sum ``` To prevent these errors, existing subformula values are reset to False opw-6297901 Forward-Port-Of: odoo/enterprise#120663
This update fixes a potential instability issue in the French PDP registration process. By moving a key function to the company record, the system now reliably accesses the necessary data, preventing errors that could occur if the temporary registration model was deleted. This ensures a more stable and dependable registration experience.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270382 Forward-Port-Of: odoo/odoo#270345
This update fixes an error in the VAT balance calculation within the l10n_uy module for Uruguay. The previous formula was inaccurate, leading to incorrect reporting. This change ensures accurate VAT reporting, aligning with local tax regulations and improving financial data reliability.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_uy 2. Go to tax report and see the formula of the VAT balance that is incorrect ### Reason to introduce the fix: Correct the formula to display the right amount. opw-6261211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269376 Forward-Port-Of: odoo/odoo#268478
A recent upgrade process caused an error when users accessed the partner page after updating to version 19.2. This was due to a change in how website templates handle titles. This fix ensures the website remains accessible after upgrades by preserving the necessary configuration elements.
Original PR description
**Issue:** Currently, an error occurs when users access the `/partners` website page after upgrading a database with the `website_crm_partner_assign` module (including demo data) to saas-19.2. **Root…
**Issue:**
Currently, an error occurs when users access the `/partners` website page
after upgrading a database with the `website_crm_partner_assign`
module (including demo data) to saas-19.2.
**Root cause:**
This issue occurs because recent changes introduced in PR [1] added a
new template as id `index_layout`. Inside this template, a `t-call` element
was using a nested `t-set` element to define `additional_title`. We were
referencing this `t-set` element in the XPath of the `index` template to
override the value of `additional_title`.
However, recent changes removed the `t-set` from the `t-call` and replaced
it with a direct variable assignment inside the `t-call`. During the upgrade,
the migration script automatically moves the `additional_title` attribute
into `t-call` and removes the `t-set` from the `t-call` (see the script and
related changes in [2]).
As a result, the XPath expression that targets the `t-set` element fails
because the referenced element no longer exists, which causes the error.
**Solution:**
This commit fixes the issue by moving the `t-set` element outside the `t-call`
and passing its value as an attribute of the `t-call` during the upgrade.
The `t-set` element is preserved to maintain compatibility with custom `XPath`
expressions that may target it, prenet XPath target errors after the upgrade.
The upgrade-specific behavior is enabled only when `config.get('upgrade_path')`
is set, allowing the code to detect that it is running in an upgrade context.
[1]: https://github.com/odoo/odoo/commit/711c3baad58f3e0f1dc39cb90eb8176aba91e9dd
[2]: https://github.com/odoo/odoo/pull/235469/changes#diff-29ae6f0bcf846a2fcaffc38fdd0d3b19ea328c133ff4dfe18cc9725715f34dd9
Sentry-7400315548This update fixes an issue where order-level customer notes weren't appearing on preparation tickets. The fix ensures that these notes are now printed, improving communication between the front-of-house and kitchen staff. It also prevents unnecessary tickets from being generated when order notes are updated.
Original PR description
Steps to Reproduce: - Open Restaurant POS configured with a preparation printer. - Create a new order and add a customer note at the order level. - Send the order for preparation. Issue: - The order-level customer note is not printed on the preparation ticket. Fix: - Ensure the customer note is included in the preparation ticket. - Prevent additional preparation tickets from being printed when the customer note (or internal note) is modified alongside order lines. Task-5960046
This update fixes an issue where tags and input fields in the Select Menu were overlapping, particularly when multiple selections were made. Now, tags and the input field are always displayed on separate lines, improving the user experience and ensuring the Select Menu takes up the correct amount of space.
Original PR description
Before: With multiSelect enabled, tags appear on the same line as the input, shrinking it. After multiple selections, the input wraps to the next line inconsistently. After: Tags and the input are always on separate lines. task-5226503 Forward-Port-Of: odoo/odoo#269497
This update fixes an issue where long text labels in SelectMenu multi-select tags would overflow, creating a poor user experience. Now, tags are automatically truncated to fit, aligning with how Many2ManyTags display, ensuring consistent and readable selection options.
Original PR description
Before: Tags in SelectMenu (multi-select) had no text-overflow handling. After: Tags now truncate text, consistent with Many2ManyTags behavior. task-5226503 Forward-Port-Of: odoo/odoo#269563
This update fixes a minor visual issue in the Web Studio interface. Previously, property tags within SelectMenu widgets were constrained to a limited width, leading to unused space. Now, tags automatically expand to fill the available width, creating a cleaner and more user-friendly experience.
Original PR description
Before: Each tag was limited to 200px, leaving available space unused. After: Each tag now expands to 100% of the available width. task-5226503 Forward-Port-Of: odoo/enterprise#120260
This update corrects a bug where selection fields within Odoo's Studio were incorrectly treated as required. The fix ensures that selection fields are only required when explicitly marked as such, improving usability and preventing accidental data entry errors. This change enhances the overall Studio experience for business users.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503 Forward-Port-Of: odoo/enterprise#120037
This update resolves an issue that caused a traceback when users deleted the last column from a table within the Odoo Report Editor. The fix prevents a technical error by ensuring the editor handles the scenario where a table has no remaining columns gracefully. This improves the overall stability and reliability of the report design process.
Original PR description
Problem: When deleting the last column in a table in studio we get a traceback. Cause: `firstCell` will be null if we delete the last cell in the table. Fix: Added a null check on `firstCell` before calling `setCursorEnd`, so the cursor is only repositioned when the table still has remaining cells. Steps to reproduce: - Edit a report with a table. - Remove all columns. - Traceback will occur when deleting the last one. opw-6263696 Forward-Port-Of: odoo/enterprise#119502
This update fixes an issue where Odoo cron workers weren't efficiently managing memory usage. By introducing a new configuration option, `ODOO_REGISTRY_LRU_SIZE_CRON`, we can now set a lower memory limit specifically for cron workers, preventing excessive registry cycling and optimizing performance. This ensures smoother operation for background tasks.
Original PR description
The configuration option `registry_lru_size` does not exist and does not work at all in recent versions. Defining odoo-specific environment variables to handle: - ODOO_REGISTRY_LRU_SIZE: the default registries size - ODOO_REGISTRY_LRU_SIZE_CRON: overwrite for cron workers Cron workers have often a different workload than HTTP workers and we may set a different limit there. If the limit is lower than the number of databases, a cron job will not reuse registries because it cycles through all known ones - in such cases, we can set a lower limit to keep the memory lower. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270069 Forward-Port-Of: odoo/odoo#268587
This update simplifies accessing employee profiles from the avatar card. Previously, a confirmation dialog forced users to activate inactive companies. Now, a 'View Profile' dropdown offers two options: directly opening the employee profile (activating the company) or accessing the contact profile without company activation. This provides a smoother user experience.
Original PR description
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the…
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the other company or cancel, with no way to reach the still-accessible contact profile. Replace the dialog with a less intrusive "View Profile" dropdown, shown only when the employee's company is allowed but not active. It offers two choices: - Open Employee Profile (activates the company) - Open Contact Profile (no company activation) Activating an extra company widens the active-company scope for the whole session, which is not always desirable, so keeping a non-mutating path to the contact profile is useful. In every other case (no employee, company already active, or company not allowed) the plain "View Profile" button is unchanged. task-6074597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270312 Forward-Port-Of: odoo/odoo#264073
This update prevents users who aren't designated approvers from directly accepting or rejecting approval requests through the activity interface. Previously, this caused errors when non-approvers attempted to interact with approval activities. This change improves system stability and ensures users only have access to actions relevant to their role.
Original PR description
Currently when a user submits an approval request, an activity is created for the approver who can validate or refuse the request directly from the activity, however these options are also visible to other users who will trigger an error if interacting with the options. This commit removes these options for users who are not the approver. **Steps to reproduce:** - Log in as admin - Go to approvals - Select dropdown menu of General Approval and Edit - Change documents to optionnal - Make sure admin is in the approvers list - Log in as demo - Go to approvals -> General Approval -> New Request - Submit the request - You'll see an activity be created for admin, with Accept and Refuse options - If you select any of these options you will get an access error opw-5423528 Forward-Port-Of: odoo/enterprise#120643 Forward-Port-Of: odoo/enterprise#109047
This update fixes a display issue where overtime details weren't showing correctly for employee attendance records. The team reversed a condition in the system's settings, ensuring that overtime information is now accurately presented for all attendance records, regardless of whether an employee has overtime rules configured.
Original PR description
Steps: * Create an extra-hours attendance for an employee that has overtime ruleset OR * Create an extra-hours attendance for an employee that has no overtime ruleset Issue: * The overtime details in the attendance view visibility condition was flipped Solution: * Reverse the visibility condition of the XML element Task: 6295710 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#269918 Forward-Port-Of: odoo/odoo#269744
This update resolves an issue preventing live chat visitors on mobile from adding emojis to their messages. The fix utilizes a technical solution to correctly identify clicks within the emoji picker, ensuring emojis are properly inserted into the composer. This improvement enhances the user experience for mobile live chat users.
Original PR description
Before this commit, livechat visitors couldn't use the "Add emojis" feature in composer when in mobile: this was opening the emoji picker, but when selecting an emoji this wouldn't add the emoji to the composer text. This happens because the livechat is inside a shadow DOM, and `ev.target` maps to livechat root rather than the specific click inside the emoji picker of livechat. This commit fixes the issue by using `ev.composedPath`, which goes through any open shadow DOM to find the most specific targets. The livechat is an open shadow DOM, thus this works like `ev.target` when there's no shadow DOM into play. This commit is also a follow-up of [1] where the file viewer was shown twice in website due to an accidental regression with fixing overlays: emoji picker was not working in desktop too, therefore the test also covers issues with the overlay like in [1]. [1]: https://github.com/odoo/odoo/pull/265603 Forward-Port-Of: odoo/odoo#267795
This update resolves an issue where errors during the forced payment process for cash drops would display confusing tracebacks to users. Now, errors are silently handled, preventing disruption. Additionally, a timeout has been added to Cashdro requests to quickly identify and address issues caused by incorrect IP addresses.
Original PR description
In odoo/odoo#268496, a fallback was added to automatically cancel the payment when forcing it, to avoid the cash machine getting stuck with a payment in progress. However, if an error occurs with this cancel request, it causes a traceback to appear. In this commit, we now catch the error from the cancellation, and don't show it to the user at all since they have already force completed the payment. We also add a timeout to Cashdro requests to fail faster when using a wrong IP (e.g. 1.2.3.4). task-6307491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270339
This update resolves a crash that occurred when adding reactions to messages on smaller screens. The fix ensures the correct data is passed to the reaction component, preventing errors and improving the user experience across different screen sizes. This enhancement ensures consistent functionality for all users.
Original PR description
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash: ``` Cannot destructure property…
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:
```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
at Proxy.onSelected
```
This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.
This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.
[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84
Forward-Port-Of: odoo/odoo#270158This update fixes an issue where capitalized email domains in alias settings caused emails to be misrouted. The change prevents users from saving capitalized domain names, ensuring emails are correctly delivered. This resolves a technical problem that could impact email delivery reliability.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257792This update fixes a technical issue that prevented users from accessing the Time Off feature on mobile devices when logged in with specific user permissions. The fix ensures the system consistently returns expected data, preventing a traceback and improving the user experience. This resolves a minor bug impacting mobile users.
Original PR description
Steps to reproduce: 1. Access the database from a mobile device (or a small browser window) 2. Sign in as a user who has access to the Time Off module, but doesn't have an employee record 3. Open Time Off 4. Observe the traceback When we try to access Time Off with a user who has no employee record, we get a traceback due to receiving an empty dictionary from the backend. The error occurs because we try to iterate over this dictionary, even though we normally expect an array from the request we make. This commit will ensure we always return an array to the frontend, preventing the error. [opw-6295568](https://www.odoo.com/odoo/project/49/tasks/6295568?debug=assets)
This update fixes several visual issues within the spreadsheet component for the 19.2 release. Specifically, it addresses problems with dark mode display, tooltip readability, and the appearance of pivot table icons. These changes improve the user experience and ensure consistent functionality across different themes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c5c6fd3c81 [REL] 19.2.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c5c6fd3c81 [REL] 19.2.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e8f060e58e [FIX] Headers overlay: unhide headers in dark mode [Task: 6233467](https://www.odoo.com/odoo/2328/tasks/6233467) https://github.com/odoo/o-spreadsheet/commit/0de087b7be [FIX] autofill: make tooltip readable in dark mode [Task: 6289977](https://www.odoo.com/odoo/2328/tasks/6289977) https://github.com/odoo/o-spreadsheet/commit/bb6868a517 [FIX] pivot: hide collapse icon when displaying formulas [Task: 6218524](https://www.odoo.com/odoo/2328/tasks/6218524) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where the website's recruitment search function couldn't find refused applicants. The previous change restricted searches to active refused applications, but refused applications are automatically archived. This fix ensures that refused applicants are now correctly searchable.
Original PR description
Searching on `[("application_status", "=", "refused")]` is always empty. It is an overlook from [odoo/206645] ([b6e4817]), where the `_search` query was changed to search only active refused applications. However, refused applications are always archived.
This was breaking `website_hr_recruitment` which was searching for refused applications, without finding any.
[odoo/206645]: https://github.com/odoo/odoo/pull/206645
[b6e4817]: https://github.com/odoo/odoo/commit/b6e48176219b2b123bcbf0353b8586c888fc6a94
opw-6204868
Forward-Port-Of: odoo/odoo#266370This update resolves an issue where multiple Oboxes connected to a database wouldn't all display a green Websocket status in the Kanban view. Now, all connected Oboxes show the correct status, ensuring accurate monitoring of Obox connectivity. This improves the reliability of Obox data visibility.
Original PR description
Before this commit, if you had multiple Oboxes connected to a DB, and you looked at them in the Kanban view, only 1 Obox would show a green status for Websocket, despite all of them being connected. After this commit, the Websocket status for each Obox is green as expected. Forward-Port-Of: odoo/enterprise#120828
This update fixes a discrepancy in the start dates of semi-monthly payrolls. Previously, payslips were incorrectly aligned with the month's halves, leading to inaccurate reporting. The change now ensures payslips begin on the 16th of the month, accurately reflecting the payroll schedule.
Original PR description
Issue: ---------------------------------------- The start date of semi-monthly payslips on second half of the month is the 15 which is also the end date of the first half of the month. Steps to reproduce: ---------------------------------------- - Have an employee with a semi-monthly payroll - When in the first half of the month, create a payslip for this employee - The payslip is from 1st to 15th - Do the same when in the second half of the month - The payslip is from 15th to end of the month Cause: ---------------------------------------- In `_schedule_period_start()` we set the start date to th 15th for semi-monthly payslips. Solution: ---------------------------------------- Set it to the 16th. opw-6281556 Forward-Port-Of: odoo/enterprise#120172
This update ensures that message links in the Odoo portal chatter remain formatted and visually appealing after a page refresh. Previously, a refresh would remove the prettified link. The fix addresses an issue where the system wasn't correctly sending the message thread's display name, which is necessary for generating the formatted link.
Original PR description
Before this commit, a message link posted on a portal chatter would lose it's prettified link (introduced in [1]) upon page refresh. This happens because `prepareMessageBody` needs the thread's `displayName` to create the prettified message link, which is not sent on portal chatter init. This commit fixes the issue by sending the thread's `display_name`. [1] https://github.com/odoo/odoo/pull/221069 task-6204819 Forward-Port-Of: odoo/odoo#269126 Forward-Port-Of: odoo/odoo#263488
This update ensures that the Intermediary SWIFT field remains visible in US company bank accounts, regardless of the selected country. Previously, the field was hidden when the US fiscal localization package wasn't active. This change improves data accuracy and simplifies bank account setup for US businesses.
Original PR description
**Steps to reproduce:** - Install the `l10n_us_account` module and switch to a My US company - Navigate to Invoicing > Configuration > Journals > Bank - Click the internal link of the `Bank Account Number` - Go to the `Bank Information` tab - Observe that the `Intermediary SWIFT` field is visible - Remove `United States` from the bank address **Observation:** The `Intermediary SWIFT` field becomes `invisible` when the country is not set to `United States`. **Root Cause:** At [1], the field Intermediary SWIFT( `intermediary_bank_bic`) is defined with a condition that makes it invisible when the country is not 'US'. **Fix:** This commit ensures that the `Intermediary SWIFT` field remains visible when the company uses the US fiscal localization package, even if the bank country is not set to United States. [1]: https://github.com/odoo/odoo/blob/1d4715e58613912bfd0ded4fd370c50c131ff164/addons/l10n_us_account/views/res_partner_bank_views.xml#L9 opw-6145872
This update streamlines the bank statement import process by replacing a duplicated controller with a more efficient, generic version. Removing unnecessary code from the import module ensures accurate data processing and avoids potential conflicts with other Odoo modules, leading to a more stable and reliable import experience.
Original PR description
account_bank_statement_import_view was using the same controller used in account.move which caused some wrong behavior when some logic isn't shared between both modules, now account_bank_statement_import uses a generic controller that doesn't add unneeded behavior. As well as removing all of the account move classes from bank statement import and using generic ones or ones specific to account bank statement import. task-5892419 Forward-Port-Of: odoo/enterprise#117476