Thursday, June 11, 2026
41 changes · saas-19.3
Resolved issues and error corrections
This update resolves a technical issue that prevented the system from correctly retrieving default values for planning slots. The problem stemmed from how a recordset was being handled, leading to an error. This fix ensures that default values are consistently retrieved, improving the reliability of planning processes.
Original PR description
`self` could be non-singletion recordset ``` (Pdb) p self.default_get(['repeat_interval']) *** ValueError: Expected singleton: planning.slot(227, 174) ``` See: 689a15b46c85774f3ab9ee4b9173a549c2ce1abf Forward-Port-Of: odoo/enterprise#120080
This update removes a duplicate button for creating channels within the Odoo system. Previously, attempting to copy a channel resulted in an error due to permission issues. Removing this button simplifies the process and addresses a usability concern without adding new functionality.
Original PR description
duplicating channels does not provide much value. when you try to copy channel error comes like `you do not have enough rights to access the field ai_agent_id on Discussion Channel (discuss.channel).` now we are remove the duplicate button from channels form view cog menu as its does make sense to use it there at all. task-5494736 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269153 Forward-Port-Of: odoo/odoo#268999
This update fixes an issue where planned dates were lost when converting projects to project templates. The fix ensures that the original planned dates are retained in the new template, improving project tracking accuracy. This change impacts how project templates are created and managed.
Original PR description
****Steps** to reproduce:** - Open a project with a planned date set. - Create Template of that project. - Observe the created project template. **Issue:** The planned dates of the project are lost when converting the project into a template. **Cause:** When we create a project template from a project, the project gets archived. Because a new project template record is created, and the start and expiration fields have copy=False, those dates are not being copied. **Fix:** Explicitly pass the planned date when copying the project, so the project template keeps the original planned date. task-5872500 Forward-Port-Of: odoo/odoo#269257 Forward-Port-Of: odoo/odoo#249411
This update corrects a bug that prevented users from successfully adding talks to their favorites on the website's event pages. The issue stemmed from an error when processing location information for reminder emails, specifically related to how event addresses were being defined. This fix ensures a smooth user experience when interacting with event listings.
Original PR description
Steps to reproduce ================== 1. Log in. 2. Open the Events page on the website. 3. Open the OpenWood Collection Online Reveal event. 4. Go to Talks. 5. Try to favorite a talk with a location. => Failed to render QWeb template for Mail Template. To compute calendar_urls for event track reminder emails, we previously used the computed field address_inline on the event, which falls back to an empty string when the address is not set. Since commit [1], event address uses contact_address_inline, which is related to address_id. As a result, contact_address_inline is False when address_id is not set, and we attempt to iterate over it with join() to build the address string. This causes an error. [1] https://github.com/odoo/odoo/commit/16d8afe9849e23d75b681cd30d7d1bee18913a92 Task-6288817
This update resolves a flaky test in the Point of Sale module, preventing unnecessary processing and potential slowdowns. The fix removes a redundant step in the test process and simplifies the test itself, ensuring more reliable results. This improves the overall stability of the POS system.
Original PR description
The test was calling action_pos_session_closing_control() before fetching the sale details report, which triggered the full session closing flow (accounting moves, validations) unnecessarily. The report does not require the session to be closed, so the closing call is removed. The test is also simplified by removing the tax and the only_round_cash_method config, which were not relevant to the cash rounding assertion being tested. runbot-243490
This update fixes a visual issue in the barcode app's picking functionality. Previously, when creating packages from scanned serial numbers, the created packages weren't displayed, leading to confusion. Now, the system correctly shows the source and destination packages, providing clearer visibility during the packing process.
Original PR description
### Steps to reproduce: - Enable `Lots & Serial Numbers` and `Packages` in the settings - Create a product tracked by SN and add SN001 and SN002 to stock - Create and confirm a delivery for 2 units -…
### Steps to reproduce: - Enable `Lots & Serial Numbers` and `Packages` in the settings - Create a product tracked by SN and add SN001 and SN002 to stock - Create and confirm a delivery for 2 units - Open the Barcode app and open the delivery - Scan the product > Scan SN001 - Click `Put in Pack` ### Current behavior: The created package is not displayed anywhere. Clicking Put in Pack again nests the package into another package without any visible indication to the user. ### Cause of the Issue: The GroupedLineComponent cannot display neither the source or destination package: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.xml#L4-L21 However, our case the grouped line contains only a single line and prevents the users from viewing the sublines since the `Show Reserved Lots` is disabled on the operation type and only one lot (with additional demand) was scanned: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L75-L77 https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L44-L55 opw-6237834 Forward-Port-Of: odoo/enterprise#119114
This change removes a failing test related to German duration formatting in the web module. The test was dependent on a specific Chrome version and a shift in Unicode CLDR definitions. This fix ensures the application continues to function correctly across different browser versions and avoids unnecessary test failures.
Original PR description
Cause: ---------------------------------------- Commit 121806b57816d0fbd48b5538d2a8beae35905d99 added a test verifying that the duration in German is correctly recognized. In the test, "2 Std. 30…
Cause: ---------------------------------------- Commit 121806b57816d0fbd48b5538d2a8beae35905d99 added a test verifying that the duration in German is correctly recognized. In the test, "2 Std. 30 Min. 45 Sek.", was supposed to be recognized as 2.5125 hours. But on some browser versions it fails, as in the latest Chrome version. This is because we use `DurationFormat()` to get the localized units. This method is supported by all browsers and will use the browser's data to get the translations. This data comes from [Unicode CLDR](https://cldr.unicode.org/) which is updated regularly. We would need to change the test depending on the Chrome version, so we just delete it. It appears that for German hours the CLDR definitions have historically shifted between two distinct representations: "Std." and "h" As an example: - CLDR 47: https://github.com/unicode-org/cldr-json/blob/16f6b8578ba5fe98959034706f337674f816fc3f/cldr-json/cldr-units-full/main/de/units.json#L3526-L3527 - CLDR 48: https://github.com/unicode-org/cldr-json/blame/4d06be52b51bb2f75688d0abe55c52a66afed790/cldr-json/cldr-units-full/main/de/units.json#L3916-L3917 So the test fails in CLDR 48 but succeeds in CLDR 47. As the latest version of `ICU` (used by browsers) updates its dependency to CLDR 48 ([src](https://unicode-org.github.io/icu/download/78.html)) this explains why the latest Chrome version makes the test fail. runbot-939543 Forward-Port-Of: odoo/odoo#268891
This update resolves an issue where the CODA integration incorrectly prioritized a journal with no currency over one with the correct currency. The change creates two journals and selects the one with the lower ID, ensuring the correct currency journal takes precedence. This improves the accuracy of currency reporting within the CODA system.
Original PR description
The journals[0] is not ideal if the user has one journal with no currency and one with currency that fits the CODA's currency. We'll have two journals and we take the first one at random. Thus if it has a lower id, the journal with no currency will be selected instead of the one whose currency is correct. The latter should take precedence over the former. task-6226835 Forward-Port-Of: odoo/enterprise#118381
A recent update to Odoo caused an error when generating PDF invoices using the ‘Get ETA Invoice PDF’ button. This fix resolves a technical issue related to how Odoo handles data received from external services, ensuring the button now functions correctly. This prevents users from encountering errors when downloading invoice PDFs.
Original PR description
Using the “Get ETA Invoice PDF” button located on the form view of invoices can result in a stacktrace error. Since installing requests==2.25.1 with python 3.10, and using: requests.exceptions.JSONDecodeError Will raise the following error: AttributeError: module 'requests.exceptions' has no attribute 'JSONDecodeError' This change fixes the error by using 'JSONDecodeError' from the 'json' package. Related: https://github.com/odoo/odoo/commit/55bddda59b8f9479d515163852fa8cbc718ddbd3 [opw-6275476](https://www.odoo.com/odoo/project/49/tasks/6275476?debug=assets) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268920
This update resolves an issue where the system previously restricted searches using record IDs to only positive values. During database migrations, negative IDs could occur, and this change ensures the system now correctly handles these cases, improving data accessibility. This ensures all records can be found during searches.
Original PR description
Currently, the validation for the name_service only allows us to search on records with ids greater than or equal to one but in some edge cases like migrations where databases needed to be merged, we ended up with negative ids (v6.0 migration on odoo.com). The ORM is capable of handling these so we allow it in the name_service as well. opw-6213802 Forward-Port-Of: odoo/odoo#268007
This update corrects a technical issue with how Odoo validates cardholder addresses for Stripe payments. The system was incorrectly using an outdated ISO 3166-2 standard for state codes, causing failures for US addresses. This fix ensures compatibility with Stripe's requirements and prepares for the upcoming US release.
Original PR description
Stripe says that address.state is "State, county, province, or region (ISO 3166-2)". There didn't seems to be any issues since it seems that it's not checked for the EU. However, this is still wrong and could raise an issue if Stripe decide to start checking them. Also, with the US coming soon, it's being checked and failed. Forward-Port-Of: odoo/enterprise#114480
This update resolves an issue where the website's main menu would unexpectedly close due to overlapping updates. By closing the extra menu before opening the main menu, the system now provides a more reliable and consistent user experience. This prevents a frustrating error for users.
Original PR description
[FIX] website: close the extra menu before opening site menu Update of the extra menu item is done multiple times (cfr `afterFontsloading`). If the extra menu item and the site menu were already open before an update of the extra menu item, the result is a close of the site menu. This can lead to undeterministic error. To solve the problem, the extra menu dropdown is closed before opening the site menu. runbot-240955 Forward-Port-Of: odoo/odoo#269177 Forward-Port-Of: odoo/odoo#266376
A bug preventing a traceback when clicking calendar slots in Knowledge articles has been fixed. The issue stemmed from an incorrect template update that was subsequently reverted. This ensures a smooth experience when users interact with the calendar functionality within Knowledge.
Original PR description
How to reproduce: 1. Create a new Knowledge article 2. Insert an "item calendar" embedded view by typing /calendar 3. Click anywhere to create an article item 4. Go back to the parent article 5. Click on the calendar slot -----> Traceback ### Technical The [commit] adds the `this.` to migrate templates to access values from the component correctly in the owl3. It mistakenly added `this.` too when accessing the `slot` in the template `knowledge.ArticleItemsCalendarCommonPopover.body`. But the `slot` isn't a variable associated with the component. It's associated with the owl3, which must be accessed directly. Therefore, we revert the change from [commit] inside Knowledge's item_calendar. [commit]: https://github.com/odoo/enterprise/commit/e43f89a0bb8e85521bbf062ab70e7a7b4bda2eb8 Task-6279097
This update fixes a technical issue where the AI system was incorrectly reporting the creation of duplicate project tasks. The change ensures that required fields are validated before task creation and preview display, preventing errors and the misleading impression of double creations. This improves the reliability of the AI-powered project task feature.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596
This update resolves a technical error that was preventing the system from reliably sending meta requests. The issue stemmed from an invalid calculation within the social module, specifically when handling failed requests. This fix ensures smoother operation and prevents potential disruptions to social features.
Original PR description
Error: ``` TypeError: unsupported operand type(s) for *: 'NoneType' and 'int' ``` Cause: - `None * len(queries_batch)` is invalid because `None` cannot be repeated with`*`. Solution: - The result should contain one None for each request in the failed batch. sentry-7541540366
This update fixes an issue where purchase order subtotals were calculated incorrectly when some order lines had a quantity of zero. The fix involves storing the filtered order lines to ensure accurate subtotals are displayed, improving the reliability of purchase order reports. This ensures accurate financial reporting.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/3ac515ab55dd6708e0df283c634e2b99fc4a5561 When order lines with qty=0 are filtered out, `line_index` refers to the filtered list but `order_line[line_index+1]` indexed into the full unfiltered recordset, causing section subtotals to fire at the wrong position with incorrect values. Solution: Pre-store the filtered recordset and use it for the next-element lookup opw-6174429 Forward-Port-Of: odoo/odoo#267924
This update corrects a bug in the journal report that prevented accurate display of multi-country tax grids. Previously, when multiple countries were selected for taxes, the report layout was broken, and some countries were missing. This fix ensures correct tax grid rendering for users with multiple country tax configurations.
Original PR description
When more than 2 country are used in the taxes, the colspan of the header is wrong. When more than 2 country are used in tax grids, the country isn't displayed anymore. Forward-Port-Of: odoo/enterprise#120032 Forward-Port-Of: odoo/enterprise#119348
This update fixes a visual issue where posted invoices were incorrectly labeled as 'proforma' when printed. The Print button has been made secondary to emphasize the Send action, aligning with the standard invoicing workflow. This ensures invoices are consistently presented without unnecessary proforma indicators.
Original PR description
Revert 3ef2c09 which incorrectly added a proforma label when printing posted invoices that had not yet been sent, proforma invoices have an entire feature in the sales app, so an invoice in invoicing should just be an invoice in all cases. --- The Print button on posted invoices was visually styled as a primary action. Make it secondary so the Send action keeps the main visual emphasis, while Print remains available with the same behavior. task-6269645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269183 Forward-Port-Of: odoo/odoo#268552
This update prevents empty ICS calendar files from being generated when users attempt to add open shifts to their calendars. Previously, the system would create an empty file when a matching time slot wasn't found. Now, the ‘Add to Calendar’ button is hidden and the ICS file is only generated when a valid time slot is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#119945 Forward-Port-Of: odoo/enterprise#118978
This update resolves an issue where users without HR access rights were seeing a placeholder image instead of their employee avatar in the timesheet kanban view. The fix ensures that the correct avatar is displayed for all users, improving the user experience and visual consistency.
Original PR description
Steps to reproduce:
- Install the hr_timesheet module
- Create a user without HR access rights
- Create a timesheet
- Log in with the above user
- Open the kanban view
Issue:
Instead of showing the employee's avatar, a placeholder image
is displayed.
Reason:
The user does not have access to the hr.employee model.
Fix:
In this commit, if the user does not have access to hr.employee,
we fetch the image from the hr.employee.public model.
Task: 4461272
X-original-commit: b3018b1ab4bcdfebd8bb83bad38209b96646da3c
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
Forward-Port-Of: odoo/odoo#269262This update resolves a bug that prevented users from successfully shortening the deadlines of final tasks within the Gantt view. The fix ensures the system correctly calculates task end dates, preventing an error when a task has no dependent tasks. This improves the reliability of the Gantt chart for project scheduling.
Original PR description
## Steps to Reproduce: - Install the Project module. - Create a project. - Project > Tasks > Open Gantt view. - Create a task without any dependent tasks. - Reduce the task duration by dragging the end of the pill backward. ## Error: `ValueError - max() iterable argument is empty` ## Cause: When shortening the deadline of a task whose start date remains unchanged, the Gantt rescheduling logic computes the end date based max of the successor tasks. For a final task (or a single task), there are no successor candidates, causing max() to be called on an empty list and raise a traceback. ## Fix: This commit uses the task's own end date when no successor candidates are available. sentry-7543381016
This update addresses a minor visual issue in the project settings by adding a space between elements. This improves the clarity and ease of use for users when viewing and managing project tasks, ensuring a more professional and user-friendly experience.
Original PR description
This commit add a space between a span and a field in the project setting for a better readability. 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 addresses a warning related to how Odoo generates PDFs using the PyPDF library. The change ensures stability and prevents potential errors by adjusting the order of operations when merging and compressing PDF pages. This improves the reliability of PDF generation within Odoo.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's…
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/odoo#268865 Forward-Port-Of: odoo/odoo#267958
This update fixes a warning related to how Odoo handles PDF generation using the PyPDF library. The change ensures stability and prevents errors by adjusting the order of operations when merging and compressing PDF pages, improving the reliability of signature creation.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's…
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669 Forward-Port-Of: odoo/enterprise#119694 Forward-Port-Of: odoo/enterprise#119239
This update resolves an issue where calendar events with multiple attendees displayed inconsistent 'Contact Details' information. The fix ensures that only the primary attendee (in 1-on-1 meetings) shows contact information, improving the clarity and reliability of event descriptions. This prevents a random attendee's details from appearing.
Original PR description
When a calendar event has multiple attendees, `_get_contact_details_description` picks the first non-organizer partner from a set-based recordset to render under "Contact Details" in the event…
When a calendar event has multiple attendees, `_get_contact_details_description` picks the first non-organizer partner from a set-based recordset to render under "Contact Details" in the event description. The recordset is built from `partner_ids_from_attendees`, a set whose iteration order depends on Python's hash seed, so the displayed contact is effectively random and not controllable from the UI. Restrict the "Contact Details" block in `_get_contact_details_description` to events with exactly one non-organizer attendee (1-on-1 meetings). For group meetings the block is omitted entirely, since any single attendee picked from a larger group is arbitrary by construction. Steps to reproduce: 1. Go to Calendar > New 2. Add 3+ attendees (e.g. Alice, Bob, Charlie) 3. Save the event 4. Check the Notes tab in the event form => One random attendee's contact info appears under "Contact Details" Ticket [link](https://www.odoo.com/odoo/project.task/6035192) opw-6035192 Forward-Port-Of: odoo/odoo#258901
This update ensures Odoo's financial reports (GSTR-3B and GSTR-2B) accurately reflect new requirements for purchase composition supplies as mandated by the Indian government. The changes align the report formats with government utility standards, improving compliance and reporting accuracy.
Original PR description
As a new GSTR section for purchase composition supplies has been introduced, the related report domains also need to be updated accordingly. With this commit: GSTR-3B domains are updated to properly include purchase_composition_supplies transactions in the relevant report section. GSTR-2B now includes a separate line for composition supplies, aligned with the government utility format. task-6239870 Forward-Port-Of: odoo/enterprise#118312
This update resolves a sporadic test failure related to highlighting the timesheet timer field. The change replaces a temporary workaround with a more reliable method using React's `useEffect` hook, ensuring the test consistently passes. This improves the overall stability of the timesheet functionality.
Original PR description
This PR replaces the macrotask hack to hightlight the content of the timer field on focus with a more idiomatic useEffect. This ensures the corresponding test won't fail randomly if the macrotask queue happens to not be cleared before we check the highlight. Forward-Port-Of: odoo/enterprise#119975
This update fixes a discrepancy in how product prices are displayed. Previously, changing the price on a product without variants only updated the variant form, not the main product template. Now, the template price will automatically update when the variant price is changed, ensuring consistent pricing across all product views.
Original PR description
Issue: When the sales price is changed from the product variant form for a product without configured variants, the price is updated only on `product.product.lst_price`. The main product form, opened…
Issue: When the sales price is changed from the product variant form for a product without configured variants, the price is updated only on `product.product.lst_price`. The main product form, opened from Inventory > Products, displays `product.template.list_price`, which remains unchanged. The same issue is visible from Purchase Orders because the product internal link on a purchase order line opens `product.product`, while the product page opens `product.template`. Steps to reproduce: - Create or open a product without configured variants - Open product variant form from the internal link in a purchase order - Change the Sales Price on the product from there - Open the product from Inventory > Products (`product.template`) - The template Sales Price still shows the old value Cause: Since version 19.1, `product.product.lst_price` is an editable stored field, allowing variant-level prices to differ from the template price. This is correct for products with multiple variants, where each variant may have its own sales price. However, for products with only one variant (the product itself), no synchronization was performed from `product.product.lst_price` back to `product.template.list_price`, leaving both product forms inconsistent. Solution: - Add `_inverse_product_lst_price` on `product.product.lst_price` so that When `lst_price` is written and the template has exactly one variant, set `list_price` to `lst_price` (delegates to the template) opw-6260015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268017
This update ensures that if preset delivery addresses are missing in self-order transactions, the system now automatically uses the company's default address. This prevents errors and ensures accurate order delivery information, improving the customer experience. It resolves an issue where empty address fields were incorrectly flagged as 'False'.
Original PR description
Before this commit: ===================== Empty delivery address fields were shown as `False`. No fallback was applied when preset delivery address fields were missing After this commit: ===================== Missing preset address values fall back to the default company address. Task-6227192
This update resolves an issue where the website rental planning module would crash when the quantity input field was removed. A recent change moved data evaluation logic directly into the DaterangePicker component, and without the quantity selector, the system encountered a 'null' error. This fix ensures the module functions correctly even with the quantity input field disabled.
Original PR description
Steps to reproduce: 1. Install website_sale_renting_planning 2. In rental module, create a product that is of type service and can be sold 3. Go to the website and remove the quantity selector input…
Steps to reproduce: 1. Install website_sale_renting_planning 2. In rental module, create a product that is of type service and can be sold 3. Go to the website and remove the quantity selector input field from the page and save. Issue: `TypeError: Cannot read properties of null (reading 'dataset')` Why this happens: Following architectural changes in v19.1, the rental data evaluation logic was moved directly into the DaterangePicker component lifecycle. Commit 4e5f71d introduces a new method to where, during initialization (`willStart`), the component triggers `setAddQtyInputMax()` to update the dataset attributes of the quantity selector input box. If the quantity selector has been removed via the website customizer `querySelector` returns `null`, causing the assignment to crash. In v19.0, this logic lived in the `WebsiteSale` interaction, executing only during post-render UI event listener triggers which kept it safe. opw-6268945 Forward-Port-Of: odoo/enterprise#119574
This update fixes an issue where tax reports for Moroccan companies were incorrectly including entries with zero balances. The fix filters out these entries, ensuring reports only display relevant financial data. This improves the accuracy and clarity of tax reporting for our Moroccan clients.
Original PR description
When generating the tax report for a Moroccan company, entries with a zero balance were appearing in the report. Steps to reproduce: ------------------- * Create a Moroccan company * Create a bill with a tax to pay * Change the bill date and accounting date to a past date * Make a first payment of the bill, with a date to today * Unreconcile the payment, and make a second payment with a date in the past (the same one as the bill date for example) * Now generate the tax report for the period of today > Observation: The report contains useless entries with a zero balance. Why the fix: ------------ We add `HAVING SUM(account_move_line.balance) != 0` to filter out the line that have a zero balance. opw-5911669 Forward-Port-Of: odoo/enterprise#113956
This update fixes an issue where automation rules using dotted paths to assign users to activities weren't working correctly. The change ensures that activity descriptions accurately reflect the assigned user, mirroring a recent fix in the mail module for handling relational field chains. This improves the reliability of automation workflows.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `ai` and `contacts` modules 2. Create an automation rule on Contact model: * Trigger: On Creation * Action To Do: Execute AI Action…
Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
* Trigger: On Creation
* Action To Do: Execute AI Action
* Add a server action tool with 'Create Next Activity' action
* Set Activity User Type to Dynamic
* Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user
Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths
Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed
Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module
opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530
Forward-Port-Of: odoo/enterprise#119179
Forward-Port-Of: odoo/enterprise#118921This update resolves a technical issue preventing users from successfully adding AI-generated images to product pages within the Enterprise edition. The fix corrects a mismatch in data handling, ensuring the system correctly processes multiple images when adding media. This ensures a smoother experience for users utilizing AI-generated content.
Original PR description
A traceback is produced when trying to add AI-generated images to a product using "Extra Media" -> "Add More". **Origin of the problem** The `ProductAddExtraImageAction` in `website_sale` always opens the Media dialog with `props.multiImages = true` and the save handler expects `loadResult.imgEls` to be an array. The `aiSave` method patched onto `ProductAddExtraImageAction` by `ai_website_sale` did not account for this, and called `apply()` with a single image element instead of an array, causing a traceback. **Fix** In `aiSave`, wrap `imgEls` in an array before calling `apply()`. task-6263899
This update fixes an issue where adding the base unit price to product labels caused layout problems and data loss. The changes adjust the label templates to ensure all product information, including barcodes and references, are consistently displayed, improving the clarity and accuracy of product labels.
Original PR description
Commit 5407449491e91 adds the base_unit_price on the product labels. This addition messed up a bit the existing labels layout. And loosing some data, like the barcode text, some part of the product reference, ... This commit adjust the template to: 1.remove the base_unit_price from the 4x12 layout as there is too few room to put it 2. make the base_unit_price less important by cropping it in case there are not enough room for the price and the barcode. 3.swap the price and the extra html in the 2x7 to make sure the price is printed completely all the time Task: 5213917 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 streamlines spreadsheet document management by disabling versioning for spreadsheets and frozen spreadsheets. This reduces unnecessary data storage and improves performance when spreadsheets are created, copied, or edited, aligning with best practices for efficient data handling.
Original PR description
This PR consists of two commits. The first commit hides the Manage Versions action button for spreadsheet and frozen spreadsheet documents, since versioning is disabled for those records. The second commit is a backport of enterprise commit 0e319d0. It disables document versioning for spreadsheet and frozen spreadsheet documents, as spreadsheets already manage their history through spreadsheet revisions. This avoids creating unnecessary document history attachments when spreadsheet data is written or when a spreadsheet is copied. Task: [6236496](https://www.odoo.com/odoo/project/2328/tasks/6236496) Forward-Port-Of: odoo/enterprise#120013 Forward-Port-Of: odoo/enterprise#118484
This update fixes a potential issue where users could repeatedly click the 'release table' button while an order was being processed, leading to unintended actions. The change now blocks the UI during table unbooking and ensures a proper redirect, improving the user experience and preventing data inconsistencies.
Original PR description
When unbooking a table, the UI was not blocked, allowing the user to potentially spam the button or perform other actions while the order was being deleted. It also lacked a proper redirection. task-id: 5859460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246741
This update corrects a bug where products without lot/serial tracking incorrectly displayed expiration warnings. The fix ensures that products tracked by quantity don't trigger the expiration flow, aligning with intended usage. This prevents unnecessary alerts and simplifies product management.
Original PR description
A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity). The issue this causes is that it can open the expiration popup…
A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity). The issue this causes is that it can open the expiration popup since from saas-18.4 there is a line where if `ml.removal_date <= datetime.datetime.now()` the picking is expired. So, if the product previously met these conditions, it will still be able to enter this flow. And since this product doesn't use a lot_id it displays “You are going to deliver the product False, False which is expired or should at least be removed from stock” What should happen: When a product is not tracked, use_expiration_date should be False as expiration dates are intended to be managed through lots or serial numbers. Steps to reproduce 1. Enable Product Expiry. 2. Create a storable product with: - Tracking: By Lots - Use Expiration Date: enabled - Set a value greater than 0 for removal_time 3. Change the product tracking to By Quantity. 4. Create and validate a receipt for the product. Related Tickets: opw-6255673 Forward-Port-Of: odoo/odoo#268965 Forward-Port-Of: odoo/odoo#268135
This update resolves an issue where custom apps built with Odoo Studio were not displaying images alongside activity records. The fix now shows a placeholder icon when a module isn't found, ensuring consistent image representation for all activity types. This improves the user experience and visual clarity of activity records.
Original PR description
When creating an activity in a custom app made with studio, no image is shown, and instead the alt text is shown with a missing image. This fixes the issue by showing a placeholder icon if no module is found for the activity group. opw-6282451 Previous behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/a2cd6e7e-666f-434d-b849-3029835cc055" /> New behavior: <img width="1315" height="568" alt="image" src="https://github.com/user-attachments/assets/145cf519-5e4a-43f0-a5a1-cf4b4af75cb7" />
This update resolves an issue where unnecessary code was left behind during a recent port of a feature. The l10n_pe_reports module has been cleaned up, ensuring the system operates efficiently and accurately for Peruvian accounting reports. This fix improves the stability and performance of the Odoo Enterprise platform.
Original PR description
During the FW port of https://github.com/odoo/enterprise/pull/117891 We forgot to remove the unnecessary code opw-5978673 Forward-Port-Of: odoo/enterprise#120183
This update fixes an issue where custom product descriptions weren't appearing on manufacturing orders created from Point of Sale (POS) sales. The change ensures that all product descriptions, including those with 'always' attributes, are correctly displayed on manufacturing orders, regardless of their origin (POS or sale module).
Original PR description
**Steps to reproduce:** - Install pos_mrp - Make a BoM for a product - The product must have a custom attribute, of type always - Go to the PoS - Make a sale, with a customer, enable Ship Later - Go…
**Steps to reproduce:** - Install pos_mrp - Make a BoM for a product - The product must have a custom attribute, of type always - Go to the PoS - Make a sale, with a customer, enable Ship Later - Go to the created MO - The Custom Description field is not showing **Why the fix:** This fix was previously done by e53dae2 but it did not account for the other variants and only did the fix for the never attributes. This is because it seemed to work with other kinds of attributes until 19.0 We now also compute the move description if we have a custom attribute. We need the never variants to have a description as well, as it is done in the sale module. This commit basically aligns the behavior to the on done in the sale module. A test had to be changed, as we now write the description in a different way, to make it the same regardless of where the picking and moves were created from. We now won't see a difference on the MO between one created from the POS and one created through the sale module. opw-6169257 Forward-Port-Of: odoo/odoo#268713 Forward-Port-Of: odoo/odoo#263350
This update clarifies the 'via' information shown when a user signs a document on behalf of another. Previously, the display was inconsistent, but now it accurately reflects whether a user signed as themselves or on behalf of someone else, ensuring clearer record-keeping.
Original PR description
Before this commit, the signer status always displayed "On <date> via <sender>". Now the message only mentions "via <user>" when the document was actually signed by a different user (for example, when an admin is logged in and signs through a signer's link). When the signer uses their own link, only the date is shown. task-6216243 Forward-Port-Of: odoo/enterprise#117460