Tuesday, March 11, 2025
6 changes · 18.0
New functionality added to Odoo
This adds a new Belgian payroll module that lets companies export payroll data in a format supported by Acerta. It helps Belgian employers streamline payroll processing by reducing manual data preparation for their payroll provider.
Original PR description
Create a new module to export payroll data for Acerta. **NOTE during fw port I need to move the test for the other ss to the main test module** task-3750799
Enhancements to existing features
Opening the Replenishment view is now much faster in databases with many automatically triggered replenishment rules. The change avoids unnecessary calculations when there are no relevant manual replenishment records to clean up, reducing wait times significantly.
Original PR description
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this…
Issue -->
When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.
Solution -->
Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.
Benchmarks -->
For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view.
| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s |
opw-4606704Resolved issues and error corrections
This fix moves standard work schedule calculations into the core HR module so recruitment features can access them without requiring payroll. It prevents errors when posting or using recruitment integrations that need weekly hours or full-time status.
Original PR description
Currently, we are getting an attribute error while executing the below lines of code.…
Currently, we are getting an attribute error while executing the below lines of code. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L16 https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L31 Error:- ``` AttributeError: 'resource.calendar' object has no attribute 'hours_per_week' ``` This is because the `hours_per_week`, `is_fulltime` are defined in the `hr_payroll`. But they are used in the `hr_recruitment_integration_monster`. Which is not dependent directly/indirectly on `hr_payroll`. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_payroll/models/resource_calendar.py#L20-L21 So this will lead to the above traceback. We can resolve this issue by moving the hr_payroll code of calculating the `hours_per_week` and `is_fulltime` to hr module. sentry-6267814511 Related Enterprise PR:-https://github.com/odoo/enterprise/pull/78521
HR teams can now import time off allocations that use accrual plans more reliably. When an accrual plan is provided, the allocation type is set automatically, and allocation duration values are compatible with export and import workflows.
Original PR description
Problem ---------- It is impossible to import batch of data with allocation_type set to 'accrual' and an allocation duration Objective ---------- - DO NOT make it possible by removing the readonly attribute on the allocation_type field - Allow the user to set directly an accrual plan and the allocation_type will be set automatically accordingly - Same fot the allocation duration make it importable Solution ---------- - Accrual plan : create an inverse, if accrual plan exists set allocation type to accrual else regular - Allocation duration, make an inverse to make it compatible export/import. It will parse the float value from the string. task-4521658
Marketing automation reports now show accurate rejected message counts when WhatsApp marketing is installed. This prevents valid email campaign statistics from being overwritten by WhatsApp-specific data, giving users more reliable campaign performance figures.
Original PR description
Currently, when `marketing_automation_whatsapp` is installed, marketing automation campaign statistics are not computed correctly. ### Steps to Reproduce 1. Install `marketing_automation_whatsapp`.…
Currently, when `marketing_automation_whatsapp` is installed, marketing automation campaign statistics are not computed correctly. ### Steps to Reproduce 1. Install `marketing_automation_whatsapp`. 2. Create a marketing automation campaign with an email activity. 3. Ensure one or more traces are rejected (e.g., by using invalid email addresses). 4. View the activity statistics. Expected Result: The rejected count on the right correctly displays the number of rejected traces. Actual Result: The rejected count on the right always displays `0`, even when rejected traces exist. ### Cause The `marketing_automation_whatsapp` module overrides `_get_full_statistics` to include WhatsApp-related statistics in addition to the marketing data. However, the override currently concatenates the results from the base `_get_full_statistics` and the WhatsApp-specific statistics. And because `MarketingActivity._compute_statistics` doesn't expect `_get_full_statistics` to return multiple entries for a given `activity_id`, the values from the WhatsApp-specific results end up overwriting the base values. opw-4292488 opw-4523885 opw-4585705 opw-4585779
This fix prevents an error when preparing job posting data for Monster recruitment integration in setups that do not use payroll. It ensures working time information is available from the HR module, improving reliability for recruitment workflows.
Original PR description
Currently, we are getting an attribute error while executing the below lines of code.…
Currently, we are getting an attribute error while executing the below lines of code. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L16 https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L31 Error:- ``` AttributeError: 'resource.calendar' object has no attribute 'hours_per_week' ``` This is because the `hours_per_week`, `is_fulltime` is defined in `hr_payroll`. But it is used in `hr_recruitment_integration_monster`. Which is not dependent directly/indirectly on `hr_payroll`. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_payroll/models/resource_calendar.py#L20-L21 So this will lead to the above traceback. We can resolve this issue by moving the hr_payroll code of calculating the `hours_per_week` and `is_fulltime` to the hr module. sentry-6267814511 Related Community PR:- https://github.com/odoo/odoo/pull/196427