Daily updates from Odoo
Friday, July 19, 2024
19 changes
4 changes
Resolved issues and error corrections
This fix helps Odoo recover when many browser sessions are waiting for live notifications at the same time. It reduces overload on the connection pool and spaces out reconnection attempts, lowering the risk of users being disconnected during busy periods or server restarts.
Original PR description
When no cursor is available to fetch bus notifications, websockets retry up to 10 times to acquire one. However, when many websockets try to acquire a cursor, the chances of getting one are very slim. Some will disconnect and will need a cursor to reconnect, worsening the cursor drought. As a result, there is minimal chance of recovery when the connection pool is full. This PR fixes this issue by wrapping cursor acquisition with a semaphore. This way, trying to acquire a cursor when none is available will make the caller wait until one is available.
The spreadsheet component was updated to the latest version for this Odoo release. This fixes an issue where COUNTIF did not correctly handle dates, helping users get more reliable spreadsheet calculations.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9e0ea2429 [REL] 17.2.17 Task: 0 https://github.com/odoo/o-spreadsheet/commit/f82ac1750 [FIX] functions: COUNTIF does not handle dates Task: 4045506 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The Point of Sale now handles cases where a sale order includes products that are not available in the PoS and the user lacks product editing rights. This prevents the order loading process from failing, helping staff continue sales workflows without needing extra permissions.
Original PR description
Before this commit, attempting to load a sale order into the PoS with products not available in the PoS would fail if the user lacked write access to the product, preventing the sale order from being loaded. opw-4057869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant staff can now scroll through the floor view when there are more tables than fit on the screen. This restores access to hidden tables, making it possible to select and manage all tables in larger restaurant layouts.
Original PR description
Currently, if a restaurant has so many table that some are hidden down the screen, it is impossible to scroll down to select the hidden table. Steps to reproduce: ------------------- * Open the **Poin of sale** App * Open restaurant session * Switch floor view * Edit plan * Add many tables such as some are not visible on the screen * Try scrolling > Observation: Unable to scroll Why the fix: ------------ For some reason, the ability to scroll in the floor view was removed with this commit https://github.com/odoo/odoo/commit/b42b0f8b541a13621b671b0b7e57812ef11fc1b2 The value changed from `overflow-auto` to `overflow-hidden` here https://github.com/odoo/odoo/blob/fb4d758ed78211a61ea797759e1fb3b02b51be60/addons/pos_restaurant/static/src/app/floor_screen/floor_screen.xml#L66 opw-4051308
1 change
Resolved issues and error corrections
Spreadsheet pivot tables and related menus were updated to align with the latest spreadsheet engine changes. This improves data consistency in pivot measures and supports smoother future spreadsheet upgrades without changing day-to-day workflows.
Original PR description
See https://github.com/odoo/odoo/pull/173681
14 changes
Resolved issues and error corrections
This fix resolves an issue where the Credit Notes button in helpdesk tickets was showing an empty list when both the helpdesk_account and helpdesk_sale_timesheet modules were installed together. The problem was caused by conflicting action names between the two modules, which has now been corrected by renaming the actions in helpdesk_account to prevent the conflict.
Original PR description
Steps to Reproduce: ----------- Install the helpdesk_account and helpdesk_sale_timesheet module. Go to the ticket form view. Perform a refund or reverse action. Click on the 'Credit Notes' stat button. Observe that the list view of credit notes is empty. Cause: ---------- When the helpdesk_sale_timesheet module is installed, the action_view_invoices method gets overridden. Fix: --------- We have renamed the actions in the helpdesk_account module to avoid conflicts. task-3972344
Fixed an issue where custom tax group labels (Preceding Subtotal values) were not displaying correctly on printed AvaTax invoices. When using AvaTax for automatic tax calculation, invoices now properly show the configured tax group names instead of generic "Untaxed Amount" labels, ensuring consistent invoice formatting across different tax configurations.
Original PR description
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”…
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)” 3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal” 4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category” 5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)” 6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box. 7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2) 8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up. This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too. opw-4027280
This update fixes three issues in the Barcode App that affect warehouse operations: (1) When scanning lots across multiple pickings in a batch, the system now correctly stays focused on the current picking until it's completed, preventing lots from being assigned to the wrong picking; (2) The quantity increment buttons now show accurate remaining quantities even when non-reserved lots are scanned; (3) Line sorting is improved to prevent duplicate entries when lines are split. These fixes ensure accurate inventory tracking and a smoother warehouse workflow.
Original PR description
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this…
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; > - Scan the product -> the first line should be selected; > - Scan a lot -> the lot is set on the first line and its qty is incremented; > - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue. > > Expected behavior: When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed. To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. **[FIX] stock_barcode: increment right qty** > When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity. That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore. > > How to reproduce: > - Create a product tracked by lots and set a barcode; > - Update the quantity on hand for this product like following: > - 3x lot1 > - 3x lot2 > - 3x lot3 > - Create a delivery for 6x this product and confirm it; > - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have: > - 0/3 lot1, [+3] > - 0/3 lot2, [+3] > - Scan lot1 one time and lot3 three times, you now have: > - 3 lot3, [+1] > - 1/3 lot1, [+2] > - 0/3 lot2, [+3] > -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity. > > To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity. task-3688770 Community PR: odoo/odoo#173521 Forward-Port-Of: odoo/enterprise#64042 Forward-Port-Of: odoo/enterprise#54589
This update hides Kenya-specific eTIMS (electronic Tax Invoice Management System) fields and buttons from companies that don't operate in Kenya. This reduces clutter and confusion for international users by only showing relevant features when Kenya is set as the company's fiscal country. The change applies across invoicing, products, stock management, and configuration screens.
Original PR description
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible.
This fix improves the user experience when connecting bank accounts by updating consent expiration dates immediately after successful synchronization, rather than making users wait up to 24 hours for the next automatic refresh. This ensures users see their updated consent status right away, making the system feel more responsive and reliable.
Original PR description
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829 Forward-Port-Of: odoo/enterprise#65408
A recent change to how French tax reports calculate values inadvertently broke the ability to audit tax line details. This fix restores the audit functionality by adjusting how the system identifies and displays the underlying journal entries for tax calculations, ensuring proper financial record-keeping and compliance.
Original PR description
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520
This update adds missing safety protections to the French tax reporting module to prevent test databases from accidentally sending real data to external systems. This ensures that when support teams create copies of production databases for investigation purposes, those copies cannot inadvertently impact customers or the live production environment.
Original PR description
This commit adds the missing neutralization necessary for the l10n_fr_reports module introduced in 06f32096749a8df29b248f29698226cf996e9106 The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. opw-3928199
This fix resolves an issue in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The problem was caused by incorrect data being passed when building the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553
This update fixes compatibility issues across multiple localization modules (Argentina, Chile, Mexico, Netherlands, Philippines, and Thailand) by updating code to work with newer versions of external libraries. The changes address deprecated methods and removed features in libraries like urllib3, zeep, cryptography, xlsxwriter, and openpyxl, ensuring the system continues to function properly with current software versions.
Original PR description
backport of #66166 Conflict notes: - ccfdc06546828868bfcfbe64f6f9c68914d96220 was dropped since the module does not exist in 17.0 (created in 17.3) - 2d58ab9042d823743bf9b0534d4572b88a30dc58 import adapted - 1728d1e448f90d3e32fc135de2370e054d0216f5 was dropped since the module does not exist in 17.0 (created in 17.2)
This fix corrects how package weight limits are handled when calculating shipping rates through Sendcloud. Previously, weight measurements were inconsistent—stored in kilograms but sent to Sendcloud as grams—causing shipping rates to be calculated incorrectly and appear unusually high. The fix ensures all weight values are properly converted to grams before being sent to Sendcloud, resulting in accurate shipping rate quotes.
Original PR description
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add…
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the package needs to be splitted, the target_weight is not being converted whereas the total_weight is.(check link at the bottom for details) Also in shipping rate request for sendcloud `max_weight` was sent in kilograms with `unit` being 'gram'. After this commit: `max_weight` is converted into grams before adding to the shipping rate request. split shipping code: https://github.com/odoo/enterprise/blob/d3b39fe78bc0ae366d32e80e325e89d2a4bb353c/delivery_sendcloud/models/sendcloud_service.py#L160-L162 opw-4035569
Fixed an issue where manually modified tax closing entries were being erased when posted. The system now preserves user changes to closing entries and properly handles dependent company closings within tax units. This ensures that accountants' manual adjustments to tax closing documents are retained during the posting process.
Original PR description
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current company. Additionally, when selecting only one company within a tax unit, it sometimes happened that, when closing the main company, the dependent closings to post (depending_closings_to_post) were empty because the moves were not generated yet for the other companies. Task: 3987807
Fixed an issue where follow-up reports and printed PDFs were missing overdue invoices from branch companies. The system now correctly includes invoices from both the parent company and all its branches when generating follow-up reports, ensuring complete visibility of all outstanding invoices across your organization.
Original PR description
To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003
This fix resolves an issue where confirmation messages were not appearing when employees validated their timesheets in the pivot and kanban views. The problem was caused by mismatched parameters in the validation action, and this update ensures users receive proper feedback when submitting timesheets for approval.
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639
This fix resolves a problem in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The issue was caused by incorrect data being passed when organizing the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553