Monday, February 3, 2025
49 changes · saas-18.1
Enhancements to existing features
When a live chat conversation ends, the navigation arrow is now shown as a clear “Continue” action. This helps visitors understand what to do next and reduces confusion at the end of support chats.
Original PR description
**Purpose of the PR:** Change the arrow icon to 'Continue' when a live chat conversation has ended to improve user clarity. task-4535875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects a problem in an automated Point of Sale test setup where a simulated function was missing required information. It helps keep internal testing reliable so future changes can be validated with fewer false failures.
Original PR description
Fix args missing in a mocked method in the test. rb error: 114229
Miscellaneous changes
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put `web/static/lib/jquery/jquery.js` in `web.assets_backend` (using custom modules) but not `web/static/src/legacy/js/libs/jquery.js`. Therefore `ensureJQuery` doesn't fetch `web._assets_jquery` and therefore `web/static/src/legacy/js/libs/jquery.js` is never included. __Description of the fix:__ If jQuery is
Original PR description
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put…
__Current behavior before commit:__ jQuery has been removed from `web.assets_backend` in [`b8fc93e`][1], now it's dynamically added with the `ensureJQuery` method. A lot of customers put `web/static/lib/jquery/jquery.js` in `web.assets_backend` (using custom modules) but not `web/static/src/legacy/js/libs/jquery.js`. Therefore `ensureJQuery` doesn't fetch `web._assets_jquery` and therefore `web/static/src/legacy/js/libs/jquery.js` is never included. __Description of the fix:__ If jQuery is present, check if the method `getScrollingElement` is defined in jQuery.fn. If not load `/web/static/src/legacy/js/libs/jquery.js`. __Steps to reproduce the issue in local:__ 1. Add back "web/static/lib/jquery/jquery.js" in the `web.assets_backend` entry of `addons/web/\_\_manifest\_\_.py` to simulate that a customer added it in a custom module. 2. Open the database and Refresh Assets in the debug menu 3. Try to open the editor Crash: "TypeError: $(...).getScrollingElement is not a function" opw-4499576 [1]: https://github.com/odoo/odoo/commit/b8fc93ea97b8 Forward-Port-Of: odoo/odoo#195092
This fixes a small issue in the Accounting app that caused some remote data requests to fail. Business users and integrations should be able to retrieve accounting records normally again without errors from this regression.
Original PR description
The decorator is missing so RPC calls are failing on the model. Introduced by #186908. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal automated test for appointment sales linked to projects by ensuring bookings are created with the correct customer information. It helps keep release validation stable and reduces false failures in the delivery pipeline, with no expected change for end users.
Original PR description
…ling test in saas-18.1 This commit aims to add missing partner_id at the creation of calendar_booking in test_project_user_appointment_type_task_population_on_confirmed_so. related task-3823058 fixes following runbot error: https://runbot.odoo.com/odoo/runbot.build.error/110584
This update adjusts a manufacturing work order test to match stricter rules around changing units of measure. It helps ensure the system correctly reflects that unit changes are blocked when related records do not use the same unit as the product.
Original PR description
Modifiy the test since it's not possible anymore to modify the UoM if all the different record doesn't belong to the same UoM than the product ones.
This update corrects a test setup issue in the point-of-sale settle due feature. It helps keep automated checks reliable so future changes can be validated with fewer false failures.
Original PR description
Fix args missing in a mocked method in the test. rb error: 114229
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195520 Forward-Port-Of: odoo/odoo#194500
Original PR description
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195520 Forward-Port-Of: odoo/odoo#194500
When settling a quotation (unconfirmed sale order) from the POS, the delivered quantity was not updated in the quotation. Steps to reproduce: ------------------- * Make a sale order but don't confirm it * Go to the POS and settle the quotation > Observation: The delivered quantity is not updated in the quotation Why the fix: ------------ If the quotation was not confirmed no move lines were created, so the `has_valued_moves` was False and no move lines were created for the PoS ord
Original PR description
When settling a quotation (unconfirmed sale order) from the POS, the delivered quantity was not updated in the quotation. Steps to reproduce: ------------------- * Make a sale order but don't confirm it * Go to the POS and settle the quotation > Observation: The delivered quantity is not updated in the quotation Why the fix: ------------ If the quotation was not confirmed no move lines were created, so the `has_valued_moves` was False and no move lines were created for the PoS order. And because the pos order has no move lines the quotation was not updated with the delivered quantity. opw-4479862 Forward-Port-Of: odoo/odoo#194420
Before we had no solution to test the synchronisation of the pos. In classic tours websocket are not supported. And we cannot launch two tours in parallel. This commit add the possibility to load test assets in the PoS during our development. That's allow us to launch tour in loop in two different browser and test the synchronisation by creating orders, payment etc. Tour assets are only added by adding `&tours=True` in the URL of the PoS interface. Forward-Port-Of: odoo/odoo#195344
Original PR description
Before we had no solution to test the synchronisation of the pos. In classic tours websocket are not supported. And we cannot launch two tours in parallel. This commit add the possibility to load test assets in the PoS during our development. That's allow us to launch tour in loop in two different browser and test the synchronisation by creating orders, payment etc. Tour assets are only added by adding `&tours=True` in the URL of the PoS interface. Forward-Port-Of: odoo/odoo#195344
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in `purchase.order` - Set a domain with analytic_distribution e.g - - e.g. ("order_line.analytic_distribution", "=", "Administrative") - Click on Refresh button - The refresh button preview shows x records - Create a new purchase.order - Add analytic on op
Original PR description
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in…
Steps:
- Install `purchase` or any other model with analytic_mixin
- Install `analytic`
- Install `web_studio`
- Enable analytic in configuration
- Add a new approval on 'button_confirm' in `purchase.order`
- Set a domain with analytic_distribution e.g
- - e.g. ("order_line.analytic_distribution", "=", "Administrative")
- Click on Refresh button
- The refresh button preview shows x records
- Create a new purchase.order
- Add analytic on optional column
- Add a new product with analytic_distribution Administrative
- Try to use `button_confirm`
- Approval is not working while the refresh shows record is available
The json fields, in particular the `analytic_distribution` fields, are not designed to be searched via a `filtered_domain` (which is what studio approval uses to check whether or not a button can be used by the current user), this is currently a technical limitation.
To avoid any future problems, this commit prevents users from using a json field to search on them, since this is not supported.
opw-4416646
Forward-Port-Of: odoo/odoo#195972
Forward-Port-Of: odoo/odoo#195765After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Original PR description
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field
Original PR description
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field does not appear. - Attempt to submit the form. - Bug: the form is not sent and there is an error message. The error occurs preventing the record from being created because all required fields are not present, we should use the default value as it has been provided. This commit prevents adding the "disabled" attribute to inputs that are required for models. opw-4447039 Forward-Port-Of: odoo/odoo#195952 Forward-Port-Of: odoo/odoo#194902
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task
Original PR description
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task- 4494040 Forward-Port-Of: odoo/odoo#195102 Forward-Port-Of: odoo/odoo#194465
Miscellanous improvements to the Print & Send and to Peppol onboarding: - Nicer translation, warning messages. - Let the bank account be editable when the invoice is posted. Only make it readonly when the invoice is sent. - Some UX change of the EAS fields. - Print & Send: check "email" by default, even when no email is set. We also go back to the default behavior and let a modal open when the email is not set. This will be improved in the generic feature in the future. - Print & Send: Re
Original PR description
Miscellanous improvements to the Print & Send and to Peppol onboarding: - Nicer translation, warning messages. - Let the bank account be editable when the invoice is posted. Only make it readonly when the invoice is sent. - Some UX change of the EAS fields. - Print & Send: check "email" by default, even when no email is set. We also go back to the default behavior and let a modal open when the email is not set. This will be improved in the generic feature in the future. - Print & Send: Rename "Recipients" to "To". - Add a "Print" button to invoice form so that it prints the PDF. - Update the EAS mapping per country. - EAS renaming to be more user-friendly. - Add a Print button to quickly preview the PDF. !this does not trigger a Print & Send wizard => no declaration to government. - Rename Print & Send to "Send" as we did in 18.1+ already. task-4478365 Forward-Port-Of: odoo/odoo#195069
This commit fixes an issue where if the user applies a group by on an aggregatable field (an integer like color_index for example), this field is also registered as an aggregator in the webReadGroup call and this leads to nonsensical results by the orm. After this commit, the group by field is automatically excluded from aggregators so the issue cannot happen. task-4491839 Forward-Port-Of: odoo/odoo#195871 Forward-Port-Of: odoo/odoo#195623
Original PR description
This commit fixes an issue where if the user applies a group by on an aggregatable field (an integer like color_index for example), this field is also registered as an aggregator in the webReadGroup call and this leads to nonsensical results by the orm. After this commit, the group by field is automatically excluded from aggregators so the issue cannot happen. task-4491839 Forward-Port-Of: odoo/odoo#195871 Forward-Port-Of: odoo/odoo#195623
Fixes two bugs on carry over amount: reset accrual carryover to lost state: steps: - set the carry over to "carry over with maximum" - set a number of days to carry over and save - set the carry over type back to "None" -> You still carry over the amount of days you typed in instead of 0 always carryover the cap: steps: - create an accrual plan with: - 21 days per year alloc - start immediate - 28 days cap - carryover with max 7 days - create
Original PR description
Fixes two bugs on carry over amount:
reset accrual carryover to lost state:
steps:
- set the carry over to "carry over with maximum"
- set a number of days to carry over and save
- set the carry over type back to "None"
-> You still carry over the amount of days you typed in instead of 0
always carryover the cap:
steps:
- create an accrual plan with:
- 21 days per year alloc
- start immediate
- 28 days cap
- carryover with max 7 days
- create allocation for the current year (1/1/XXXX)
- take 15 days holidays -> 6 days left on the alloc
- check the leaves left for next year -> 28 days, should be 27 (21 + 6)
This happened because the carry-over calculation didn't take into account
the number of days left on the allocation and always carried over the cap.
Forward-Port-Of: odoo/odoo#190917
Forward-Port-Of: odoo/odoo#188621Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other
Original PR description
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any others field types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195432
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom Font". Notice that the selected font reverts to the "default/system" font. Issue: The issue occurs because when a predefined "we-button" is selected from the dropdown menu(we-button with value i.e. data attributes defined), its value is passed to widgetValue. However, when the "Add a Custom
Original PR description
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom…
Steps to reproduce: 1. Go to Website -> Edit -> Theme section. 2. Choose a predefined font family for the paragraph, such as "Arvo". 4. Return to the font family dropdown and click on "Add a Custom Font". Notice that the selected font reverts to the "default/system" font. Issue: The issue occurs because when a predefined "we-button" is selected from the dropdown menu(we-button with value i.e. data attributes defined), its value is passed to widgetValue. However, when the "Add a Custom Font" button is clicked(which does not have value i.e. data attributes are not defined), the "we-button" value changes to an empty string, which is then passed into widgetValue. As a result, it triggers refreshBundle with the empty string and resets to the default value. Solution: This PR ensures that `_refreshBundles` is not triggered until the widgetValue has a valid (non-empty) value. This prevents the font from being reverted to the default. task-4373983 Forward-Port-Of: odoo/odoo#195848 Forward-Port-Of: odoo/odoo#190329
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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#179592
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represe
Original PR description
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represented correctly in Python (including 7, 3.3 etc.). opw-4485316 Forward-Port-Of: odoo/odoo#195497 Forward-Port-Of: odoo/odoo#195328
Before this commit, a rounding error could leading to scenarios where orders with a zero total could not be validated. For instance, adding a product priced at $70 with a 15% tax included and then applying an eWallet payment in PoS would result in a zero total. However, during the payment step, the system erroneously prompted for an additional zero-amount payment line, causing confusion and preventing order validation. opw-4487591 --- I confirm I have signed the CLA and read the PR
Original PR description
Before this commit, a rounding error could leading to scenarios where orders with a zero total could not be validated. For instance, adding a product priced at $70 with a 15% tax included and then applying an eWallet payment in PoS would result in a zero total. However, during the payment step, the system erroneously prompted for an additional zero-amount payment line, causing confusion and preventing order validation. opw-4487591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195258
Before this commit, the error_checker asserting that a JS unit test run failed performed a strict equality with an outdated string on error logs. Now, the message has been changed, flagged explicitly as something that shouldn't be changed and the presence of that message is checked accross the entire message for robustness. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195947
Original PR description
Before this commit, the error_checker asserting that a JS unit test run failed performed a strict equality with an outdated string on error logs. Now, the message has been changed, flagged explicitly as something that shouldn't be changed and the presence of that message is checked accross the entire message for robustness. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195947
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the du
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Check if the employee if on flexible hours we calcualte the duration as the difference between the date_to and date_from rounded up in days opw-4309551 Forward-Port-Of: odoo/odoo#195223
Colorless tags are always hidden in the frontend interface, this allows to manage them in backend without showing them. Since there's no filter on the `websiteEventTrackProposalFormTags` widget, those tags were still selectable from the website, resulting in the following issues: - Adding useless noise in the selection. - Letting users select tags that are not intended to be selected. - Users could also wrongly select a tag instead of the intended one. Forward-Port-Of: odoo/odoo#195856
Original PR description
Colorless tags are always hidden in the frontend interface, this allows to manage them in backend without showing them. Since there's no filter on the `websiteEventTrackProposalFormTags` widget, those tags were still selectable from the website, resulting in the following issues: - Adding useless noise in the selection. - Letting users select tags that are not intended to be selected. - Users could also wrongly select a tag instead of the intended one. Forward-Port-Of: odoo/odoo#195856
The b2b fields are still required in the portal form even if the "Show b2b fields" is deactivated Steps: - From the website editor, on the checkout form, unselect the "Show b2b fields" setting - Log out and go to ecommerce - Add a product to card and checkout - Fill the address form with a Brazilian address -> Error: "Some required fields are empty." With this commit, we add the field `vat` to the mandatory fields only if the option "Show b2b" fields is activated. opw-4403161 Forward-Port
Original PR description
The b2b fields are still required in the portal form even if the "Show b2b fields" is deactivated Steps: - From the website editor, on the checkout form, unselect the "Show b2b fields" setting - Log out and go to ecommerce - Add a product to card and checkout - Fill the address form with a Brazilian address -> Error: "Some required fields are empty." With this commit, we add the field `vat` to the mandatory fields only if the option "Show b2b" fields is activated. opw-4403161 Forward-Port-Of: odoo/odoo#195888 Forward-Port-Of: odoo/odoo#194110
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On…
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477 ### Fix: Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`. opw-4428050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194068
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet
Original PR description
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet 1 - Drop text snippet 2 and hide it for desktop - Drop text snippet 3 - Remove text snippet 3 - Bug => text snippet 1 is not activated as expected [1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337 [2]: https://github.com/odoo/odoo/commit/2de0ad7259993f654ca8d826f5430f78090a28c5 task-4531506 Forward-Port-Of: odoo/odoo#195941 Forward-Port-Of: odoo/odoo#195743
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c
Original PR description
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id.…
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd - On TODO picking, do the following steps WITHOUT CLICKING ON SAVE - Operations -> Add a line: (demand 0, quantity 0) - Click on 'Open Move' button (fa-list icon) - Popup 'Open: Stock move': Add a line - Popup 'Add line: <product>': click on 'New' - Popup 'Create Move Line': click on 'Save & Close' - Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close' - Validate picking -> Create backorder => Check picking move_line_ids = EMPTY ## Solution Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list). OPW-3974109 Forward-Port-Of: odoo/odoo#171766
… ref, not the name 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#194714
Original PR description
… ref, not the name 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#194714
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from
Original PR description
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from 17.4): - Install website_sale module - Go to /sitemap.xml - Observe that all the products and category urls are duplicated. [1]: https://github.com/odoo/odoo/commit/1b52b00d2aa96b9360d50a0f0960f1febb5e607e opw-4420398 task-4074719 Forward-Port-Of: odoo/odoo#195949
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A traceback occurs during synchronization. Before this commit: ===================== A traceback occurred when making a POS order, printing a receipt in offline mode, and later going online. The issue arose because the nb_print field was updated via a backend write call to restrict payment
Original PR description
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A…
Steps to Reproduce: =================== - Open a POS session and go offline. - Create orders and print receipts at the receipt screen. - Restore the internet connection and bring the POS online. - A traceback occurs during synchronization. Before this commit: ===================== A traceback occurred when making a POS order, printing a receipt in offline mode, and later going online. The issue arose because the nb_print field was updated via a backend write call to restrict payment method edits. However, during offline mode, the order_id was a string, causing the traceback. After this commit: =================== - The backend write call for nb_print is bypassed in offline mode. Instead, the `nb_print` count is updated on the frontend. When the order syncs after going online, the increased `nb_print` value prevents payment method edits as expected. - Removed the nb_print validation constrains from payment lines. Validation is already handled in the write method of pos.order. This change avoids validation errors when syncing orders from offline to online, where nb_print = 1 and payment lines exist. The write method ensures proper handling during order creation. - A `Connection Lost` error message is displayed when attempting to send orders to the kitchen while in offline mode. Task-4504625 Forward-Port-Of: odoo/odoo#194694
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the w
Original PR description
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the website_sequence of conflicting products to ensure all products have unique values. **Affected Versions:** 16.0~master opw-4150099 Forward-Port-Of: odoo/odoo#195880 Forward-Port-Of: odoo/odoo#191297
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent
Original PR description
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent crashes. [1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1#diff-b51336c1ad97255bfb3646f013327eca1904ca194078f4ce671e517096233c58 task-4420262 Forward-Port-Of: odoo/odoo#195940 Forward-Port-Of: odoo/odoo#194976
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
Original PR description
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
Before this commit: ========== - To create a new floor plan, the user must click the plus icon on the floor plan's create button; clicking anywhere else on the floor plan's create button was not working. After this commit: ========== - Users can click anywhere on the floor plan's create button to create a floor plan. task-4517219 Forward-Port-Of: odoo/odoo#195544
Original PR description
Before this commit: ========== - To create a new floor plan, the user must click the plus icon on the floor plan's create button; clicking anywhere else on the floor plan's create button was not working. After this commit: ========== - Users can click anywhere on the floor plan's create button to create a floor plan. task-4517219 Forward-Port-Of: odoo/odoo#195544
Whatsapp API doesn't allow to send captions with audio anymore, therefore we should modify the way we handle captions. After this commit audio will be sent first while text message will stay in a composer, it will only be sent after the audio is sent. task-4007616 Forward-Port-Of: odoo/enterprise#78117 Forward-Port-Of: odoo/enterprise#66818
Original PR description
Whatsapp API doesn't allow to send captions with audio anymore, therefore we should modify the way we handle captions. After this commit audio will be sent first while text message will stay in a composer, it will only be sent after the audio is sent. task-4007616 Forward-Port-Of: odoo/enterprise#78117 Forward-Port-Of: odoo/enterprise#66818
Now we move to february, the test is failing on runbot... See (similar): https://github.com/odoo/enterprise/commit/e29b2265fe60e90443d753558e6c9a071ee23d33 task-no Forward-Port-Of: odoo/enterprise#78346
Original PR description
Now we move to february, the test is failing on runbot... See (similar): https://github.com/odoo/enterprise/commit/e29b2265fe60e90443d753558e6c9a071ee23d33 task-no Forward-Port-Of: odoo/enterprise#78346
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Original PR description
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Original PR description
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
Original PR description
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
task-4478365 Forward-Port-Of: odoo/enterprise#77772
Original PR description
task-4478365 Forward-Port-Of: odoo/enterprise#77772
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
Original PR description
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
From version 18.0, the closing should work fine and there's no need to hide the closing button anymore. This reverts commit cf86ce0e0c7c47336446da5b335cbc53b7602fcd. Forward-Port-Of: odoo/enterprise#77906
Original PR description
From version 18.0, the closing should work fine and there's no need to hide the closing button anymore. This reverts commit cf86ce0e0c7c47336446da5b335cbc53b7602fcd. Forward-Port-Of: odoo/enterprise#77906
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Original PR description
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
Original PR description
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2
Original PR description
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted…
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.
To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
* Recurring plan: Monthly
* Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.
---
Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
self.assertTrue(bool(second_picking))
AssertionError: False is not true
```
OPW-4280155
Forward-Port-Of: odoo/enterprise#73825
Forward-Port-Of: odoo/enterprise#73484The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id Forward-Port-Of: odoo/enterprise#78260
Original PR description
The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id Forward-Port-Of: odoo/enterprise#78260
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#7803
Original PR description
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#78034 Forward-Port-Of: odoo/enterprise#76877