Daily updates from Odoo
Wednesday, January 14, 2026
400 changes
21 changes
New functionality added to Odoo
This update reflects a recent change in the daily UMA (Mexican Wage Base) value as determined by INEGI, effective February 1st, 2026. The new value of 117.31 MXN ensures accurate payroll calculations for Mexican employees within the Odoo Enterprise system. This change is necessary to comply with updated Mexican tax regulations.
Original PR description
As per the INEGI press release (published on January 8, 2026), the daily UMA value has been updated for 2026. New value: 117.31 MXN Effective date: February 1st, 2026. This commit adds this new parameter value to "Mexico: Daily UMA". Reference: https://www.inegi.org.mx/app/saladeprensa/noticia/10533 target: 19.0 task-5488243 Forward-Port-Of: odoo/enterprise#104064
Enhancements to existing features
This update simplifies product pricing management by consolidating all pricing configurations – Sales, Rentals, and Subscriptions – into a single, easy-to-use interface. This improves efficiency for users and ensures consistent pricing across the Odoo ecosystem, particularly for eCommerce and rental products.
Original PR description
The primary goal of this PR is to unify product pricing management across the Odoo ecosystem by centralizing configurations for Sales, Rental, and Subscription applications within the core pricelist…
The primary goal of this PR is to unify product pricing management across the Odoo ecosystem by centralizing configurations for Sales, Rental, and Subscription applications within the core pricelist engine. This consolidation introduces a single "Prices" tab on the product template form, effectively replacing fragmented, app-specific views with a unified interface. To improve daily efficiency, the PR enables users to quickly manage fixed-price rules through an inline editable interface directly on the product form, while still providing access to the full pricelist engine for more complex configurations. On a technical level, the pricelist engine has been evolved to support the temporal and contextual needs of dependent applications; this includes dissociating the date used for rule application from the date used for currency conversion, as well as propagating request contexts during eCommerce price computations. task-5375343 See also: - https://github.com/odoo/enterprise/pull/102625 - https://github.com/odoo/upgrade/pull/9172 --- To accelerate this PR, it was decided to rebase the work on an ongoing PR [^1][^2] refactoring and greatly facilitating the interactions backend-frontend of the eCommerce/Rental applications. Thx Louis 😉 (and Victor for thinking about it) [^1]: https://github.com/odoo/odoo/pull/234405 [^2]: https://github.com/odoo/enterprise/pull/98161
This update allows system administrators to customize the main Odoo Enterprise home menu with a targeted message. Administrators can set a message via a database configuration, such as a maintenance notification, which will then be displayed to all users. This provides a flexible way to communicate important information directly to users.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#103831
Forward-Port-Of: odoo/enterprise#102239Resolved issues and error corrections
This update corrects a previous navigation enhancement for the forum on mobile devices. The prior change caused an unnecessary breadcrumb display when the forum was part of a course. This fix ensures the correct breadcrumb is shown, improving the user experience and preventing duplicate navigation elements.
Original PR description
This PR fixes an oversight introduces in Commit[^1]. With Commit 1, we improved the navigation by showing the back button everywhere on the forum but this created an issue due to a rule in `website_slides_forum` rendering the whole breadcrumb if the forum is a course one. | saas-19.1 and above | This PR | |--------|--------| | <img width="391" height="205" alt="image" src="https://github.com/user-attachments/assets/385a6d95-d8b4-4693-8c13-457e2b06f2fe" /> | <img width="390" height="145" alt="image" src="https://github.com/user-attachments/assets/429979a9-ed09-4fe7-8ded-e95909a9c97b" /> | [^1]: https://github.com/odoo/odoo/commit/bb5b7cfa284a55e6dd3a5deb4870bcfae28033af task-5490243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where part-time employee time off calculations incorrectly included company working days, even when those days were holidays. Now, time off is accurately calculated based on the employee's actual work schedule, ensuring correct holiday pay is applied. This improves payroll accuracy and compliance.
Original PR description
Currently when a employee has a diferent working schedule than the company's one (part time employee), when he takes time off the computation includes days where he is not working but is an active working day for the company. That is not considering holidays. e.g. -employee works monday to wednesday -company works monday to friday -there is a holiday on the thursday taking monday to wednesday should count 4 days. added holidays support for this case opw-5082080 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240299 Forward-Port-Of: odoo/odoo#228960
This update resolves a minor issue where the theme selector iframe sometimes took longer to load, impacting user experience. The fix ensures the iframe and its associated assets are fully loaded before the test is executed, resulting in faster and more reliable performance.
Original PR description
This commit fixes an undeterministic issue with the theme selector iframe's loading. It could take a bit longer for it to be properly displayed. When [1] was merged it introduced some non-determinism as we now needed to load an iframe that could contain shadow roots. This iframe needs to load some more assets, which leads to loading wait times. This change wasn't taken into account for the fixed test in this commit. Now we properly await for the iframe to be loaded before querying elements inside it. [1]: https://github.com/odoo/odoo/commit/0f7ee1764e8b59029003c6ad7269e185b30c6b43 runbot-234965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug preventing AI server tools from running correctly. The issue stemmed from an unnecessary inclusion of '__end_message' in tool arguments, causing validation errors. The fix removes this element before tool execution, ensuring reliable AI tool operation.
Original PR description
When executing AI server actions, tools with `ai_tool_schema` defined would fail with "Missing definition for __end_message" error. Root cause: - `_prepare_tools` adds `__end_message` to the schema sent to the LLM - The LLM returns tool calls with `__end_message` in arguments - `_ai_tool_run` validates arguments against the original schema (which doesn't have `__end_message`) - Validation fails with "Missing definition for __end_message" Fix: Use `pop` instead of `get` to extract and remove `__end_message` from arguments before calling the tool executor. This ensures that it's not passed to the tool validation. TASK-ID: 5423756
This update fixes a visual inconsistency in the website logout process. Previously, only the iframe would disconnect, leaving users with a misleading connection indicator in the main menu. The update now ensures a complete logout experience for all users, regardless of whether they are accessing the website through an iframe.
Original PR description
Problem --------- When Portal and Website are installed, a user that is in the Website app and tries to logout from the website iframe (not from the menubar) will get disconnected correctly. However, only the iframe gets redirected; not the whole page. This leaves the user in an interesting stage where he is disconnected but still seem connected when looking at the menubar. Solution --------- Instead of using a form in the XML, we use a custom JS tool that will correctly redirect the user depeding on whether or not there is an iframe. task-5262619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting. The change ensures that contract overlap dates are capped by the payslip period's start and end dates, providing more reliable payroll data. This improves the accuracy of employee compensation calculations.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#100694
This update resolves a bug where the 'Working Time to Assign' field incorrectly remained at 0 when assigning tasks after switching between companies with time off. The fix ensures that the system accurately calculates working time based on the last stage change and considers company-specific holiday impacts, preventing incorrect time assignments.
Original PR description
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in…
__ ## Short functional explanation of the error Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. ## Reproduction Steps 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. ### Expected behavior The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation ### Unexpected behavior Nothing happens ## Origin of the issue When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546 The company isn't taken into account in the domain, applying the holiday for every company. _________________________________________ opw-5222883 Forward-Port-Of: odoo/odoo#242228 Forward-Port-Of: odoo/odoo#236043
This update resolves a technical issue with the demo data for the HR Recruitment module. The previous setup incorrectly used user records instead of partner records, which caused problems with how the demo data was displayed. This fix ensures the demo data accurately reflects the expected record structure.
Original PR description
author_id expects a res.partner record. In this commit: Replace the user record with the corresponding partner record to avoid passing an incorrect recordset in demo data. Forward-Port-Of: odoo/odoo#241260
This update corrects a technical issue where notification messages incorrectly moved channels to the top of the list. This change ensures consistency with other notification features and avoids unnecessary channel updates. The fix improves the user experience by preventing channel list disruptions.
Original PR description
Before this commit, a notification message would bump a channel on top of the channel list. This happens because the update of `last_interest_dt` is done on the `message_post` method, which is called when posting notification messages. This behaviour is unwanted as those messages are not considered important enough to bump the channel, and is inconsistent with other features such as push notifications and undread badge. This commit fixes the issue by updating `last_interest_dt` on the actual "human" flow of posting a message. task-5138777 Forward-Port-Of: odoo/odoo#241510
This update enhances the reliability of the barcode tour process by ensuring all calls are completed before the tour ends. The team removed a synchronous check for DOM elements, which could lead to unpredictable errors. This change improves the overall stability and performance of the barcode functionality.
Original PR description
After validate an operation, it's still beter to wait for trigger .o_stock_barcode_main_menu to be sure the calls are finished before closing the tour... especially when assertions are made after the tour in python. runbot-error-id~234470 Forward-Port-Of: odoo/enterprise#103699
This update significantly speeds up the website builder by optimizing how snippets are retrieved. The fix eliminates a slow process of searching through snippets, resulting in faster page loading times and a smoother user experience. It addresses a performance bottleneck impacting website builder responsiveness.
Original PR description
__Before commit:__ The method `getOriginalSnippet` is called hundreds of times per website builder test inside the `disableUndroppableSnippets` method from `DisableSnippetsPlugin`. Each time, it recreates the same snippet array and loops through them to find one snippet by its name. This may take around 100 ms for a single website builder test. Moreover, `getOriginalSnippet` loops through `snippetStructures`, which includes the custom snippets. This is unnecessary, since snippet names are equal to the value of `data-snippet`, which is always copied from the base snippet when a custom one is created. __Fix:__ Create an object for which the snippet `name` values are the keys and each value is the first snippet having this `name`. This allows `getOriginalSnippet` to retrieve a snippet in `O(1)` instead of `O(n)` and reduces total time spent in this function to virtually nothing. task-5269391 Forward-Port-Of: odoo/odoo#243372 Forward-Port-Of: odoo/odoo#243102
This update corrects a potential issue with the transmission of ELM (Einnahmen-Lohn-Meldung) data for Swiss payroll. By using a reference date when locking payroll periods, the system now accurately reflects the correct reporting timeframe, ensuring compliance and reliable data transmission. This resolves a technical problem that could have resulted in inaccurate reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#104269
This update corrects formatting issues in the Japanese and Korean translation files for the accounting module. Specifically, it fixes problems with incorrect line wrapping within the translated text, ensuring proper display and readability of financial reports and user interfaces. This improves the overall user experience for international customers.
Original PR description
Forward-Port-Of: odoo/odoo#243513
This update corrects formatting issues within the Japanese localization files (AI) for the Odoo Enterprise platform. Specifically, it fixes problems with line wrapping in the PO files, ensuring correct display and functionality of translated text. This improves the overall quality and accuracy of the Japanese user experience.
This update fixes an issue where the website menu incorrectly linked to the most recently created page when multiple pages with the same name were created. Previously, the menu would update even with existing pages, leading to inconsistent page links. Now, menu entries are only updated when a new page is created without a prior association.
Original PR description
With commit 19302cd40347065fcd937bd54e6dce27fe4940cc, when a page is created, menu entries with a url corresponding to the created page are updated to set their `page_id` to the new page. The update may also be triggered when creating several pages with the same name in a row. This commit updates a menu entry on page creation only if no page were already associated to the menu. Steps to reproduce: - Create a new page, call it "test" (will be available on `/test`) - Create a new page, call it "test" (will be available on `/test-1`) - Go to editor menu - Bug: both entries point to `/test-1` - Create a new page, call it "test" (will be available on `/test-2`) - Go to editor menu - Bug: the first one (and the new one) is pointing now to `/test-2` task-5186653 Forward-Port-Of: odoo/odoo#243312
This update resolves a minor issue in a performance test related to menu loading within the Odoo web application. The change optimizes a query number used in the test, resulting in faster and more reliable test execution. This improves the overall stability and efficiency of the Odoo system.
Original PR description
Forward-Port-Of: odoo/odoo#243298
This update resolves a problem preventing the migration of Odoo 16 to 19.1 for the Italian localization (l10n_it) module. The migration process failed because a required column was missing. This change adds the necessary column, ensuring a smooth and successful upgrade for Italian businesses using Odoo.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
Code cleanup and technical improvements
This update centralizes rental pricing within Odoo, replacing previous app-specific models with a flexible pricelist system. This simplifies product configuration, enables dynamic pricing based on rental periods (hours, days, etc.), and improves consistency across the Sales and Rental applications. The changes also update the eCommerce frontend to reflect these new pricing capabilities.
Original PR description
The primary goal of this PR is to finalize the unification of product pricing across Odoo Enterprise by migrating the Rental and Subscription applications to the core pricelist engine. This change…
The primary goal of this PR is to finalize the unification of product pricing across Odoo Enterprise by migrating the Rental and Subscription applications to the core pricelist engine. This change eliminates legacy, app-specific pricing models in favor of a centralized and more capable architecture. This consolidation integrates Subscription and Rental pricing directly into the unified *Prices* tab introduced in the base module. For Subscriptions, recurring prices are now managed alongside standard rules. For Rental, the rigid `product.pricing` model and legacy configuration settings (such as static delay fines) are removed. Instead, users define rental prices using standard pricelist items, supported by a new `periodicity` configuration (Hours, Days, Weeks, Nights) on the product form. On a technical level, the rental engine has been refactored to leverage the full capabilities of the pricelist system, enabling previously unavailable features like formula-based pricing and variant specific extra-price. The eCommerce frontend has been updated to support this dynamic logic, ensuring that availability constraints, periodicity display, and price computations are consistent with the new backend architecture. task-5375343 Co-authored-by: Lionel Piraux <lipi@odoo.com> Co-authored-by: Victor Feyens <vfe@odoo.com> Co-authored-by: Louis Tinel <loti@odoo.com>
14 changes
New functionality added to Odoo
This update allows businesses to seamlessly handle self-billed invoices, a key requirement for Peppol integration. It enables the export of vendor bills as compliant self-billed invoices and the import of Peppol-provided invoices into Odoo, streamlining accounting processes and facilitating international trade.
Original PR description
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice…
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes. Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct. See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/ #### This PR provides (1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard (2) the ability to import BIS3 self-billed invoices as customer invoices (3) the ability to send vendor bills as self-billed invoices over Peppol (4) the ability to receive self-billed invoices from Peppol in a specified Sales journal. #### Configuration Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration. We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types. Backport of https://github.com/odoo/odoo/pull/222658 Enterprise PR: https://github.com/odoo/enterprise/pull/97803 Upgrade PR: https://github.com/odoo/upgrade/pull/8886 task-5153851 Forward-Port-Of: odoo/odoo#232548
Resolved issues and error corrections
This update fixes an issue where the original invoice information wasn't correctly displayed when reversing invoices. Previously, the 'Source Document' field in the invoice list was blank after a reverse move. This change ensures that the correct source invoice is always visible, improving accuracy and traceability of financial transactions. It resolves a regression introduced in a previous update.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
This update corrects a bug where manually changed currency rates on invoices weren't updating correctly, leading to lost data. Now, the system only recalculates rates if the user hasn't modified them, preserving user input. This ensures invoices with different dates accurately reflect the intended currency rates.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243126 Forward-Port-Of: odoo/odoo#242800
This update corrects a bug where matching a partner by bank account could be overwritten by a subsequent match found through the partner's name. This ensures that the correct partner is always associated with bank statements, improving data accuracy and reliability. It addresses a potential issue with duplicate partner records.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update fixes a dashboard warning issue where employee data wasn't being displayed correctly in payroll exports. The changes ensure that all employee data, including version codes, is accurately reflected, resolving a previous omission of the 'acerta' code and improving data consistency.
Original PR description
\* = {acerta, group_s}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code. This commit also solves an issue of not showing acerta code of the version
task: 5212681This update ensures salary configuration personal information is automatically populated using the employee's most recent version, regardless of whether it's a standard offer or a contract template. This eliminates manual data entry and ensures accurate salary settings for all employees, streamlining the offer creation process.
Original PR description
The personal informations in the salary config is prefilled using the version selected in the offer. When making a new offert for an already employed person, the default version is the last active version, the address and other personal info are already set on that version and the salary has the last up-to-date data. But when selecting a contract template in an offer, the version does not have the personal info from the employee (as it's a template). In this commit, we force to use the employee itself (from the active version of the employee, or the employee linked to the contract template copy - created during the offer creation). may it be an applicant or an existing employee, when an offer is generated, an employee is created (or re-used) and set on the contract template. So it works in every case. Taks-5162703
This update corrects an issue where payslip names were not being generated accurately for the Swiss (l10n_ch_hr_payroll) module. The fix ensures that payslip names now display correctly, improving the accuracy of payroll reporting and data for Swiss users. This ensures consistent and reliable payroll information.
This update resolves an issue where failed IoT driver actions were incorrectly recorded, preventing them from being re-executed. By only registering successful actions, we enhance the reliability and efficiency of the IoT driver system. This change improves the overall stability of the Odoo platform.
Original PR description
We currently reject an action if it has the same id of a previous one. If the action failed, we still registered it, making it impossible to be executed again. We now only register if the action succeeds.
This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or last installed module). The fix ensures that payment reports now automatically use the correct format based on the company's localization, improving report accuracy and usability for users. The change is being backported to version 18.0.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#103864
Forward-Port-Of: odoo/enterprise#100126This update resolves a technical problem preventing order details from being correctly saved in the Odoo POS system for the Swedish localization. The fix involves renaming related fields in the user interface to ensure data is properly recorded in the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104218 Forward-Port-Of: odoo/enterprise#104180
This update fixes an issue where customer statements incorrectly showed an outstanding balance after a payment was made on an invoice. The fix ensures the system accurately considers partially reconciled amounts when determining follow-up actions for invoices and payments. This improves the accuracy of customer statements and reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update resolves an issue where the height of image gallery snippets would unexpectedly reset when images were reordered. The fix ensures users can set and maintain custom heights for gallery snippets, providing consistent control over their appearance. Additionally, minor template issues have been addressed.
Original PR description
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The…
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281 Forward-Port-Of: odoo/odoo#242385 Forward-Port-Of: odoo/odoo#126766
This update simplifies the process of generating UBL invoices for Colombia and Mexico by refactoring internal code and streamlining the UBL 2.0 builder. The changes ensure correct customer/supplier order for vendor bills and improve the flexibility for future updates to these specific tax modules.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851 Forward-Port-Of: odoo/enterprise#97803
This update ensures that the print wizard always closes correctly, regardless of whether a custom report handler (like for IoT) is used. Previously, using a custom handler would prevent the wizard from closing after a report download, leading to unexpected behavior. This fix maintains a consistent user experience across all report printing scenarios.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
6 changes
New functionality added to Odoo
This update allows businesses to seamlessly handle self-billed invoices, a key requirement for Peppol integration. It enables exporting vendor bills as compliant invoices, importing Peppol invoices, and sending/receiving them via the Peppol network, streamlining accounting processes and verifying invoice accuracy.
Original PR description
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice…
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes. Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct. See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/ #### This PR provides (1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard (2) the ability to import BIS3 self-billed invoices as customer invoices (3) the ability to send vendor bills as self-billed invoices over Peppol (4) the ability to receive self-billed invoices from Peppol in a specified Sales journal. #### Configuration Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration. We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types. Backport of https://github.com/odoo/odoo/pull/222658 Enterprise PR: https://github.com/odoo/enterprise/pull/97803 Upgrade PR: https://github.com/odoo/upgrade/pull/8886 task-5153851 Forward-Port-Of: odoo/odoo#232548
Resolved issues and error corrections
This update aligns a small icon used in the SaaS dashboard with established design guidelines. The change ensures a more consistent and professional look and feel for our users. It's a minor visual improvement that contributes to overall brand quality.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719
This update corrects a display issue in customer statements where outstanding balances weren't accurately calculated due to a flaw in how the system checked invoice balances. The fix ensures that the amount due is correctly displayed, reflecting partially reconciled payments. This improves the accuracy of financial reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This pull request removes a redundant CSS class from the Point of Sale module. The class was previously used to limit button width but is no longer needed. This cleanup improves the codebase and reduces potential maintenance overhead.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/229478 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the process of generating UBL invoices for Colombia and Mexico by refactoring internal code and automating the customer/supplier swap for vendor bills. This change improves the flexibility and maintainability of the system, ensuring accurate UBL invoice generation.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851 Forward-Port-Of: odoo/enterprise#97803
This update resolves an issue where the wizard didn't automatically close after report downloads when using custom report handlers (like those for IoT). Previously, IoT devices caused the wizard to remain open, leading to a confusing user experience. This fix ensures the wizard closes correctly regardless of the report handler used, improving consistency and usability.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
5 changes
New functionality added to Odoo
This update introduces support for Peppol Self-Billing, allowing customers to create invoices on behalf of vendors for easier accounting. It enables the export of vendor bills as compliant invoices and allows receiving these invoices directly within Odoo, streamlining the billing process for Peppol transactions.
Original PR description
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice…
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes. Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct. See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/ #### This PR provides (1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard (2) the ability to import BIS3 self-billed invoices as customer invoices (3) the ability to send vendor bills as self-billed invoices over Peppol (4) the ability to receive self-billed invoices from Peppol in a specified Sales journal. #### Configuration Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration. We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types. Backport of https://github.com/odoo/odoo/pull/222658 Enterprise PR: https://github.com/odoo/enterprise/pull/97803 Upgrade PR: https://github.com/odoo/upgrade/pull/8886 task-5153851 Forward-Port-Of: odoo/odoo#232548
Enhancements to existing features
This update enables public users to register for document sharing without needing a traditional Odoo user account. Previously, a public user invited via link would be forced to create a user, which wasn't ideal. Now, the system intelligently creates a linked user for the partner, streamlining the document sharing process.
Original PR description
Purpose ======= We can share a document to a partner without a user, and with `access_via_link == 'none'`. In that situation, the partner is forced to create a user, but if he clicks on signup, then the new user won't be linked to the partner set on the `documents.access` (a new partner will be created). Now, when inviting a member, if he doesn't have a user, we invite him to create a user. If the partner has a user, then we just redirect him to the login page. Task-5242208 Forward-Port-Of: odoo/enterprise#100628
Resolved issues and error corrections
This update corrects a bug where customer statements incorrectly showed no outstanding amounts after partial invoice payments. The fix ensures the system accurately considers both reconciled and unreconciled balances when determining follow-up actions for invoices. This improves the accuracy of customer statements and reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring accurate price difference calculations and preventing erroneous invoice lines.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#238428
This update simplifies the process of generating UBL invoices for Colombia and Mexico by streamlining internal code. Specifically, the order of customer and supplier information in vendor bills has been automatically corrected, and the underlying code has been refactored for easier future modifications. This ensures consistent and accurate UBL invoice generation.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851 Forward-Port-Of: odoo/enterprise#97803
14 changes
New functionality added to Odoo
This update adds the expiration date of product lots to invoices, aligning with industry standards for the pharmaceutical sector. This ensures accurate information is provided to customers regarding product shelf life, improving transparency and compliance. The change impacts the Point of Sale, Sale Stock, and Stock Account modules.
Original PR description
It's common in pharmaceutical industry to provide expiration dates of lots on customer invoices. Because of that, the lot expiration date is now added to `_get_invoiced_lot_values()`, together with lot properties. Task: 4985878 Related: https://github.com/odoo/enterprise/pull/103649 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 simplifies the process of using the 'Purchase Alternative' feature by moving it into a separate module. Previously, it was hidden within the purchase requisition process, making it difficult to find. Now, users can directly enable this feature from the Purchase settings, improving usability and streamlining workflows.
Original PR description
*: purchase_requisition ----------------------------------------------------------------------------------------- We have separated the `Purchase Alternative` functionality from the `purchase_requisition` module and created a new independent module called `purchase_alternative`. A new Boolean field, Purchase Alternative, has been added in Purchase settings to manage this feature. Previously, the `Purchase Alternative` option was hard to find; It only appeared after enabling Purchase Agreements, saving, and refreshing the Purchase settings view. This was very confusing and difficult to find for the user Now, users can directly enable the `Purchase Alternative` feature from the Purchase settings without relying on the `purchase_requisition` module. This makes the feature easier to access and more modular. taskId :- 4737059
Enhancements to existing features
This update enhances the visual appearance of Odoo’s onboarding samples across several modules, including loyalty and point-of-sale. By aligning the layout, colors, and icons with Odoo’s established UI standards, this change improves the overall user experience and ensures a more polished look for new users. This work addresses previous inconsistencies and strengthens brand consistency.
Original PR description
*: survey, point_of_sale, pos_restaurant - requires : https://github.com/odoo/enterprise/pull/98400 - extracted from: https://github.com/odoo/odoo/pull/228308 Before this commit, some onboarding suggestions were not fully aligned with Odoo’s UI standards. This commit readjusts the layout, colors, icons to ensure better visual consistency with others onboarding suggestions samples. task-5089102 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the visual appeal of the Odoo onboarding experience by aligning colors with Odoo’s design standards. The changes focus on improving the overall look and feel, ensuring a more polished and professional first impression for new users. This improves brand consistency and user experience.
Original PR description
*: marketing_automation_website_sale, marketing_automation_crm, appointment - requires : https://github.com/odoo/odoo/pull/233666 - extracted from : https://github.com/odoo/enterprise/pull/95384 Before this commit, some onboarding suggestions were not fully aligned with Odoo’s UI standards. This commit adjusts colors to ensure better visual consistency. task-5089102
Resolved issues and error corrections
This update addresses a requirement from the pharmaceutical industry to display lot expiration dates on customer invoices. The change adds lot expiration dates to the information provided for invoiced lots, aligning with industry best practices and improving invoice accuracy. This ensures consistent and complete information for customers.
Original PR description
It's common in pharmaceutical industry to provide expiration dates of lots on customer invoices. Because of that, the lot expiration date is now added to `_get_invoiced_lot_values()`, together with lot properties. Task: 4985878 Related: odoo/odoo#236734
A minor typo in the Odoo Enterprise module summary has been corrected. The original summary incorrectly displayed as 'Odooenvironment' in the user interface. This update ensures accurate module identification and a consistent user experience.
Original PR description
Typo introduced by commit 838b5e4. Because of the missing space, it appeared as "Odooenvironment" in the UI. task-none
This update resolves an issue where certain parts of the account module were unintentionally granted elevated permissions (sudo access) to bank statement data. This change improves security and data access control, ensuring only authorized processes can interact with sensitive financial information. The fix removes this unnecessary privilege.
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#243161 Forward-Port-Of: odoo/odoo#242771
This update corrects a bug where matching a partner by bank account could be overwritten by a subsequent match found through the partner's name. Previously, the system didn't check if a partner was already identified, leading to incorrect partner assignments. This change ensures accurate partner retrieval, improving data consistency in bank statement processing.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update fixes a limitation in the website builder where certain snippet options (Model and Template) were hidden. The change removed a technical restriction, now allowing users to select these options when adding snippets like the 'Blog' snippet. This simplifies the website customization process for non-technical users.
Original PR description
Steps to reproduce (19.0+): 1. Add a "Blog" mono-record snippet to a website page. 2. Select the snippet → the "Model" and "Template" options are visible. The code from [1], which introduced mono-record dynamic snippets, restricted the visibility of these options as follows: - The "Model" option should only be visible for generic mono-record snippets (in `Debug` mode). - The "Template" option should be available for generic snippets and, exceptionally, for the "Products" snippet (which had no default layouts in the snippets dialog). Starting from [2], these conditions are no longer applied, as the change simply removed the `props.modelNameFilter` used in the XML to enforce them. [1]: https://github.com/odoo/odoo/commit/e3b062e5d3820ddfcee2eb669f21edc0c53c3330 [2]: https://github.com/odoo/odoo/commit/36f741745b927d7cbac9b32042bd53b47711da6f related-task-4280375 Forward-Port-Of: odoo/odoo#241602 Forward-Port-Of: odoo/odoo#240995
This update fixes a previous restriction on website snippet options, allowing users to select 'Model' and 'Template' when adding dynamic snippets. The change removed a technical filter that previously limited these choices, ensuring greater flexibility in customizing website content. This improves the user experience for managing website snippets.
Original PR description
Steps to reproduce (19.0+): 1. Add a "Blog" mono-record snippet to a website page. 2. Select the snippet → the "Model" and "Template" options are visible. The code from [1], which introduced mono-record dynamic snippets, restricted the visibility of these options as follows: - The "Model" option should only be visible for generic mono-record snippets (in `Debug` mode). - The "Template" option should be available for generic snippets, except for "Products" snippet - (which is using another "Cards Design" option to customize the layout). Starting from [2], these conditions are no longer applied, as the change simply removed the `props.modelNameFilter` used in the XML to enforce them. [1]: https://github.com/odoo/odoo/commit/e3b062e5d3820ddfcee2eb669f21edc0c53c3330 [2]: https://github.com/odoo/odoo/commit/36f741745b927d7cbac9b32042bd53b47711da6f related-task-4280375
This update resolves issues that arose during module uninstallation, specifically related to how the system handles deleting records from database tables. The changes ensure data integrity by adding warnings for potential problems and updating the uninstallation process to align with best practices, preventing inconsistencies when reinstalling modules.
Original PR description
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled. It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator. ### Add warnings…
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled.
It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator.
### Add warnings when some model/field could not be deleted
The uninstallation process tries to delete all the records created by the modules being uninstalled. It uses a best-effort strategy, i.e., it skips the records that cannot be deleted, whatever the reason. But some records are very likely to cause problems, namely `ir.model` and `ir.model.fields` records, because skipping them implies not cleaning up their corresponding table's schema.
For instance, if a column is not dropped, reinstalling the corresponding module will possibly cause inconsistencies, because
- the column contains old values for existing records, which won't be recomputed (if the field is computed);
- the column contains NULLs for records created between the uninstallation and the reinstallation of the module.
We therefore add a warning in those cases, in order to detect and fix those potential issues as soon as possible.
### Make ondelete decorator work as documented
A method decorated with `@api.ondelete(at_uninstall=False)` should be called except when the method's module is being uninstalled. Currently the method is skipped when *any* module is uninstalled.
The fix consists in adding the set of modules being uninstalled in the attribute `registry.uninstalling_modules`, which may be used to detect uninstallation and determine which modules are being uninstalled.
### Replace MODULE_UNINSTALL_FLAG by new conventional flag 'force_delete'
We turn constant `MODULE_UNINSTALL_FLAG` into an explicit conventional flag, and rename it `force_delete` for the sake of simplicity. The idea is to decouple the flag from uninstallation. The caller simply uses
```py
records.with_context(force_delete=True).unlink()
```
to bypass some deletion hooks, which typically prevent deletion by raising some exception, in order to avoid data inconsistencies. On the callee's side, one has to explicitly detect the flag and skip the checks, like in:
```py
@api.ondelete(at_uninstall=False)
def _prevent_deleting_confirmed(self):
if self.env.context.get('force_delete'):
return
if any(record.state == 'confirm' for record in self):
raise UserError(_("You cannot delete confirmed records!"))
```
Note that the uninstallation process uses the convention by automatically adding `force_delete=True` in the `context` for deleting records.
### Fix issue module mail uninstallation
Two overrides of `unlink()` on models `ir.model` and `ir.model.fields` fail when uninstalling module "mail", because their code relies on some columns and those columns have been dropped already. This causes some table and column to remain after uninstallation. When reinstalling module "mail", errors like follows are logged:
```
column "mail_message_id" of relation "mail_tracking_value" contains null values
```
The fix consists in turning the overrides in proper "ondelete" methods, which are skipped when module "mail" is uninstalled.
https://github.com/odoo/enterprise/pull/103651
Forward-Port-Of: odoo/odoo#242777This update resolves an issue where module uninstallation could cause data loss. The update ensures that data is properly handled during module removal, preventing potential problems with related data. This improves the overall stability and reliability of the Odoo Enterprise system.
Original PR description
Companion of https://github.com/odoo/odoo/pull/242777 Forward-Port-Of: odoo/enterprise#103651
This update ensures that the wizard automatically closes after a report is downloaded, regardless of whether a custom report handler (like for IoT) is used. Previously, using a custom handler prevented the wizard from closing, leading to unexpected behavior. This fix maintains consistent user experience across all report types.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
This update corrects a previous navigation enhancement that caused duplicate breadcrumb displays on mobile forums, specifically within course forums. The fix ensures a cleaner, more intuitive user experience by properly scoping the breadcrumb rendering. This improves usability for all users accessing the forum on mobile devices.
Original PR description
This PR fixes an oversight introduces in Commit[^1]. With Commit 1, we improved the navigation by showing the back button everywhere on the forum but this created an issue due to a rule in `website_slides_forum` rendering the whole breadcrumb if the forum is a course one. | saas-19.1 and above | This PR | |--------|--------| | <img width="391" height="205" alt="image" src="https://github.com/user-attachments/assets/385a6d95-d8b4-4693-8c13-457e2b06f2fe" /> | <img width="390" height="145" alt="image" src="https://github.com/user-attachments/assets/429979a9-ed09-4fe7-8ded-e95909a9c97b" /> | [^1]: https://github.com/odoo/odoo/commit/bb5b7cfa284a55e6dd3a5deb4870bcfae28033af task-5490243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243585
31 changes
Enhancements to existing features
This update clarifies the certificate scope field in the Spanish EDI SII localization module. It now only displays this field when the company is located in Spain, preventing confusion for users working with other Odoo localizations. This ensures accurate reporting and simplifies the certificate management process for Spanish businesses.
Original PR description
Will make it visible the scope fiel only if the company country is ES. The field will remain invisible as defined in the certificate module for other cases. This way we avoid to show this field on certificates that use other localizations that can confuse to the user. 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 enhances error tracking within the Stripe expense module by providing full traceback logs when errors occur during webhook events. Additionally, a fix was implemented to prevent unnecessary communication with Stripe when a card is being destroyed, streamlining the process and improving efficiency.
Original PR description
## [IMP] hr_expense_stripe: full traceback logging When a pyhon error is raised during a webhook event we only get the error main line, not the full traceback. This adds the full traceback message to the log ## [FIX] hr_expense_stripe: Fix returned card error When a card is returned to the factory for destruction, when Stripe sends us the information, we sent a payload to stripe. This makes no sense as the card has been updated by Stripe into a state that doesn't allow further changes
Resolved issues and error corrections
This update corrects a bug that occurred when a leave request was linked to a refused allocation and the 'Time Off: Cancel invalid leaves' cron job ran. The issue stemmed from an empty data structure being used, which caused an error. This fix ensures the system handles refused allocations correctly during the cron process.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243505
Forward-Port-Of: odoo/odoo#227201This update ensures that leave dates are automatically recalculated when an employee's working schedule changes. Previously, leave entitlements weren't dynamically updated, leading to potential inaccuracies. This fix corrects this issue, guaranteeing accurate leave calculations based on the latest working calendar.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243287 Forward-Port-Of: odoo/odoo#241284
This update brings the latest version of the Odoo spreadsheet component to version 19.0.17. It includes several bug fixes and minor improvements to enhance the spreadsheet functionality and address performance issues, ensuring a smoother user experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2165bade2 [REL] 19.0.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2165bade2 [REL] 19.0.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5bd5ed31c [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782) https://github.com/odoo/o-spreadsheet/commit/7473925f8 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f3be8c001 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885) https://github.com/odoo/o-spreadsheet/commit/f9256eee3 [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713) https://github.com/odoo/o-spreadsheet/commit/a6aaeeffe [IMP] figure: add data-type attribute to figure carousel tabs [Task: 5447027](https://www.odoo.com/odoo/2328/tasks/5447027) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a restriction that prevented non-administrator users from updating GI CFDI sequences. Previously, sequence updates required elevated privileges, limiting functionality. Now, users can independently manage GI CFDI sequences, streamlining the process and improving efficiency.
Original PR description
In odoo/enterprise#102500, support was added for custom GI CFDI sequences at branch level. However, the sequence consumption fails for non-admin users due to missing write access on ir.sequence, so sudo() is required when updating number_next.
This update automatically recalculates taxes and fiscal positions for draft website orders whenever a partner's address is updated. This prevents incorrect tax calculations and ensures data accuracy for online sales. The change introduces a flexible mechanism to recompute taxes for a wider range of records, prioritizing draft orders to maintain data integrity.
Original PR description
Followup of 290d77cde41295b28aa522025136b48f74abcfc5.
When updating a partner address that may impact the fiscal position, we will recompute the fiscal position (and taxes) for draft website orders.
But other modules may also need to recompute other records, so avoid repeating the recomputing, this commit introduces a hook to allow extending the subset of records for which we need to recompute the fiscal position and taxes.
As the extended domain may contain non-draft records, ensure we only recompute prices for draft orders.
opw-5365258
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where subscription tax calculations were incorrect after a partner address was updated. The change ensures that fiscal positions and taxes are automatically recalculated when subscriptions are running or churned subscriptions are reopened, preventing inaccurate invoice amounts. This improves the accuracy of subscription billing and invoicing.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258
This update fixes an issue with how Odoo exports negative discounts when generating Peppol BIS 3 invoices. Previously, the system incorrectly treated negative discounts as allowances, leading to compliance errors. Now, the system dynamically adjusts the export to correctly represent negative discounts as surcharges, ensuring adherence to PEPPOL standards and accurate invoice calculations.
Original PR description
In Peppol BIS 3 (UBL 2.1), negative discounts are logically treated as Surcharges (Charges) rather than Allowances. Previously, Odoo exported negative discounts as an Allowance with a negative amount and a numeric reason code (95). This violated: BR-CL-20 / PEPPOL-EN16931-CL003: Coded charge reasons must belong to the UNCL 7161 (alphabetic) list when ChargeIndicator is 'true'. PEPPOL-EN16931-R120: The line net amount calculation failed due to the negative sign in the calculation. Solution: Dynamically toggles ChargeIndicator based on the discount sign. Swaps AllowanceChargeReasonCode to 'ADK' (Surcharge) for negative discounts. task-5432024 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
A previously random failure in a key stock management tour has been resolved. The fix ensures the system correctly verifies the first pallet line is unpacked before proceeding to the second, preventing a race condition that caused incomplete actions. This improves the reliability of the tour and the overall stock management process.
Original PR description
Before this commit, the tour `test_internal_picking_reserved_move_packages_into_new_palet` was randomly failing. In this tour, we have two palets we unpack. The issue is, after unpacked the first one, we complete the second one line and then we unpack it. But it can happen the click on the button to complete the second line was done too quickly (in the meantime the first palet line is unpacked) and thus, because of this race condition, the second palet line was not complete (either it's just a visual bug due to a refresh in the wrong time, either the complete action is dropped due to the first line unpacking action.) To fix that, this commit adds a step to verify the first line is correctly unpacked before going further. runbot-build-error: [237801](https://runbot.odoo.com/odoo/runbot.build.error/237801)
This update fixes a dashboard display issue that was preventing accurate employee information from being shown in payroll export warnings. The changes now correctly list employees without version ID export codes and incorporate Prisma code for a better user experience. This ensures more reliable and complete payroll export data.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681This update resolves an issue where Nilvera e-invoice synchronization for sales and purchases was conflicting, preventing updates to both flows. By using unique configuration keys based on the journal type (sale or purchase), the system now ensures each flow can independently fetch and sync e-invoices without interference. This improves the reliability of Nilvera data import.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently,…
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently, this parameter is shared between sales and purchase flows, causing their synchronization states to overwrite each other. # Current behavior before PR: When sales and purchase documents are synchronized from Nilvera, both flows use the same configuration parameter to store the last fetched date. As a result, running one synchronization (e.g. sales) may prevent the other flow (e.g. purchases) from fetching new documents, leading to missing or incomplete imports. # Desired behavior after PR is merged: Sales and purchase synchronizations maintain independent last fetched dates by using journal-specific configuration keys. This allows both flows to run reliably and incrementally without interfering with each other. taskId - 5494295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where ZATCA invoice XML generated in version 19.0 had inconsistent line amount calculations, leading to validation errors. The fix ensures that LineExtensionAmount, TaxAmount, and RoundingAmount align correctly, allowing invoices to pass ZATCA validation. This improves compliance and avoids potential disruptions to sales processes.
Original PR description
**Steps to reproduce:** * Install the **l10n_sa_edi** and **accounting** modules. * Create a **15% tax** (tax-included). * Create a customer invoice with two lines with amounts 18 and 14 and apply…
**Steps to reproduce:**
* Install the **l10n_sa_edi** and **accounting** modules.
* Create a **15% tax** (tax-included).
* Create a customer invoice with two lines with amounts 18 and 14 and apply
the tax on an invoice line.
* Post the invoice and **send it to ZATCA**.
* Review the generated XML or submit it for ZATCA validation.
**Observed behavior:**
* The XML nodes **LineExtensionAmount**, **TaxAmount**, and
**RoundingAmount** contain inconsistent values.
* ZATCA validation raises warnings due to rounding mismatches.
* Example:
* in xml data look like this
* `15.66(LineExtensionAmount) + 2.34(TaxAmount) != 17.99(RoundingAmount)`(v19)
* The required relation
**LineExtensionAmount + TaxAmount = RoundingAmount**
is violated.
**Cause:**
* In v19.0, `_round_base_lines_tax_details()` distributes rounding deltas so
that the **sum of rounded line taxes** matches the **rounded global tax**.
* When taxes are **included in price** and there are **multiple invoice lines**,
this distribution adjusts the per-line tax and base amounts.
Example pattern:
* Raw line taxes sum to something like **4.1739…**
* Rounded global tax = **4.17**
* Sum of individually-rounded line taxes = **4.18**
* A **-0.01 delta** is distributed across the lines
* Result:
* Line 1 base becomes **15.66**, tax **2.34**
* Line 2 base becomes **12.17**, tax **1.83**
So the XML correctly reports:
* **LineExtensionAmount = 15.66**
* **TaxAmount = 2.34**
* However, **RoundingAmount** is computed differently:
https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L439-L444
* Here, `base_line['tax_details']['total_excluded_currency']` **does not include the distributed delta**. It still reflects the *pre-distribution* base (e.g. **17.99 total excluded**), while **LineExtensionAmount** uses `vals['total_excluded_currency']`, which *does* include the delta.
* Result: the required identity
`LineExtensionAmount + TaxAmount = RoundingAmount`
is broken — producing inconsistencies such as:
`15.66 + 2.34 ≠ 17.99`
**Fix:**
* Use the same **vals[total_excluded_currency]** as it has a tax-excluded price with the delta included.
opw-5402750This update hides the 'suggest next documents' tab within the signing feature from users who are not logged in. This change ensures that sensitive document suggestions are only accessible to authorized personnel, enhancing security and data protection. It aligns with our security protocols by limiting access to features requiring user authentication.
Original PR description
This commit makes the suggestion tab of signing next documents hidden to public users, as they should be logged in to be able to see the next documents to be signed. task-5487349
This update resolves an issue related to the DmfA declaration within the Belgian payroll module. The change ensures compatibility with recent refactoring efforts, maintaining accurate payroll calculations for employees in Belgium. This update focuses on a technical fix to improve payroll processing reliability.
This update corrects a technical issue where subcontracting purchase orders were sometimes incorrectly identified as having multiple destinations. Previously, older orders could cause errors. This change ensures accurate processing of subcontracting orders by handling destination receipt counts correctly, improving order fulfillment accuracy.
Original PR description
Since commit fc66e2d4eb638f1486e69cd5920f02c787055da1 , a subcontracting MO only has one destination receipt. However, Subcontracting MOs created in previous versions can still have multiple move_dest_ids, hence `is_subcontract` must be accessed in a filter or after an `ensure_one()` OPW-5493343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where email templates with images would sometimes duplicate content when saved. The change ensures all images load completely before processing, preventing errors and maintaining template integrity. This improves the reliability of email templates.
Original PR description
Problem: In Email templates, having an email with an image using `t-att-src` (Qweb) on save will duplicate the template. Cause: Images without a `src` attribute (or empty src) make `waitUntilImagesLoaded` fail immediately if the image loading promise rejects. Because the errors were not caught, the inline conversion process was interrupted and duplicating content. Solution: Use `Promise.allSettled` instead of `Promise.all` to ensure the system waits for all images to finish loading regardless of success or failure. Additionally, filter the query selector to strictly select images with a non-empty `src` attribute (`img[src]:not([src=""])`) to avoid processing invalid or dynamic Qweb images. Steps to reproduce: - Open An email template with Qweb image. - Do a change and save. - Observe the content is duplicated. opw-5489040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing the creation of credit notes with DIAN support documents, specifically when using certain journals. The problem stemmed from an incorrect namespace being used, leading to errors when sending the required DIAN documents. This fix ensures credit notes with DIAN support documents can be successfully processed.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540
This update fixes an issue where translated text within views was being incorrectly escaped as HTML. By marking translated attributes as safe elements, the system now correctly renders translated strings, ensuring accurate display of localized content. This improves the user experience by preventing unexpected characters from appearing in translated text.
Original PR description
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding…
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding XML/HTML.
When `edit_translations` is active, translated strings are wrapped in `<span>` tags containing translation metadata. To maintain backward compatibility and allow in-place translation, values from `.translate` attributes are now explicitly marked as Markup safe elements. This ensures that the translation wrappers are correctly rendered as HTML rather than escaped text.
Exemple:
```xml
<t t-call="payment.submit_button">
<button><t t-out="submit_button_label"/></button>
</t>
<t t-name="payment.mytemplate">
<div class="modal-body">
<div class="float-end mt-2" t-att-data-provider-id="provider_sudo.id">
<t t-call="payment.submit_button" submit_button_label.translate="Pay"/>
</div>
</div>
</t>
```
When reading the views, `submit_button_label` value must be translated. We We want the button to be rendered with the translated value and not to display the escaped char like "<".
see: https://github.com/odoo-dev/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df
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-prThis update fixes an error in the calculation of pay run end dates for Mexican companies using specific payroll schedules (10 Days, 14 Days, Bi-weekly, Bi-monthly). The underlying calculation method was updated, but the Mexican payroll module hadn't been adjusted, leading to incorrect period determination. This ensures accurate payroll processing for Mexican businesses.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#102326
This update addresses a compatibility problem with older browsers. A recent change in how Promises were handled caused errors for users running older versions of Odoo. This fix backports a necessary polyfill to ensure consistent functionality across all supported browsers.
Original PR description
This commit adds a polyfill for Promise.withResolvers. Such a polyfill had been introduced in [1], which deprecated Deferred in favour of withResolvers, but withResolvers was already used in v19, thus leading to tracebacks for people running (very) old versions of their browsers. This commit backports the polyfill. [1] https://github.com/odoo/odoo/pull/235237 task~[special request from our cto] --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a potential issue in how the system locks payroll periods for tax reporting in Switzerland (l10n_ch_hr_payroll). By using a reference date, the system now accurately reflects the period being used for ELM transmission, ensuring correct tax calculations and compliance. This improves the reliability of financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#104269
This update fixes an issue where menu entries were incorrectly linked to the latest page when multiple pages with the same name were created. Now, menu updates only occur when a new page is created, ensuring accurate page associations and preventing confusion for users. This improves the consistency of website navigation.
Original PR description
With commit 19302cd40347065fcd937bd54e6dce27fe4940cc, when a page is created, menu entries with a url corresponding to the created page are updated to set their `page_id` to the new page. The update may also be triggered when creating several pages with the same name in a row. This commit updates a menu entry on page creation only if no page were already associated to the menu. Steps to reproduce: - Create a new page, call it "test" (will be available on `/test`) - Create a new page, call it "test" (will be available on `/test-1`) - Go to editor menu - Bug: both entries point to `/test-1` - Create a new page, call it "test" (will be available on `/test-2`) - Go to editor menu - Bug: the first one (and the new one) is pointing now to `/test-2` task-5186653 Forward-Port-Of: odoo/odoo#243312
This update fixes an issue where changes to website views (like footer edits) were lost during module upgrades. The fix ensures that translations are correctly applied after upgrades, preventing data loss and maintaining consistent website content across languages. This improves the reliability of website updates and the accuracy of translated content.
Original PR description
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view.…
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view. This happened because the update of the view did not take into account the possible delayed translations when updating it and the translations in specific views. This commit updates (and uses as source) the current versions, instead of the delayed ones. Steps to reproduce: - Install a second language for the website - Set the default language for the website to the second language - Edit footer by changing structure not just text (like changing a link to have a button appearance) - Upgrade the "Website" app - Bug: footer lost the last edit Steps to reproduce: - Install a second language for the website - Edit footer by changing structure not just text (like changing a link to have a button appearance) - (Observe that the change is not in the website in the second language) - Upgrade the "Website" app - Bug: the change is now in the website in the second language task-5248173 Fixes #233723
This update corrects a bug where matching a partner by bank account could be overwritten by a subsequent match found through the partner's name. Previously, the system didn't check if a partner was already identified, leading to incorrect partner assignments. This ensures accurate partner retrieval, particularly when using bank statements.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update fixes an issue where GS1 barcodes with quantity information weren't being properly used in manufacturing orders. Previously, the system only added one unit of the product, regardless of the barcode's quantity. Now, the system accurately reflects the quantity specified in the GS1 barcode when scanning the final product, ensuring consistent behavior and accurate production tracking.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104024 Forward-Port-Of: odoo/enterprise#95174
This update resolves an issue where the original invoice linked to a reverse move was not being displayed correctly. Previously, when reversing an invoice, the 'Source Document' field in the invoice list was blank. This fix ensures that the correct original invoice is always linked, improving reporting accuracy and traceability of financial transactions. This was a regression identified and addressed in the Odoo system.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
This update resolves a bug preventing the correct saving of order details related to Swedish point-of-sale transactions. The fix ensures that all necessary data is recorded in the database, improving the accuracy of sales reporting. It also includes updates for compatibility with the latest IoT box image.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104218 Forward-Port-Of: odoo/enterprise#104180
This update fixes an issue where customer statements incorrectly showed an outstanding balance after invoices were partially paid and reconciled. The fix ensures the system accurately considers the remaining amount due, including partially reconciled invoices, leading to more precise customer statements. This improves the accuracy of financial reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update resolves an issue where the wizard didn't automatically close after downloading reports when using custom report handlers (like those for IoT). Previously, IoT integrations caused the wizard to remain open, leading to unexpected behavior. This fix ensures the wizard closes correctly regardless of the report handler used, improving the user experience.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
This update resolves an issue where incorrect credentials caused misleading error messages when sending invoices. The fix ensures a clearer and more informative error display, preventing confusion and streamlining the invoice processing workflow. This improves the user experience and reduces potential delays.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243489
8 changes
New functionality added to Odoo
This update allows businesses to seamlessly handle self-billed invoices – invoices created by customers for their own accounting – through the Peppol network. It enables the export, import, and automated receipt of these invoices, streamlining accounting processes and improving data verification for vendors.
Original PR description
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice…
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes. Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct. See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/ #### This PR provides (1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard (2) the ability to import BIS3 self-billed invoices as customer invoices (3) the ability to send vendor bills as self-billed invoices over Peppol (4) the ability to receive self-billed invoices from Peppol in a specified Sales journal. #### Configuration Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration. We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types. Backport of https://github.com/odoo/odoo/pull/222658 Enterprise PR: https://github.com/odoo/enterprise/pull/97803 Upgrade PR: https://github.com/odoo/upgrade/pull/8886 task-5153851
Enhancements to existing features
This update simplifies the process of generating UBL invoices for Colombia and Mexico by refactoring internal code and automating the customer/supplier swap for vendor bills. This change enhances the flexibility and maintainability of the UBL export functionality, ensuring compliance with local tax regulations.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851
Resolved issues and error corrections
This update fixes an issue where products created through the website were automatically published without a category assigned. The change removes code that forced publication and now ensures products remain unpublished until a category is selected, aligning with the user's expected experience. This improves consistency and prevents accidental product listings.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the website's product barcode lookup functionality accurately reflects a recent change in Odoo. Specifically, the test now correctly handles scenarios where products created through the website aren't automatically published if a category hasn't been selected, aligning with a community update.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779
A bug was preventing users from clicking the 'Validate' button after an invalid barcode scan in stock picking. This was caused by a misconfigured fix that blocked further validation attempts. This update reverts the previous fix and utilizes the framework's mutex mechanism for reliable, sequential barcode validation, ensuring accurate stock updates.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on…
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on Validate > Invalid operation - Scan a Serial number #### > You can not click on validate anymore ### Cause of the issue: The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since orm call returns an error, the call of the validate method is interupted at this orm call and the line https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133 ### Fix: We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 : https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135 we have the guarantee that the records will not be validated twice. ### Note: We had to also adapt this line in 18.0+: https://github.com/odoo/enterprise/blob/e04ecb45cc99f74e9956a0c1e669bb2c05816fde/stock_barcode/static/src/models/barcode_picking_model.js#L921-L925 Since the wrapper is equivalent to itself while `super.validate()` calls the `_validate` of the `BarcodeModel` and not of the `BarcodePickingModel` and since we need to bypass the regular validate call to avoid an infinite loop: https://github.com/odoo/enterprise/blob/6b0585d2776392c32b190f6e77761d805da49802/stock_barcode/static/src/models/barcode_picking_model.js#L931-L935 opw-5388297 Forward-Port-Of: odoo/enterprise#103835
This update corrects a previous issue where all fixed taxes were incorrectly converted to allowance charges during UBL exports. Now, fixed taxes that don't affect the tax base (like 'recupel') are properly represented as separate invoice lines, aligning with the changes introduced in Odoo v18+. This ensures accurate tax reporting for UBL invoices.
Original PR description
Context : In v18+, fixed taxes are handled differently depending on whether they affect the tax base or not. Before this commit : All fixed taxes were systematically converted into allowance charges during UBL exports. This behaviour was incorrect, as some fixed taxes (e.g., recupel) do not affect the tax base and should instead be represented as separate invoice lines. This commit aligns the v17 behavior with the logic introduced in v18+ by distinguishing between the two cases: - Fixed taxes that affect the base are converted into allowance charges. - Fixed taxes that do not affect the base are converted into additional invoice lines. task-5405115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240706
This update automatically corrects discrepancies between check amounts and payment amounts when using third-party checks for vendor payments. Previously, users had to manually adjust payment amounts, leading to errors and delays. This change ensures accurate accounting and eliminates the need for manual intervention.
Original PR description
Current behavior: when using third-party checks to create vendor payments, withholding amounts are creating a difference between the checks amount and the payment amount, resulting in a warning and requiring manual adjustment of the payment amount until the amount minus withholdings matches checks amount. Solution: adding an automated adjustment algorithm to the wizard. task-4257629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue affecting compatibility with stable IoT Box devices. The system now correctly interprets data responses from these terminals, ensuring smoother and more reliable operation. This change enhances the overall stability of the Point of Sale (POS) system.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104113
1 change
Resolved issues and error corrections
This update fixes an issue where the DDT number wasn't included in delivery reports. The change ensures the DDT number is generated and added to the report before the email is sent, resolving a problem that prevented accurate tracking of delivery documents. This improves the clarity and completeness of shipping notifications for Italian businesses.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265