Daily updates from Odoo
Thursday, April 4, 2024
33 changes
17 changes
Miscellaneous changes
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159878 Forward-Port-Of: odoo/odoo#159320
Original PR description
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159878 Forward-Port-Of: odoo/odoo#159320
Currently, the emoji picker uses the `onWillUnmount` hook to detect when the popover element is closed. The code defined in this hook accesses the component's DOM and retrieves the scroll offset of the emoji picker's scroll view. The scroll offset will then be saved and restored the next time the emoji picker is opened by the user. Unfortunately, it happens that the emoji picker's scroll view is no longer in the DOM when the popover is closed and when the callback function passed to the `onWi
Original PR description
Currently, the emoji picker uses the `onWillUnmount` hook to detect when the popover element is closed. The code defined in this hook accesses the component's DOM and retrieves the scroll offset of…
Currently, the emoji picker uses the `onWillUnmount` hook to detect when the popover element is closed. The code defined in this hook accesses the component's DOM and retrieves the scroll offset of the emoji picker's scroll view. The scroll offset will then be saved and restored the next time the emoji picker is opened by the user. Unfortunately, it happens that the emoji picker's scroll view is no longer in the DOM when the popover is closed and when the callback function passed to the `onWillUnmount` hook is called. When this happens, the system will log an error to the console (`TypeError: this.gridRef.el is null`) and the user will not be able to reopen the emoji picker. To fix this, we simply check that the emoji picker's scroll view exists before retrieving the scroll offset of the element in the `onWillUnmount` hook. This fix will prevent the error while keeping the code simple. Steps to reproduce the issue: 1. Click on the article emoji 2. Click out of the dropdown to close it 3. Click on the article emoji again => The emoji picker no longer appear. TO BE: The emoji picker should reappear when the user clicks on the emoji. task-3818728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158432
Steps to reproduce the issue: ============================= - Go to website and open editor - Click on the 'Contact Us' button - Change the color of the text - error Origin of the issue: ==================== `HistoryReverCurrentStep` will call `observerFlush` which will mark `_toRollback = true` and in `_observeOdooFieldChanges` we will update the html with `withoutRollback` but this only works only if `_toRollback` is `false`. Solution: ========= We need to rever the step withou
Original PR description
Steps to reproduce the issue: ============================= - Go to website and open editor - Click on the 'Contact Us' button - Change the color of the text - error Origin of the issue: ==================== `HistoryReverCurrentStep` will call `observerFlush` which will mark `_toRollback = true` and in `_observeOdooFieldChanges` we will update the html with `withoutRollback` but this only works only if `_toRollback` is `false`. Solution: ========= We need to rever the step without rollback too. task-3770287 Forward-Port-Of: odoo/odoo#156461
Currently, when making a manufacture order, the duration for operations is not computed when time was not tracked. Steps to reproduce: ------------------- * Go to the **Manufacturing** App * Under **Products**, select **Bill of Materials** * Create a new bill of materials * Add any product * Add any component * Add an operation * Select any work center * For `Duration Computation`, select `Set duration manually`, set any amount * Save everything * Under **Operations**
Original PR description
Currently, when making a manufacture order, the duration for operations is not computed when time was not tracked. Steps to reproduce: ------------------- * Go to the **Manufacturing** App * Under…
Currently, when making a manufacture order, the duration for operations is not computed when time was not tracked.
Steps to reproduce:
-------------------
* Go to the **Manufacturing** App
* Under **Products**, select **Bill of Materials**
* Create a new bill of materials
* Add any product
* Add any component
* Add an operation
* Select any work center
* For `Duration Computation`, select `Set duration manually`, set any amount
* Save everything
* Under **Operations**, select **Manufacturing Orders**
* Create a new order
* Select the product for which the bill of meterial was created
* Save > Confirm > Mark as done
> Observation: Real duration is showing 0, instead of the manual amount.
Why the fix:
------------
As of now, the duration only depends on the time tracked on each operation. https://github.com/odoo/odoo/blob/7a9b05e5e7ccc54fe673a00167a261c2c6181d0a/addons/mrp/models/mrp_workorder.py#L318-L321
The issue was solved in upper versions with this fix: https://github.com/odoo/odoo/commit/5e2b97b47f3cf14616c24631acf2cd08f0295a43
I'm backporting this fix for consistency even though the issue it was originally for does not exist in 16.0 but it still solves the fact that the duration isn't computed if time was not tracked.
opw-3800477
Forward-Port-Of: odoo/odoo#160282
Forward-Port-Of: odoo/odoo#158789**[IMP] web_editor: prevent the colorpicker from closing on inner click** Before this commit, clicking in the area below the "Hex color" input would close the color picker. This was annoying when entering a value in the "Hex color" input and then clicking below to confirm it. After this commit, the color picker no longer closes when clicking on its background. task-3747408 ----------------------- **[IMP] web: update the colorpicker on hex color input's input event** This commit
Original PR description
**[IMP] web_editor: prevent the colorpicker from closing on inner click** Before this commit, clicking in the area below the "Hex color" input would close the color picker. This was annoying when entering a value in the "Hex color" input and then clicking below to confirm it. After this commit, the color picker no longer closes when clicking on its background. task-3747408 ----------------------- **[IMP] web: update the colorpicker on hex color input's input event** This commit improves the UX of the color picker's hex input in two ways: If the user enters a hex color without the "#" symbol, it's automatically added. As soon as a valid hexadecimal color is entered in the input, the colorpicker updates, and the color is applied to the target element. task-3747408 Forward-Port-Of: odoo/odoo#157034
Before this commit, the custom attribute names were not correctly displayed when added to an order. opw-3795843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159732 Forward-Port-Of: odoo/odoo#158805
Original PR description
Before this commit, the custom attribute names were not correctly displayed when added to an order. opw-3795843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159732 Forward-Port-Of: odoo/odoo#158805
Current behavior: When you refund an order that was paid with bank and so not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: - Setup a rounding method with a precision
Original PR description
Current behavior: When you refund an order that was paid with bank and so not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: - Setup a rounding method with a precision of 5.0 - Create a product with a price of 138.0 - Open the POS and add the product to the order - Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80. - Validate the order - Go in the backend and refund the order - The refund will be rounded to 135.0 opw-3701574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160139 Forward-Port-Of: odoo/odoo#155619
…prone Currently when we call copy data twice (e.g. due to some strangely designed 2many fields), the second call returns None instead of a list containing a values dict. Use case is linked to whatsapp, where a template contains variables and buttons. Buttons also contains variables, shared from templates. It means than copying a template and its buttons calls the copy_data twice on variables once from the template and once from buttons. This is quite annoying as ``copy_data`` crashes, exp
Original PR description
…prone Currently when we call copy data twice (e.g. due to some strangely designed 2many fields), the second call returns None instead of a list containing a values dict. Use case is linked to…
…prone Currently when we call copy data twice (e.g. due to some strangely designed 2many fields), the second call returns None instead of a list containing a values dict. Use case is linked to whatsapp, where a template contains variables and buttons. Buttons also contains variables, shared from templates. It means than copying a template and its buttons calls the copy_data twice on variables once from the template and once from buttons. This is quite annoying as ``copy_data`` crashes, expecting sub calls to return a list with one element. We plan to change this design but this fix target stable version, and anyway copy_data should be resilient in case this design happens in some module. Looking at odoo/odoo@4ac2702c31f0e95f33f9ad554e7350bef9dab8bd None is appended to the returned list of values when converted into multi copy. In this fix we choose to do the same kind of behavior in order to be coherent. It now returns [None] instead of None, allowing notably to avoid issues with a one-liner filtering None from returned list. Task- Forward-Port-Of: odoo/odoo#160332 Forward-Port-Of: odoo/odoo#157576
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406 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 Fo
Original PR description
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406 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#160184
This commit reverts [#133504](https://github.com/odoo/odoo/pull/133504), as it was deliberating access to private event information to uninvited administrators in the calendar view. Only the event organizer and its attendees must be able to fetch private events information. In addition, two tests have been added to: 1. ensure the confidentiality of private events from uninvited administrators and 2. prohibit uninvited administrators from edit the information of any event, private or not. t
Original PR description
This commit reverts [#133504](https://github.com/odoo/odoo/pull/133504), as it was deliberating access to private event information to uninvited administrators in the calendar view. Only the event organizer and its attendees must be able to fetch private events information. In addition, two tests have been added to: 1. ensure the confidentiality of private events from uninvited administrators and 2. prohibit uninvited administrators from edit the information of any event, private or not. task-3837646 Forward-Port-Of: odoo/odoo#160308 Forward-Port-Of: odoo/odoo#159743
This commit removes an unwanted `bg-primary` class applied to the change password modal, making it weird and unconsistent regarding others modals across Odoo. ### Steps to reproduce 1. Open a database 2. Click on your avatar in the top right corner 3. Click on `Preferences` 4. Go to `Account Security` 5. Click on `Change password` The modal has a `bg-primary` class, making it look purple. | saas-16.3 | saas-16.3-fix-unconsistent-modal-design-chgo | |--------|--------| |
Original PR description
This commit removes an unwanted `bg-primary` class applied to the change password modal, making it weird and unconsistent regarding others modals across Odoo. ### Steps to reproduce 1. Open a database 2. Click on your avatar in the top right corner 3. Click on `Preferences` 4. Go to `Account Security` 5. Click on `Change password` The modal has a `bg-primary` class, making it look purple. | saas-16.3 | saas-16.3-fix-unconsistent-modal-design-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/7abc9d80-1570-4364-adda-a505721bfb55"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/128f4729-6e02-4105-b16a-efadac8c2ea8"> | Forward-Port-Of: odoo/odoo#159774 Forward-Port-Of: odoo/odoo#155334
Steps: - Install project app. - Share a project which contains a task with blockby task. - Open that project in project sharing and keep login via admin. - Edit something in blockby page. Issue: - Warning displaying about other private project task blockby even though there are no task in blockby which from other project. Cause: - Computation on changing project task block by tree call compute of depend_on_count field but since record is just temparory save it get _origin instead of
Original PR description
Steps: - Install project app. - Share a project which contains a task with blockby task. - Open that project in project sharing and keep login via admin. - Edit something in blockby page. Issue: - Warning displaying about other private project task blockby even though there are no task in blockby which from other project. Cause: - Computation on changing project task block by tree call compute of depend_on_count field but since record is just temparory save it get _origin instead of actual record and because of origin it fails to get actual id key data from dictonary. Fix: - Get id from origin if record is _origin record to properly get and set data. task-3764782 Forward-Port-Of: odoo/odoo#155366
After modifying the registry on a worker (e.g. by installing a module), the first HTTP request on other workers may fail to compute the endpoint's readonly attribute and throw an exception (see _call_kw_readonly()). The user may then experience 'random' errors for a short period of time (until the registries/workers are recycled). The problem is that we are using the old registry (`registry`) instead of the one that can be reset by the check_signaling (`self.registry`). Forward-Port-Of: odoo
Original PR description
After modifying the registry on a worker (e.g. by installing a module), the first HTTP request on other workers may fail to compute the endpoint's readonly attribute and throw an exception (see _call_kw_readonly()). The user may then experience 'random' errors for a short period of time (until the registries/workers are recycled). The problem is that we are using the old registry (`registry`) instead of the one that can be reset by the check_signaling (`self.registry`). Forward-Port-Of: odoo/odoo#160367
In [this commit](https://github.com/odoo/odoo/commit/a010a22f3ae6dda8c45cb6a4c36bb38f949b33e9) we introduced a new behavior on our fields having an invalid state applying a slight danger background. However in the list view table, the background of the inputs that are at the same line were displaying the error state. -> To reproduce, enter a wrong value in the list view, save and click outside of focus. This commit resets the `o-input-background-color` to it's initial value inside the l
Original PR description
In [this commit](https://github.com/odoo/odoo/commit/a010a22f3ae6dda8c45cb6a4c36bb38f949b33e9) we introduced a new behavior on our fields having an invalid state applying a slight danger background.…
In [this commit](https://github.com/odoo/odoo/commit/a010a22f3ae6dda8c45cb6a4c36bb38f949b33e9) we introduced a new behavior on our fields having an invalid state applying a slight danger background. However in the list view table, the background of the inputs that are at the same line were displaying the error state. -> To reproduce, enter a wrong value in the list view, save and click outside of focus. This commit resets the `o-input-background-color` to it's initial value inside the list view making it fallback to transparent, not displaying the bg when line is in error state and avoiding overlapping with the background already set on the td. task-3644895 | Before | |:------:| |  | | After | | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146832
This commit fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this commit, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we remove the `.oe_left` class, we apply a `.col-md-4` `.col-lg-6` to handle the width on large devices, and add a `.pe-3` to ensure that the labels are not placed right next to the image in mobile. task-3847917 | saas-16.3
Original PR description
This commit fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this commit, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we remove the `.oe_left` class, we apply a `.col-md-4` `.col-lg-6` to handle the width on large devices, and add a `.pe-3` to ensure that the labels are not placed right next to the image in mobile. task-3847917 | saas-16.3 | saas-16.3-fix-ecommerce-categories-formview-layout-on-mobile-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/66bd001f-0bcc-424f-89e4-40b4b7f15841"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/d08ee984-4bb9-4425-b3ac-58e0ed56ac54"> | Forward-Port-Of: odoo/odoo#160478 Forward-Port-Of: odoo/odoo#160314
Steps to reproduce ================== - Go to Field Service - Group by "start date: week" - Archive every record in a column until there is only one left - Go back to the kanban view - Click on the single record from the column - Archive it - Using the breadcrumbs, go back to the kanban view => `Cannot read properties of undefined (reading 'planned_date_begin:day')` Cause of the issue ================== Before archiving the record, we have the following data: `{group1: [1, 2
Original PR description
Steps to reproduce ================== - Go to Field Service - Group by "start date: week" - Archive every record in a column until there is only one left - Go back to the kanban view - Click on the…
Steps to reproduce
==================
- Go to Field Service
- Group by "start date: week"
- Archive every record in a column until there is only one left
- Go back to the kanban view
- Click on the single record from the column
- Archive it
- Using the breadcrumbs, go back to the kanban view
=> `Cannot read properties of undefined (reading 'planned_date_begin:day')`
Cause of the issue
==================
Before archiving the record, we have the following data:
`{group1: [1, 2], group2: [3]}`
After archiving the record, we have `{group1: [1, 2]}`
The KanbanDynamicRecordList recreates a new group datapoint, matching
the now empty one. Compared to an actual one loaded from the server, it
is missing the range.
`getServerValue` is called from the Group setup and is put inside a
defaultContext, used when quick creating a record.
When grouped by date, it uses the range to compute the server value.
Solution
========
We can export the range and use that when recreating the empty group
opw-3816409
Forward-Port-Of: odoo/odoo#160121
Forward-Port-Of: odoo/odoo#158872Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single
Original PR description
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 Fixes #155162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160198 Forward-Port-Of: odoo/odoo#159122
1 change
Resolved issues and error corrections
This update fixes a warning message appearing when users share projects with tasks created using the 'blockby' feature. The issue stemmed from a technical error in how Odoo processed temporary project records, leading to incorrect data comparisons. This change ensures warnings are suppressed when sharing projects, improving user experience.
Original PR description
Steps: - Install project app. - Share a project which contains a task with blockby task. - Open that project in project sharing and keep login via admin. - Edit something in blockby page. Issue: - Warning displaying about other private project task blockby even though there are no task in blockby which from other project. Cause: - Computation on changing project task block by tree call compute of depend_on_count field but since record is just temparory save it get _origin instead of actual record and because of origin it fails to get actual id key data from dictonary. Fix: - Get id from origin if record is _origin record to properly get and set data. task-3764782
9 changes
Resolved issues and error corrections
The Helpdesk ticket activity view now handles tickets without an assigned user more cleanly. This prevents a broken empty picture placeholder and gives users a smoother, more consistent ticket view.
Original PR description
issue: If you don't have a picture on the assign, display is broken Without the assign in the ticket, the empty image placeholder is not shown properly. I display the O2M widget rather than an empty image holder. A side effect of this commit- https://github.com/odoo/odoo/commit/13382398d2ebeb3df52fb67d9963c292372031d1 task-3706742
Code cleanup and technical improvements
The website editor's snippet menu has been reworked in the appointment and enterprise website areas to use Odoo's newer interface technology. This keeps the visible editing experience consistent while making the menu easier to maintain and evolve.
Original PR description
*: website_appointment, website_enterprise
As explained in the community commit:
This commit also takes advantage of the OWL rendering engine by moving most of the SnippetsMenu UI into a static frontend template (previously it was a backend view). The view is kept, to generate the list of snippets and still generate the options' HTML.
The structure of the list of snippets is now the following:
```
<snippets>
<category>
<title>Base Structure
<snippets>
<t t-snippet=""...../>
</snippets>
</category>
</snippets>
```
task-3323657
Community PR: https://github.com/odoo/odoo/pull/121295Miscellaneous changes
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens: https://github.com/odoo/odoo/blob/f7ee5633a8c80afca05074b8574e9c2a720e4bc9/addons/point_of_sale/models/pos_config.py#L496 Steps to reproduce: 1. Install PoS and IoT applications -- will install `pos_enterprise` module. 2. Set is_posbox = True, via the PoS settings. 3. Uninstall IoT application -- will uninstall `iot` and `pos_iot` mod
Original PR description
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:…
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:
https://github.com/odoo/odoo/blob/f7ee5633a8c80afca05074b8574e9c2a720e4bc9/addons/point_of_sale/models/pos_config.py#L496
Steps to reproduce:
1. Install PoS and IoT applications -- will install `pos_enterprise` module.
2. Set is_posbox = True, via the PoS settings.
3. Uninstall IoT application -- will uninstall `iot` and `pos_iot` modules.
4. Try to install a module that writes in a column of the pos_config with is_posbox=True
We get an error like:
```
...
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 569, in _button_immediate_function
raise UserError(_('The method _button_immediate_install cannot be called on init or non loaded registries. Please use button_install instead.'))
odoo.exceptions.UserError: El método _button_immediate_install no puede ser llamado en registros init o no cargados. Por favor, utilice button_install en su luga
```
The issue is that when we uninstall `iot` module the flag is never reset. This then causes issues if we try to install a module that writes on any value of `pos.config`. Observed during upgrades, e.g `l10n_es_pos` at xml load of data files. Other modules also affected.
The solution we propose here is to introduce a _soft_ dependency between pos_iot -- which is an enterprise module -- and pos_enterprise. The former checks at uninstall if the latter is installed to clear the `is_posbox` flag.
Forward-Port-Of: odoo/enterprise#59810Current behavior: After this refactor https://github.com/odoo/odoo/pull/142566 the use_proxy became undefined. And so the pos is not able to connect to the proxy and use the printer connected to the IoT Box. Steps to reproduce: - Install the PoS IoT module - Configure the IoT Box with a printer - Select the printer from the IoT Box in the PoS configuration - Try to print a receipt - Nothing happens, it only try to print via the browser print popups Note: There was also an issue in t
Original PR description
Current behavior: After this refactor https://github.com/odoo/odoo/pull/142566 the use_proxy became undefined. And so the pos is not able to connect to the proxy and use the printer connected to the IoT Box. Steps to reproduce: - Install the PoS IoT module - Configure the IoT Box with a printer - Select the printer from the IoT Box in the PoS configuration - Try to print a receipt - Nothing happens, it only try to print via the browser print popups Note: There was also an issue in the StatusLoop that was not correctly getting the ids of the devices. This was fixed in the same commit. opw-3800437 Forward-Port-Of: odoo/enterprise#59570 Forward-Port-Of: odoo/enterprise#59433
**Step to reproduce:** - Install `Knowledge` and `Documents` modules (for test purpose) - Go to Documents app - Click on Action button -> Knowledge -> Insert view in article - Select any article **Issue:** View is not loaded correctly in the article. Error message: Something went wrong! The view does not exist or you are not allowed to access to it. **Cause:** In the imported view, we try to retrieve the selected Folders, but this last one need the search model
Original PR description
**Step to reproduce:** - Install `Knowledge` and `Documents` modules (for test purpose) - Go to Documents app - Click on Action button -> Knowledge -> Insert view in article - Select any article…
**Step to reproduce:**
- Install `Knowledge` and `Documents` modules (for test purpose)
- Go to Documents app
- Click on Action button -> Knowledge -> Insert view in article
- Select any article
**Issue:**
View is not loaded correctly in the article.
Error message: Something went wrong! The view does not exist or you
are not allowed to access to it.
**Cause:**
In the imported view, we try to retrieve the selected Folders, but this last one need the search model to retrieve the data.
https://github.com/odoo/enterprise/blob/11daa694d4ca51939c2b458bced8ab9d48030ef8/documents/static/src/views/documents_controller_mixin.xml#L5
The method called to retrieve the folders (`getSelectedFolder`) is set on the documents search model (`DocumentsSearchModel`), however, the search model set in the embedded_view is the knowledge search model (`KnowledgeSearchModel`).
**Solution:**
Change the `KnowledgeSearchModel` class into a mixin so it can extend the (potentially) custom search model defined for any embedded view during the mounting process (default to the generic search model), instead of overwriting it.
opw-3752927
Forward-Port-Of: odoo/enterprise#59758Issue - Edit Payslip Lines are reset to previous value Steps: go to -> payroll / all payslip create a payslip compute payslip action -> Edit Payslip Lines edit a line Issue: it is reset to previous value Forward-Port-Of: odoo/enterprise#59665
Original PR description
Issue - Edit Payslip Lines are reset to previous value Steps: go to -> payroll / all payslip create a payslip compute payslip action -> Edit Payslip Lines edit a line Issue: it is reset to previous value Forward-Port-Of: odoo/enterprise#59665
During this PR: https://github.com/odoo/enterprise/pull/51954 tests were not added directly. This PR will add test for the following: - Simple export with no moves - Simple export with moves - Non critical errors - Critical errors task-3794278 Forward-Port-Of: odoo/enterprise#59431
Original PR description
During this PR: https://github.com/odoo/enterprise/pull/51954 tests were not added directly. This PR will add test for the following: - Simple export with no moves - Simple export with moves - Non critical errors - Critical errors task-3794278 Forward-Port-Of: odoo/enterprise#59431
When installing module l10n_eu_oss, account 2205 Output VAT (Sales) OSS was not referenced in the Balance Sheet. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59137
Original PR description
When installing module l10n_eu_oss, account 2205 Output VAT (Sales) OSS was not referenced in the Balance Sheet. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59137
On the buttons bar of the account reports, the button was smaller than the dropdown item and so when clicking on the dropdown nothing happens. This Pr will move the actions on the dropdown. task-3826440 Forward-Port-Of: odoo/enterprise#59350
Original PR description
On the buttons bar of the account reports, the button was smaller than the dropdown item and so when clicking on the dropdown nothing happens. This Pr will move the actions on the dropdown. task-3826440 Forward-Port-Of: odoo/enterprise#59350
6 changes
Enhancements to existing features
VAT validation examples in the system can now be displayed in users' local languages instead of always appearing in English. This improvement enhances the user experience for international customers by making VAT format guidance more accessible and easier to understand in their native language.
Original PR description
Currently some VAT examples that contain other terms than only the number are always displayed in English. This commit makes sure they can be translated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159051 Forward-Port-Of: odoo/odoo#158629
Resolved issues and error corrections
This update fixes a display issue where the helpdesk ticket information was not showing up in the timesheet list views. Employees can now see which helpdesk ticket is associated with their timesheets in both the "My Timesheets" and "All Timesheets" views, making it easier to track time spent on specific support tickets.
Original PR description
Before this commit, the `helpdesk_ticket_id` field in `account.analytic.line` model was not defined in the list view used in `My Timesheets` menu. This commit updates the list view to correctly display the `helpdesk_ticket_id` field in `My Timesheets` and `All Timesheets`.
This update fixes a testing issue in the Sales Subscription module where certain tests were failing when the Website Sales module was installed. The fix ensures that all necessary data fields are properly synchronized during tests, preventing conflicts and improving test reliability.
Original PR description
Issue: ------ Some tests of `TestSaleReport` introduced with the fix [^1], do not pass if the module `website_sale` is installed. This is due to the fact that the sale order flush does not flush all the fields of the sale order line model that are used in the tests (`price_subtotal` for example). Solution: --------- Use `flush_all` to flush the `sale.order` and `sale.order.line` models. opw-3818584 [^1]: https://github.com/odoo/enterprise/commit/f886e65ce123f06ee8a5a2f149330864bcdb3254 Forward-Port-Of: odoo/enterprise#59915
This update resolves a timing issue in the barcode inventory testing process that was causing inconsistent test results. The fix ensures that the inventory adjustment test runs reliably without unexpected failures, improving the stability of the barcode scanning system's quality assurance.
Original PR description
This commit fixes a race condition in the following test tour: `test_inventory_adjustment_dont_update_location` Runbuild error: 60324 Forward-Port-Of: odoo/enterprise#59900
The password change modal had an incorrect purple background color that made it look different from other modals in Odoo. This fix removes the unwanted styling to make the modal consistent with the rest of the application's design.
Original PR description
This commit removes an unwanted `bg-primary` class applied to the change password modal, making it weird and unconsistent regarding others modals across Odoo. ### Steps to reproduce 1. Open a database 2. Click on your avatar in the top right corner 3. Click on `Preferences` 4. Go to `Account Security` 5. Click on `Change password` The modal has a `bg-primary` class, making it look purple. | saas-16.3 | saas-16.3-fix-unconsistent-modal-design-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/7abc9d80-1570-4364-adda-a505721bfb55"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/128f4729-6e02-4105-b16a-efadac8c2ea8"> | Forward-Port-Of: odoo/odoo#159774 Forward-Port-Of: odoo/odoo#155334
Code cleanup and technical improvements
The Peru localization module for Point of Sale has been simplified by removing redundant code. Since the main Point of Sale system now handles errors when editing customer information, the Peru module no longer needs to duplicate this functionality. This cleanup reduces code complexity and maintenance burden.
Original PR description
Now, point_of_sale handles errors in partner editions, so it is not required inheriting the method to add the functionality. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr