Daily updates from Odoo
Navigate
Branch
Thursday, January 30, 2025
78 changes
14 changes
Resolved issues and error corrections
This fix prevents Odoo from totaling the same numeric field that users choose for grouping records. It avoids confusing or incorrect grouped results, making views such as Kanban more reliable for everyday analysis.
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
The website partner map now continues to zoom correctly even when some partner records do not have saved latitude and longitude details. This prevents one incomplete or unresolvable address from blocking the map display for visitors.
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
Miscellaneous changes
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#195541
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
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#195399
### 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
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
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
**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 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
… 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
Versions -------- - 16.0 Backport of https://github.com/odoo/odoo/pull/195266 Issue ----- Use `float_compare` to compare floating point amounts on reward validation. Forward-Port-Of: odoo/odoo#195679 Forward-Port-Of: odoo/odoo#195637
Original PR description
Versions -------- - 16.0 Backport of https://github.com/odoo/odoo/pull/195266 Issue ----- Use `float_compare` to compare floating point amounts on reward validation. Forward-Port-Of: odoo/odoo#195679 Forward-Port-Of: odoo/odoo#195637
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
**Problem**: `this.state.showCodeView` cannot be relied upon because `toggleCodeView` of `HtmlField` is never called in cases like mass mailing. Instead, `MassMailingSnippetsMenu` forces code view without using the `HtmlField` mechanism. **Solution**: Instead of checking `this.state.showCodeView`, directly check the return value of `this._getCodeViewEl()` in `MassMailingHtmlField`. **Steps to Reproduce**: 1. Add an Image-Text snippet. 2. Save the snippet. 3. Resize the image. 4.
Original PR description
**Problem**: `this.state.showCodeView` cannot be relied upon because `toggleCodeView` of `HtmlField` is never called in cases like mass mailing. Instead, `MassMailingSnippetsMenu` forces code view without using the `HtmlField` mechanism. **Solution**: Instead of checking `this.state.showCodeView`, directly check the return value of `this._getCodeViewEl()` in `MassMailingHtmlField`. **Steps to Reproduce**: 1. Add an Image-Text snippet. 2. Save the snippet. 3. Resize the image. 4. Switch to code view. 5. Save. 6. Observe that the class `o_modified_image_to_save` is not removed from the image. opw-4406195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195587 Forward-Port-Of: odoo/odoo#195539
19 changes
Enhancements to existing features
Document-related settings are streamlined by removing rarely used default folder options, improving labels, and hiding empty configuration sections. Some apps now centralize documents by default, while Projects gains a clearer setting to choose where new project folders are created.
Original PR description
[IMP] documents_spreadsheet: remove default folder We remove the spreadsheet default folder from the settings and make all spreadsheets lands into My Drive if they were created from somewhere else…
[IMP] documents_spreadsheet: remove default folder
We remove the spreadsheet default folder from the settings and make all spreadsheets lands into My Drive if they were created from somewhere else than Documents.
[IMP] documents_sign: remove sign base folder
We remove the base folder configuration for sign. That folder was used as base folder when creating a folder in the sign app. It's still possible to create a folder on the fly in the sign app but the parent folder is not configurable anymore.
We also change the wording of the link to the sign document templates in the settings.
[IMP] documents_project: allow to configure base folder
We add a settings allowing the user to choose the base folder where new project
folders will appear.
[IMP] documents_{*}: rename workspace label as folder
[IMP] documents_{*}: avoid file centralization empty settings block
When installing only documents, an empty section "Files centralization" is present in the settings.
We solve the problem by making invisible by default when it is declared in the documents App and make it visible in all module that add a setting in that block.
[IMP] documents_{*}: reword some labels of the "Files centralization" settings
We reword some labels of the "Files centralization" settings.
[IMP] documents_{*}: enable by default document centralization for some modules
We enable by default the document centralization for some modules.
Note that the post init is necessary as the module only set the folder for the main company and other company can exist at the install of those module. A simple way to test that is to install stock (which create "My company (Chicago)") and documents_hr. We apply the same correction to documents_fleet for which the document centralization was already enabled by default.
[IMP] documents, documents_{*}: rename internal as administrative folder
We rename the internal folder as administrative folder as internal doesn't mean much. We have decided to not rename the xmlid as it is used in the code of the server action which is complex to update.
Task-4294237The room booking module’s automated tests were moved to a newer testing framework. This is an internal quality improvement that helps maintain reliability without changing how users book or manage rooms.
Original PR description
This PR aims to convert QUnit tests to hoot. Part of Task-3818666
Odoo now stores and shows the filing status of invoices for Indian GSTR-1 reporting. This helps users quickly identify invoices that were not included in a filed return, reducing reconciliation effort and mismatches with the GST portal.
Original PR description
- Currently, if the user files a return and the accountant posts a dated invoice, it also appears in filed GSTR-1 in ODOO. which creates conflict with the actual return filed and data available over the GST portal. It's time-consuming for the user to find out the transaction that got skipped. - This functionality of status would help users to easily identify the records not sent for GSTR-1. task - 3953623
This update refreshes specific Mexico electronic invoicing payment test cases to better reflect expected behavior when payments and invoices use different currencies. It helps maintain confidence that Mexican localization workflows continue to calculate and validate payment balances correctly.
Original PR description
updating the below-mentioned test cases: - test_foreign_curr_payment_comp_curr_invoice_forced_balance - test_comp_curr_payment_foreign_curr_invoice_forced_balance task - 3707383 Community PR - https://github.com/odoo/odoo/pull/165077 Enterprise PR - https://github.com/odoo/enterprise/pull/62442 Upgrade PR - https://github.com/odoo/upgrade/pull/6014
Resolved issues and error corrections
Odoo Sign now adds an extra confirmation step before a signature request can be refused from an email link. This prevents automated corporate email scanners from accidentally cancelling signature requests, improving reliability for customers using tools such as Microsoft Office365.
Original PR description
Several enterprise email solutions, including Microsoft's Office365 package, include automated email scanning as a premium feature. These scanners may automatically click any number of links in received emails at time of reception, triggering (and invalidating) magic links. In Sign, this would automatically refuse any incoming signature request if the sending email address is flagged by Microsoft as "suspicious". To combat this, an intermediate screen with a form possessing a single button is added, as while the safety bot does send forms it also strips them of their parameters (including the CSRF token), invalidating them. See task-3972953 for more information about Microsoft's email scanning feature task-4016343
Code cleanup and technical improvements
This change updates Field Service and Studio screens to reuse cached field information instead of repeatedly requesting it directly. It should make related pages more efficient without changing how users work.
Original PR description
The field service caches fields_get results. Here we replace some direct calls to fields_get via the orm by calls to the method loadFields of field service.
This internal change updates spreadsheet-related test utilities so they return the test environment needed by related checks. It helps keep spreadsheet sales and list testing aligned with the main platform changes, reducing maintenance risk without changing user-facing behavior.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/195552 Task: 4525938
Miscellaneous changes
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
Original PR description
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
When opening the Invoice Overdue through the partner form: 1 - Create over due MISC entries (through deferred entries for example) 2 - Open a partner 3 - Go the the Accounting tab 4 - Click the Overdue Invoices button -> Some MISC entries show while we only want to view sale document. This commit fixes that by adding a filter on the domain to reduce the search scope to only sale documents. task-4523037 Forward-Port-Of: odoo/enterprise#78095
Original PR description
When opening the Invoice Overdue through the partner form: 1 - Create over due MISC entries (through deferred entries for example) 2 - Open a partner 3 - Go the the Accounting tab 4 - Click the Overdue Invoices button -> Some MISC entries show while we only want to view sale document. This commit fixes that by adding a filter on the domain to reduce the search scope to only sale documents. task-4523037 Forward-Port-Of: odoo/enterprise#78095
Steps to reproduce: - Create a new accounting report - Create a new line - Set a value in the groupby field -> A warning appears, stating that the line uses a custom user-defined "group by" value. This warning is only useful when modifying a groupby value for a line that has a xmlid. task-4286306 Forward-Port-Of: odoo/enterprise#78067 Forward-Port-Of: odoo/enterprise#74526
Original PR description
Steps to reproduce: - Create a new accounting report - Create a new line - Set a value in the groupby field -> A warning appears, stating that the line uses a custom user-defined "group by" value. This warning is only useful when modifying a groupby value for a line that has a xmlid. task-4286306 Forward-Port-Of: odoo/enterprise#78067 Forward-Port-Of: odoo/enterprise#74526
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not readonly, causing the ORM to perform an inverse related and update the company's `currency_id`. This is problematic since changing the currency triggers a massive recompute of nearly all accounting records unnecessarily. For example, in the case of this customer, it was trying to update 191219 account
Original PR description
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not…
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not readonly, causing the ORM to perform an inverse related and update the company's `currency_id`. This is problematic since changing the currency triggers a massive recompute of nearly all accounting records unnecessarily. For example, in the case of this customer, it was trying to update 191219 account.analytic.line, which caused this memory error. The initial design aimed to show the monetary symbol on the form when the `onchange` in `web/models/models.py` was triggered, but this approach led to the issue. ### Fix: By adding `company_id` to the view as an invisible field, the onchange can retrieve it to display the monetary symbol without triggering the problem. This change is backward-compatible; customers who haven't updated their views will only miss the monetary symbols on the form view until the record is saved. ### Reference: opw-4486739 Forward-Port-Of: odoo/enterprise#77990
Using a newly created payslip structure for Mexico it is not possible to generate payslips Steps to reproduce: - With an MX Company setup - Go to Payroll > Configuration > Salary > Structures - Create new structure with the following attributes: - Type: "Mexico: employee" - Country: "Mexico" - Go to Payroll > Payslips > Batches, create a new batch - Click "Generate Payslips" - Select the freshly created salary structure in the wizard, then click "Generate" Issue: An error is ra
Original PR description
Using a newly created payslip structure for Mexico it is not possible to generate payslips Steps to reproduce: - With an MX Company setup - Go to Payroll > Configuration > Salary > Structures - Create new structure with the following attributes: - Type: "Mexico: employee" - Country: "Mexico" - Go to Payroll > Payslips > Batches, create a new batch - Click "Generate Payslips" - Select the freshly created salary structure in the wizard, then click "Generate" Issue: An error is raised while creating the payslip Error: float() argument must be a string or a real number, not 'NoneType' This occurs because we don't have a fallback in `_get_paid_amount` opw-4328900 Forward-Port-Of: odoo/enterprise#78058 Forward-Port-Of: odoo/enterprise#77277
Steps to reproduce: 1) install document_hr_recruit module 2) create an application and upload an attachment to it 3) go to the kanban view and click on the attachment icon on the right bottom 4) it will lead you to the document view instead of the document Cause : In the document settings, there’s a recruitment option to select the folder for job positions and application documents. By default, the setting should be 'Recruitment', but the visibility is not configured in the code Fix:
Original PR description
Steps to reproduce: 1) install document_hr_recruit module 2) create an application and upload an attachment to it 3) go to the kanban view and click on the attachment icon on the right bottom 4) it will lead you to the document view instead of the document Cause : In the document settings, there’s a recruitment option to select the folder for job positions and application documents. By default, the setting should be 'Recruitment', but the visibility is not configured in the code Fix: We will provide 'view' access to the folder Task-4348197 Forward-Port-Of: odoo/enterprise#77794 Forward-Port-Of: odoo/enterprise#74950
Steps to reproduce: ----- - Create a FSM task - Add products - Mark as done - Create invoice - Duplicate the task Issue: ----- The newly created task is linked to the invoice of the duplicated task. This comportment is not intended. Fix: ---- Creation of the copy method so the sale_order_id and the sale_line_id get set to false when duplicating a record. opw-4393596 Forward-Port-Of: odoo/enterprise#77797 Forward-Port-Of: odoo/enterprise#76547
Original PR description
Steps to reproduce: ----- - Create a FSM task - Add products - Mark as done - Create invoice - Duplicate the task Issue: ----- The newly created task is linked to the invoice of the duplicated task. This comportment is not intended. Fix: ---- Creation of the copy method so the sale_order_id and the sale_line_id get set to false when duplicating a record. opw-4393596 Forward-Port-Of: odoo/enterprise#77797 Forward-Port-Of: odoo/enterprise#76547
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
Change an f-string into an sql.identifier for injection prevention Forward-Port-Of: odoo/enterprise#77956
Original PR description
Change an f-string into an sql.identifier for injection prevention Forward-Port-Of: odoo/enterprise#77956
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product -
Original PR description
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule…
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product - Confirm the SO - Create another SO for the same customer with the same product => A delivery order should be created with 2 operations with the same product - Open the delivery order in Barcode - Scan the source location - Select the 2nd line - Scan the lot **Issue:** The first line is incremented instead of the second one. Even when all the products for the first line will be scanned, it will not be possible to scan the lot to increment the second line. **Cause:** The selected line is not taken into account when searching the line on which the scanned lot should be applied. **Solution:** Unshift the selected line to the first position of the array of lines to prioritize it when searching for the adequate line for a scanned lot. opw-4208612 Forward-Port-Of: odoo/enterprise#78122 Forward-Port-Of: odoo/enterprise#76713
**Before this PR:** Upload fails(normal) but there is no proper error message. **Technical:** We previously received an error message in the "handleUploadError" function, such as "result.error." However, after the commit https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e, the error now appears directly in the "result". **After this PR:** An appropriate error message will be shown. Task-4357390 Forward-Port-Of: odoo/enterprise#75344
Original PR description
**Before this PR:** Upload fails(normal) but there is no proper error message. **Technical:** We previously received an error message in the "handleUploadError" function, such as "result.error." However, after the commit https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e, the error now appears directly in the "result". **After this PR:** An appropriate error message will be shown. Task-4357390 Forward-Port-Of: odoo/enterprise#75344
**Issue:** A error shows up when trying to insert a grouped and ordered list into spreadsheet. **Expected:** The displayed list, even if groups or orders are applied, should be insertable into spreadsheet. **Steps to reproduce:** - Activate Employees app (or any app using lists and allowing to group results) and enter in it; - Display employees as a list; - Add a `Group By` constraint (e.g. `Manager`) and order it by clicking the 2 arrows (appearing on hover);  - Open a toggled section; - Select several (or all) employees; - Using `Actions`, try `Insert in spreadsheet`. **Cause:** The list renderer doesn't manage the `Group By` constraints. **Fix:** Ignore grouped constraints. opw-4254376 Forward-Port-Of: odoo/enterprise#78022 Forward-Port-Of: odoo/enterprise#76283
45 changes
New functionality added to Odoo
Odoo now supports Envia as a delivery provider, giving businesses access to a broad network of carriers across the Americas and other supported countries. This helps companies offer more shipping options and manage deliveries through a single aggregator integration.
Original PR description
Envia is a delivery aggregator for North and South America that supports a large subset of carriers in the area. It integrates with the main carriers used in: Argentina, Australia, Brazil, Canada, Chile, Colombia, Spain, Guatemala, India, Mexico, United States, and Uruguay task-4056309 odoo PR: https://github.com/odoo/odoo/pull/174098
Enhancements to existing features
This update makes invoice sending clearer and easier by renaming Print & Send to Send, improving labels and warnings, and adding quick PDF print/preview actions. It also improves Peppol onboarding with more user-friendly EAS fields and updated country mappings, while allowing bank account edits until an invoice is actually sent.
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
The point of sale receipt screen now hides the Edit Payment button once a receipt has been printed when employee-based POS features are installed. This prevents staff from seeing an action that should no longer be available after completing the sale receipt flow.
Original PR description
Before this commit: =============== - The 'Edit Payment' button appears even after printing the receipt. (only when pos_hr installed) After this commit: =============== - The 'Edit Payment' button will disappear after printing the receipt. task-4507326 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance kiosk mode now opens directly instead of first showing a popup, reducing an extra step for users. An install button has also been added in the kiosk view, making setup easier from the same screen.
Original PR description
**Specifications:** - remove modal when user click on kiosk mode and directly open kiosk view. - add an install button in kiosk view **After this PR:** Modal will be removed while opening kiosk mode in hr_attendance. Task-4161336
Event staff can now open the registration desk view directly instead of first seeing a kiosk modal. The desk view also includes an Install button, making setup or access more convenient during event operations.
Original PR description
**Specifications:** - remove modal when user click on registration desk and directly open desk view. - Add an Install button in desk view **After this PR:** Modal will be removed while opening kiosk mode in event. Task-4161336
Frontdesk users can now open a desk directly in kiosk mode without first seeing a modal dialog. The kanban card menu also includes an install button, making setup actions easier to find.
Original PR description
**Specifications:** - remove modal when user click on open desk and directly open kiosk view. - add an install button in menu-item in kanban card **After this PR:** Modal will be removed while opening kiosk mode in frontdesk Task-4161336
Resolved issues and error corrections
This fixes Spanish TicketBAI reporting for Bizkaia so vendor bills send the supplier reference instead of the internal invoice name. It helps ensure submitted invoice data matches official supplier documents and supports correcting or cancelling invoices created with the previous numbering behavior.
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
This update fixes a small issue in sales PDF quote building so available product documents are calculated correctly when multiple sales orders are processed together. It helps keep generated quotes consistent and avoids missing or incorrect document options in batch operations.
Original PR description
This fix addresses a minor issue with the `_compute_available_product_document_ids` method of `sale.order`, which doesn't fully support multi-compute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now treats an order as a refund only when every line is negative, rather than when just some lines are negative. This prevents loyalty rewards from being incorrectly affected on mixed orders that include both sales and negative lines.
Original PR description
Assuming that an order is a refund with the presence of some negative lines is not compatible with the current implementation of pos_loyalty rewards. In this PR, we make an assumption that is valid in most cases than previous, such that an order is a refund if all of its lines are negative.
Fixes an issue where downloading a PDF for an unconfirmed invoice could fail with an error. Business users can now export draft invoice PDFs reliably from the invoice list, avoiding disruption during invoice preparation.
Original PR description
Steps to reproduce the error: - Create a new invoice. Don't confirm it. - Go to list view of invoices. - Select that invoice > Download > PDF Traceback: "AttributeError: 'bool' object has no attribute 'replace'" `_get_move_display_name` can be used instead as it already handles draft invoices. sentry-6191644587
Manufacturing order overviews now calculate expected bill of materials costs using the same workcenter assumptions as the bill of materials overview. This makes planned versus actual production cost comparisons more reliable by including time efficiency, setup time, and cleanup time.
Original PR description
Steps to reproduce the bug:
- Create a workcenter “WC1”:
- Cost by hour: 60
- Setup time: 10 min
- Cleanup time: 10 min
- Time Efficiency: 85
- Create a storable product “P1” with the following BoM:
- Operation: OP1 -> 60 min in WC1
- Create a MO to produce one unit of P1:
- Confirm the MO
- Go to the MO overview
Problem:
Time Efficiency, setup, and cleanup times are not taken into account in
the BoM Cost calculation.
The calculation should be the same as in the BoM overview. The purpose
of the BoM cost in the MO overview is to provide information for
comparison with the real cost, in case the user has modified certain
parameters during production.
Attention: There may be a slight difference in the calculation of
"mo_cost" and "bom_cost" because the expected duration is rounded to
two digits in the work order. This affects the mo_cost calculation
since it relies directly on this field,
opw-4478070This fix ensures carousel control options behave correctly when editing a website page. Business users get a more reliable preview and setup experience when choosing whether carousel arrows and indicators are hidden or centered.
Original PR description
Since [1], a method was introduced to prevent the "controllers" options from being centered when arrows and indicators are displayed. However, it was implemented in the wrong overridden method (computeWidgetState), which cannot update the DOM. Additionally, it failed to account for the preview mode. This commit resolves these issues. Steps to reproduce: - Website - Edit mode - Drag and drop a "carousel intro" snippet onto the page. - Select the option "Controllers > Arrows > Hidden." - Then select the option "Controllers > Centered." - The controllers are now displayed as centered. - Hover over the "Controllers > Arrows" options and preview a value other than "Hidden." - The preview does not update correctly. [1]: https://github.com/odoo/odoo/commit/454d743ed631c068b7b0bc72e4fd81b225a5ac52 Related to: task-4094405
The hierarchy view icon now appears in the intended tree-like orientation as soon as it is shown. This avoids a confusing visual glitch where the icon initially appeared incorrectly until users opened the hierarchy view.
Original PR description
This PR aims to fix an issue about the icon related to the hierarchy view not being rotated anymore. | 18.0 and above | This PR | |--------|--------| | <img width="529" alt="image"…
This PR aims to fix an issue about the icon related to the hierarchy view not being rotated anymore. | 18.0 and above | This PR | |--------|--------| | <img width="529" alt="image" src="https://github.com/user-attachments/assets/11289aa4-948d-4725-b8d5-e91bf5d601fc" /> | <img width="531" alt="image" src="https://github.com/user-attachments/assets/bc74ef4e-6e74-47d1-ac06-6bde1d6ed933" /> | To render the icon of the hierarchy view, we use a little trick by rotating the `fa-share-alt` icon so that it looks like a tree diagram one. Unfortunately, this does not work anymore in `18.0` and above. It seems the CSS won't be loaded until you entered the module, which leads to the icon being rendered to `fa-share-alt` by default and then rotated correctly once you click on it. To fix this issue, we actually make use of available utility classes `fa-rotate-90`to handle the icon rotation and `align-text-top` to handle the vertical alignment when the icon is rendered within a node. task-4501317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when receiving a purchased kit product that includes a lot-tracked component. Businesses can now validate these receipts reliably, ensuring inventory and costing updates complete without interruption.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Product category: “AVCO” - BoM: - Type: Kit - Components: - C1: Tracked by lot and valuated by lot - C2 - Create a purchase order: - 1…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Product category: “AVCO”
- BoM:
- Type: Kit
- Components:
- C1: Tracked by lot and valuated by lot
- C2
- Create a purchase order:
- 1 unit of P1 → Price: $10
- Confirm the PO
- Go to the reception:
- Set a new lot (Lot_1) for C1
- Validate the reception
Problem:
A traceback is triggered:
```
new_std_price = move_cost[lot]
~~~~~~~~~^^^^^ KeyError: stock.lot(19,)"
```
When validating the picking, the moves will first be validated, and then
the product price will be updated before the move is marked as done:
https://github.com/odoo/odoo/blob/168f4d75ef724ee99ffaf7884730facd8ed936bb/addons/stock_account/models/stock_move.py#L387-L388
The move cost is retrieved using the _get_price_unit function:
https://github.com/odoo/odoo/commit/2d933b83613ad52d76ab457201adecac6fcf184b#diff-ad6229e976ce0bd1592e805b88e9813ac4e3f6fb989d3dfb8dfb8b70af03cd58R403
However, since move.product_id is different from move.purchase_line,
the parent product will be treated as a kit, and the unit price of the
kit product will be used instead: https://github.com/odoo/odoo/blob/17.0/addons/purchase_mrp/models/stock_move.py#L19
Based on this, the unit price for each component is calculated using
the cost_share and the bom_lines quantities. This is then stored in a
dictionary with an empty record of the ```”stock.lot”``` model:
When attempting to access the dictionary using the lot key from the move,
no result is returned, leading to an error.
https://github.com/odoo/odoo/blob/2d933b83613ad52d76ab457201adecac6fcf184b/addons/stock_account/models/stock_move.py#L425
Solution:
The process should account for the fact that the move product is a
component of a kit. Therefore, the price should be directly retrieved
from the dictionary without requiring a key.
opw-4434390Saudi Arabia POS orders with a zero total, such as orders fully paid with an eWallet, no longer trigger an error during validation. This helps businesses complete legitimate sales smoothly without manual workarounds.
Original PR description
Before this commit, attempting to validate an order with a zero total (such as when fully paid using an eWallet) would result in an error. opw-4487591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The survey editor now prevents users from adding embedded components that would not display correctly when respondents view the survey. This avoids broken or missing content in published surveys and helps creators use options that work reliably.
Original PR description
**Problem**: Embedded components do not render when the `html` field content is displayed outside the editor, as their mechanism relies on the editor plugin. **Solution**: Disable embedded components for the survey. **Steps to Reproduce**: 1. In a survey, add a section. 2. Add a "View" button. (Debug mode ON) 3. Use the `/` command box and add the "Video link" option. 4. Save and test the survey. 5. The video does not display. opw-4487027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where users could hit an error when registering a payment for an invoice without an invoice date, especially when early payment discounts are involved. The payment flow now skips discount date calculations when the required invoice date is absent, avoiding disruption for accounting users.
Original PR description
Currently, a traceback occurs when there is no invoice date and tries to register a payment from actions. To reproduce this issue: 1) Install accounting 2) Create a customer invoice with payment term…
Currently, a traceback occurs when there is no invoice date and tries to register a payment from actions. To reproduce this issue: 1) Install accounting 2) Create a customer invoice with payment term having an early discount 3) Make sure the invoice date to be empty 4) Add a line and from actions click pay Error:- ``` TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' ``` In account move, `invoice_date` is not required. So when the user tries to register a payment with payment term having an early discount and no invoice date, It leads to the above traceback from below line. https://github.com/odoo/odoo/blob/ee48df7f33a3aeb1798bf5852be8c6d26a7db7fd/addons/account/models/account_payment_term.py#L256-L258 Indeed, a date is required to get an early discount date. so without date, we should not execute the `_get_last_discount_date` method. In some other locations, it was managed in a similar manner as indicated in the below line. https://github.com/odoo/odoo/blob/ee48df7f33a3aeb1798bf5852be8c6d26a7db7fd/addons/account/models/account_payment_term.py#L262-L264 We can resolve this issue by adding an additional check of invoice_date, Which makes the code more robust. sentry-6149404219
A test in the Brazilian electronic invoicing area was corrected to match the current default email behavior. This helps keep automated checks reliable and reduces false failures during maintenance.
Original PR description
task-4478365
This fix restores subtotal information in Ecuadorian electronic withholding documents after a previous issue was resolved. Businesses using Ecuador localization should see more complete withholding records and fewer errors when reviewing related accounting documents.
Original PR description
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330
Italian point-of-sale receipts sent to fiscal printers now calculate payment totals correctly when customers receive change. This prevents change amounts from being counted as an additional payment, helping ensure fiscal documents match the actual sale.
Original PR description
The issue was that payment lines with `is_change` were also being considered in the computation.
Exemple:
Product: 14.50
Payment: 20.00
Change: 5.50Deleting a website no longer causes related documents to be deleted unintentionally. This protects business files from accidental loss while still allowing documents to remain linked to the correct website when appropriate.
Original PR description
Due to an oversight when migrating documents share to documents in Sharepocalypse, documents were being deleted when their related website was deleted. This is not a desired behavior. Even though setting the "correct" website is possible (and desired) when there is a `company_id`, there is no problem with having empty `website_id` in the other case. opw-4494091
This fixes an unreliable automated test in Web Studio that could fail when all apps were installed. The change makes the test steps more precise, helping reduce false failures and keeping validation of updates more stable.
Original PR description
runbot-error-108304
Creating a loan could fail for companies with existing accounting activity because the system unnecessarily tried to update and recalculate a very large volume of accounting data. This fix prevents that costly recalculation while still allowing the loan form to show the correct currency information.
Original PR description
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not…
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not readonly, causing the ORM to perform an inverse related and update the company's `currency_id`. This is problematic since changing the currency triggers a massive recompute of nearly all accounting records unnecessarily. For example, in the case of this customer, it was trying to update 191219 account.analytic.line, which caused this memory error. The initial design aimed to show the monetary symbol on the form when the `onchange` in `web/models/models.py` was triggered, but this approach led to the issue. ### Fix: By adding `company_id` to the view as an invisible field, the onchange can retrieve it to display the monetary symbol without triggering the problem. This change is backward-compatible; customers who haven't updated their views will only miss the monetary symbols on the form view until the record is saved. ### Reference: opw-4486739
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 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
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
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in ot
Original PR description
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all…
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in other companies/warehouses. This commit and an option to allow the cancel propagate upstream. It's hidden under the `stock.cancel_moves_origin` system parameter in order to avoid a huge behavior modification for other users. opw-3274939 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#195035 Forward-Port-Of: odoo/odoo#186730
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: g - Go to inventory > operation > Scrap: - Create a new one: - product: P1 - UoM: KG - Quantity: 1 - Validate the scrap - A wizard is triggered indicating insufficient stock quantity. - validate it Problem: The quantity in the scrap is updated to 1000 kg, and the related move is created with a quantity of 1000 kg. opw-4485849 Forward-Port-Of: odoo/odoo#194012
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: g
- Go to inventory > operation > Scrap:
- Create a new one: - product: P1 - UoM: KG - Quantity: 1
- Validate the scrap
- A wizard is triggered indicating insufficient stock quantity.
- validate it
Problem:
The quantity in the scrap is updated to 1000 kg, and the related move is created with a quantity of 1000 kg.
opw-4485849
Forward-Port-Of: odoo/odoo#194012This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "
Original PR description
This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "My invoices" or navigate to my/invoices url. - Click on one invoice in order to see its preview. - Via the browser tools, edit the amount of on the left sidebar and insert a very big number. task-4435472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194277 Forward-Port-Of: odoo/odoo#192769
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, wh
Original PR description
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, which is used to create new partners with the correct email associated with the res.user login. opw-4378487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193495
Forward-Port-Of: odoo/odoo#195005 Forward-Port-Of: odoo/odoo#193276
Original PR description
Forward-Port-Of: odoo/odoo#195005 Forward-Port-Of: odoo/odoo#193276
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#195656 Forward-Port-Of: odoo/odoo#194885
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
- open a record with an URL: `/{model}/{id}`; - delete or archive the record; Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button. This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is : - if a pager exists, disp
Original PR description
- open a record with an URL: `/{model}/{id}`;
- delete or archive the record;
Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button.
This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is :
- if a pager exists, display the next record;
- if not, return to the previous controller (the previous action, usually the multi-record view);
The issue here is that we don't have a previous action or a multi-record view.
Now, in this particular case, we will fallback to the default application.
opw-4354129
Forward-Port-Of: odoo/odoo#195622
Forward-Port-Of: odoo/odoo#195393In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determin
Original PR description
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already…
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determine the `source_lang`. This is used to search for the original term in the source language and update its translation. However, due to the `website=True` parameter not being set for the controller,the system defaults to English (`source_lang = 'en_US'`). As a result: 1. The system searches for the original word in English, even if it exists in another language. 2. The translation update fails because the original word cannot be found in English. __Description of the fix:__ A new controller was introduced to specifically handle translation updates, ensuring the correct language is fetched and the translation logic is applied correctly. __Steps to reproduce the issue:__ 1. Add 2 or more languages to the website. 2. Set the default language to any language other than English (US). 3. Create a blog post and write text in the default language. 4. Switch to another language, translate the text and save. 5. Edit the translated text again. The last edits are not saved. - bug introduced in: [#06346b0][1] - opw-4239512 [1]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e Forward-Port-Of: odoo/odoo#184415
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
### Description of the issue/feature this PR addresses: Since this PR #162009, all uncommented invisible fields raise an error. This commit improves the error message from the method `test_uncommented_invisible_field` by showing which line of the view should be removed/commented. The error message before this commit : ``` Addons: 'module_name' Views: ['view_name1', 'view_name2'] ``` After: ``` Addon: 'module_name' View: view_name1 Fields: <field name="field1"
Original PR description
### Description of the issue/feature this PR addresses:
Since this PR #162009, all uncommented invisible fields raise an error.
This commit improves the error message from the method `test_uncommented_invisible_field` by showing which line of the view should be removed/commented.
The error message before this commit :
```
Addons: 'module_name' Views: ['view_name1', 'view_name2']
```
After:
```
Addon: 'module_name'
View: view_name1
Fields:
<field name="field1" invisible="1">
<field name="field2" invisible="1">
View: view_name2
Fields:
<field name="field1" invisible="1">
```
The main benefit of this change is to display in a single test all uncommented fields that need to be fixed.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195166Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "cha
Original PR description
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before…
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "change" event. However, at that point, the form controller is already destroyed, hence the error. In that flow, we don't want to perform the onchange as we're discarding the form. Actually, we don't want the field to listen to the "change" event anymore. We delay for a micro-tick the activation of the previously active element, to wait for owl to have called destroy on the whole component hierarchy, and thus for the "change" handler to be removed (in input_field_hook). The issue could be reproduced in Studio: - click on Edit menu - open a menu to edit it - change its name but to not blur/click out - press Esc This is a backport of odoo/odoo#195238, where we add a test (hoot). The faulty scenario could not be reproduced in the QUnit suite because we do not precisely enough mock events that occur when focusing/bluring elements. opw-4490577 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#195430 Forward-Port-Of: odoo/odoo#195242
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
- 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
### Steps to reproduce the issue: 1. Create an clean Analytic Account and use it in a Budget 2. Create a Purchase Order with Analytic Account in the Distribution and a Discount then Confirm 3. In the Budget report, the Committed Amount does not include the Discount ### Explanation: In the `purchase.order.line` side of the calculation of the committed amount of the budget report, we are using `unit_price` as base, because of it having a `not null` constraint, then adding a lot of other
Original PR description
### Steps to reproduce the issue: 1. Create an clean Analytic Account and use it in a Budget 2. Create a Purchase Order with Analytic Account in the Distribution and a Discount then Confirm 3. In the Budget report, the Committed Amount does not include the Discount ### Explanation: In the `purchase.order.line` side of the calculation of the committed amount of the budget report, we are using `unit_price` as base, because of it having a `not null` constraint, then adding a lot of other variables to extract the correct amount: `currency_rate`, `analytic_distribution`, `product_qty` and `qty_invoiced`. This does not include `discount` nor price-included `taxes_id`. ### Fix reasoning: To avoid an issue regarding down payment lines, which have no `price_subtotal`, we will prioritize the field with a fallback on `price_unit`. opw-4391098 Forward-Port-Of: odoo/enterprise#75902
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
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
Original PR description
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
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 ----- 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