Daily updates from Odoo
Navigate
Branch
Thursday, April 4, 2024
52 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
14 changes
Enhancements to existing features
Self-order kiosks now detect when a connected printer runs out of paper and alert both the kiosk user and the linked preparation displays. This helps staff react quickly and prevents orders from being delayed or missed because a receipt or ticket could not print.
Original PR description
This commit handles the case when no more paper in printer. It sends a notification the the preparations displays that are linked to the kiosk. And displays a popup on the kiosk to notify the user. Community: odoo/odoo#160284
Weekly planning views now show an occupancy percentage next to allocated hours when schedules are grouped by resource and another category. This helps managers quickly understand how fully each resource is booked using clear text in addition to existing color indicators.
Original PR description
In the gantt view, when grouping by resource > something else, this commit introduces an occupancy percentage that is displayed next to the aggregated allocated hours of each pill. This percentage actually represents the same information as the colors added in https://github.com/odoo/enterprise/pull/38343 but in a textual way. Note that the occupancy percentage is only displayed for the week scale. occupancy rate = total number of allocated hours for a given period of time / total number of hours to work for that period of time (according to the resource working calendar or the company calendar in case of flexible hours) task-3651242
Field service worksheet templates and reports are easier to manage, with clearer template selection, company visibility, and direct access to template design. Customer-facing reports are also cleaner, with better formatting, consistent PDF naming, and safeguards that prevent printing incomplete reports.
Original PR description
In this PR add following improvements: **worksheet, **industry_fsm_report - the 'company' and 'color' fields as optional and hidden by default in worksheet template list view. - add a group by…
In this PR add following improvements: **worksheet, **industry_fsm_report - the 'company' and 'color' fields as optional and hidden by default in worksheet template list view. - add a group by 'companies' on search view of worksheet. - add 'company' field under the name in kanban view of worksheet template. - update the description of the 'custom worksheets' feature and add link button that will redirect to the worksheet template. - sort records from newest to oldest in worksheet template. - update action helper of worksheet template analysis. - remove the 'create' option and only keep 'create and edit in product form view and project.project form view also add placeholder on worksheet template field - update log note on sign report of field service task and add pdf name same as send report. - display the labels in bold + display values closer to their labels also add striped stlye on rows of worksheet report. - raise user error on printing report without timesheet or workseet or product. - set the 'worksheet template' as the project is selected instead of doing it on save of product form view. - worksheet template field on create and edit in product,project and task: - hide the 'analysis' button - add a 'design template' primary button task-3504607
Point of Sale receipts in the Chilean localization now include the bidimensional code and header information needed to qualify as valid electronic documents. Credit notes for refunded invoices now show only the required document number, improving compliance and consistency with backend refunds.
Original PR description
This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. It also changes the code shown on the credit note when refunding a previous invoice. Before the commit, it was showing the full name (eg. BEL 00001), but we actually need to have only the number (eg. 00001) as it is done when refunding from the backend. task-id: 3747828 Community PR: odoo/odoo#159671
Payroll report entries now take users directly to the corresponding payslip instead of opening a confusing technical report form. This makes payroll review faster and clearer for users who need to inspect payslip details from reports.
Original PR description
Clicking upon the payroll report opens the form view of the report which is very confusing for some users In this PR, clicking on the payroll report now opens the related payslip. task-3716854
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
20 changes
New functionality added to Odoo
This update adds Catalan language translations for the Spanish localization module, allowing users who configure their environment to use Catalan to see account names and financial terms in their preferred language instead of English. The change includes translated account names across multiple Spanish accounting templates and a new Catalan translation file.
Original PR description
Description of the issue/feature this PR addresses: Add the name@ca for catalan translation at the main account plans in the spain l10n_es localization, and the l10n_es/i18n/ca.po file too. Current behavior before PR: The accounts names are in english when user configures her environment to use the catalan language. Desired behavior after PR is merged: The accounts names are in catalan. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The survey results page has been redesigned to improve usability and readability. Changes include a more compact layout with better spacing, repositioned filter buttons, improved table scrolling for smaller screens, and cleaner badge displays. These improvements make survey results easier to read and navigate while maintaining compatibility with existing systems.
Original PR description
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing…
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing the header tags. - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for fold/unfold - Align questions to the left to be on the same level as the sections - Add an horizontal scroll to the matrix and simple/multiple choices tables when the screen is not wide enough to display all the data - Reduce vertical spacing between elements to gain space - Reduce simple/multiple choices tables line height - Reduce survey title, section title and KPIs font size - Display the "Correct", "Partial", "Responded" and "Skipped" badges on a single line and set a rounded border around. - Removing the "Result Overview" title - Removing survey description, section description and question description Task-3707687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 fix resolves a system crash that occurred when users removed attendees while creating a new staff booking appointment. The system now properly checks whether attendees are assigned before processing the appointment, preventing errors and allowing users to save appointments without attendees if needed.
Original PR description
This traceback will arise when the user removes the attendees while creating the new "Staff Booking". Steps to reproduce: - Install ``appointments`` - Open appointments -> Dental care - Go to new ->…
This traceback will arise when the user removes the attendees while creating the new "Staff Booking".
Steps to reproduce:
- Install ``appointments``
- Open appointments -> Dental care
- Go to new -> create appointment -> remove Attendees -> Save&Close
Traceback :
```TypeError: 'bool' object is not subscriptable
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/appointment/models/calendar_event.py", line 392, in get_gantt_data
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
File "home/odoo/src/enterprise/saas-17.1/appointment/models/calendar_event.py", line 392, in <listcomp>
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
```
This commit will check for the presence of partner_ids. If they are present, it will schedule the appointment; otherwise, it will not.
sentry-4934421570This 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`.
When a subscription contract is cancelled, the subscription state is now properly reset to draft or renewal quotation status. This fix resolves confusing filter results and allows users to restart the subscription workflow if needed after cancellation.
Original PR description
Before this commit, when a churned contract was cancelled, the subscription_state was not reset. The resulting filter on SO would be confusing: Group by subscription_state > state After this commit, the churned order subscription-state is reset to draft or renewal quotation when canceled. This allow to reset the canceled order to quotation and to be able to restart the flow if necessary.
Fixed a bug that prevented the list view from opening when users clicked the search icon in the timesheet grid. The issue was caused by a component rendering loop that occurred when the system tried to load and edit a timesheet simultaneously. The fix separates these operations into different lifecycle stages to prevent the infinite loop.
Original PR description
Steps to reproduce: ------------------- - in My Timesheet, click on start; - add a project, a task and a description; - click on search icon in the grid (magnifying glass); Issue: ------ The list view never opens. Cause: ------ When the component performs the `onWillStart` hook, we add the timesheet with the current timer and put it into edit mode. This will have the effect of making a new render (destroy the component and create a new one). This will create a new component and repeat the process. Solution: --------- Let the component load the timesheet during the `onWillStart` but manage the edit mode during the `onMounted` hook. opw-3788661
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
This fix resolves a problem where clicking "Search more" on the milestone field in shared projects would open an incorrect backend view with unusual formatting. The solution hides the "View Tasks" button from the milestone search dialog to prevent users from accidentally accessing the backend task view. This ensures a consistent and proper user experience when managing milestones in shared projects.
Original PR description
Steps: - Install project app. - Share a project with allow milestone on. - Open project sharing task from. - Click on Search more botton of milestone field. - Click on view tasks button of Search more tree dialog. Issue: - Backend task kanban view opens with unusual charactoristics like progress bar display purple Add stage button display etc. Casue: - Search more on milestone field open backend milestone list view with view tasks button which open back-end task kanban view. Fix: - Hide `View Tasks` button for project sharing milestone field. task-3764782
This update fixes two issues with Peppol invoice processing. First, partners are no longer incorrectly marked as valid Peppol participants when incompatible formats are selected. Second, invoice Peppol states now properly reset when invoices are returned to draft status, allowing users to correct configuration issues without being stuck in a 'ready' state.
Original PR description
- Create a Partner who is a valid Peppol participant - Clear their UBL format - they are still displayed as valid (Bug 1) - Create an invoice for that partner and confirm it. The Peppol state changes to 'ready' - Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant - Reset the invoice to draft, confirm again: the peppol move state is still `ready` (Bug 2) 1. Do not set a participant as valid if a peppol-incompatible edi format has been selected 2. Only save Peppol move state if it's processing/done already. Otherwise, let users clear it by resetting to draft. (until we implement giving them control over this field) opw-3784945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug where product warning messages were displaying even when set to "no message" mode. After this update, warning messages will only appear when the warning type is actually enabled, giving users proper control over when warnings are shown during the sales process.
Original PR description
Problem: When the user sets a warning message for a product, the message will always display even if the warning type is no-message. Purpose: The product's warning message should not display if the warning type is no message. Steps to Reproduce on Runbot17: 1.Install Sales 2.Enable Sale Warnings in Setting > Sales 3.Modify the sale warnings for a product 4.Create a quotation 5.Click on the catalog and look for the modified product 6.Observe the warning opw-3806520 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 resolves issues that occurred when archiving records in kanban views grouped by date. When all records in a group were archived, the empty group would either disappear or appear in the wrong position, and users would see error messages. The fix ensures empty groups are properly restored with their correct position and date range information.
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#159884
Forward-Port-Of: odoo/odoo#158872This fix resolves an issue where manufacturing order operation durations were not being calculated correctly when time tracking was not used. Previously, if a duration was manually set in the bill of materials but no time was tracked during production, the system would show 0 duration instead of the manually configured amount. This update ensures that manually configured operation durations are properly reflected in completed manufacturing orders.
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#158789Fixed an issue where accepting recurring events from Google Calendar with the "this event" option wasn't being reflected in Odoo. The problem occurred because Google's update timestamps were being compared against Odoo's current timestamps, causing some updates to be incorrectly discarded. The fix preserves the original timestamps before processing updates to ensure all Google Calendar changes sync properly.
Original PR description
Before this commit when accepting a recurrent event from google calendar with option "this event", it didn't reflect on odoo calendar. This happened due to the write_date check which applies google update only if their write_date is after odoo write_date, but multiple updates from google might change some events write_date to now, which causes other google updates to get discarded. This commit aims to fix this issue by keeping the write_date of the affected events before applying any google updates, and considering these dates instead of the live odoo write_date. Task: 3731552 Forward-Port-Of: odoo/odoo#158509
Fixed a bug where the emoji picker would crash and become unusable after being closed and reopened. The issue occurred because the system tried to access a part of the emoji picker that no longer existed in the interface. This fix adds a simple check to prevent the error, allowing users to open and close the emoji picker multiple times without problems.
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
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
This update fixes a display issue in the eCommerce categories form that was causing improper layout on mobile devices. The form content was incorrectly positioned, making it difficult to view and interact with on smaller screens. The fix ensures the form displays properly across all device sizes, improving the mobile shopping experience for customers managing product categories.
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#160314
This fix prevents customers from encountering errors when they modify their shopping cart to reach a zero total (such as by applying a coupon for a free item). The express checkout button now automatically disappears when the cart total becomes free, preventing customers from attempting to proceed with payment when no payment is needed.
Original PR description
In the cart, customers can edit the quantity, add or remove products, and redeem promo codes, coupons, etc. The express checkout form handles only the quantity change, but the buttons are still shown even with a free cart (e.g. coupon for a free desk). When the customers use them, an error is thrown. Now, if a user has free cart after his modification, it will make express checkout button disappear. task-3568644 Forward-Port-Of: odoo/odoo#149565
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