Thursday, April 4, 2024
29 changes · saas-17.2
Resolved issues and error corrections
This fix ensures a Knowledge test tour can run reliably even when demo data is not installed. It creates a dedicated internal test user instead of relying on a demo user, reducing failures in nightly validation runs without changing customer-facing behavior.
Original PR description
This commit fixes an issue with one of the nightly runbot test: No Demo. This trigger launches tests without using any demo data for all of the modules the issue with it is that the user `demo`, which is used in some tours, is part of the demo data. This leads to the thread tour to fail since it is using a demo user. To fix this, the commit creates a new internal test user inside the test class which is then used as login when launching the tour. This way the tour is no longer dependant on a demo user without using the admin login. task-3844899
The invoice document review overlay was adjusted so users can click extraction boxes as expected. This restores an important interaction in invoice processing that had been blocked by a display layering change.
Original PR description
Added a high z-index to o_invoice_extract_box_layer css class to make the extract box layer on top and clickable again. This was caused by an added z-index to textLayer class in odoo/odoo@5c238950bbf6
Miscellaneous changes
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`. Forward-Port-Of: odoo/enterprise#59255
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`. Forward-Port-Of: odoo/enterprise#59255
In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Have a user [DEMO] with Accounting access set to 'Read-only' Log in with [DEMO] Try to access the Accounting App Dashboard Issue: Access Error """ You are not allowed to access 'Bank Connection' (account.online.link) records. This operation is allowed for the following groups: - Accounting/Accountant - Accounting/Boo
Original PR description
In the system parameters, switch account_online_synchronization.proxy_mode to sandbox
Add a bank with plaid for example and follow the different steps
Have a user [DEMO] with Accounting access set to 'Read-only'
Log in with [DEMO]
Try to access the Accounting App Dashboard
Issue:
Access Error
"""
You are not allowed to access 'Bank Connection' (account.online.link) records.
This operation is allowed for the following groups:
- Accounting/Accountant
- Accounting/Bookkeeper
Contact your administrator to request access if necessary.
"""
This occurs because the read access to the account.online.link
and account.online.account records is granted only to users having at
least the account.group_account_user group
But, as those accesses are defined to be read only, it should be
greanted also to account.group_account_readonly users
opw-3821540
Forward-Port-Of: odoo/enterprise#59984Deleting 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 Forward-Port-Of: odoo/enterprise#59932
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 Forward-Port-Of: odoo/enterprise#59932
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for following tasks / tickets * Task-3619004 (WhatsApp: Fix variable computation and name) * Task-3680030 (WhatsApp: Fix buttons / template duplication) * Task-3829328 (WhatsApp: Allow to send yellow quality templates) * Task-3644990 (Whatsapp: Fix retrying message with report on template) * Task-
Original PR description
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for…
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for following tasks / tickets * Task-3619004 (WhatsApp: Fix variable computation and name) * Task-3680030 (WhatsApp: Fix buttons / template duplication) * Task-3829328 (WhatsApp: Allow to send yellow quality templates) * Task-3644990 (Whatsapp: Fix retrying message with report on template) * Task-3679715 (WhatsApp: Fix cron block or crash with shared users) * Task-3576712 (WhatsApp: Sync template attachments at sync, avoid missing) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3605612 (WhatsApp: Fix header / upload / reporting usage) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3794483 (WhatsApp: Add account information in template views) * Task-3794365 (WhatsApp: Ease module / variable name change) * Task-3691887 (WhatsApp: Avoid draft templates in event mail schedulers) * Task-3732188 (Whatsapp Event: Avoid crashing registration process) Co-Authored-By: Amélie Dieudonné <amdi@odoo.com> Co-Authored-By: Akshat Trivedi <aktr@odoo.com> Co-Authored-By: Dato Nefaridze <dane@odoo.com> Co-Authored-By: Nishant Jain <niai@odoo.com> Co-Authored-By: Rahul Prajapati <rapr@odoo.com> Co-Authored-By: Noé Antoine <nan@odoo.com> Co-Authored-By: Thibault Delavallée <tde@odoo.com> Forward-Port-Of: odoo/enterprise#59987 Forward-Port-Of: odoo/enterprise#58535
Users with the access right for recruitment set to 'user: referral only' were not able to access applicants even when they are the referree. Now, users have access to all applicants where they are the referee. Task: 3744194 Forward-Port-Of: odoo/enterprise#58589
Original PR description
Users with the access right for recruitment set to 'user: referral only' were not able to access applicants even when they are the referree. Now, users have access to all applicants where they are the referee. Task: 3744194 Forward-Port-Of: odoo/enterprise#58589
During this commit: https://github.com/odoo/enterprise/pull/45792/commits/3a3d9c877f3e8bd2db9e66cd8120d889fd09f125 a xpath was refactored to add the closing attribute for the belgian tax report. Before this commit the xpath wasn't working but didn't cause a traceback. By adding the parenthesis, the last operator can get the last div of the pdf_export_filters template and put after it the different closing attribute. no task id Forward-Port-Of: odoo/enterprise#59453
Original PR description
During this commit: https://github.com/odoo/enterprise/pull/45792/commits/3a3d9c877f3e8bd2db9e66cd8120d889fd09f125 a xpath was refactored to add the closing attribute for the belgian tax report. Before this commit the xpath wasn't working but didn't cause a traceback. By adding the parenthesis, the last operator can get the last div of the pdf_export_filters template and put after it the different closing attribute. no task id Forward-Port-Of: odoo/enterprise#59453
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
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
In General Ledger report, we get an error when trying to reformat value (K$, M$, ..) Steps: - Open GL report - Unfold at least one line - Reformat in any format -> KeyError Reason: `format_column_value()` being called a first time by `get_expanded_lines()`, if there is no `column_dict` we only set `column_dict['name']` to `''`, therefore when calling `format_column_values()` directly from js side, we get a KeyError because column_dict is set but has only `'name'` set on it.
Original PR description
In General Ledger report, we get an error when trying to reformat value (K$, M$, ..) Steps: - Open GL report - Unfold at least one line - Reformat in any format -> KeyError Reason: `format_column_value()` being called a first time by `get_expanded_lines()`, if there is no `column_dict` we only set `column_dict['name']` to `''`, therefore when calling `format_column_values()` directly from js side, we get a KeyError because column_dict is set but has only `'name'` set on it. opw-3793209 Forward-Port-Of: odoo/enterprise#58678
Before this commit, the lowest shipping rate was used as the delivery cost, as in: https://github.com/odoo/enterprise/blob/8c40ba77b23c4ccd24c3785bc1e6cf5b3fbe0e51/delivery_sendcloud/models/sendcloud_service.py#L91 However, the prices received from the Sendcloud are strings, and as a result, this line returned the rate with the lowest lexicographical order. As a result, sometimes the rates with a higher value were chosen. The issue happens when a shipping product costs a single digit amount (
Original PR description
Before this commit, the lowest shipping rate was used as the delivery cost, as in: https://github.com/odoo/enterprise/blob/8c40ba77b23c4ccd24c3785bc1e6cf5b3fbe0e51/delivery_sendcloud/models/sendcloud_service.py#L91 However, the prices received from the Sendcloud are strings, and as a result, this line returned the rate with the lowest lexicographical order. As a result, sometimes the rates with a higher value were chosen. The issue happens when a shipping product costs a single digit amount (e.g. `9.00`) but a second product costs in double digits (e.g. `11.00`). In this case the latter is used which is wrong. This commit, converts the prices to float before comparing them to get the actual best price. opw-3815117 Forward-Port-Of: odoo/enterprise#59536
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/f886e65ce123f06ee8a5a2f149330864bcdb
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
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