Daily updates from Odoo
Friday, December 5, 2025
14 changes · 17.0
Enhancements to existing features
This update ensures that newly imported partner records are automatically identified as 'companies' within Odoo. This is crucial for accurate accounting and reporting related to electronic invoices (UBL-CII) and simplifies the process of matching imported transactions with company data. It addresses a previous issue where imported partners weren't correctly categorized.
Original PR description
Ensure imported partner records are marked as companies when creating new partners. Task-5353923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes an accounting error related to invoice processing for 'Unearned Revenue' (account 3387). Previously, the system incorrectly created both receivable and payable entries. By changing the account type, the system now accurately reflects 'Unearned Revenue' as a current liability, ensuring correct balance sheet reporting.
Original PR description
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the…
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a current liability, not a payable account. By changing the account type from `Payable` to `Current Liabilities`, the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner. After this fix: - Entry: Dr 131 (Receivable) / Cr 511 - Deferral: Dr 511 / Cr 3387 (Current Liabilities) 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 resolves an issue where the TBAI XML generated for invoices with past invoice and delivery dates was missing a crucial field, `FechaOperacion`. The fix ensures that this field is now correctly populated, aligning with TicketBAI specifications and preventing potential reporting discrepancies. This ensures accurate tax reporting for Spanish businesses.
Original PR description
**[FIX] l10n_es_edi_tbai: fix FechaOperacion** With l10n_es_tbai: - Create an invoice with an `invoice_date` and `delivery_date` that are the same and earlier than today. - In the generated TBAI XML, `FechaOperacion` is missing. In the TBAI XML, `FechaExpedicionFactura` corresponds to the date on which the XML is generated. `FechaOperacion` corresponds to the `delivery_date` and should appear whenever it differs from the issue date. The TicketBAI specs define `FechaOperacion` as: > “Date on which the transaction was carried out, whenever it differs from the issue date.” So when the invoice date and delivery date are equal but set in the past, `FechaOperacion` is not generated, even though it should be. opw-4477135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a rare issue where Odoo would crash when attempting to schedule messages without a linked model. The fix ensures that necessary variables are always defined, preventing these scheduling errors and improving overall system stability. This change primarily impacts the mail functionality.
Original PR description
In rare case when we would like to schedule messages without model a variable is not defined in that scope. Forward-Port-Of: odoo/odoo#238762
This update ensures the Frontdesk kiosk always displays the correct company logo. Previously, switching companies caused a display issue due to a permissions problem. The fix automatically includes the selected company in the kiosk's access settings, resolving the logo display issue.
Original PR description
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least…
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least two companies, each with a logo configured. - `Enable multi-company` access (user has access to all companies). - Open any Frontdesk station configuration and change the company to one different from the currently active company. - Copy the kiosk URL and open it in an incognito/private window. - The kiosk opens, but the company logo is missing. **Issue:** - Company logo not comes on frontdesk kiosk. **Root cause:** - When the kiosk URL is accessed, Odoo logs an `Access Denied by record rules`. - This happens because the selected company on the station is not included in the `Public User’s companies`. - As a result, the public user cannot read the company record, so the logo does not load. **Solution:** - Added an `onchange` on `company_id` to automatically include the selected company in the Public User’s `company_ids` if it is not already present. - This ensures the kiosk always has access to correct company record and logo. - Also added an XML-side fix to prevent an access error that occurs when a company is not activated and we attempt to select it in the company field. **Before:** <img width="500" height="500" alt="frontdesk_image_before" src="https://github.com/user-attachments/assets/b002ac6e-5271-4561-bf03-542a3feeefd1" /> **After:** <img width="500" height="500" alt="frondesk_image_after" src="https://github.com/user-attachments/assets/7b5bffe4-ccbf-48f5-ad9c-d5e6d2e7678e" /> **opw-5138980**
This update resolves an issue where removing a video URL in the website editor would create a broken link, leading to a 404 error. The fix ensures that the 'Add' button is disabled when a video URL is empty, preventing the creation of invalid links and improving the user experience. This ensures consistent and functional video embedding.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485
This update fixes issues related to generating and resending snailmail reports. Specifically, a new function was created to ensure reports have consistent formatting (including cover pages) and to prevent unnecessary resending of followup reports. These changes improve the reliability and accuracy of snailmail communications.
Original PR description
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's…
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's margins are fixed and a cover page is added to it after the function is called in `_fetch_attachment`. The new function is extended in the related enterprise commit to generate the followup report inside `_fetch_attachment` (when sent via snailmail). This way it will respect the cover page option and page layout / size requirements. (See the related enterprise PR for more details.) #### [FIX] snailmail: extract letter resending function We extract a function `_resend_letters` from the `update_resend_action`. It handles the regeneration of letters after the cover option has been updated. This way the resending logic can easily extended to adjust the logic depending on attributes of the letter. The new function is extended in the related enterprise commit to disable the resending for followup report letters. This is necessary because the followup report requires special options to be generated that are not available at the point of the regeneration. #### references opw-5160121 opw-5209504 opw-5226366
This update resolves issues with generating snailmail follow-up reports, specifically addressing address validation problems, cover page functionality, and PDF layout inconsistencies. The fix ensures reports are correctly formatted for Pingen, provides feedback on invalid addresses, and allows for re-sending failed letters with cover page options.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366This update corrects an issue where batch barcode scans weren't accurately reflecting partial deliveries across different pickings. The fix prevents moves from being incorrectly merged, ensuring accurate tracking of inventory within batches, especially when using batch picking functionality. This improves the reliability of stock management.
Original PR description
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of…
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of both pickings - Go back to the barcode main screen - Open the batch again > Both pickings have their demand = partially delivered quantity Cause ----- When leaving the page, we trigger https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68 in which we end up merging the moves together https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51 This has been added by 9753c24 (ade0bef in 17.0) The problem is that `_merge_moves` merges all of the moves into the first of `merge_into` https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088 This, however, doesn't make much sense for batches because the moves can be from different pickings. ----- Ticket: opw-5163740
This update resolves an issue where trailing spaces were automatically removed from config parameters, even when the 'trim=False' setting was intended to prevent this. This restriction limited the ability to create parameters with separators like '; ' for reporting and other configurations. The fix ensures that whitespace is handled correctly according to the 'trim=False' setting, allowing for more flexible configuration options.
Original PR description
Description of the issue/feature this PR addresses: Allow creating config_parameters in res.config setting, with trailing whitespace, by using the 'trim' attribute already existing in Char fields. This problem may also exist in other versions, but has currently only been tested in Odoo 17. Current behavior before PR: When creating a config_parameter all trailing whitespaces are removed even when the field specifies trim=False, which is meant to allow trailing whitespaces. This restricts the creation of separator config_parameters e.g for name computations, qweb reports, etc. Desired behavior after PR is merged: When creating a config_parameter all trailing whitespaces are removed by default, to avoid bugs. However when the field has specified trim=False, the whitespace is not removed as per the original intention of the attribute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time zones differed. The change ensures calendar events now correctly display the employee's time off hours, regardless of the system's timezone. This improves the accuracy of time off schedules and reporting.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375
This update fixes an issue where large .docx files weren't being correctly identified by their file type. The change increases the amount of data sent to the mimetype guesser, ensuring accurate detection, particularly when the python-magic library is used. This prevents misinterpretation of file types and ensures proper handling of documents like Word files.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where shipping labels for FedEx deliveries were missing the company name. The fix ensures the company name from the ecommerce form is correctly used, resulting in accurate shipping label generation and improved order fulfillment. This addresses a data inconsistency impacting delivery accuracy.
Original PR description
Steps to reproduce: - install ecommerce (i.e. website_sale) and delivery_fedex_rest - setup demo payment + fedex delivery method (including publishing it) - open the db while not logged in (i.e. in private browsing) - add something in the ecommerce page to cart + checkout > checkout - type in random contact info INCLUDING "Company Name" - continue checkout > select FEDEX as delivery method > pay now - go to Sales App > Sale orders > open the SO generated by ecommerce - open delivery + validate Expected result: - Shipping label with the name + company name from the ecommerce form Actual result: - company name is missing Issue is due to a company not being generated by ecommerce. Instead a string field is filled in (which is not visible when creating a contact directly via the contacts app). Code has been adapted to consider this use case. opw-5119089
This update resolves an issue causing delays in server logging by reverting a recent change to the logging interval. The previous adjustment was leading to a buildup of log messages, impacting performance. This fix ensures logs are flushed more frequently, maintaining optimal logging speed.
Original PR description
Based on this review of https://github.com/odoo/odoo/pull/238740 this pr reverts the flush interval to 0.5s introduced in https://github.com/odoo/odoo/pull/238648 to avoid queue saturation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr