Monday, February 12, 2024
37 changes · 17.0
New functionality added to Odoo
The Point of Sale system now includes a new quick payment button for electronic payments and has made the electronic payment process automatic instead of requiring manual user input. This streamlines the checkout experience and reduces the steps needed to process electronic payments.
Original PR description
[ADD] pos: allow faster electronic payments - added a small button that does the same functionality we already had for electronic payments. - changed the functionality of the electronic payment button to be automatic instead of waiting for user input. TASK-ID: 2770467
Enhancements to existing features
This update improves the performance of spreadsheet dashboards by eliminating an unnecessary network request that was previously made to fetch currency information. The currency is now loaded directly with the dashboard, reducing load time and improving the overall user experience when opening dashboards with monetary amounts.
Original PR description
Most (if not all) dashboards have monetary amounts. They are formatted with the main company currency format. Before this commit, a RPC was made to fetch the company currency. With this commit, the dashboard is loaded with the currency. It saves one network request and a full spreadsheet evaluation (which would have occured after the request is done) Task: 3709466
Resolved issues and error corrections
This update resolves several operational issues, including automated rules not triggering, delivery return loops, portal search errors, and point of sale setup problems. It also improves day-to-day usability in expenses, recruitment, manufacturing, fleet, and time off by making key information clearer and easier to manage.
This update adds support for easyShip as a delivery carrier option in the Amazon sales integration. This enhancement allows businesses using Odoo to offer easyShip as a shipping method when fulfilling Amazon orders, expanding delivery options for customers and improving logistics flexibility.
Original PR description
task-3533500 Forward-Port-Of: odoo/enterprise#55990
The LinkedIn integration has been updated to use the newest LinkedIn API version (202401) to ensure continued compatibility and support. While this upgrade maintains the same functionality, it requires more API calls to fetch data since the API no longer supports batch data retrieval. This may result in slightly slower performance when syncing LinkedIn pages and comments, but ensures the system remains current with LinkedIn's latest requirements.
Original PR description
Purpose ======= On the 3 December 2023, we are using the API version 202211. However, the version 202209 is depreciated, so it might be the time to upgrade. Technical ========= The only technical change is the fact that projections are removed. Those were useful to fetch everything we needed in a single HTTP request, and so now, we have to make many HTTP requests to fetch the data (at least, one per "model"). Task-3620605 Forward-Port-Of: odoo/enterprise#56227 Forward-Port-Of: odoo/enterprise#52006
This update optimizes how the Approvals module searches for records by simplifying database queries. The change removes unnecessary steps in the search process, allowing the system to retrieve information more directly and quickly. This results in faster performance when the approval system filters and retrieves data.
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
But in the context of domain in `ir.rule` themselves, the previous concern isn't of application, as `ir.rule` are generated in a `sudo` context, therefor no `ir.rule` are applied.
## Fix
Remove the `.id` from left leafs of domains from `ir.rule`
task-3735923This update adds a safety check to prevent system crashes when invoicing subscription orders that contain recurring products without an associated subscription plan. The improvement makes the system more robust by adding defensive programming to handle edge cases gracefully.
Original PR description
…roduct and no plan We prevent creating subscription sale orders with recurring products and no recurring plans However it's better to be defensive to avoid crashes. This commit adds an additional condition before accessing order_id.plan_id closes odoo/enterprise#56160 Task: 3725476
This update improves spreadsheet performance by eliminating unnecessary network requests when displaying monetary values. The system now uses currency information that's already available in the spreadsheet configuration, rather than making extra calls to fetch it. This results in faster spreadsheet loading times and a smoother user experience.
Original PR description
Pivot/list monetary fields needs the company currency to display the value in the said currency format. Until now, a RPC was made to fetch the currency. However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785 the currency format is already in the model config. There's no need for the RPC. This saves one network request and one full spreadsheet evaluation (which would have occured after the request is done) Note: This optimization currently doesn't work for dashboards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how the HR Homeworking module searches for employee records by simplifying database queries. The change removes unnecessary steps in the search process, allowing the system to find records faster without compromising accuracy. This results in improved system responsiveness when filtering employee data.
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed. `.id`
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update improves the speed of product filtering and search operations on the website sales module by optimizing how the system retrieves product information. The change simplifies database queries to be more efficient, resulting in faster page load times and better user experience when browsing and filtering products.
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update optimizes how the system handles Luxon date and time objects by preventing unnecessary performance overhead. Luxon objects are immutable and don't change, so the system no longer wastes resources trying to track changes within them. This results in faster performance when working with dates and times throughout the application.
Original PR description
When reading values in reactive objects, Owl's reactivity system will return reactive versions of the sub-objects to allow tracking reads in depth, so that changes to values in deep object hierarchies can still cause components to render themselves if needed. Luxon objects are immutable. Since they cannot change and values inside them cannot change either, tracking reads within luxon objects is pure overhead. This commit makes luxon objects non reactifiable by setting the Symbol.toStringTag property on the luxon classes, which is what Owl uses internally to determine if objects can be made reactive. It will also cause some of these objects to serialize to more specific strings instead of just [object Object], eg [object LuxonZone]. Forward-Port-Of: odoo/odoo#153387
The automated visitor cleanup job now allows administrators to customize how it processes old visitor records, making it easier to tune performance based on their system resources. This reduces unnecessary error messages and prevents potential timeout issues that could disrupt the cleanup process.
Original PR description
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records.…
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records. However it still searches for records with no limit, which in high record count scenarios and based on instance resources may still generate memory/timeout errors. Technically it could be considered "fine" for the cron to timeout since every batch is committed, so previously unlinked records are not rolled back and the cron should eventually delete them all. However there are some edge cases where memory/time out errors would not be fine, like the cron failing during the first batch, which means no unlink operations would be committed to the database. Errors that are "fine" also generate noise and leave administrators wondering which errors they should ignore and which they should not. It also alarms non-technical customers since after all, they are seeing a reported error. Therefore the search limit and batch size have been added as arguments to the cron. This is completely opt-in since they have the previous values as their defaults. This makes it easy to customize and tune the performance of the job accordingly if required. [1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150476
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet formulas that display the selected value of a date range filter now work correctly. This helps users see active from/to date filters in exported, shared, or viewed spreadsheets without missing filter information.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inventory label printing now correctly produces separate labels for multiple units from the same lot instead of counting them only once. This helps warehouse teams print accurate barcode labels and avoids missing labels during stock operations.
Original PR description
Description of the issue/feature this PR addresses: The feature allows printing multiple labels corresponding to the quantities of inventory moves, even if they are from the same lot. This issue was that printed items were stored in an `OrderedDict` by the record ID. A quantity of the same item from the same lot will always have the same ID, therefore this item will only be counted once. This was solved by replacing the `OrderedDict` with a normal `list`.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds comprehensive test coverage to the room booking application and fixes several user-facing issues including form responsiveness, time display consistency, and booking duration updates. These improvements ensure the booking interface works reliably when multiple users interact with bookings simultaneously and displays accurate information across all views.
Original PR description
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the…
Purpose: -------- This commit adds some tests for the room application which currently has almost none. It also fixes some issues that were pointed out by writing these tests: - Fix reactivity of the booking form view: when a notification of a booking update was received during the edition of a booking, its duration was changed in the sidebar but not in this form view. - Fix luxon locale desync: since the redesign of the frontend view, the locale used when loading the existing bookings was not the same as the one used after it. - Fix current week in the form view: the week was not updated when clicking on a booking in the sidebar while already in the form view. - Fix remaining time flicker: when a booking ended, the remaining time could be minus 1 second for a split second. - Fix remaining time reactivity: when a booking started immediately after that another one ended, the remaining time shown was not updated at the same time than the sidebar and current booking title. Task-3609006
This fix resolves an issue where spreadsheet formulas couldn't properly retrieve filter values when using date range filters (from/to filters). Users can now correctly use the ODOO.FILTER.VALUE function with date range filters in their spreadsheets, improving data analysis capabilities.
Original PR description
Task: 3584650
This fix ensures that product documents attached to subscription products are now properly displayed on the customer portal when viewing confirmed subscription orders. Previously, documents that were marked as visible during confirmed orders were not showing up, which has now been corrected.
Original PR description
### Version: - 17.0 ### Steps to reproduce: - Add a document to the subscription product and make it visible during the confirmed order. - Create a new subscription quotation for that product. - Confirm the subscription quotation. - In confirmed orders, the product document will not be visible. ### Issue: The product documents are not visible on the portal template. ### Improvement: According to its visibility value, the product document will be shown on the portal template. task-3667716 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update resolves an issue where replying to tweets in Odoo was creating duplicate mentions of the original author. The mention is no longer needed for Twitter to recognize the reply, eliminating the redundant mention that appeared in Odoo's system.
Original PR description
Bug === Before, we needed to mention the author of the Tweet we are replying to, in order to make the Tweet looks like a reply on Twitter. It seems not needed anymore and cause double mention issue (only on the Odoo side, Twitter seems to show only one mention). Task-3686630
Fixed an issue where content copied using the clipboard command lost formatting (like font colors) when pasted. The fix ensures that copied content retains all its original Odoo formatting by properly marking it as Odoo content in the clipboard, so users see consistent styling when they paste copied knowledge items.
Original PR description
There was an issue with the `copy` feature of the `/clipboard` command. When
pasted, the content was formatted as if it was not originally `Odoo` content
(and some style features were removed, like the font color).
To remedy that, instead of using the `clipboard` API, the deprecated
`execCommand('copy')` function is used so that the `copy` handler of the
`OdooEditor` is properly triggered and the html content is properly set under
the `text/odoo-editor` custom "MIME type".
Remark: it is not possible use that "fake" "MIME type" to write data directly to
the clipboard because it is not officially recognized (will produce an error).
task-3700875Fixed a problem in the Spanish VAT Book (libros) export feature where tax lines appearing out of order could cause the export to fail. The code has been refactored to handle unordered lines properly and prevent similar errors in the future, making the export process more reliable.
Original PR description
Sometimes, when handling export of VAT Book (libros) by getting all the lines from the tax report, some of the line might not be ordered as expected. If a tax/surcharge line appear in the list before the base line, this will result in a KeyError when trying to access sheet_line_vals of the id because they have not been created yet. This commit aims to fix that, and also refactor this part of the code to be more clear, clean, & error-proof in the future. An handler for error in the common error place (KeyError) is also written for similar problems we might encounter in the future. task-id: 3703023
Fixed an issue where clicking on line amounts in the Spanish Tax Report (Mod 347) was showing an empty list instead of the underlying transaction details. The problem was caused by mismatched configuration keys that prevented the system from retrieving the correct transaction data for audit purposes.
Original PR description
### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * open the Tax Report * on the top right, switch the report to "Tax Report (Mod 347) (ES)" * attempt to audit any line in that report (click on the amounts) You should be met with an empty list view. ### Cause When we attempt to get the domain for the lines to display, the `MOD_347_CUSTOM_ENGINES_DOMAINS` dict keys do not match with the custom engine function name. https://github.com/odoo/enterprise/blob/61e565517cc54ee0af9ed6123d3dc23b52c52522/l10n_es_reports/models/aeat_tax_reports.py#L101-L106 opw-3697928 Forward-Port-Of: odoo/enterprise#56199 Forward-Port-Of: odoo/enterprise#56044
This update corrects the module dependencies for the Mexican EDI Stock Extended feature, which were causing installation errors. By properly configuring these dependencies, the module will now install correctly without inheritance conflicts, ensuring smooth setup for users in Mexico who need EDI compliance for stock operations.
Original PR description
The dependencies were not set properly, causing inheritance errors during installation. Forward-Port-Of: odoo/enterprise#56159
Fixed a bug in the General Ledger report that caused the system to crash when viewing invoices with multiple payments made on different dates while using the Cash Basis accounting method. The report now correctly displays all payment details without errors by using unique identifiers that include payment dates.
Original PR description
The key used was the id of the journal item, this is fine for most cases but will fail due to duplicate if the "Cash basis" function is set and a receivable aml is reconciled with two payment made at different dates. In this case the report will show the receivable aml split in two with the date/amount of each payment. To support this case, we now use a markup with the date of aml to produce unique keys. When the two payments have the same date, it's ok since the receivable aml is not split in the report. Steps to reproduce 1/ Create an invoice 2/ Register 2 payments at different dates for this invoice 3/ General ledger with options "Unfold all" + "Cash basis" => Traceback `Got duplicate key in t-foreach: ~account.account~6|~account.move.line~1128` opw-3687800 Forward-Port-Of: odoo/enterprise#55136
This update fixes a crash that occurred when exporting Studio customizations containing monetary fields. The issue was in how the system retrieved currency field information, causing incompatible data types to be combined. Now exports work correctly and properly include currency field details for monetary fields.
Original PR description
Create a monetary on a model. In studio, remove the currency_field for that field. Note that the currency field would have been create automatically since commit [1] Try to export the studio customization module. Before this commit, there was crash, because the code that retrieves the currency_field was somewhat erroneous and a recordset of ir.model.fields was joined to a recordset of ir.model. After this commit, there is no crash and we export the value for the currency_field of the monetary opw-3677016
This fix resolves an issue where filtering tasks by status in a Kanban board's progress bar was incorrectly applying filters across all newly created groups instead of just the selected group. Users can now click on a progress bar color to filter tasks within only that specific group, making the Kanban view work as intended for project management.
Original PR description
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter…
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages. Observerd Behaviour: The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be visible. Also the filter would get applied on all other stages or groups created at that time. In those stages all the task with that state would be visible and rest of them would get blurred. Steps to produce: - Install `Project` and add a new project in it. - In the newly created project add some new stages or groups, each consisting some new tasks. - Give some states to those tasks through project state selector (for eg: Approved, Changes Requested). - Click on any particular colour in the `Progressbar` of any particular group or stage. Expected Behaviour: When the user clicks on any colour in the progressbar then it should filter out only those tasks which are associated with that color/state and only in that particular group or stage. Reason: https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114 group.serverValue results as Undefined. Because when the data is being prepared here: https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231 there is no serverValue provided. So, whenever a group is getting created here serverValue `Undefined` as value. https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25 Note: - There was a need to change the function name from `getServerValueFromGroupData` to `getGroupServerValue` as now now this function calculates serverValue while the data is being created and not when the data is already created. - The function is exported into another file as this function defines the basis to calculate serverValue and there is a necessity to calculate serverValue while data is being created. Task-3620697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where reducing event ticket quantities during checkout would leave excess registrations incorrectly marked as active in the system. Previously, when customers reduced their ticket quantity from the cart, the payment would process for the correct amount but the extra registrations would remain open. Now the system properly cancels the excess registrations to match the actual purchased quantity.
Original PR description
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations…
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database. Steps to Reproduce: 1 Install Events Online Ticketing. 2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets. 5 Complete the checkout and payment. 6 Upon inspecting the database for the same event, you'll notice an inconsistency: the number of attendees is higher than it should be. Solution: This issue arises from the implementation of `_compute_registration_status`, which only considers the sale order line and marks registrations as cancelled only if the entire order line is cancelled. This means either all 3 registrations are cancelled, or none. The solution introduced here addresses this by checking for registrations already marked as cancelled and incorporating them into the cancellation logic, ensuring accurate tracking of active and cancelled registrations. opw-3653452
Regular users without admin access can now update their Live Chat username and language preferences in their user profile. Previously, a security update prevented these users from modifying these fields even though they should have permission to edit their own profile settings.
Original PR description
Issue: ------ Since this commit[^1], a user who is not in the `Administration/Access Rights` group cannot modify certain fields available to him on his user profile (`livechat_username` and `livechat_lang_ids`). Solution: --------- As it is possible for a user to write to these fields, it is necessary to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights when writing if the environment user corresponds to the user to whom we want to write the new values. opw-3717266 [^1]: 78f6b83b348326ac0848692ca228a4650057f95c
This fix resolves an issue where dynamically generated content in embedded code snippets would duplicate each time the snippet was edited. The system now properly manages script tags during editing to prevent duplication, and adds helpful warnings to guide users on proper usage of this advanced feature.
Original PR description
Since the introduction of the Embed Code snippet with [1], in case some content was created dynamically through a `<script>` tag, it would be duplicated upon editing the snippet again after it had…
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
Forward-Port-Of: odoo/odoo#152426
Forward-Port-Of: odoo/odoo#142130This fix corrects how the Time Off dashboard calculates future accrual balances when using hourly units. Previously, the system was incorrectly converting hourly accruals to days, causing inaccurate balance displays. For example, a 1-hour monthly accrual now correctly shows 2 hours in the next month instead of 1.12 hours.
Original PR description
Issue: - When checking future accruals in the Time Off dashboard, the Balance view doesn't update correctly. For example, with an accrual plan of 1h per month starting on 30/11/23, the balance in December should show 2h but incorrectly shows only 1.12h. - This happens because the '_get_future_leaves_on' method always returns values in days, ignoring the 'type_request_unit' of the allocation. Steps to Reproduce: - In the time-off app set an accrual plan: 1h per month, accrued on the first day of the month. - add a new allocation to Mitchell Admin with that plan - Notice that In the dashboard the balance is 1h - Change the date to next month, new amount is 1.12h, in stead of 2 Solution: - Added a check to correctly calculate future accruals in hours when type_request_unit is 'hour', ensuring accurate hour-based balances. opw-3685077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves two navigation problems in the chat and messaging features. Users can now properly navigate backwards and forwards through live chat session history without getting stuck, and clicking on the current conversation no longer breaks the browser's back button functionality. These fixes improve the overall user experience when managing multiple conversations.
Original PR description
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the…
This PR fixes 2 issues with discuss navigation: 1. Broken backwards navigation when going back and forth from the live chat session history. 2. Broken backwards navigation when trying to access the same thread than the current one. Steps to reproduce 1: - Open the command palette - Go to the live chat session history view - Click on one of your channels - History back => leads to the session history view - History forward => leads to discuss - History back => stays on discuss, history is broken This occurs because the active id is not passed in the action context when navigating backwards which leads to the URL being pushed again in history (URL without active id is different). The active id should be put in the context when available. Steps to reproduce 2: - Go to discuss - Click on the active thread - History back => stuck on discuss, cannot navigate backwards anymore. We should not push in history when accessing the same thread than the current one. task-3422516 Forward-Port-Of: odoo/odoo#152423
This fix corrects the visual layout of dialog windows used when importing modules and installing industry packages in Odoo. A previous update had fixed the module import dialog but inadvertently broke the shared industry installation dialog. This change restores proper formatting for both dialogs so they display correctly to users.
Original PR description
The commit odoo/odoo@a72007508a985d95 fixed the dialog for the import of a module, but broke the (shared) view for the dialog of the installation of an industry. This commit fixes both dialog views. Before the commit:  After the commit:  And the import dialog remains as it was: 
This fix resolves an issue where grouped list views would display no records after applying a filter that reduces the number of pages. When users filtered data on a grouped list view while viewing a later page, the system now correctly resets to the first page and displays the filtered results instead of showing a blank view.
Original PR description
Have a grouped list view s.t. there's a group with enough records to have a pager in the group. Go to the second page of that group. Then, apply a filter such that there's only a single page remaining in the group. Before this commit, no record was displayed, because the previous offset wasn't reset to 0 it should have been. With this commit, the offset is recursively reset, so we correctly display the records of the first page after a reload. 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
This fix ensures that when the Mail module is installed, it no longer overwrites the system email address that may have been customized before installation. The email is now set once during database creation, allowing users to modify it without it being reset during the Mail module installation process.
Original PR description
Current behavior before PR: If base.partner_root email is modified before installing mail, mail will overwite it (since it is at install and not on update) Desired behavior after PR is merged: Set it up once: on database creating then let the user modify it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152665
This update fixes a problem where images in email marketing templates were displaying at incorrect sizes and couldn't be resized properly. The issue occurred when viewing templates on smaller screens. By applying a responsive image class to certain template images, they now display and resize correctly across all screen sizes.
Original PR description
Issue: ====== Some templates that contains an image have wrong width and it can't be updated. Steps to reproduce the issue: ============================= - Use a view with width < 1135px - Go to email marketing - Create a new mailing - Use the welcome message template - The size of the signature is wrong and you can't update it Origin of the issue: ==================== There is an applied style which fixed the minimum width to 100% if the img is alone inside the parent element (has no siblings) https://github.com/odoo/odoo/blob/749133f3170f795c9deabc6ad6f7684baa76db59/addons/mass_mailing/data/mailing_data_templates.xml#L98 Solution: ========= Add `img-fluid` class to some `img` elements to keep the layout correct. task-3718618 Forward-Port-Of: odoo/odoo#153304 Forward-Port-Of: odoo/odoo#152837
This fix resolves an issue where gift cards were restricted to only the specific customer they were assigned to. Now, gift cards can be used by any customer, making them more flexible and useful for your business. This improves the customer experience and reduces friction in the point-of-sale process.
Original PR description
Prior to this commit, Gift cards assigned to a specific partner were restricted for use only by that partner. This commit rectifies the issue, enabling Gift cards to be usable by any customer as intended. opw-3689391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152950 Forward-Port-Of: odoo/odoo#149913
This fix prevents order line quantities from being accidentally updated when the customer list screen is opened. The system now disables number input handling while the customer screen is active and automatically focuses the search field for better usability. This resolves a frustrating issue where staff could inadvertently modify orders while searching for customers.
Original PR description
Previously, the order line quantity would inadvertently update if the Customer list screen was opened without clicking the search bar and typing numbers. This commit resolves the issue by disabling the event handler while a temp screen is open. Also, it enhances usability by focusing on the search bar upon opening the Customer list screen. opw-3634910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151606 Forward-Port-Of: odoo/odoo#146993
This update fixes memory leaks that were causing the application to retain unnecessary data in memory when views were being used and restored. The system was keeping references to old components and DOM elements even after they were no longer needed. By cleaning up these references, the application will use less memory and perform more efficiently, especially during extended use with multiple views.