Daily updates from Odoo
Friday, January 23, 2026
351 changes
8 changes
Resolved issues and error corrections
This update fixes a situation where quality checks wouldn't display a helpful message if no IoT device was connected. Now, users will receive a notification when a quality check requires an IoT device and one isn't configured, preventing confusion and ensuring accurate data collection.
Original PR description
We now display a notification when no device is configured for a measure quality check. opw-5409775 Forward-Port-Of: odoo/enterprise#105207
This update improves the product information displayed in the Point of Sale system. It now includes the product's internal code (default_code) in the product name shown in the product info popup, making it easier for staff to identify and track products. This change enhances clarity and efficiency within the sales process.
Original PR description
This commit adds the default_code (internal reference) to the display name of the product in the product info popup. opw-5493827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244068
This update resolves a bug that prevented website tour tests from running correctly when the header template was changed to 'Sidebar'. The fix ensures the Website Builder remounts properly before the tour continues, preventing the builder from resetting to its initial state and disrupting the test flow.
Original PR description
When changing the header template to 'Sidebar', the loading screen disappears but the WebsiteBuilder component remounts asynchronously. If the tour proceeds to the theme tab before the remount completes, the builder resets to the Edit tab (its initial state), breaking the test flow. We wait for the builder to remount, and add `.editor_enable` class to the body of the iframe, so then nothing disrupts the flow. runbot-234504 Forward-Port-Of: odoo/odoo#245271 Forward-Port-Of: odoo/odoo#243518
This update resolves an issue where users would encounter errors when uploading corrupted or encrypted PDF files for quotation document headers and footers. The fix prevents the system from crashing when encountering these files, ensuring a smoother user experience when creating quotes.
Original PR description
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the…
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the `sale_pdf_quote_builder` module. - Navigate to: Sales > Configuration > Headers/Footers. - Upload encrypted file [1], or incomplete file [2]. **Error:** `PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm` `PyPDF2.errors.PdfReadError: EOF marker not found` **Root cause:** At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises an error. **Fix:** This commit prevents errors when users upload unreadable or encrypted PDF files. [1]: https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing [2]: https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11 sentry-6928220164 opw-5227601 Forward-Port-Of: odoo/odoo#245264 Forward-Port-Of: odoo/odoo#230712
This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix, ensuring a smoother experience for all users within the Odoo system. This improves stability and prevents potential disruptions to sales workflows.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
This update resolves an issue preventing dropshipping orders with average cost products from being processed correctly. Previously, users with limited access rights were blocked from updating product prices during the picking process. The fix adds necessary permissions to allow these operations, ensuring dropshipping orders can be completed without errors.
Original PR description
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method…
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO). 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights). 5. Create a dropship order using the product and validate the picking. ``` You are not allowed to access 'Product Value' (product.value) records. This operation is allowed for the following groups: - Inventory/Administrator Contact your administrator to request access if necessary. ``` Issue:- During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169) if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error Fix:- To fix this sudo is added during getting _run_avco opw-5431121 upg-3762999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242841
This update fixes a calculation error in the VAT sales reports for Vietnam. The previous formula excluded the base amount for 8% VAT transactions, leading to inaccurate sales reporting. This change ensures that the total taxable base is calculated correctly, aligning with Vietnamese tax regulations.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
This update ensures the chatbot answer selection dropdown always displays answers relevant to the current chatbot script, regardless of whether a search term is entered. Previously, an issue caused incorrect filtering, showing answers from other scripts. This fix improves the user experience and ensures accurate chatbot interactions.
Original PR description
**Description of the issue/feature this PR addresses:** In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is…
**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.
This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.
**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.
**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.
task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)
Forward-Port-Of: odoo/odoo#245322
Forward-Port-Of: odoo/odoo#2281928 changes
Resolved issues and error corrections
This update corrects a technical inconsistency where certain fields in payroll modules (l10n_au, l10n_eg, l10n_lu) were incorrectly marked as editable. Removing this setting ensures that fields designated as 'readonly' remain protected, maintaining data integrity and compliance within these payroll calculations.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983
This update corrects a problem with the tax report tour that prevented it from running correctly in certain scenarios. The fix addresses an incompatibility between the tour's assumptions about date calculations and the Odoo system's configuration, particularly when using the US tax report localization. This ensures the tour functions reliably across different Odoo setups.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624
This update resolves an issue where image snippets weren't consistently updating across the website builder. The fix ensures that the correct image is always used in subsequent handler calls, resulting in a more reliable and accurate image snippet display for users. This improves the overall user experience when adding images to website content.
Original PR description
[FIX] html-builder, *: update snippet at each snippet dropped handler *: website In the `ImageSnippetOptionPlugin`, at the `on_snippet_dropped_handlers` call, the `snippetEl` received as argument is replaced by the image selected by the user in the media dialog. The problem is that the call to subsequent handlers is done with `snippetEl` that is not an element of the DOM anymore. This commit fixes this by updating `snippetEl` if needed after each call to a `on_snippet_dropped_handlers` handler. task-5785233
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update resolves a bug where full payments on invoices with installment payment terms were incorrectly generating duplicate tax entries. The fix ensures that only the remaining balance is processed as a tax payment when an invoice is fully paid, aligning with the intended batch functionality. This improves the accuracy of cash basis accounting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. This came from the fact that we didn't consider a move would be fully paid by several lines at the same time, like with installments. We now only put the leftover amount when the move is fully paid and we're on the last partial. Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches opw-5061136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236536
This update fixes a technical detail related to the translation of Odoo's Greek language support. The incorrect language code ('gr') was replaced with the correct code ('el') in several configuration files. This ensures accurate translations and proper functionality for Greek-speaking users.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245352 Forward-Port-Of: odoo/odoo#244684
This update corrects a technical issue where newly added modules to the Odoo Enterprise platform were not correctly identified for translation. This fix ensures that the Greek language (el) is properly supported and translatable within the system, preventing errors and improving localization for users in Greece. It resolves a previous oversight related to .weblate.json configuration.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105243 Forward-Port-Of: odoo/enterprise#104890
This update resolves an issue where invoices generated with the Solution Factible PAC in Mexico were being rejected due to incorrect exchange rate formatting. The fix ensures that exchange rates are rounded to the required 6 decimal places, aligning with Mexican tax regulations and preventing invoice errors. This ensures compliance and accurate CFDI generation.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#105102 Forward-Port-Of: odoo/enterprise#102557
5 changes
Resolved issues and error corrections
This update resolves an issue where non-administrator users were receiving access errors when attempting to validate direct debit mandates. The fix restricts access to the payment provider model during validation, aligning with user permission controls for mandate creation. This ensures all users with the appropriate role can successfully validate mandates.
Original PR description
## Versions
saas-18.3+
## Issue
Non admin users get an access error when trying to validate a direct debit mandate.
## Steps to reproduce
As admin user:
- Navigate to "Users":
- Select Marc Demo:
- Under "Access Rights", in the "Accounting" section, set his "Accounting" role to "Invoicing & Banks";
As Marc Demo:
- Navigate to "Direct Debit Mandates":
- Create a new mandate for Deco Addict and its first IBAN record;
- Click on the "Validate" button.
## Cause
Issue introduced by the `action_validate_mandate` method override from b63eb2d6b91be28f4837309b5d972cc0b05846e0 Non admin users have no permissions on `payment.provider` while `_read_group` checks read rights on model via https://github.com/odoo/odoo/blob/ac084b1010faf49b63844ecc96284d567e59de2e/odoo/orm/models.py#L1632
## Fix
Allow `payment.provider` access only on mandate validation as only `account.group_validate_bank_account` users can create a new mandate.
opw-5255694This update resolves an issue preventing bookings from being scheduled for the last hour of the day. The fix corrects a technical error that was incorrectly flagging the end of the day as unavailable, now allowing appointments to be booked from 23:00 to 00:00. This ensures users can utilize the full range of available appointment times.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#100853
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the correct method, enabling proper data aggregation and reporting. This improves the functionality of the planning feature.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update resolves minor visual issues in the website's image gallery template. Specifically, it corrects errors like missing styling and undefined class names, ensuring a consistent and properly formatted display of images for users. This improves the overall user experience and presentation of product images on the website.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#241785
This update fixes an issue where zero-percent taxes (NT/EXEMPT) were incorrectly filtered out of downpayment calculations in the Arabic localization. Previously, these taxes weren't being properly applied, leading to inaccurate financial reporting. This change ensures that all taxes, including zero-percent NT/EXEMPT amounts, are correctly included in downpayment calculations.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245361 Forward-Port-Of: odoo/odoo#245252
7 changes
Resolved issues and error corrections
This update provides more specific error messages when the message list fails to load. Previously, users only saw a generic 'Ann error occurred' message. Now, the commit displays the underlying error details, giving support teams a clearer understanding of the issue and its potential cause.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244094 Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="305" height="67" alt="Screenshot 2026-01-20 at 15 10 38" src="https://github.com/user-attachments/assets/34c546df-71e6-4055-9f85-8d85a9c89b35" /> <img width="334" height="100" alt="Screenshot 2026-01-20 at 15 09 07" src="https://github.com/user-attachments/assets/5fadd0b7-7ea0-43ca-8c28-0ac1d33650ff" /> Forward-Port-Of: odoo/odoo#245073 Forward-Port-Of: odoo/odoo#244754
This update resolves an issue where tax reverse charges weren't being accurately reported on BIS3 invoices. The system now correctly handles these charges by classifying them as 'Prepaid Amounts,' ensuring accurate tax calculations and compliance. This change improves the reliability of invoice data for international transactions.
Original PR description
There is no WithholdingTaxTotal node in BIS3. You cannot report any negative tax amount as taxes. You can only report VAT taxes but tax reverse charge are not considered as VAT. This commit reports the tax reverse charge amount as a PrepaidAmount instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240525
This update fixes an issue where zero-percent taxes (NT/EXEMPT) were incorrectly filtered out during downpayment creation in the Arabic localization. Previously, these taxes weren't properly accounted for, leading to incorrect calculations. This change ensures accurate tax reporting for downpayments and other scenarios.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245361 Forward-Port-Of: odoo/odoo#245252
This update resolves minor visual inconsistencies in the website's image gallery template. Specifically, it corrects issues with missing styling and undefined class names, ensuring a more polished and consistent user experience. This improves the overall presentation of images on the website.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#241785
This update enhances the security and reliability of our Peppol integration by implementing a safer process for server-initiated deregistration. Previously, an issue caused disruptions when a server unexpectedly removed a participant. Now, the system handles this more gracefully, allowing users to re-register after a soft reset of the configuration. This change was driven by a postmortem analysis of a recent incident.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#245038 Forward-Port-Of: odoo/odoo#239254
This update resolves issues related to error handling and compatibility with the UBL (Universal Business Language) tax extension for HR payroll. Specifically, it prevents conflicts with other UBL modules and now displays warnings for invoices that fail to fiscalize correctly, improving the reliability of payroll processing.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245028
This update resolves a technical issue identified during testing of Odoo's project scheduling features. Specifically, a problem with how spaces were handled in test data was corrected. This ensures the accuracy and reliability of the project scheduling system, preventing potential errors in planning and reporting.
Original PR description
Fixes https://runbot.odoo.com/odoo/runbot.build.error/162366 Forward-Port-Of: odoo/enterprise#105370
7 changes
Enhancements to existing features
This update optimizes the suggestion list in email communication by placing the current user last. This change prioritizes more relevant suggestions for other partners, improving the user experience and efficiency.
Original PR description
With this commit the current user will be the last suggested partner in the suggestion list, as it's very unlikely to mention yourself so the space is better used to display other more relevant suggestions. part of task-5867464
This update significantly speeds up the process of analyzing module dependencies within Odoo, reducing processing time by a third. The change streamlines the underlying code and removes unused features, resulting in a more efficient system. This improves overall Odoo performance and stability.
Original PR description
Looping through every module of community + enterprise (1367 modules) and getting their entire set of dependencies, the new version runs in about a third the time on my machine (1.5s to 4.2s), yielding a result that's almost identical: the new version includes `base`, the old one did not (not sure why, or how).
Now supports calling with `exclude_states=()`, which did not work previously and led to wonky workarounds e.g.
self.upstream_dependencies(exclude_states=('',))
or
module.upstream_dependencies(exclude_states=('uninstallable'))
(which the keen-eyed will notice does not pass a tuple so excludes the individual non-existent states `u`, `n`, `i`, `s`, `t`, `a`, `l`, `b`, and `e`).
Also drops support for `known_deps`: it's not used anywhere and doesn't really seem useful.This update simplifies the mass mailing editor by removing a specific setting related to link font sizes. Users can now adjust link font sizes using the standard editor toolbar, providing a more intuitive and flexible design experience. This change focuses on improving usability within the mass mailing module.
Original PR description
Remove the `mass_mailing` Design Tab `--link-font-size` special variable, as it is more natural that a link font-size is aligned with its container. It is still possible to use the editor toolbar `font-size` feature to change the `font-size` of links individually. task-5868086
Resolved issues and error corrections
This update resolves a technical problem preventing changes to the Invoice Type field within the l10n_tr_nilvera_einvoice module. Previously, the system couldn't properly store data due to a limitation with the field type. This change allows for correct data storage and functionality.
Original PR description
After a recent PR, #235832 the `fields.Binary` can not store data other than bytes, due to this a traceback occurs while trying to change the Invoice Type, since a compute method is triggered that computes domain for a field that is of type Binary. Error: `TypeError: 'str' object cannot be interpreted as an integer` This commit fixes that issue by changing field type from Binary to Json. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows users to create working files with custom date ranges, addressing a previous limitation. The fix ensures accurate generation of reports by correctly passing necessary context during file creation. Additionally, minor improvements have been made to display audit titles more clearly in the user interface.
Original PR description
It should be possible to create a working file with any dates. odoo/enterprise#100757 should have solved this but the context for force_periodicity_violation wasn't passed to _try_create_returns_for_fiscal_year which doesn't allow creating those custom working files in the wizard. Also, includes a small changes to make longer audit titles display better in their record view (checks kanban view) and kanban view.
This update resolves an issue with how payroll dependencies were configured, specifically removing a redundant and incorrect exclusion setting. Simultaneously, the team modernized the testing code by replacing older print statements with more efficient f-strings, improving code readability and maintainability.
Original PR description
Community fixes `upstream_dependencies` to support an empty list of states to exclude, and these tests don't seem to actually need anything (since they would previously exclude no less than 9 states which don't exist, as `('uninstallable')` is a string not a 1-uple).
While at it, convert a bunch of printfs to f-strings.A recent update added options to the account reports footer generation process. However, the code wasn't updated to handle cases where no options were provided, leading to an error. This fix ensures the report generates the default footer layout when no options are specified, resolving the issue.
Original PR description
The following commit added a new 'options' argument to _get_layout_footer but forgot to add pass those in one of the calls to the method. Therefore, we get an error when 'options' is None (default…
The following commit added a new 'options' argument to _get_layout_footer but forgot to add pass those in one of the calls to the method. Therefore, we get an error when 'options' is None (default value) and 'options.get()' is called.
Commit:
https://github.com/odoo/enterprise/commit/b02b65ad2baa999b62e3b44fcfc05f9afff5f8cc
Error:
```
RPC_ERROR
Odoo Server Error
Occured on 98738418-master-design-theme.runbot278.odoo.com on 2026-01-22 08:48:56 GMT
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/controllers/main.py", line 32, in get_report
generated_file_data = report.dispatch_report_action(options, file_generator)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2630, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_journal_report.py", line 265, in export_to_pdf
footer = self.env['account.report']._get_layout_footer(rcontext)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 6139, in _get_layout_footer
custom_config = options.get('custom_display_config', {})
^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://98738418-master-design-theme.runbot278.odoo.com/web/assets/3059a1f/web.assets_web.min.js:3221:165)
at decoder.onload (https://98738418-master-design-theme.runbot278.odoo.com/web/assets/3059a1f/web.assets_web.min.js:3203:7)
```
task-none7 changes
New functionality added to Odoo
This update introduces a new Know Your Customer (KYC) process for Belgian users registering through the Peppol network. It leverages the Itsme service to streamline verification, improving security and compliance. This enhancement simplifies the registration process for Peppol participants.
Original PR description
Add KYC for Belgian Peppol users through Itsme. task-5478657
Resolved issues and error corrections
This update resolves an issue where the l10n_cl_edi module was incorrectly creating duplicate vendor bills when receiving identical XML invoices via the incoming mail server. The fix prevents duplicate bill creation, ensuring accurate record keeping and avoiding potential accounting discrepancies. This addresses previous bugs opw-5362664 and opw-5409700.
Original PR description
Steps to reproduce: - With a CL Company setup - Configure an incoming mail server with DTE server option enabled - In Vendor Bills journal, enable 'Use Documents?' - Receive the same XML twice via the incoming mail server - Check created vendor bills Issue: There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn' However, the system should avoid duplicates from being created. opw-5362664 opw-5409700 Forward-Port-Of: odoo/enterprise#103211
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
This update removes a previous restriction that limited the use of journal accounts for reconciliation. Previously, certain accounts couldn't be used if they were designated as default debit or credit accounts within a journal. This change provides greater flexibility for accounting processes and simplifies account management.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244398
This update resolves an issue where full payments on invoices with installment payment terms were incorrectly generating duplicate tax entries. The fix ensures that only the remaining balance's tax is recorded when an invoice is paid in full, aligning with the intended batch processing functionality. This improves the accuracy of cash basis accounting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. This came from the fact that we didn't consider a move would be fully paid by several lines at the same time, like with installments. We now only put the leftover amount when the move is fully paid and we're on the last partial. Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches opw-5061136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236536
This update fixes a potential issue with how payroll reports are generated in Switzerland. Specifically, it ensures that a snapshot is only created if one doesn't already exist, streamlining the process and preventing unnecessary data duplication. This improves the efficiency of report generation and reduces potential processing delays.
Original PR description
Forward-Port-Of: odoo/enterprise#105258 Forward-Port-Of: odoo/enterprise#105135
This update corrects a problem with the import of Swiss payroll tax rates for 2026, specifically related to single canton calculations. The change ensures accurate tax reporting for businesses operating in Switzerland, aligning with updated Swiss tax regulations. This update maintains compliance and avoids potential errors in payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#104991 Forward-Port-Of: odoo/enterprise#104333
5 changes
Resolved issues and error corrections
This update resolves a technical issue that was preventing our project scheduling tests from running correctly. The fix ensures proper handling of spaces in test data, improving the reliability of our testing process and ultimately contributing to more stable project planning features. This change focuses on internal test improvements.
Original PR description
Fixes https://runbot.odoo.com/odoo/runbot.build.error/162366
This update corrects a bug where a delivery order's picking state would incorrectly update the serial number of a product. The fix ensures that the original serial number is maintained when adding new moves to a 'ready' picking, preventing data discrepancies and improving inventory accuracy. This resolves an issue impacting product traceability.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state.
This update corrects a bug where a delivery order's picking state would incorrectly update the serial number of a product. The fix prevents changes to the serial number when adding new moves to 'ready' pickings, ensuring accurate tracking of inventory and serial numbers. This improves data integrity and reduces potential errors in stock management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993
This update replaces "Deco Addict" with "Acme Corporation" in various Odoo demo data sets to address a user complaint. This ensures demo data accurately reflects business scenarios and avoids confusion for users. The change improves the user experience and data consistency.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245434 Forward-Port-Of: odoo/odoo#245205
This update resolves a user complaint regarding test data that incorrectly included 'Deco Addict'. The company name has been updated to 'Acme Corporation' to align with demo and test environments, ensuring a more accurate and professional experience for potential users. This change improves data consistency and user perception.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105279 Forward-Port-Of: odoo/enterprise#105151
4 changes
Resolved issues and error corrections
This update fixes an issue where users could successfully make payments through expired Sales Orders. The system now automatically prevents payment attempts when a Sales Order's expiry date has passed, ensuring accurate financial records and preventing potential payment errors. This improves the reliability of the payment process.
Original PR description
## Issue: Payment link should expire if payment is expired. #### Steps to reproduce: 1- Create a new quotation. 2- Set the expiry date in the past. 3- Open the action menu and generate a payment link. 4- Open the payment link and pay. Expected result: The payment should fail if the so is expired. opw-5478691
This update fixes an error in the FAIA report that incorrectly classified partners as suppliers. The change allows partners to be recognized as both customers and suppliers, resolving an issue caused by credit notes. This ensures accurate reporting of financial transactions within the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924
This update resolves errors in the SAF-T export process for Romanian companies when partner information (country or name) is incomplete. Specifically, it corrects issues related to generating the RegistrationNumber and prevents errors during report generation, ensuring accurate financial reporting for Romanian businesses.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918
This update resolves a technical issue that was causing crashes during the import of accounting data. The fix prevents a specific error related to incorrect data handling, ensuring that import processes run smoothly and reliably. This improves the stability of our accounting reports and reduces the risk of data loss.
Original PR description
Fixes crash caused by #97263