Thursday, January 30, 2025
27 changes · saas-17.4
Resolved issues and error corrections
A Point of Sale issue could create blank orders when depositing money for customers with no outstanding balance and then refreshing the browser. The fix prevents empty, unpaid orders from being synchronized or created, keeping sales records cleaner and avoiding confusion for staff.
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Page titles in the Marketing Card app are now included in translations, so users can see them in their selected language. This improves the experience for multilingual teams and customers without changing how the app works.
Original PR description
[opw-4421055](https://www.odoo.com/odoo/project.task/4504454)
Accounting report lines now keep the intended order after users rearrange them with drag and drop in the report builder. This helps prevent confusing or incorrect report layouts when configuring reports in the enterprise interface.
Original PR description
Issue: When using the enterprise version, and configuring an accounting report with the report builder, issues might arise when changing the sequence of lines (using the drag and drop feature). Combined with the enterprise PR, this commit solves the issue by returning the lines ordered by sequence. Enterprise PR: https://github.com/odoo/odoo/pull/187907#pullrequestreview-2581564549 task-4328098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can now add a custom font without losing the font they already selected. This prevents unexpected changes to page styling and makes theme customization more reliable.
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 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
The Sign app onboarding helper text is now set up correctly for translation. This ensures users working in different languages can see the guidance in their chosen language instead of untranslated text.
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)
Customer deposits for accounts with a zero balance no longer create blank point-of-sale orders after a browser refresh. This keeps sales records cleaner and avoids confusion from unintended empty orders.
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049
Miscellaneous changes
The World Map view when you are on the "/partners" page doesn't zoom. This happens when any of the partners that are getting rendered doesn't have a location (longitude and latitude). Geocoder is then used to locate those addresses on the map. We use Promises, and when there is an error, we're not catching it where we are calling it from. The failed Geocode triggers the reject, which is not caught, and we're stuck in the await Promise. The zoom-in line never gets called. Steps to Rep
Original PR description
The World Map view when you are on the "/partners" page doesn't zoom. This happens when any of the partners that are getting rendered doesn't have a location (longitude and latitude). Geocoder is then used to locate those addresses on the map. We use Promises, and when there is an error, we're not catching it where we are calling it from. The failed Geocode triggers the reject, which is not caught, and we're stuck in the await Promise. The zoom-in line never gets called. Steps to Reproduce on Runbot: Integrate the Google Place Map key via Settings -> Geolocation -> Google Place Map. Go to "/partners." Toggle on the world map view for the page via the editor. Ensure one partner on the page lacks a location. Go to the "map" view, and the map will not zoom in. opw-4319619 Forward-Port-Of: odoo/odoo#189518
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#194110
… ref, not the name For Bizkaia, when we send the invoices, the numfactura and seriefactura should be the name of the vendor and the one of the customer. In order to make it possible to correct it and to cancel an invoice with the previous way of doing, we check in the original XML what the dates sent were. opw-4498833 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CL
Original PR description
… ref, not the name For Bizkaia, when we send the invoices, the numfactura and seriefactura should be the name of the vendor and the one of the customer. In order to make it possible to correct it and to cancel an invoice with the previous way of doing, we check in the original XML what the dates sent were. opw-4498833 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#195113
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#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#195623
The reCAPTCHA feature is currently controlled by the "Module Installation" setting: `module_google_recaptcha`, which, due to dependencies, caused the removal of many other modules when disabled. The goal of this commit is to simply hide this option in stable to prevent this misleading behaviour. A user can still disable the reCAPTCHA checks by removing API keys (Which was already mentioned on the setting block) The feature behaviour will be updated in master to allow disabling reCA
Original PR description
The reCAPTCHA feature is currently controlled by the "Module Installation" setting: `module_google_recaptcha`, which, due to dependencies, caused the removal of many other modules when disabled. The goal of this commit is to simply hide this option in stable to prevent this misleading behaviour. A user can still disable the reCAPTCHA checks by removing API keys (Which was already mentioned on the setting block) The feature behaviour will be updated in master to allow disabling reCAPTCHA without uninstalling the modules. task-3380702 Forward-Port-Of: odoo/odoo#194907
**Current behavior before PR:** Push notifications displayed the Odoo Bot icon regardless of the actual message author. **Desired behavior after PR is merged:** The push notifications now correctly display the avatar of the message author. Task-[4510479](https://www.odoo.com/odoo/project/1519/tasks/4510479) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195219
Original PR description
**Current behavior before PR:** Push notifications displayed the Odoo Bot icon regardless of the actual message author. **Desired behavior after PR is merged:** The push notifications now correctly display the avatar of the message author. Task-[4510479](https://www.odoo.com/odoo/project/1519/tasks/4510479) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195219
The credit limit in the partner form view was missing a currency symbol, leading to ambiguity about whether the limit was in the customer's currency or the company's currency. Displayed the partner limit in the company currency to avoid confusion. task-4507336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195325 Forward-Port-Of: odoo/odoo#194807
Original PR description
The credit limit in the partner form view was missing a currency symbol, leading to ambiguity about whether the limit was in the customer's currency or the company's currency. Displayed the partner limit in the company currency to avoid confusion. task-4507336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195325 Forward-Port-Of: odoo/odoo#194807
In https://github.com/odoo/odoo/pull/127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347 Forward-Port-Of: odoo/odoo#194600
Original PR description
In https://github.com/odoo/odoo/pull/127877, the active field was removed and replaced with state: cancel. This domain was modified but removed the check for the cancelled state. opw-4420347 Forward-Port-Of: odoo/odoo#194600
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3 different fonctionalities (a foot switch can work as a keyboard, a mouse and a joystick) Our current code only detects input from one of these 3 event files (the last one in the list) while the input is actually only sent to the keyboard event file. Since "evdev" and "usb core" libraries don't allow us t
Original PR description
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3…
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3 different fonctionalities (a foot switch can work as a keyboard, a mouse and a joystick) Our current code only detects input from one of these 3 event files (the last one in the list) while the input is actually only sent to the keyboard event file. Since "evdev" and "usb core" libraries don't allow us to determine which evdev device is the right one this PR allows listening to all of the event files associated to a usb device to read input from all of them. This PR also adds some comment to simplify the understanding of the input detection and event files structure on Linux. Note: on IoT Box images > 25.01 the user "odoo" which runs Odoo service needs to be in the group "input" to be able to correctly detect evdev devices and have access to their event files. task-4432802 Related PR: #195307 Forward-Port-Of: odoo/odoo#195306
This PR is backporting of these commits: [1] Commit https://github.com/odoo/odoo/commit/a1b7d8aba255ec477a030d44897b8ea73d1f37e7 [2] Commit https://github.com/odoo/odoo/commit/3653131d32997392b2170ce542bfc544fd96bef2 These commits introduce the computation of fiscal positions for sales and purchase documents based on the place of supply. While these changes are already merged into version 18.1, they are now required in version 17.0. --- I confirm I have signed the CLA and read
Original PR description
This PR is backporting of these commits: [1] Commit https://github.com/odoo/odoo/commit/a1b7d8aba255ec477a030d44897b8ea73d1f37e7 [2] Commit https://github.com/odoo/odoo/commit/3653131d32997392b2170ce542bfc544fd96bef2 These commits introduce the computation of fiscal positions for sales and purchase documents based on the place of supply. While these changes are already merged into version 18.1, they are now required in version 17.0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195633 Forward-Port-Of: odoo/odoo#195399
When a note was logged or a message was posted on any move, the email recipients of that message would get an email with both the move name and the total move amount (without any context) in the header. For invoices and vendor bills, this makes sense. As these are typically amounts that can be paid or received. However, for miscellaneous moves this was confusing users. Often it means nothing, and users wonder if they have to pay something. We remove the amount from messages sent on miscell
Original PR description
When a note was logged or a message was posted on any move, the email recipients of that message would get an email with both the move name and the total move amount (without any context) in the header. For invoices and vendor bills, this makes sense. As these are typically amounts that can be paid or received. However, for miscellaneous moves this was confusing users. Often it means nothing, and users wonder if they have to pay something. We remove the amount from messages sent on miscellaneous moves here. [opw-4042715](https://www.odoo.com/odoo/project.task/4042715) Forward-Port-Of: odoo/odoo#195647 Forward-Port-Of: odoo/odoo#195541
### Description of the issue/feature this PR addresses: - Similar error: https://github.com/odoo/odoo/pull/194338 - In `_compute_plan_available_ids()` with `self` there can be multiple records but still use `self.department_id` in `for scheduler in todo`. ### Current behavior before PR: - The error ValueError: Expected singleton: mail.activity.schedule(1, 2) occurred Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read
Original PR description
### Description of the issue/feature this PR addresses: - Similar error: https://github.com/odoo/odoo/pull/194338 - In `_compute_plan_available_ids()` with `self` there can be multiple records but still use `self.department_id` in `for scheduler in todo`. ### Current behavior before PR: - The error ValueError: Expected singleton: mail.activity.schedule(1, 2) occurred Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194650
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but no
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but not for partners. Instead it relies on the partner's country_id, which could be empty. Solution -------- When computing the `property_product_pricelist`, add the geoip country to the context. Use this value in the fallback for partners without specific pricelist property set, and without a `country_id`. opw-4398543 Forward-Port-Of: odoo/odoo#194885
Steps to Reproduce: ========= - Install the modules: pos_razorpay, l10n_in, and pos_restaurant. - Create a payment method for the Razorpay terminal. - Open a restaurant register linked to an Indian company with the added Razorpay terminal payment method. - Create an order, add a Razorpay payment line, and navigate to the floor screen. Issue: ========== - A traceback occurs when completing a payment. Cause: ========= - Polling for the Razorpay terminal continues even after leaving
Original PR description
Steps to Reproduce: ========= - Install the modules: pos_razorpay, l10n_in, and pos_restaurant. - Create a payment method for the Razorpay terminal. - Open a restaurant register linked to an Indian company with the added Razorpay terminal payment method. - Create an order, add a Razorpay payment line, and navigate to the floor screen. Issue: ========== - A traceback occurs when completing a payment. Cause: ========= - Polling for the Razorpay terminal continues even after leaving the payment screen and navigating to the floor screen. Fix: ========= - Stop the polling process when the user leaves the payment screen. - Resume polling only when the user returns to the payment screen. task-4414016 Forward-Port-Of: odoo/odoo#192072
Since the "new" Chrome's headless mode (default starting with version 128), the tour testing the accounting's bank reconciliation widget fails on some steps while selecting and editing the entry's line amount. More precisely, but without absolute certainty, this looks to be a concurrency issue between the selection of the line, the update of the notebook's form and the focus of the related field (for quick edition). While the failing step relies solely on the field being focused (which
Original PR description
Since the "new" Chrome's headless mode (default starting with version 128), the tour testing the accounting's bank reconciliation widget fails on some steps while selecting and editing the entry's line amount. More precisely, but without absolute certainty, this looks to be a concurrency issue between the selection of the line, the update of the notebook's form and the focus of the related field (for quick edition). While the failing step relies solely on the field being focused (which is finicky on headless browser where the "focus" needs to be emulated), this commit works around this issue by checking on the entry's line selected instead. Note: while being an issue in automated test, the feature operated by an actual user is working properly. Forward-Port-Of: odoo/enterprise#78005 Forward-Port-Of: odoo/enterprise#77644
- make kiosk mode open in the same page and logout the user to avoid unwanted rights Task: 4509632 Forward-Port-Of: odoo/enterprise#77852
Original PR description
- make kiosk mode open in the same page and logout the user to avoid unwanted rights Task: 4509632 Forward-Port-Of: odoo/enterprise#77852
We already support the non-SEPA ISO 20022 method in the `account_sepa` module. However, we were still requiring the origin bank account to be an IBAN account, according to SEPA rules. However, since ISO 20022 can be used outside of the SEPA zone, we don't need to check for an IBAN in that case. This commit fixes that, so non IBAN bank accounts can use ISO 20022 payments. Forward-Port-Of: odoo/enterprise#78023 Forward-Port-Of: odoo/enterprise#77873
Original PR description
We already support the non-SEPA ISO 20022 method in the `account_sepa` module. However, we were still requiring the origin bank account to be an IBAN account, according to SEPA rules. However, since ISO 20022 can be used outside of the SEPA zone, we don't need to check for an IBAN in that case. This commit fixes that, so non IBAN bank accounts can use ISO 20022 payments. Forward-Port-Of: odoo/enterprise#78023 Forward-Port-Of: odoo/enterprise#77873
At the moment, when grouping by a selection field, the in-database name of the selection option is shown rather than the human-readable name. This is fixed by the present commit. task-none Forward-Port-Of: odoo/enterprise#78145 Forward-Port-Of: odoo/enterprise#78128
Original PR description
At the moment, when grouping by a selection field, the in-database name of the selection option is shown rather than the human-readable name. This is fixed by the present commit. task-none Forward-Port-Of: odoo/enterprise#78145 Forward-Port-Of: odoo/enterprise#78128
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor, click on the instruction to open a dialog. - Spam the Pass button #### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId') ### Cause of the issue: Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a
Original PR description
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor,…
### Steps to reproduce:
- Create a bom for a product FP:
- 1 x COMP (component)
- operations: OP1:
- instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button
#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')
### Cause of the issue:
Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.
### Fix:
We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).
### Note:
By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.
opw-4352828
Forward-Port-Of: odoo/enterprise#77262
Forward-Port-Of: odoo/enterprise#74795Versions -------- - 17.0 - saas-17.2 - saas-17.4 - 18.0 Default automation rules were removed from the module via ca5de2aea907 Steps ----- 1. Copy a default automation from Subscriptions; 2. try to edit it. Issue ----- Action form is readonly, displaying the following message: > Action data can not be updated to avoid unexpected behaviors. Create a new automation rule instead. This makes sense for the default automations, but copies should be editable. Cause ----- T
Original PR description
Versions -------- - 17.0 - saas-17.2 - saas-17.4 - 18.0 Default automation rules were removed from the module via ca5de2aea907 Steps ----- 1. Copy a default automation from Subscriptions; 2. try to edit it. Issue ----- Action form is readonly, displaying the following message: > Action data can not be updated to avoid unexpected behaviors. Create a new automation rule instead. This makes sense for the default automations, but copies should be editable. Cause ----- The Subscriptions module adds a `is_sale_order_alert` field to its automations to make them readonly. This field is copied when duplicating an automation. Solution -------- Add `copy=False` to the field declaration to make copies editable. opw-4055597 Forward-Port-Of: odoo/enterprise#77008
**Issue:** Sometimes "test_select_sublines_with_same_product_and_lot" tour is failing. **Cause:** It could be due to consecutive actions (scan of the lot) that are executed too quickly. **Solution:** Add an extra step after scanning a lot to check the DOM and wait if necessary before scanning another lot. opw-4208612 Forward-Port-Of: odoo/enterprise#78120 Forward-Port-Of: odoo/enterprise#77998
Original PR description
**Issue:** Sometimes "test_select_sublines_with_same_product_and_lot" tour is failing. **Cause:** It could be due to consecutive actions (scan of the lot) that are executed too quickly. **Solution:** Add an extra step after scanning a lot to check the DOM and wait if necessary before scanning another lot. opw-4208612 Forward-Port-Of: odoo/enterprise#78120 Forward-Port-Of: odoo/enterprise#77998