Daily updates from Odoo
Monday, November 18, 2024
13 changes
9 changes
Resolved issues and error corrections
This fixes a restaurant point-of-sale issue where staff could no longer transfer an order to a table on another floor. Floor selection now remains available during a table transfer, helping service teams move orders correctly without interruption.
Original PR description
In c57f2ba594d2e1d081e6521b06d63a7d2a260921 we refactored the table transfer mechanism. This introduced a bug, namely the fact that table transfer to a different floor no longer works. This is because with the new logic, a click anywhere on the screen other than on a table would cancel the transfer. This makes sense when clicking on the burger menu for ex, but it removes the possibility of transferring an order to a different floor, because that requires clicking on the floor selector button. In this commit we fix the issue by ignoring clicks on the floor selector in the transfer cancellation logic. Task: 4285748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves several issues that could cause errors or confusing behavior in day-to-day workflows, including link tracking, SEO suggestions, sales delivery adjustments, spreadsheet balances, surveys, point of sale, and time off upgrades. It also reduces unnecessary background processing load and clarifies a purchasing field label, improving reliability and usability for affected users.
Original PR description
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
Fixes an issue that could block users from resetting company-paid expense reports back to draft. This prevents an unexpected error screen and keeps the expense correction workflow available when the configured currency data is missing in this edge case.
Original PR description
When the user tries to reset the expense report to draft, A traceback will appear. Steps to reproduce the error: - Go to Expenses > Configuration > Settings > Select Employee Expense Oustanding…
When the user tries to reset the expense report to draft,
A traceback will appear.
Steps to reproduce the error:
- Go to Expenses > Configuration > Settings > Select Employee Expense Oustanding Account
- Create a new expense > Paid by: Company > Create Report > Submit to Manager >
Approve > Post Journal Entries > Reset to Draft
Error:
```
File "/home/odoo/odoo/community/addons/account/models/account_move_line.py", line 1807, in _prepare_move_line_residual_amounts
has_zero_residual = company_currency.is_zero(remaining_amount)
File "/home/odoo/odoo/community/odoo/addons/base/models/res_currency.py", line 257, in is_zero
self.ensure_one()
File "/home/odoo/odoo/community/odoo/models.py", line 6196, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.currency()
```
https://github.com/odoo/odoo/blob/7ad6205ca901ed97a9728d5eec746b7b68e40c48/addons/account/models/account_move_line.py#L1803-L1806
Here, When ``company_currency`` is empty,
It will lead to the above traceback.
sentry-5988408651
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures required Colombian localization fields appear when customers add an address during checkout. It prevents checkout errors for Colombian company websites and makes the billing/delivery address option work as expected.
Original PR description
Steps to reproduce: - Switch to CO Company - Website > Configuration > Company = CO Company - Home Page > Shop > Any product > Add to cart > Proceed to Checkout - Checkout > Add address > Error occurs Coupled with https://github.com/odoo/enterprise/pull/73734 Columbian localization is supposed to add fiscal regimen and obligation types to the form when Identification Type is NIT. The xpath is unstable as Identification Type is only displayed if the partner_id of the contact is the same as that of the order and the partner_id is only passed on redirections when the address is missing mandatory fields. Additionally, despite having an option to use the same address for billing and delivery being checked, those fields are inaccessible on the address form, showing up only on the billing address if the addresses are separate. opw-4295936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the Manufacturing Master Production Schedule more reliable when users view planning data by different time periods, such as weeks, months, or years. It prevents users from placing or editing replenishment orders in views where the totals could be misleading, and improves lead-time calculations by using the actual forecast dates instead of broad period start dates.
Original PR description
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the…
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - disable max_to_replenish_qty: `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - make replenish input cells readonly: When showing a bigger period type than the one selected in the settings (e.g. year > week), the replenish input fields are made readonly. This is because there's a loss of precision when showing bigger period and changing values may have unintended consequences that way. Also remove the colors on the replenish cells when in readonly. >[IMP] mrp_mps: more tests Adding more tests for various cases in MPS. Also, do `_get_date_range` in `setUpClass` for the month periods since it is the default. Remove all `_get_date_range` apart from when the default period has been changed in the settings. >[FIX] mrp_mps: use real dates with lead times When a bom has a lead time, we want to use the real date to compute the indirect demand forecast of the components in the MPS. Currently when showing the MPS in a period other than 'day', Odoo will do the sum of all forecast records for each period and base its calculation on the 1st day of the period. E.g. for the month of January, it will do the sum of all forecasts of that month then calculate lead times based on the 1st of January. > indirect_demand_qty > > Jan-25: 1000 > > Feb-25: 500 This causes issues with lead times when selecting bigger periods. This fix ensures that the forecasts are stored per date: > demand_qty_dict > > Jan-25 > > > 01-01-25: 200 > > > 01-07-25: 500 > > > 01-23-25: 300 > > Feb-25 > > > ... That way, when calculating lead times, it uses the real date for each forecast instead of the 1st day of the period shown. task 4172967
Users can now find frozen spreadsheets in Shared With Me when the related folder is hidden or no longer accessible. This makes shared documents easier to locate and avoids confusion when access to a folder changes.
Original PR description
Purpose ======= Hide the "frozen folders" by default, the frozen spreadsheets can be accessed in "Shared With Me". Task-4316768
SEPA payment file generation for employee payslips no longer fails when an employee's work address has no country set. The system now uses the valid payment address, such as the employee's private address, so payroll payments can be generated reliably.
Original PR description
When trying to generate SEPA for employee payslip, and one of the the employee has a work address with no country, the generation fail with the following error:
```
File "/home/odoo/src/enterprise/18.0/account_iso20022/models/account_journal.py", line 394, in _get_PstlAdr
Ctry.text = partner_id.country_id.code
^^^^^^^^^
File "src/lxml/etree.pyx", line 1043, in lxml.etree._Element.text.__set__
File "src/lxml/apihelpers.pxi", line 749, in lxml.etree._setNodeText
File "src/lxml/apihelpers.pxi", line 737, in lxml.etree._createTextNode
File "src/lxml/apihelpers.pxi", line 1528, in lxml.etree._utf8
TypeError: Argument must be bytes or unicode, got 'bool'
```
This fix by using the country code of the compute valid partner address (i.e in our case the employee private address) and not the partner itself (the work address).The Colombian eCommerce checkout now reliably shows the required tax-related address fields when customers add or edit an address. This prevents checkout errors and helps customers complete purchases correctly when fiscal information is required.
Original PR description
Steps to reproduce: - Switch to CO Company - Website > Configuration > Company = CO Company - Home Page > Shop > Any product > Add to cart > Proceed to Checkout - Checkout > Add address > Error occurs Coupled with https://github.com/odoo/odoo/pull/187064 Columbian localization is supposed to add fiscal regimen and obligation types to the form when Identification Type is NIT. The xpath is unstable as Identification Type is only displayed if the partner_id of the contact is the same as that of the order and the partner_id is only passed on redirections when the address is missing mandatory fields. Additionally, despite having an option to use the same address for billing and delivery being checked, those fields are inaccessible on the address form, showing up only on the billing address if the addresses are separate. opw-4295936
Customer statements now show information that better matches what users need to understand customer balances and activity. PDF exports have also been improved, while the changes are limited to customer statements and should not affect the partner ledger.
Original PR description
The current iteration of this feature is lacking and does not cover the need. These improvements aim at correcting that by displaying a report that is more relevant to what the user want to know, as well as improving the PDF export. All changes have been made to only impact the report in the context of a customer statement, and should not impact the partner ledger.
4 changes
Resolved issues and error corrections
This update fixes a potential issue where payment data wasn't being accurately captured. By waiting for the completion of the payment initiation flow, the system now reliably records the transaction result, improving payment processing reliability. This ensures accurate financial records and a smoother payment experience for users.
Original PR description
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route.
This update automatically removes inactive WhatsApp chats after two weeks, regardless of whether they've been read. Previously, unread chats could accumulate and slow down the Discuss feature, limiting performance. This change prevents data overload and ensures a smoother user experience.
Original PR description
When a whatsapp conversation is inactive after 1 day, they are automatically unpinned as long as user has seen all the messages. However, if the user never reads them, these whatsapp conversations…
When a whatsapp conversation is inactive after 1 day, they are automatically unpinned as long as user has seen all the messages. However, if the user never reads them, these whatsapp conversations keep being added to the pinned list of conversations, which adds more and more loads on Discuss fetched data over time. There is a practical limit of around 2000 pinned conversations, after which Discuss is very slow and hardly usable. This is a known limitation with the current implementation. Whatsapp conversations usually involved many operators for a given conversation, even though usually a single operator is actively communicating with the whatsapp customer. This means that all the inactive operators are keeping many unread whatsapp conversations, thus lots of whatsapp conversations stay unpinned. This commit fixes the issue by forcing unpinning inactive whatsapp conversations after 2 weeks, regardless of whether current user has read the conversation or not. Most of the time whatsapp conversations are short-lived conversations, therefore after 2 weeks this is almost guarantee that there's no point keeping this conversation pinned. opw-4331007
This update fixes a bug where users could accidentally create multiple batches for the same payment, leading to validation errors. The change prevents adding payments to existing batches, ensuring batch validation processes run smoothly and reliably. This improves data accuracy and prevents export file generation issues.
Original PR description
## Issue: When we create a batch from a payment by selecting it and clicking on "Create Batch", even if the payment is already in a batch or validated, it is possible to add it to a new batch, which…
## Issue: When we create a batch from a payment by selecting it and clicking on "Create Batch", even if the payment is already in a batch or validated, it is possible to add it to a new batch, which can lead to issues when validating the batch. ## Steps to reproduce: - Create a payment (posted but not sent) SEPA transfer. - Select this payment and create batch payment. - validate the batch - Open payments list again, and select that same payment, then create a batch payment from the selection. - a new batch payment will be created. - If you open the batch payments list you'll notice 2 batches: 1. the original batch now has no payments inside it so the "re-generate Export File" button won't show up. 2. the second batch now contains the payment, but we can't re-generate the export file because it shows an error: The batch could not be validated, Some payments have already been sent. Solution: - before creating a batch with payments or adding payments to a batch we check if the payments we are adding are already in a batch. OPW-3976563 Forward-Port-Of: odoo/enterprise#67315
This update corrects a configuration issue impacting payroll processing for Colorado and Washington states. The changes prioritize tax rules above post-tax deductions and standardize their categorization as 'Taxes,' ensuring accurate tax calculations and reporting. This improves the reliability of payroll data.
Original PR description
All the Colorado and Washington taxes rules should be above the Post Tax Deductions and should all be of the category Taxes. Task: 4329645