Friday, September 27, 2024
9 changes
1 change
Enhancements to existing features
Demo payroll data now includes two local banks with appropriate names and BIC codes for multiple country payroll localizations. This makes sample payroll setups feel more realistic and easier to evaluate in demonstrations or testing.
Original PR description
* = au, bd, eg, hk, jo, ke, lt, lu, ma, mx, nl, pl, ro, sk, and us. This PR improves the demo data for multiple l10n payroll modules by adding two banks (`res.bank`) with local bank names and BIC codes to each localization.
6 changes
Enhancements to existing features
The web interface now lets teams define custom visual styles for fields that show remaining days. This makes it easier to highlight time-sensitive records according to each business process, such as marking items as healthy or urgent based on configured day thresholds.
Original PR description
This commit adds the ability to customize the classes of the `remaining_days` field through the `classes` option.
Usage:
```xml
<field
name="fname"
widget="remaining_days"
options="{'classes': {'success': 'days >= 10'}"
/>
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr2 changes
Enhancements to existing features
The Spanish Modelo 303 tax form has been updated to comply with new government regulations effective Q3/Q4 2024. The changes include new fields for reporting tax adjustments, refund requests, and updated VAT rates (7.5% and 2%) and equivalence surcharge rates (1% and 0.26%). These updates ensure Spanish companies can accurately report their quarterly VAT obligations under the latest tax rules.
Users can now include property fields when importing and exporting records, making these flexible custom data points easier to manage in bulk. This improves data migration and reporting workflows while keeping property definitions controlled by the related parent record.
Original PR description
https://github.com/odoo/enterprise/pull/69287 task-4027103
Event reminder and follow-up messages now send in smaller batches instead of trying to process every registration at once. This reduces the risk of failed scheduled jobs, duplicate messages, and performance issues for large events using email or SMS communications.
Original PR description
RATIONALE When invoked through cron, event schedulers currently run on all available registrations. This can lead to Memory or Time errors when dealing with big events. We should instead move towards…
RATIONALE
When invoked through cron, event schedulers currently run on all available
registrations. This can lead to Memory or Time errors when dealing with
big events. We should instead move towards an interactive sending, committing
after each batch, to gradually send communications without errors and without
sending multiple times mails, sms, whatsapp messages, ...
SPECIFICATIONS
Global approach for this PR
* rewrite schedulers execution code, notably to have more control on
input / output of each type: event-based or attendee-based schedulers,
give registrations to contact as input, ... ;
* introduce more performance oriented code: avoid filters on all attendees,
search for batches instead; find once attendees to contact then;
delegate the sending only to sub modules;
* make communications iterative
* event-based: use recently introduced "last_registration_id" field to know
at which point process was stopped, and resume communication sending;
* attendee-based: contact by batches;
* make code more defensive against ill defined templates and issues during
communication sending;
* add / improve tests;
See sub commits for more details.
Task-3814592: Event: Limit scheduler in cron mode
Task-3084943: Event: Improve communication scheduler scalabilityThe shop floor view no longer applies the default “This Station” filter, so teams can see manufacturing orders beyond the current workstation by default. This change is possible because prior performance improvements now keep the view responsive without needing that restriction.
Original PR description
The 'This Station' default filter was introduced in [1] as a stopgap solution for limiting the amount of MOs loaded simultaneously in the view, to avoid performance bottlenecks. Since the introduction of a limit (also in [1]), as well as later performance improvements from [2], the performance of the shop floor is now acceptable without this filter, so we proceed with removing it completely in this PR. [1] https://github.com/odoo/enterprise/pull/64551 [2] https://github.com/odoo/enterprise/pull/66898
Event-related automated messages now run in smaller batches and can resume where they stopped, reducing failures for large events. This helps prevent duplicate emails, SMS, WhatsApp messages, and social posts while improving reliability and performance.
Original PR description
RATIONALE When invoked through cron, event schedulers currently run on all available registrations. This can lead to Memory or Time errors when dealing with big events. We should instead move towards…
RATIONALE
When invoked through cron, event schedulers currently run on all available
registrations. This can lead to Memory or Time errors when dealing with
big events. We should instead move towards an interactive sending, committing
after each batch, to gradually send communications without errors and without
sending multiple times mails, sms, whatsapp messages, ...
SPECIFICATIONS
Global approach for this PR
* rewrite schedulers execution code, notably to have more control on
input / output of each type: event-based or attendee-based schedulers,
give registrations to contact as input, ... ;
* introduce more performance oriented code: avoid filters on all attendees,
search for batches instead; find once attendees to contact then;
delegate the sending only to sub modules;
* make communications iterative
* event-based: use recently introduced "last_registration_id" field to know
at which point process was stopped, and resume communication sending;
* attendee-based: contact by batches;
* make code more defensive against ill defined templates and issues during
communication sending;
* add / improve tests;
See sub commits and linked community PR for more details.
Task-3814592: Event: Limit scheduler in cron mode
Task-3084943: Event: Improve communication scheduler scalabilityAppointment manual confirmation now depends on the selected booking slot rather than the scheduled day, giving administrators better control during busy periods. Customer confirmation emails are clearer because accept and decline actions are reserved for admins, and cancelled appointment records are labeled more accurately.
Original PR description
### Purpose Currently, manual confirmation was inconveniently triggered based on scheduled booking days, causing users inconvenience. The purpose of this PR is to Change the Manual Confirmation Trigger conditions and Change Mail Template when Manual Confirmation is enabled. ### Specs **1. Update Trigger Conditions for Manual Confirmation** - Change trigger conditions to be based on booking slots instead of scheduled days. This allows admins to verify bookings manually before confirmation, especially during peak times. **2. Revise Mail Template for Confirmation** - Update mail template context for users receiving confirmation notifications. - Remove 'Accept' and 'Decline' buttons, as only admins can now accept or decline bookings. **3. Appointment Booking Form View Improvements** - Changed 'Archived' ribbon to 'Cancelled', when an appointment type is set. Task-3918889
Original PR description
The Modelo 303 has been updated according to [Orden HAC/819/2024] of July 30, 2024. Changes starting from periods 09 and 3T 2024: --------------------------------------------- * Box 108 was added to…
The Modelo 303 has been updated according to [Orden HAC/819/2024] of July 30, 2024. Changes starting from periods 09 and 3T 2024: --------------------------------------------- * Box 108 was added to allow for manually entering those rectifications for which there is no specific box in the form. * Box 111 was added to differentiate refund requests that arise from the application of tax regulations from those that may correspond to a request for undue income. * 3 boolean fields were added in case we are submitting a rectification to indicate that: - we want to cancel/modify the direct debit made before; - the rectification is due to a discrepancy with administrative criteria; - the rectification is due to another reason. Changes starting from periods 10 and 4T 2024: --------------------------------------------- * Boxes 153, 154 and 155 were changed to reflect the updated VAT rate of 7.5%. * Boxes 16, 17 and 18 were changed to reflect the updated Rec. Eq. rate of 1%. * Boxes 165 to 170 were added to report the new VAT rate of 2% and the new Rec. Eq. rate of 0.26%. * Box 27 was updated to take into account the new boxes 167 and 170 in its computation. (See also [Real Decreto-ley 4/2024]) The BOE file export was updated accordingly. > [!IMPORTANT] > In order to use this, you need to update both the `l10n_es`, `l10n_es_reports` modules and install the new `l10n_es_reports_2024` module. [Orden HAC/819/2024]: https://www.boe.es/eli/es/o/2024/07/30/hac819 [Real Decreto-ley 4/2024]: https://www.boe.es/buscar/act.php?id=BOE-A-2024-12944 [task-4147046](https://www.odoo.com/odoo/all-tasks/4147046) Related to https://github.com/odoo/odoo/pull/179797 Forward-Port-Of: odoo/enterprise#70348 Forward-Port-Of: odoo/enterprise#69736
This improvement makes the fiscal folio (a required Mexican tax identifier) visible in list views for vendor invoices and payments, matching the existing functionality for customer invoices. This enhances visibility and makes it easier for users to track and verify fiscal information across all transaction types in Mexico.
Original PR description
Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices. Related https://github.com/odoo/enterprise/pull/69359