Daily updates from Odoo
Thursday, May 23, 2024
52 changes · 17.0
Resolved issues and error corrections
This fix resolves a bug in the barcode scanning system where scanning a lot number that exists for multiple products would incorrectly add the wrong product to a delivery order. The issue occurred because the system's cache was not properly distinguishing between identical lot numbers across different products. The fix improves the caching mechanism to use more precise keys based on search filters, ensuring the correct product is always selected when scanning.
Original PR description
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to…
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to Configuration > Operation Types > Delivery Orders - Enable Product in the Barcode App - Go to the barcode app > Operations > Delivery Orders and click on New - Scan 123 - Scan aaa (or bbb it probably depends on order of creation of product) - Scan 123 Issues: bbb has been added even though we never scanned it. The reason for this bug is that when we scan 123 we don't have it in the cache as such we make an RPC and store 123 in `missCache`. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185 After this when we scan aaa we retrieve the record, and add the line as intended. The problem arise when we scan 123, since it's already in our cache. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130 However that record is not right since this lot is linked to the wrong product bbb. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138 We will try to retrieve again the right record, however we will once again get a hit on the cache. As such no RPC call will be made to retrieve the lot we're looking for. We will go in the function once again, where we will have the same problem this time in the `if (model)` condition. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115 Later in the execution we will get to this line where we call the function without a filters which will allow the wrong record to be added. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943 The root of this problem lies in the way we set the key to the cache, since two product can share the same barcode we need a more precise cache key to differentiate them. The proposed solutions is to cache result based on the provided arguments to the function. This means fewer hit if we retrieve the same record with different filter for example, however it's safer as when we hit we are sure to get the right record. opw-3862263
This fix resolves an issue where uploading a file to a document activity would create two documents instead of one, causing an access error. The system now prevents duplicate document creation by checking if a document already exists for the activity before creating a new one during file upload.
Original PR description
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go…
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message. **Cause:** Simple explanation: 2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked. Detailed explanation: When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46 When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment. https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63 Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33 Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8 **Solution:** Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists. COM PR: https://github.com/odoo/odoo/pull/159943 opw-3458850 Forward-Port-Of: odoo/enterprise#62209 Forward-Port-Of: odoo/enterprise#59796
This update resolves an issue where users creating immediate transfers in the Barcode app were unable to scan certain warehouse locations due to overly restrictive validation rules. The fix allows users to scan any relevant location when creating transfers on-the-fly, since they cannot pre-set source and destination locations. Additionally, a minor bug is corrected where location names containing the default location's name were not displayed correctly on barcode lines.
Original PR description
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But…
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue. How to reproduce: - Inventory -> Settings -> Enable "Multi-Step Routes"; - Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments; - Go to the Barcode App > Operations > Internal Transfers > New; - In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT) - :arrow_right: An error message is displayed because you are not allowed to scan this location. The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d. Also, fix a minor unrelated bug where locations on the barcode line are not correctly written when there name include the picking's defaut location's name (eg.: WH/Stock 2 when the default location is WH/Stock.) [OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62550 Forward-Port-Of: odoo/enterprise#62480
This fix corrects a typo in the Mexican EDI payment complement feature that was preventing bank account information from appearing on payment receipt PDFs. The update also improves how the system retrieves payment data to handle cases where not all information is always available, making the payment receipts more reliable and complete.
Original PR description
Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values. https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392
This update adjusts the employment bonus calculations in the Belgian payroll system to reflect the latest government regulations through May 2024. The changes ensure that employee bonuses are calculated correctly according to current Belgian labor law, which is important for accurate payroll processing and compliance.
Original PR description
TaskID: 3942303
This fix resolves an issue where the "Send" button was not appearing in the Dutch ICP report wizard unless users manually checked the "Is Test" checkbox. The problem was caused by missing date fields that the system needs to properly determine when to show the button. By adding these invisible fields to the form, the button now displays correctly based on the selected dates.
Original PR description
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
This update fixes how account codes are extracted from trial balance reports for Mexican tax filing (SAT XML). Previously, the system incorrectly parsed account codes when users added custom accounts with dots in their names or codes with more than the standard format. The fix now correctly handles these variations while maintaining compatibility with standard accounts, ensuring accurate tax report generation.
Original PR description
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing…
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots. Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter. This fix makes the parsing of the NumCta value more strict so it supports the above use cases. In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case. opw-3878763 Forward-Port-Of: odoo/enterprise#62885 Forward-Port-Of: odoo/enterprise#62113
This update fixes a memory issue that occurred when generating SAFT financial reports with large amounts of data. The system now processes data in smaller batches instead of loading everything at once, preventing crashes and allowing the report to complete successfully even with extensive transaction histories.
Original PR description
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
This fix resolves a performance issue in batch payment creation where an editable payment method code field was triggering unnecessary recalculations across all related payments. By making this field read-only, the system no longer performs these redundant calculations, improving database performance especially for organizations processing large volumes of batch payments.
Original PR description
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers the recompute. opw-3848817 Forward-Port-Of: odoo/enterprise#62431 Forward-Port-Of: odoo/enterprise#61908
Customers who receive a link to a helpdesk ticket with an attached field service task were getting an error (403 access denied) when clicking the link while not logged in. This fix prevents the Tasks link from appearing to users who don't have permission to access it, ensuring a better customer experience.
Original PR description
**Steps** - Install Field Service and Helpdesk - Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link ** **Issue** Access rights issue here https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34 **Fix** Don't show the "Tasks" link if the user doesn't have access rights to them. opw-3911444 Forward-Port-Of: odoo/enterprise#62087
A testing component was moved from the CRM Enterprise module to the correct location, enabling community users to run related quality assurance tests. This fix resolves an issue where certain tests were inaccessible to users without the enterprise version.
Original PR description
This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/odoo/pull/166475
This update fixes a display issue in the Partner Ledger report where grouped partner lines were incorrectly showing "0.0" in text columns instead of remaining blank. The fix ensures that non-numeric columns display properly when partners are grouped by prefix, improving report readability and accuracy across all accounting reports that use this grouping feature.
Original PR description
To reproduce the issue, on a runbot with the demo data: 1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger ==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines. The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bit to check that behavior as well. Forward-Port-Of: odoo/enterprise#62740
Fixed a technical error that occurred when users attempted to clear the team assignment on a helpdesk ticket. Previously, the system would crash with an error message instead of properly validating the input. Now users will only see a validation message if they try to save without assigning a team, providing a better user experience.
Original PR description
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change,…
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that. Solution: Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team. version 16.0 - master task - 3895303 Forward-Port-Of: odoo/enterprise#61563
This fix corrects how shipping reference IDs are processed when sending delivery requests to bpost. Previously, only the first two forward slashes were being removed from reference IDs, which caused incorrect shipping request URLs when references contained more than two slashes. Now all slashes are properly removed, ensuring accurate shipping requests.
Original PR description
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
This update increases the timeout for Sendcloud delivery requests from 15 seconds to 60 seconds. The previous timeout was too short when processing large amounts of shipping data, causing requests to fail. This change ensures that large delivery requests complete successfully without timing out.
Original PR description
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
Fixed an issue where lines with zero values were still appearing in exported PDF and Excel reports even when the "Hide lines at 0" option was enabled. Now when users toggle this setting, zero-value lines are properly hidden in both the on-screen view and printed documents, ensuring consistency between what they see and what they export.
Original PR description
0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle 'Hide lines at 0' - Click in PDF to export a PDF version of the report - 0 lines are included in the PDF file When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees and what is printed. Another reason to hide lines at 0 from the printed report is that lines with Hide if Zero checked does impact the PDF. This means the two options (Hide lines at 0 and Hide if Zero) have similar impacts in the user view but different behavior in printed reports. This commit implements the function _filter_out_0_lines to remove lines at 0 from printed report if "Hide lines at 0" is toggled, and adds a test. task-3888290
This update fixes an issue with the kitchen display system's main menu visibility in the Point of Sale module. The fix prevents unnecessary software installations from occurring during system upgrades, ensuring a smoother and more efficient update process for restaurant operations.
Original PR description
Backport of fix from master to 17.0 to avoid unnecessary installation during upgrades: https://github.com/odoo/enterprise/pull/56794 task-3725031
This update corrects how base amounts are calculated in accounting tax reports when they are grouped by account and tax. Previously, only tax amounts were properly summed while base amounts were duplicated, causing inaccurate tax reporting. The fix ensures both base and tax amounts are correctly aggregated in grouped tax reports.
Original PR description
Before this commit: The sum of base amounts and tax amounts for accounting reports in 16 is inaccurate. When collecting taxes, implementation was included in 16 to create multiple nodes based off whether the node was a refund, it's tax_id, sale/purchase, and it's account_id. This logic was done to prevent duplicates from being added to the report. However, the base amount was the only value that did this sum with a check, and the tax amount was added regardless. This results in multiple databases with improper tax information generated on the tax reports that are sorted by "Account >> Tax" or "Tax >> Account". Including the addition of base_amount in the computations that check for duplicates will create the right sum for the grouped tax report templates. opw-3890736 opw-3793820
This fix corrects how payment reference information is extracted from CAMT bank statement files. Previously, the system was looking for reference information in the wrong location within the file structure, causing it to display "/" instead of the actual payment details. Now it correctly retrieves the additional entry information that serves as a fallback when primary reference data is unavailable.
Original PR description
Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The imported statement's payment reference contains `/` instead. ### Cause The system attempts to use `<AddtlNtryInf>` as a fallback for `payment_ref`. However, it looks in the wrong place. It searches inside `<TxDtls>`, whereas `<AddtlNtryInf>` is actually a child of `<Ntry>`. opw-3878785 Forward-Port-Of: odoo/enterprise#62703
This fix resolves a system error that occurred when users tried to delete toppings from lunch vendors. Previously, deleting a topping would cause the system to crash with an error message. Now users can successfully delete toppings without encountering this issue.
Original PR description
When the user tries to delete the toppings, a traceback appears. Steps to reproduce the error: - Go to Lunch > Configuration > Vendors > Open any vendor - Now add extra 2 (topping 2) > Save - Delete…
When the user tries to delete the toppings,
a traceback appears.
Steps to reproduce the error:
- Go to Lunch > Configuration > Vendors > Open any vendor
- Now add extra 2 (topping 2) > Save
- Delete that extra 2 (topping 2) > Save
Traceback:
```
IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 71, in web_save
self.write(vals)
File "addons/lunch/models/lunch_supplier.py", line 193, in write
topping_values = topping[2]
```
https://github.com/odoo/odoo/blob/07f6d71e4dd3fac7b4cacc545819430aa48823cd/addons/lunch/models/lunch_supplier.py#L192-L193 Here when the user deletes the extra 2 (topping 2),
"topping" will be [2,2] instead of [2,2,False].
So when it tries to access topping[2],
It will lead to the above traceback.
sentry-5203693767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes two display problems with mobile menus on websites. First, when users click to close and reopen a mobile menu, the menu backdrop now displays correctly instead of breaking the page layout. Second, when a header is set to display "Over The Content," it now properly remains transparent when the mobile menu opens, instead of incorrectly showing a colored background. These fixes improve the mobile browsing experience for website visitors.
Original PR description
**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD…
**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD to have the mobile menu. - Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it. - Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken. This is due to the fact that the code handles the hint preview for the "Powerbox" considers that it must insert the hint in a "<div>" if it's empty. See the "_makeHint()" function in this commit [1]. In this commit, we fix this by preventing selection on the backdrop. There's probably a better way to fix it. But until the problem is solved more generally, we simply fix it in CSS for the "Backdrop". [1]: https://github.com/odoo/odoo/commit/4600086e7a2831664cc104a143e1014870874427 task-3853573 ----------------------------- **[FIX] website: fix overlay header when mobile menu is open** Steps to reproduce the bug: - Open a page in Website edit mode. - Click on the header. - Select a red color for the background option of the header. - Choose "Over The Content" for the "Header Position" option. - Resize the screen to MD to have the mobile menu. - Click on the "hamburger button". => Bug: The header is red instead of transparent. The bug arises because since this commit [2], the transparent background of the "Over The Content" header is removed when the mobile menu is open. [2]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510 task-3853573
This fix resolves an issue where creating multiple down-payments on the same sales order would generate extra unwanted down-payment lines. The system now correctly filters out previously created down-payment lines when calculating new ones, ensuring only product-based lines are considered. This prevents confusion and errors in invoice generation.
Original PR description
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow,
down-payment lines are created based on product lines in the sales order,
not on down-payment lines themselves. Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
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-prThis update fixes a critical issue where setting the repeat interval to zero in recurring maintenance requests causes the system to crash when accessing the maintenance calendar. A validation check has been added to prevent users from saving invalid repeat interval values, ensuring the maintenance calendar functions properly.
Original PR description
If you have "repeat interval" set to "0" in the Maintenance request, and if you go to the Maintenance calendar, then the system crashes. Adding a validationError to avoid the crash. To Reproduce on Runbot: 1. Go to Maintenance Request 2. Make a new request with Maintenance type as Preventive, Recurrent checked, and Repeat Every to 0. 3. Save it 4. Go to Maintenance Calendar 5. The system crashes opw-3859966 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue in the e-learning app where the word "false" was incorrectly displayed when a quiz had no description. The problem occurred because the code wasn't properly handling empty description values, causing them to be converted to the text string "false" instead of remaining blank. Users will no longer see this unwanted text when viewing quizzes without descriptions.
Original PR description
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website page of the course. 4. Open the quiz in fullscreen. 5. A "false" message is displayed on the top-left corner. opw-3887445
This fix resolves a problem where employees couldn't reorder rows in two-week work schedules. When users tried to drag and reorder schedule rows, they would reset to their original positions. The issue has been corrected so that reordering now works as expected, and new schedule rows now appear in a more intuitive location in the interface.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Ensure debug mode is off; 2. go to Employees / Configuration / Employee / Working Schedules; 3. select a schedule and switch it to a 2 week calendar; 4. try…
Versions -------- - 17.0+ Steps ----- 1. Ensure debug mode is off; 2. go to Employees / Configuration / Employee / Working Schedules; 3. select a schedule and switch it to a 2 week calendar; 4. try to reorder one of the rows. Issue ----- Row resets to original place. Cause ----- Commit a9b804b1ad6c added a `default_order` to the view, its values get passed to the `_sort` function of `StaticList`, which then compares them to the `activeFields` of the loaded model. One of the fields given to `default_order` is `week_type`, which isn't included in the `activeFields` of the loaded model unless you're in developer mode. This is a consequence of being assigned to the group `base.group_no_one`. Because of this mismatch, it assumes the model isn't loaded yet, and creates a new one with the `week_type` field in order to sort them, leaving the original records (the ones in view) unchanged. Solution -------- Remove the `groups` attribute from `week_type`, and make it an optional field. Also switch `editable` from `top` to `bottom` to make the line appear right above the `Add a line` line. opw-3773432
This fix corrects a problem where changing the unit of measurement on an expense would incorrectly update the unit price. The issue occurred because the system was recalculating prices in situations where it shouldn't. The fix ensures that price recalculation only happens when using the OCR (document scanning) feature, preventing unintended price changes when users manually adjust units.
Original PR description
Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR enterprise: https://github.com/odoo/enterprise/pull/62425 opw-3869104
This fix corrects how byproduct quantities are displayed in manufacturing order overviews. Previously, the system was showing the planned quantity instead of the actual quantity produced, which could confuse users about what was actually manufactured. Now byproducts display the same accurate quantity information as components.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: 1 unit of C1
- By-product: 1 unit of C2
- Create a manufacturing order to produce 2 unit of P1
- Confirm the MO
- Set the qty producing to 1 unit and mark it as done
Problem:
The quantity displayed for the byproduct is the quantity to produce (product_uom_qty) instead of the quantity produced (Quantity)
https://github.com/odoo/odoo/blob/a94f3f4dcb24e08cd4db7fd50ea704e9a065fd83/addons/mrp/report/mrp_report_mo_overview.py#L434
opw-3903182This fix ensures that when restaurant staff select a table and view the product selection screen, the table number is now displayed in the navigation bar. Previously, staff had no visual reminder of which table was selected, which could lead to orders being placed for the wrong table. This improvement helps prevent order mistakes in restaurant operations.
Original PR description
For version 17.0 only Problem: In restaurant, in the product page, we don't have anything to remind which table is selected Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Open a restaurant session - Click on a table, the product page is loaded and we don't see the table number in the navbar Note: Solution copied from version 17.1 opw-3929069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how the accounting system retrieves product information by ensuring it properly considers the company context. When no specific company is provided, the system now automatically uses the current company from the environment, and prioritizes products that are explicitly linked to that company. This ensures consistent and accurate product data retrieval across different company setups.
Original PR description
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163938
This fix resolves errors that occurred when using IoT devices (like printers) with the Point of Sale system and invoice reports. The issue was caused by missing required service files in the system configuration. After this fix, businesses can now successfully use IoT-connected printers and devices in their POS operations without encountering errors.
Original PR description
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes two issues in the subcontracting workflow. First, it prevents the subcontracting button from appearing prematurely on stock moves before any quantity has been delivered. Second, it corrects the details button to properly display subcontracting information instead of redirecting to the wrong view. These fixes ensure users see the correct interface at the right time when managing subcontracted manufacturing orders.
Original PR description
### Steps to reproduce: - Enable subcontracting in the settings - Create a finished product FP tracked by lot using the buy route - Create a component product CP tracked by unique serial numbers and…
### Steps to reproduce: - Enable subcontracting in the settings - Create a finished product FP tracked by lot using the buy route - Create a component product CP tracked by unique serial numbers and using the routes: - Buy - Resupply Subcontractor on Order - Create a BOM for FP of type subcontracting and consuming 1 x CP - Create and confirm a purchase order for 2 x CP, assign serial numbers on the receipt, receive products and validate - Create and confirm a purchase order for your subcontractor for 2 x FP - Go to the resupply picking, assign the stock moves related to your components and validate - Go to receipt #### Two issues reported by the PO (mgm): 1) The subcontracting button is visible on the move even though no qty was delivered yet. 2) The `fa-list` button on the move redirects to stock move lines of the move rather than to the "action_show_details". ### Cause issue 1: The `show_subcontracting_details_visible` computed field determine if the button should be visible. Prior to the `quantitypocalypse` this field relied on the `quantity_done` to determine if the button should appear: https://github.com/odoo/odoo/blob/c68b17e944079f0718a1bef74b941dcb18b841e3/addons/mrp_subcontracting/models/stock_move.py#L30-L37 As this field does not exist in 17.0 anymore, the new condition relies on the `quantity` field: https://github.com/odoo/odoo/blob/3dc2e25f30a411f49f895568b4689265152f153d/addons/mrp_subcontracting/models/stock_move.py#L30-L36 However, this field only represents the same thing as the quantity_done when the move is `picked`. ### Cause of issue 2: The `fa-list` button referring to the `action_show_details` in 16.0: https://github.com/odoo/odoo/blob/d1bdcde5160d1a320396f0703103a50e8636e96f/addons/stock/views/stock_picking_views.xml#L302-L303 (that is overriden in `mrp_subcontracting`) has been replaced in 17.0 on the `stock.picking` form view by the one2Many record stock.move widget: https://github.com/odoo/odoo/blob/b4ae1ed7382dcb9c91c06ba0055974994dcdf54c/addons/stock/static/src/views/picking_form/stock_move_one2many.xml#L3-L8 see commit 4da8c6e for more details. opw-3871634 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This fix prevents customers from completing purchases when shipping information contains errors (such as invalid addresses or unsupported delivery locations). Previously, the "Pay Now" button remained active even when shipping costs were incorrectly calculated as zero due to carrier validation failures. Now the payment button is properly disabled when shipping errors are detected, protecting both customers and the business from incorrect orders.
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165267
Forward-Port-Of: odoo/odoo#161704Event tickets were displaying dates in UTC instead of the user's local timezone, causing the date to appear one day off when the event was scheduled in a timezone west of UTC. This fix ensures that event dates on downloaded ticket PDFs now display correctly in the user's timezone, improving the accuracy of event information provided to attendees.
Original PR description
The date on an event ticket can be wrong. To reproduce, create an event with a date_begin datetime that falls on the next UTC day. For example, specifying 2024-05-23 18:30 with the user's timezone as America/Los_Angeles results in a stored UTC time of 2024-05-24 01:30:00 (next day). Make sure the timezone of the public user is unset for simplicity's sake (it will fall back on that timezone), and then register for the event in an incognito window through the website. After registering, click "Download Tickets". The ticket PDF will display the UTC date. The event_registration_report_template_full_page_ticket wrapper sets the timezone in context: <t t-set="event" t-value="attendee.event_id._set_tz_context()"/> But ir.qweb.field.datetime doesn't use the record with attached context and only looks directly at the value. To make it work, tz_name must be specified explicitly. This is already done for the time part of date_begin below. opw-3930916
This fix prevents partners without active user accounts from appearing in the chat command palette when using the @ mention feature. Previously, any partner who was a member of a channel (like WhatsApp) would show up as a chat option, even if they couldn't actually receive messages. Now only partners with valid user accounts will be suggested, improving the user experience and preventing failed chat attempts.
Original PR description
**Current behavior before PR:** if a partner is a member of any channel (eg, whatsapp channel) it will be displayed in the command palette even if he does not have any associated user.which will cause issues as you can not chat with partner who do not have any dedicated user. **Desired behavior after PR is merged:** partners with no dedicated users will not be displayed in the command palette to chat with when you enter @. Task-3815150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165960 Forward-Port-Of: odoo/odoo#159239
This update fixes a critical bug where the system crashes when calculating how much a customer can still invoice, and improves the speed of these calculations. The fix prevents errors from invalid data and makes the system more efficient by letting the database handle calculations instead of processing large amounts of data in the application.
Original PR description
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were…
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values into an array and then postprocess them in python. Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values. Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing. This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders) and just pass around a single value. This commit introduces the changes mentioned in (2). These changes also solve (1): The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.) related PR introducing the changed lines of code: https://github.com/odoo/odoo/pull/162770 a comment about the issue in 17.0: https://github.com/odoo/odoo/commit/b5d02cc72543b36c7e5e620a3a579f15c88baed6#r141990142 Forward-Port-Of: odoo/odoo#166175 Forward-Port-Of: odoo/odoo#166087
This update fixes a crash that occurred when users tried to select multiple tables at once using their mouse in the web editor. The fix prevents the application from throwing an error by properly handling cases where the selection doesn't contain a valid table element.
Original PR description
**Current behaviour before PR:** Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked. **Desired behaviour after PR:** There should be no traceback. This can be handled by returning the method if we don't find the closest table. task-3922517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165234
This fix prevents multiple duplicate dialog windows from opening when users click the same action multiple times while waiting for it to load on slow internet connections. Now only the last requested action will open, providing a cleaner and less confusing user experience.
Original PR description
Current Behaviour: - Currently, if the internet is slow and the user tries to open any action, which action target='new,' it takes time to open the action form in the browser, if the user clicks multiple times during this loading process, multiple instances of the same action will be displayed to the user. Steps to produce: - Open CRM and navigate to the activity view of CRM. - Select throttling as 'Slow 3G' in your browser network setting. - Now click multiple times on any scheduled activity to open an action. Expected Behaviour: - Only open the dialog for the last action requested when there are multiple actions requested with target='new'. Task-3750720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165940 Forward-Port-Of: odoo/odoo#159236
Fixed a bug where design changes made to email templates (colors, formatting, sizing) were not appearing in test emails. The system was using outdated styling rules instead of the updated ones. This fix ensures that when users customize the design of their marketing emails and send a test, the changes are properly reflected in the preview.
Original PR description
Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject,…
Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject, mailing list, and choose any template that have some blocks - Go to design tab in editor and change any color or size of something - Click save and test sending the email - The email doesn't have the changes applied Origin of the issue: ==================== When first rendering , CssRules are calculated using the first version of the template and styles. When we update the design so the css rules, they are not applied in the inlineHtml since it uses the old cssRules. Solution: ========== We only use `_rulesCache` defined in `wysiwyg` and we already handle everything in `toInline` from calculating the `cssRules` to saving them in the cache, so we just pass `undefined` as cssRules and let it take care of everything. task-3289131 Forward-Port-Of: odoo/odoo#166246 Forward-Port-Of: odoo/odoo#153180
This update implements new Indonesian tax authority rules for E-faktur invoicing where NPWP (tax ID) and NIK (national ID) now work together as complementary fields. Users must now provide either a valid NPWP, NIK, or both—the system will no longer auto-fill NPWP with zeros. This ensures compliance with the latest e-invoice regulations and improves data accuracy for Indonesian businesses.
Original PR description
Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur 3815006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166182 Forward-Port-Of: odoo/odoo#163707
This update fixes how date filters work in spreadsheets when dealing with datetime fields across different timezones. Previously, the system was comparing dates incorrectly, which could cause filters to show wrong data because a date in one timezone might actually be a different date in UTC. The fix ensures that date and time comparisons are done properly regardless of the user's timezone.
Original PR description
Steps to reproduce: - add a pivot in a spreadsheet - create a From/To global filter - match the filter with a datetime field of the pivot - set some values in the filter => the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time. opw-3805775 Task:3853821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the web interface from getting stuck in an endless reload cycle when the server connection is lost while viewing records. Previously, if a user tried to open a record while the server was down, the system would repeatedly attempt to reload the list view indefinitely. The fix restores a check that detects when an error occurs in a view that's already displayed, and shows the error message instead of continuing to reload.
Original PR description
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be…
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback. Since [1], we'll indefinitely try to reload the multi record view, because we removed the check detecting that the error occurs in the controller that is already in the DOM. If that controller fails, there's no point trying to restore it again, instead, we just show the error. This commit simply restores that part of the code as it was before [1]. [1] odoo/odoo@9c954de94148ab6f3b8d02e6a4713a87fe233a28 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how timesheet entries are displayed in the customer project portal. When timesheets are configured to use days as the unit of measurement, the portal was incorrectly showing hours instead. The fix ensures the correct unit (days or hours) is passed to the portal view so customers see accurate timesheet information.
Original PR description
Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a…
Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day. - Share the project and copy the link provided. - When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal Current behavior before PR: We are not passing the 'is_uom_day' value in the project portal view. So in XML when it checks this variable it will get undefined. so, always will go with the else condition. https://github.com/odoo/odoo/blob/16.0/addons/hr_timesheet/views/project_portal_templates.xml#L50:L53 Desired behavior after PR is merged: We are now passing this value to check if the timesheet unit is days so it will be shown as 'Days spent' instead of 'Hours spent' opw-3925368 Forward-Port-Of: odoo/odoo#166164 Forward-Port-Of: odoo/odoo#165737
This fix prevents users from accidentally modifying critical manufacturing-related warehouse settings in debug mode. Previously, these special location and picking type fields could be edited, unlike similar fields in other modules. Now they are locked as read-only to maintain system consistency and prevent misconfigurations.
Original PR description
In debug mode, the special locations and picking types are shown on the warehouse 'Technical Information' tab. All the values shown there are readonly, with the exception of the mrp-related fields. This was likely forgotten at the time, and can lead to misconfigurations, so we make it consistent with the other location and picking types introduced in stock and other modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164162
This update fixes a technical issue in the automation system that was causing errors when comparing dates and times. The system was trying to compare two different types of time values (one with timezone information and one without), which was preventing time-based automated workflows from running properly. This fix ensures that automated tasks scheduled by time will execute correctly.
Original PR description
Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121 Forward-Port-Of: odoo/odoo#166147
Fixed a bug that prevented users from checking refund amounts for multiple payments at once. The system was incorrectly searching for payment records, causing errors when trying to retrieve refund availability information. This fix ensures the refund calculation works properly whether checking one payment or multiple payments together.
Original PR description
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
This fix resolves a crash that occurred when translating website pages with invisible elements like the Cookies Bar enabled. The issue was caused by a previous update that prevented the system from properly handling invisible snippets during translation. The fix ensures invisible elements are correctly processed and prevents them from being accidentally activated when users interact with the sidebar.
Original PR description
[FIX] web_editor: fix the translation of invisible elements Steps to reproduce: - Add a second language and enable the "Cookies Bar" in your website settings. - Go to a website page (in translation…
[FIX] web_editor: fix the translation of invisible elements Steps to reproduce: - Add a second language and enable the "Cookies Bar" in your website settings. - Go to a website page (in translation mode) > Traceback. The implementation from [1] allowed to use text options (text animations & text highlights) in the translation mode by only creating snippet editors if the target is a text option snippet. This code unintentionally prevented editor creation for invisible snippets, which was required to correctly add entries for every invisible snippet in the sidebar box (see [2] and [3]). The goal of this commit is to fix this behavior by forcing the editor's creation to consider "invisible" elements. A small adaptation of the `_activateSnippet()` method is also required to prevent activating invisible snippets when their related sidebar buttons are clicked. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/e9096a3844459b271cecbcc5e50df4a18c4c3d2a [3]: https://github.com/odoo/odoo/commit/f45a6ea38553566ff35cde3eceb2e4220075205d opw-3941516 (main one) Marked as similar: opw-3936669 opw-3939855 opw-3940168 opw-3940210 opw-3940218 opw-3940224 opw-3940407 opw-3940776 opw-3940845 opw-3940982 opw-3941047 opw-3941333 opw-3941377 opw-3941986 opw-3942480 opw-3944506 opw-3944641 opw-3944862 opw-3944893 opw-3945094 opw-3945589
This update fixes a bug where inventory routes were being duplicated unnecessarily in the manufacturing and purchasing workflows. The system now properly prevents route duplication by refining how routes are searched and created, ensuring cleaner data and more reliable inventory operations.
Original PR description
Few improvements for commit [1]: \- Before [1], `_find_global_route`, was not supposed to create any route. Let's keep it like that \- `_find_global_route` is sometimes calls with an empty `self` \- The name of the copied route should not contain "(Copy)" \- When looking for a route, we should skip the `active` criteria [1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41 OPW-3889889 OPW-3888885 Forward-Port-Of: odoo/odoo#165949 Forward-Port-Of: odoo/odoo#165728
This fix resolves a problem where WebSocket connections were hanging and becoming unresponsive when using Werkzeug version 2.3.x or newer. The issue occurred because Werkzeug was discarding socket data after sending responses, which prevented WebSocket frames from being processed. The fix ensures WebSocket connections remain active and responsive by using alternative data streams.
Original PR description
Since [1], Werkzeug discards any remaining data in the read socket after sending the response. In the case of WebSocket connections, the socket is not closed, and data keeps coming. As a result, WebSocket connections to the threaded server hang indefinitely in this discarding phase and never reach the processing phase. Thus, frames sent to the server are never processed. To solve this issue, rfile and wfile are replaced by dummy byte streams to ensure that our socket remains intact. [1]: https://github.com/pallets/werkzeug/commit/4f7048e7a31752142f18eefeccd49acc42a89e31 Forward-Port-Of: odoo/odoo#166231
This fix corrects an inventory valuation calculation error that occurred when a purchase order was created in one currency (e.g., Euro) but the vendor bill was issued in a different currency (e.g., USD). Previously, the system incorrectly calculated inventory values, resulting in wrong stock valuations. The fix ensures that bill amounts in different currencies are properly converted and used for accurate inventory costing.
Original PR description
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor bill in USD (10 $) > Now Receive the quantities > Check the valuation > Wrong value (15.92 $) the value should be 10$ (taken from the bill) Bug: In the case of BIlling policy on Ordered Quantities and PO in a foreign currency we assume the bill will be in same currency as the PO Fix: currently unit price is first computed in PO currency and then converted in the end to company currency added conversion from bill to PO opw-[3805454](https://www.odoo.com/web#id=3805454&view_type=form&model=project.task) also fixed a rounding issue opw-[3773413](https://www.odoo.com/web#id=3773413&view_type=form&model=project.task) alternative fix: compute everything in company currency (https://github.com/odoo/odoo/pull/155937) Forward-Port-Of: odoo/odoo#162827
This fix ensures that analytic distributions (cost center tracking) are properly applied to cash basis accounting entries, not just the initial invoice entries. Previously, analytics were only tracked on transfer accounts, but now they correctly follow through to the actual accounts when payments are recorded. This ensures accurate financial reporting and cost allocation across all accounting transactions.
Original PR description
Currently the analytic distribution is applied to the journal items of the invoice but not to the ones of the cash basis entries. This leads to the following problem. The journal items of the invoice…
Currently the analytic distribution is applied to the journal items of the invoice but not to the ones of the cash basis entries. This leads to the following problem. The journal items of the invoice (may) contain transfer / transitional accounts. For each payment a crash basis entry is created (on the date of the payment). The cash basis entries "move" the amounts from the transfer accounts to the "real" accounts. Thus currently the analytics are only applied to the transfer accounts and not to the "real" accounts. After this commit: Consider the creation of a new cash basis entry for an invoice. The analytic distribution from the journal items of the invoice will now also be applied to the lines of the new cash basis move. A test was replaced. The old test checked that the base lines are duplicated for different analytic distributions. The newer test is more detailled and also covers the old test. task-3340797 Forward-Port-Of: odoo/odoo#166356 Forward-Port-Of: odoo/odoo#155696
This fix corrects how the Italian electronic invoicing system handles missing or invalid VAT numbers. Previously, when customers had "/" or "NA" entered as their VAT number (which indicate no VAT), the system would generate incomplete electronic invoices. Now these values are properly recognized as empty VAT and handled consistently with other missing VAT cases, ensuring compliant invoice generation.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts - Create an EU contact with "/" or "NA" as VAT (e.g. a German contact with a full address) - Create an invoice: * Customer: [the created contact] * Product: [any] - Confirm the invoice - Process the electronic invoice - Check the generated electronic invoice **Issue:** When a customer has not VAT number, a special value is used in the XML (i.e. 0000000). However, "/" and "NA" that are equivalent to an empty VAT, do not have the special value. Instead, the "IdFiscaleIVA" section is empty in the XML. **Cause:** "/" and "NA" are handled as a normal VAT and are truncated because the 2 first characters are not digits. opw-3889051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166404 Forward-Port-Of: odoo/odoo#166316
A test setup function was incorrectly placed in the enterprise-only CRM module, preventing community users from running related tests. This fix moves the function to the standard CRM module so tests can run properly for all users.
Original PR description
This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/enterprise/pull/63056