Tuesday, January 27, 2026
9 changes · 18.0
Resolved issues and error corrections
This update fixes an issue where the tour pointer was appearing in unwanted locations, like above dialogs, creating a cluttered user experience. Now, the pointer is hidden when it's not directly linked to the active element, resulting in a cleaner and more focused tour experience.
Original PR description
POC for task-5490670 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in the Time Off Balance report that was incorrectly calculating remaining leave days. The report previously aggregated allocations across different periods, leading to inaccurate balances. The fix ensures allocations are correctly deducted only when taken within the same period, improving report accuracy.
Original PR description
The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report Steps to reproduce: 1. Install Time Off app 2. Open Time Off app and go to Management > Allocations 3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it 4. Go to Reporting > Balance 5. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026 Solution: Subtract leaves taken from allocations only if they take place in the same period opw-5156142
This update prevents the deletion of attachments from email templates when removed from the mail composer. Previously, removing an attachment resulted in it being permanently lost, impacting future email communications. The fix ensures attachments remain associated with their templates, maintaining data integrity.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679
This update corrects a bug in the automatic currency rate system. The BNB now provides exchange rates in EUR, and this change ensures that companies using EUR as their main currency can correctly sync exchange rates. Companies using BGN will also experience the same error, as expected.
Original PR description
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the…
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR. This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates. refs: We can compare the data here from 31 December using the WayBackMachine: https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm Compared to today: https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm And see the comparison used to be to BGN but is now for EUR Steps To Reproduce: 1. Create a company for Bulgaria with EUR as the main currency. 2. Go to Accounting Settings -> Automatic Currency Rates. 3. Select "[BG] Bulgaria National Bank" as the service provider. 4. Click the sync button. 5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one." The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR. Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO. Ticket [link](https://www.odoo.com/odoo/project.task/5483771) opw-5483771 Forward-Port-Of: odoo/enterprise#105074
This update prevents users from selecting payment method lines from archived journals when creating or editing contacts. Previously, users could inadvertently use outdated payment methods. Now, archiving a journal automatically removes it from the selectable options, simplifying journal management and preventing data inconsistencies.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the IoT Box was incorrectly downloading standard drivers, leading to potential conflicts and outdated versions. To allow custom driver development, a checkbox was added, but this caused unnecessary duplication and the risk of reintroducing previous bugs. Now, the system avoids downloading standard drivers to ensure stability.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue where the product quantity and unit of measure fields on the MRP production kanban cards would shrink and become unreadable when product names were long. The changes ensure these fields remain consistently sized regardless of product name length, improving readability and usability.
Original PR description
Description of the issue/feature this PR addresses: On MRP production kanban, if the name of the product is too long, `product_qty` and `product_uom_id` fields on the card shrink and become unreadable. This adds proper classes to keep those fields from shrinking no matter how long product's name is. Current behavior before PR: <img width="1561" height="303" alt="image" src="https://github.com/user-attachments/assets/08e299be-c6e2-4241-b289-aaa2fab9a94f" /> Desired behavior after PR is merged: - The size of the product's name should be fine no matter how long the name of the product is. - The `product_qty` and `product_uom_id` should not shrink if the name of the product is long. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug that occurred when scheduling repair orders without a product assigned to a move line. Specifically, updating the scheduled date triggered an error related to unit of measure calculations. This fix ensures repair scheduling functions correctly, preventing disruptions to the repair workflow.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error.
This update resolves an issue where Odoo couldn't connect to printers with overly long names. The fix truncates the printer name to a maximum of 127 characters, preventing a CUPS error and ensuring reliable printer connectivity. This improves the overall usability of the printer functionality.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr