Daily updates from Odoo
Monday, November 18, 2024
23 changes
7 changes
New functionality added to Odoo
Adds a new Employee State Insurance report for Indian payroll, showing employee and employer contributions for a selected month or period. This helps payroll teams review ESIC contribution details per employee and export them to Excel for easier compliance and reporting.
Original PR description
This PR adds a new ESI (Employee State Insurance) report that details the amounts contributed by employees and employers to the ESIC during a given month/period. It generates an xlsx file containing ESI details for each employee. task-4011111
Enhancements to existing features
Payroll salary rule categories can now be linked to a country, helping companies use the right categories for each local payroll setup. This reduces duplicate or conflicting category choices and removes a redundant Moroccan payroll category.
Original PR description
-added new field country_id on salary rule categories model. -added constrain to prevent from creating two categories with same code in same country. -added constrain for the category which is currently used in existing salary rule, country field should not be changed. -added domain for category_id in hr salary rule model based on the country of structure, which means the structure without the country will show the category without country and structure with country will show the categories of that specific country and category without country in hr.salary.rule -added domain for parent_id to display only categories with same country or available to all countries. -added the specific countries in l10n data for salary rule category. -added tests * = l10n_ma_hr_payroll -removed Employer's contributions rule category in Moroccon localization because its same as the Company Contribution rule category task-3947372
The signing experience has been cleaned up so completed, cancelled, refused, and expired documents behave more consistently in the thank-you screen. Mobile users also get a simpler signing interface with clearer actions and better zoom controls, reducing confusion when completing documents on small screens.
Original PR description
This commit aims to fix some issues with sign: 1. on the Thank-you dialog, when clicking on cancel, document should be removed from the list. 2. don't include expired sign requests in the Thank-you dialog. 3. change the layout of Thank-you dialog. 4. for mobile view, remove "Fill in" input field. 5. for mobile view, rename the validate button. 6. changing validity to the past, should set the state to 'expired'. 7. refusing sign requests on the Thank-you dialog doesn't cancel them. 8. fix zoom in/out on mobile screens. task: 4294860
This change lays groundwork for a revised Discuss messaging service used across several Odoo apps. It improves the shared communication foundation that supports chatter, activities, attachments, live chat, VoIP, and related collaboration features, helping teams benefit from more consistent messaging behavior over time.
Original PR description
https://github.com/odoo/odoo/pull/125092
WhatsApp template buttons that use a relative link, such as /my/home, are now automatically completed with the current Odoo instance domain when submitted for approval. This makes it easier to create message buttons that reliably send customers back to the right Odoo website without manually entering the full address.
Original PR description
Whenever a WhatsApp template has a url button with website_url that has no domain (e.g., /my/home), this website_url intuitively is expected to be prefixed with the current instance domain (e.g., https://odoo.com/my/home). This domain prefixing takes effect when the template is submitted for approval. This feature is useful in case we want to create a template button redirecting to the Odoo instance that created it. task-4241442
This update refines the look and behavior of Discuss-related screens and messaging tests, making conversations feel more polished and consistent. It also touches WhatsApp messaging and stock barcode image preview areas to keep related communication experiences aligned.
Original PR description
https://github.com/odoo/odoo/pull/170120
Code cleanup and technical improvements
Dutch statutory reporting features have been merged into the main Dutch reports module to simplify maintenance and reduce duplicated functionality. This keeps SBR and ICP reporting available in a more central place, making future updates easier and more consistent.
Original PR description
We added l10n_nl_reports_sbr, l10n_nl_reports_sbr_icp, l10n_nl_reports_sbr_ob_nummer and l10n_nl_reports_sbr_status_info in stable, this pr will do some cleaning by merging l10n_nl_reports_sbr, l10n_nl_reports_sbr_ob_nummer, l10n_nl_reports_sbr_status_info and l10n_nl_reports_sbr_icp into l10n_nl_reports and merging the ICP report from l10n_nl_intrastat into l10n_nl_reports as well.
- adhere to ruff styling
- l10n_nl_reports_sbr_tax_report_wizard: because global variables are discouraged and can be a source of bugs we removed the 'server_leaf_cert' variable and instead implemented the `SoapClientWrapper` class which now holds the `server_leaf_cert`
task: 318703111 changes
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.
5 changes
New functionality added to Odoo
This update introduces a 'Bonus' input type to Odoo's payroll system for the United States Regular Pay structure, allowing for additional income sources to be included in employee salaries. It also adds support for including employee expenses in the calculation, improving payroll flexibility and accuracy. This change enhances reporting and compensation management.
Original PR description
Add `Bonus` input type to `United States Regular Pay Salary Structure`.
Use `Expenses` and `Bonus` input types in the computation of payslips.
* Expenses:
* Allows users to include expenses (added automatically from the Expenses app) into the salary calculation when using the Structure Type "United States: Regular Pay". The rule is placed post taxes in the structure.
* Bonus:
* Add an Input type in "hr.payslip.input.type" called `Bonus`.
* "Bonus" allows users to add an extra source of income for employees that have associated the "United States: Regular Pay" Structure type in their payslip. The rule is placed pre-taxes in the structure, it is a taxable amount.
task-4097635Resolved 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