Daily updates from Odoo
Friday, October 10, 2025
6 changes · master
Resolved issues and error corrections
This update corrects how Swiss payroll payslip issues are recalculated, helping ensure warnings and payroll checks stay accurate after changes. It reduces the risk of outdated or incorrect payroll guidance appearing during payroll processing.
Original PR description
task-5150492 Forward-Port-Of: odoo/enterprise#96489
Mexican electronic invoice cancellations could fail with an “invalid passphrase” error because certificate keys were sent in a format not accepted by cancellation providers. The fix restores the expected unencrypted key format for these cancellation requests, helping businesses cancel CFDI invoices reliably.
Original PR description
### Steps to reproduce 1. Install `l10n_mx_edi` with demo data 2. Switch to the ESCUELA KEMPER URGATE demo company 3. Create an invoice to the INMOBILARIA CVA demo partner 4. Send the invoice CFDI 5.…
### Steps to reproduce 1. Install `l10n_mx_edi` with demo data 2. Switch to the ESCUELA KEMPER URGATE demo company 3. Create an invoice to the INMOBILARIA CVA demo partner 4. Send the invoice CFDI 5. Request cancellation of the CFDI 6. The cancellation fails with the error 'invalid passphrase'. ### Analysis When calling `_finkok_cancel`, `_solfact_cancel`, or `_sw_cancel`, one of the API call parameters is the `pem_key` of the certificate given by the SAT. Before 19.0, the PEM key was in an unencrypted format. Since f88f8258ead, `env['certificate.key'].pem_key` is encrypted. According to Finkok's API documentation, the private key should be encrypted using DES when given as a SOAP parameter. https://wiki.finkok.com/home/webservices/ws_cancelacion/cancel However, in testing, encrypting the private key using DES seems to be rejected by Finkok. Solucion Factible and SwSapien don't indicate in their documentation whether and how the private key should be encrypted. ### Solution We send the private key unencrypted, as was already the case before 19.0. opw-5137549 Forward-Port-Of: odoo/enterprise#96562
This fix ensures receipts print with the correct order details after a fast validation payment flow. It prevents empty receipts and avoids a restaurant-mode printing error, improving checkout reliability for staff and customers.
Original PR description
pos*: pos_event_iot, l10n_it_pos Steps to reproduce: - Enable a one-click payment method. - Create and validate an order using fast validation. - On the receipt screen, print the order receipt. Issue: - The printed receipt is empty (no order details). - In restaurant mode, a traceback occurs when printing the receipt. Fix: - Use the receipt screen’s `currentOrder` reference instead of fetching the order directly from the POS instance. Task-5093060 Related: https://github.com/odoo/odoo/pull/227621 Forward-Port-Of: odoo/enterprise#96695
This fixes receipt printing for Italian fiscal printers when the point of sale is set to skip the receipt screen and print automatically. It also ensures the correct completed sale is sent to the printer, avoiding missed or incorrect fiscal receipts after checkout.
Original PR description
This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer First, before this PR, if the option to skip the receipt screen was ticked, then the receipt would…
This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer First, before this PR, if the option to skip the receipt screen was ticked, then the receipt would never print. This was caused by the printing logic being implemented on the receipt screen instead of on the pos itself. steps to reproduce: 1. install l10n_it_pos 2. configure one pos 3. configure the IT printer 4. select to skip the receipt screen (print automatically) 5. open the pos 6. make a sale => no ticket printed and the chrome console shows a printer error With this new verison the printing logic was moved to the pos so that printing of fiscal receipts with the italian fiscal printer works, even when receipt screen is skipped. This put to light another potential bug related to how the `order` variable was treated. Before this PR, the printReceipt logic in the module would not pass the order to be printed. This can become a problem upon context changes, where `pos.get_order()` does not return the completed order, but a newly created one. This can for example happen when skipping the receipt screen with the option to "print automatically" (iface_print_auto). After this PR, we keep order as an argument, so we always print the last completed order and not a newly created one. opw-4882480 Forward-Port-Of: odoo/enterprise#96346 Forward-Port-Of: odoo/enterprise#91412
Users who are allowed to print and send SEPA direct debit mandates can now generate and access the related PDF attachments without needing an extra accounting read-only permission. This prevents email sending failures and ensures users can retrieve documents they created through the mandate sending process.
Original PR description
Removing the groups restriction from the `mandate_pdf_file` field in model `sdd.mandate` because it was causing issues when using the `sdd.mandate.send` wizard. Any user who has access to the `sdd.mandate` model can use this wizard to print and send the record. During this process, the system generates a PDF and stores it in the `mandate_pdf_file` binary field, linking the resulting attachment to the record. The previous group restriction prevented users who were not part of the `account.group_account_readonly` group from sending the email with the attachment. Even if the email was somehow sent, those users still couldn’t access the attachments they themselves had generated and sent. With this change, any user who is allowed to send and print `sdd.mandate` records will also be able to generate and later access the corresponding attachments. Forward-Port-Of: odoo/enterprise#96463 Forward-Port-Of: odoo/enterprise#96119
Point-of-sale appointment bookings now use the right capacity values, making it possible again to add or remove resources reliably. The update also restores missing placeholder text in POS appointment fields and fixes appointment type names shown in planning popovers.
Original PR description
The waiting list capacity used to be set indirectly via the `total_capacity_reserved` field In [1] it was removed as it was not otherwise used. Meaning we should have set the default wishlist…
The waiting list capacity used to be set indirectly via the `total_capacity_reserved` field In [1] it was removed as it was not otherwise used. Meaning we should have set the default wishlist capacity instead. While doing that we also noticed a logical issue with only using the wishlist capacity, it does not allow adding or removing resources that don't correspond to the capacity that was originally set. Instead we now actually use total_capacity_reserved when the appointment type manages capacities. And let users use the wishlist capacity otherwise. Which allows them to again select resources freely in both contexts. -------------------------- Additionally we fix the missing placeholder in point-of-sale caused by the placeholder html editor plugin being missing from the minimal html editor used there. As well as an incorrect access to a record name in kanban popover. task-5103532 [1]: https://github.com/odoo/enterprise/commit/2aab4dcfbe8491968f0721741efbab894667aefe Forward-Port-Of: odoo/enterprise#95539