Monday, November 18, 2024
11 changes · 18.0
Enhancements to existing features
Studio exports now preserve the specific type of actions instead of treating them as generic actions. This makes exported customizations more accurate and easier to reuse, with only minor related test and cleanup updates.
Signing boxes that do not require action are now hidden, reducing clutter during document review and signing. Boxes also show the responsible person's name, making it clearer who needs to complete each required field.
Original PR description
- Hide sign item box when you don't need to fill it - Add responsible name to box task-id: 4316046
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.