Daily updates from Odoo
Thursday, September 26, 2024
20 changes
1 change
Resolved issues and error corrections
Point of Sale receipts can now be printed through the web browser when an ePoS printer encounters an error. This prevents failed printer connections from blocking receipt printing, helping stores keep checkout operations moving smoothly.
Original PR description
Before this commit, if there was an issue with printing via an ePoS printer, the system did not allow for printing the receipt through the web as a fallback. This was due to the erroneous passing of the error object instead of the receipt content. opw-4209073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
Duplicating a financial report now creates a clearly labeled copy and includes its budget lines. This helps users create new financial budgets from existing reports without rebuilding them manually.
Original PR description
Enable the copy of a financial report. Right now, when duplicating a financial report (or several at the same time), only the name is copied (same name, not even a "(copy)" after. We want to improve it by adding this "(copy)" in the title, and also copy the budget lines. This will enable a user to not start from scratch every time he wants to create a new financial budget. task-4207202
The asset modification wizard now refreshes the residual value when users change the date, giving a more accurate preview before confirming changes. Related accounting fields also adjust based on the recalculated gain or loss, reducing confusion and helping users make better decisions.
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. task-3981380
8 changes
Resolved issues and error corrections
Website editors can once again place form blocks cleanly inside other page sections without unwanted titles, background colors, or layout constraints. The main form option remains available as a polished, titled block, so users get the right default appearance for each use case.
Original PR description
It was still possible to use it as an inner snippet, but since [1], it looked broken without further edition of the dropped inner snippet: - The form had a gray background (instead of transparent). -…
It was still possible to use it as an inner snippet, but since [1], it looked broken without further edition of the dropped inner snippet: - The form had a gray background (instead of transparent). - It was forced to be small-width and centered. - There was a big title coming with it, forcing the user to remove it. - ... Since then, [2] was introduced to regroup "main" snippets in a dedicated modal. The form snippet was moved there but also remained outside of it to keep the inner form snippet feature. This commit just splits the two usecases: - The original `s_website_form` snippet is now only suggested as an inner snippet. It was restored to be without title, background and other default styling features. - A new `s_title_form` is introduced, using the `s_website_form` inside, and suggested in the snippets modal instead of the original one. That one comes with a background color, title, etc. Note: in old databases and other codebase places, `s_website_form` will still be used as a main snippet so the code here also keeps that possibility to drop it as a main snippet and move it. It is just not suggested to be used as a main one anymore, but still possible. [1]: https://github.com/odoo/odoo/commit/a3b176bf21e4ad291f51b69360ca2194517617a0 [2]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Related to task-4206683
This update corrects how unpaid balances are shown when sales orders are loaded in Point of Sale and prevents crashes in common POS workflows. It improves reliability when adding products with add-ons in self-ordering and when reopening restaurant orders already at the payment stage.
Original PR description
In this commit: ==== - Order total was not shown properly when loading sales order in POS, instead of unpaid amount, total amount was shown everytime in due balance. - Fixed Traceback on adding product in cart which contains addons. - Fixed Traceback while opening an order that is in the payment stage in the restaurant from floorscreen.
This fixes a problem where tasks could not be found through linked selection fields because their display name was not searchable. The change helps users search and select tasks normally again across related records.
Original PR description
Since https://github.com/odoo/odoo/pull/174967, use name_search on task doesn't work correctly: "Non-stored field project.task.display_name cannot be searched" Which makes any many2one toward it unsearchable. The field display_name is only added when no display_name are set on the model. It means that every model 'overriding' display_name should also included `search='_search_display_name'`. Two solution: - add `display_name` has a normal field to be extended as usual. (import nightmare to fix) - just add `search='_search_display_name'` on every model taht have display_name =field...
This change ensures the Odoo Debian package correctly includes a required dependency on Ubuntu 24.04, preventing startup failures after installation. It also updates the packaging test environment so this kind of issue is caught earlier.
Original PR description
Since lxml.html.clean was moved to a separate package starting in lxml 5.2 the odoo Debian package was broken in Ubuntu 24.04. A first fix was attempted in 318df32585b. While the package was properly…
Since lxml.html.clean was moved to a separate package starting in lxml 5.2 the odoo Debian package was broken in Ubuntu 24.04. A first fix was attempted in 318df32585b. While the package was properly built with this fix and was installable, but Odoo failed to start under Ubuntu. The bug flew under the radar because the simple test after the package build is done with a Docker based on Debian Bookworm. In fact, the fix was not taken into account because the python packages defined in the debian/control are not really taken into account by dh_python3 that tries to compute the python dependencies. With this commit, a py3dist-overrides file is used to overrides the package mapping between python packages and debian packages. The same pipe trick is used as in the previous fix to ensure that the package is installable in Ubuntu 24.04 (which provides python3-lxml-html) and in Debian Bookworm (which does not provide the python3-lxm-html). Finally, the Docker image used for the build and the test is changed to use Ubuntu 24.04. 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
The Website SEO tool now correctly handles newer language code formats when adding keywords. This prevents an error that interrupted SEO optimization work, helping users continue editing website metadata without disruption.
Original PR description
Steps to reproduce: - Go to Website - Open the menu Site > Optimize SEO - Try to add some keyword - Traceback occurs. Since [1], language codes in the front-end now follow the BCP 47 format. This commit ensures the proper application of jsToPyLocale and pyToJsLocale conversions. [1]: https://github.com/odoo/odoo/commit/42551616dcb563c39b915f2d510217a159668cb7 task-4210172
Spreadsheet pivot tables now correctly support using the same measure field more than once with different calculations, such as sum and average. This ensures users see all requested results instead of only one calculation being loaded.
Original PR description
Steps to reproduce: - Insert a pivot view in a spreadsheet - Add two measures with the same field name and different aggregators => Only one aggregator is fetched Before this commit, the Odoo pivot view in spreadsheet didn't support correctly the case where the same field was used multiple times in the measures section with different aggregators. This commit fixes this issue by overriding the needed methods of the web pivot model (on which the spreadsheet pivot model is based on) to change the way the measurements are stored. Before, it was the fieldname of the measure, now it is an id, based on the fieldname, the aggregator and the type of the measure. Task: 4207668 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
Bank statement reconciliation is now handled in the background instead of during the user's on-screen workflow. This prevents long loading times when bank statement data is processed, making the experience more responsive.
Original PR description
Previously, the _cron_try_auto_reconcile_statement_lines method was called directly from _fill_document_with_results, which could cause significant delays when triggered from the UI, resulting in long loading times for users. This commit resolves the issue by scheduling the reconciliation process as a background cron job, improving the responsiveness of the _fill_document_with_results function. Original task-4061457
Portal users can now switch to the document list view without seeing a client error. This keeps document browsing reliable for external users who need list-based navigation.
Original PR description
When portal users try to switch to the list view, they get a client error. The error is solved by keeping the studio service accessible to the ListRenderer. task-3373836
9 changes
Resolved issues and error corrections
Fixed an issue where exporting the Thai Sales Tax Report (xlsx) would fail when using a branch company. The system now correctly looks up tax group information from the parent company when it's not found in the branch, allowing the export to complete successfully.
Original PR description
### Steps to reproduce * install `l10n_th_reports` * create a Thai company and its branch * using the company selector, ensure the current company is the branch company, while selecting both parent and branch company * open the Thai Tax Report * attempt to export the "Sales Tax Report (xlsx)" You should be met with a traceback about a tax group External ID not being found ### Cause The system looks for an XML ID which is only present in the parent company, while using the branch company opw-4181071
This fix restores the date display on receipts for Chilean Point of Sale transactions. Previously, a system update removed the date field, causing receipts to appear without transaction dates. The fix ensures dates are properly shown on all POS receipts for Chilean companies.
Original PR description
When validation an order in a Chilean shop, the date is not show on the receipt. Steps to reproduce: ------------------- * Change the company for the Chilean one **CL Company** * Go to the **Point of…
When validation an order in a Chilean shop, the date is not show on the receipt. Steps to reproduce: ------------------- * Change the company for the Chilean one **CL Company** * Go to the **Point of sale** App * Open shop session * Make and order and validate it > Observation: The date is not reported on the receipt Why the fix: ------------ Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chilean localization. Header uses the data from `props.headerData` https://github.com/odoo/odoo/blob/5f748c9d5731fe2e7e519ee9625da25e2bb219bc/addons/point_of_sale/static/src/app/navbar/cash_move_popup/cash_move_receipt/cash_move_receipt.xml#L6 The date field in `headerData` is computed in `getReceiptHeaderData` https://github.com/odoo/enterprise/blob/923dfe962b714797ee41e8f7beed2cb2d6df7048/l10n_cl_edi_pos/static/src/overrides/models/pos_store.js#L48 However, this commit https://github.com/odoo/odoo/commit/5cb7639160cef5401ada8cdde5a5522d8d29c9a9 removed the field `receiptDate` on the pos order. We thus use the same logic to set the date in `headerData`. opw-4136943
The Accounting and Benchmark dashboards had a problem where selecting quarterly filters would cause errors because the underlying formulas were only designed to work with monthly data. This fix disables the quarter filter option to prevent users from encountering broken dashboards and ensure the filtering functionality works as intended.
Original PR description
The Accounting and Benchmark dashboards were designed with a global filter working with months. But when filtering by quarter, everything breaks because formulas do not expect an input such as "Q4/2020". This commit disable the possibility to select quarters. Task: 4184088
The eBay module was logging complete API responses at INFO level, which caused excessive log file growth and disk space issues for customers. This fix changes API response logging to DEBUG level, reducing unnecessary log bloat while keeping detailed information available when needed for troubleshooting.
Original PR description
## Description Currently the ebay module logs as `INFO` the whole content of the JSON response coming from the Ebay API. This can bloat excessively the logs of databases, forcing customers to quickly exceed their disk quotas. We can just log this type of information as a DEBUG log. ## Reference opw-4192547 Forward-Port-Of: odoo/enterprise#70626
This update fixes the Swiss HR payroll module (l10n_ch_hr_payroll_elm) to properly handle module updates. The change ensures that payslip processing works correctly when the module is updated, preventing potential data inconsistencies or processing errors for Swiss payroll operations.
This fix resolves an issue where only the first bank account could be added to a customer during bank reconciliation. Previously, when reconciling multiple bank accounts with the same customer, only the first account would be saved. Now all bank accounts are properly added to the customer record, allowing businesses to maintain complete banking information for their partners.
Original PR description
Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4145124
This fix resolves an issue where completing a repair order would incorrectly duplicate the original return item in the product return list. When ending a repair, the system was mistakenly linking the repair's internal stock movement to the customer's return shipment, causing the returned item to appear twice. This fix ensures repair movements are properly separated from return shipments.
Original PR description
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer…
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense. opw-4159779
This update fixes the IoT (Internet of Things) integration in the manufacturing shop floor system, enabling proper communication with IoT devices like cameras and sensors. The changes allow workers to scan workorder barcodes and use IoT equipment for quality checks, improving the efficiency and accuracy of the manufacturing process.
Original PR description
Make ShopFloor use IoT task: 4017327
Fixed a bug in the manufacturing shop floor where the Quality Checks button would remain visible and cause an error when clicked after quality checks were already completed. The issue was that production data wasn't being refreshed properly on screen. This update ensures the system always displays the most current production status, preventing users from attempting duplicate quality checks.
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` to a getter so it always contains the correct reference to the record. opw-4176393