Friday, September 27, 2024
6 changes
5 changes
Enhancements to existing features
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
1 change
Enhancements to existing features
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