Thursday, October 31, 2024
8 changes
3 changes
Enhancements to existing features
Users can now use Ctrl+click or middle-click to open supported records and links in a new browser tab across several Odoo areas. This makes it easier to compare information or keep the current page open while navigating, improving day-to-day workflow efficiency.
Original PR description
task-id 4031939
Payroll users can now specify an effective payment date when generating SEPA payment reports. This date is included in the exported SEPA file, helping businesses control when payroll payments are processed by the bank.
Original PR description
When creating a payment report with the sepa format, we can specify an effective date that will be written in the sepa file. Task: 4213487
The Mexican electronic invoicing sales module now shows additional relevant fields on pro-forma invoice PDFs, sales reports and portal views, and invoice reports and portal views. This helps customers and staff see more complete transaction information directly in their documents.
Original PR description
This commit will add some fields in the pdf of the pro-forma invoice but also the sale report/portal and invoice report/portal. task: 4191835
3 changes
Enhancements to existing features
Odoo now applies email-specific cleanup rules when generating outgoing email content, preserving formatting needed by email clients such as Outlook while still sanitizing content. This improves consistency and reliability for emails created from templates, composers, and mass mailing campaigns.
2 changes
Enhancements to existing features
This update enhances the depreciation board by visually distinguishing cancelled depreciation entries in grey. Additionally, users can now properly dispose of assets through hashed journals, resolving a previous error that prevented disposal. This improves asset management workflows.
Original PR description
This commit makes cancelled depreciation entries appear in grey in the depreciation board. It also turns the the depreciation entry's name into a link towards the move's form view.
Odoo now enables restricted email template rendering by default, allowing regular users to use common simple template fields without broad template-editing rights. This reduces the need to grant wider permissions while preserving flexibility for companies that want to allow all internal users to edit templates via settings.
Original PR description
https://github.com/odoo/odoo/pull/164671 offers a way for non-template editors to use simple expressions. Thanks to this, most of the expressions used in email templates, such as the partner name in an opportunity email template, can be used by regular users without the need to be an email template editor. Thanks to this, the need to set, by default, internal users as template editors is no longer a strong necessity. This revision aims to set the "Restrict Template Rendering" setting by default. Companies needing to set everyone as an email template editor can enable this back by un-checking its related box in the general settings. task-4246174
Email template rendering is now restricted by default, reducing the need to give all internal users broad template editing rights. Regular users can still use common simple expressions in templates, while companies that prefer the previous behavior can re-enable it in general settings.
Original PR description
https://github.com/odoo/odoo/pull/164671 offers a way for non-template editors to use simple expressions. Thanks to this, most of the expressions used in email templates, such as the partner name in an opportunity email template, can be used by regular users without the need to be an email template editor. Thanks to this, the need to set, by default, internal users as template editors is no longer a strong necessity. This revision aims to set the "Restrict Template Rendering" setting by default. Companies needing to set everyone as an email template editor can enable this back by un-checking its related box in the general settings. task-4246174
The system now automatically selects the correct document type (e-Factura or e-Ticket) based on the partner's identification type in Uruguay. When a partner has a RUT/RUC identification, the system defaults to e-Factura, which is the correct choice in 95% of cases. This reduces manual adjustments while still allowing users to override the selection when needed.
Original PR description
Description of the Issue/Feature Addressed by This PR: The current system sets the default document type to e-Ticket, regardless of the partner's identification type. However, for usability purposes, if the identification type is RUT/RUC, the document type should default to e-Factura, as this is the correct choice in 95% of cases. Current Behavior Before PR: The default document type is always set to e-Ticket, irrespective of the identification type. Desired Behavior After PR: The system will automatically select the appropriate document type (either e-Factura or e-Ticket) in the account.move module, based on the partner's identification type (RUT/RUC or other). This will reduce the need for manual adjustments. Users will still have the flexibility to select other document types to account for any exceptions. Latam-task: 1273 Adhoc-side-task: 44194