Daily updates from Odoo
Navigate
Branch
Friday, November 14, 2025
276 changes
12 changes
Enhancements to existing features
Product names and descriptions sent in India e-invoicing and e-waybill documents are now automatically shortened when they exceed the required character limits. This helps prevent submission errors and ensures generated JSON stays compliant with local rules.
Original PR description
Product descriptions in invoice lines must comply with character limits: - E-invoicing: maximum 300 characters - E-waybill: maximum 100 characters for both product names and descriptions Descriptions exceeding these limits are automatically truncated in the generated JSON. task-5061450 Forward-Port-Of: odoo/odoo#228549
Resolved issues and error corrections
This update corrects how shipping data is rounded before being sent to DHL. It prevents validation failures caused by tiny floating-point precision differences, so shipments with prices or weights like 11.43 or 0.3 are accepted reliably.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98913 Forward-Port-Of: odoo/enterprise#96012
This update ensures the first line of a bank statement is always identified correctly, even when certain values are set during creation or later updated. This prevents incorrect bank journal balances from appearing, improving the reliability of account balances.
Original PR description
Ensure proper computation of first_line_index when line.internal_index or line.state changes. Previously, the computation of first_line_index was grouped with the date computation. However, due to a specific ORM behavior, the compute method is not triggered when one of the computed fields (in this case, the date) is provided in the create values. As a result, first_line_index could remain falsy, leading to an incorrect balance in the bank journal. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235561
This change fixes a crash that could happen when checking which message was last seen by everyone in a discussion. It now uses a more reliable way to identify the current user’s member record, which prevents the error and makes the calculation more robust.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
This change ensures the system always sends the expected reconnecting and reconnect events when a websocket connection is lost unexpectedly, even if the closing handshake was incomplete. It improves the consistency of connection status updates and helps avoid intermittent failures in automated tests and live sessions.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This update removes the requirement to enter share capital for Italian companies that are not limited liability companies. It prevents unnecessary validation issues when setting up or updating company details, making the registration process smoother.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
This fix allows users to generate a debit note from an existing credit note in the Argentine localization. Before this change, the process failed with an error, which made it harder to correct invoicing mistakes after a credit note had been issued.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
This fix ensures submenu items in the hamburger menu automatically use the same font size as the header. As a result, when the header style is changed, the menu labels stay visually consistent and update correctly.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
This change fixes an issue where creating multiple journals of the same type could trigger a duplicate alias error. Odoo now checks all relevant aliases, even when no alias domain is configured, so journal creation works consistently.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233101 Forward-Port-Of: odoo/odoo#225537
The self-order IoT component now correctly reads newer image version numbers that use a full date format. This prevents version checks from failing and helps keep the device software update flow working smoothly.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This update corrects how scheduling intervals are combined so they are consistently normalized before use. It prevents mismatches and errors when different interval types are merged, improving the reliability of planning-related operations.
Original PR description
Note: >The `WorkIntervals` class has been removed, and the `keep_distinct` flag has been introduced in `18.4` to simplify its logic. For the following explanation, we will refer to an `Intervals`…
Note: >The `WorkIntervals` class has been removed, and the `keep_distinct` flag has been introduced in `18.4` to simplify its logic. For the following explanation, we will refer to an `Intervals` class with `keep_distinct = False` as 'Intervals', and to one with `keep_distinct = True` as 'WorkIntervals'. ## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#235133 Forward-Port-Of: odoo/odoo#234352
This fix restores employee selection for users who do not have full Employees access, especially in mobile and Studio-created fields. It ensures public employee information can be read correctly so search results appear instead of showing no records.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#234456 Forward-Port-Of: odoo/odoo#197575
10 changes
Enhancements to existing features
Product names and descriptions sent for Indian e-invoicing and e-waybill generation are now automatically shortened when they exceed the required character limits. This helps ensure the exported data stays valid and avoids failures when submitting documents to the authorities.
Original PR description
Product descriptions in invoice lines must comply with character limits: - E-invoicing: maximum 300 characters - E-waybill: maximum 100 characters for both product names and descriptions Descriptions exceeding these limits are automatically truncated in the generated JSON. task-5061450 Forward-Port-Of: odoo/odoo#228549
Resolved issues and error corrections
This update keeps long product attribute text inside the product card when browsing products in the sales catalog. It improves the appearance of the interface and prevents the layout from looking broken or misaligned.
Original PR description
**Steps to reproduce:** 1. Go to Products > Create a new product. 2. Add or create a new attribute and set a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
**Steps to reproduce:** 1. Go to Products > Create a new product. 2. Add or create a new attribute and set a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. **Issue:** - The attribute value text overflows outside the product card in the kanban view, causing layout misalignment and making the UI look broken. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/80ce5eb5-ba00-4545-a981-57f08889ab0f" /> **Cause:** - The inner <div> containing the attribute text did not have overflow control, allowing long text to exceed the card boundary. **Solution:** - Added the Bootstrap class overflow-hidden to the <div> to ensure the content stays within the container and prevents layout breakage. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/ae76186b-4ec9-410c-9ac4-99bdbd4b4493" /> **opw-5222002** Forward-Port-Of: odoo/odoo#234478
This change makes connection status notifications more consistent when a browser connection is lost unexpectedly. It ensures users and background services receive the full sequence of reconnecting and reconnect events, which helps avoid missed updates and reduces test failures.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This change prevents an error that could occur when the system checks which message was last seen by everyone in a conversation. It makes the check more reliable when some participant details are missing, improving chat stability for users.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
The website now hides mega menu links when the linked content is not visible to the visitor, both on desktop and mobile. This prevents users from seeing and opening empty menu entries, making the navigation cleaner and less confusing.
Original PR description
Before this commit, when setting the mega menu content visibility, the navbar link would still appear even if the user does not have access to the mega menu content. This commit hides the navbar link for the mega menu in the mobile and desktop view when the user does not have access to the mega menu content, in order to prevent unnecessary elements in the navbar. Steps to reproduce the bug: - Add a mega menu element in the navbar - Open the mega menu - Set the mega menu content visibility to conditional (logged in) - Open the website while logged out (The mega menu link is here but the content is not displayed. However, the dropdown is still opened but it is empty.) task-3992066 Forward-Port-Of: odoo/odoo#235289 Forward-Port-Of: odoo/odoo#179454
This update fixes the Italian e-invoicing setup so share capital is not forced for company types where it is not legally required. It prevents unnecessary validation errors and makes company registration details easier to complete correctly.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
We updated the self-order IoT component so it can correctly read the newer image version date format. This prevents version checks from failing and helps keep device updates working smoothly.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This change fixes the hamburger-style website menu so submenu labels inherit the header’s selected font size. As a result, when the navbar format is updated, the menu stays visually consistent with the rest of the header.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
This update lets users create a debit note from an existing credit note in the Argentine localization. It removes an error that blocked this correction flow, making it easier to reverse and adjust documents when a credit note was issued by mistake.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
This fix ensures that restaurant self-orders placed with online payment and “Pay After Meal” selected are sent to the kitchen display as expected. It prevents orders from being missed in preparation, helping staff start work on time and avoid service delays.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table Issue : Order Not coming in Preparation Display for (Pay-After-Meal) Online ---------------------------------------------------- Steps to Reproduce: 1. Open the Restaurant. 2. Place an order from the mobile self-order with “Pay After Meal” enabled. 3. Set online payment. 4. order does not appear in the kitchen display. Cause: - The system only sent paid orders to the kitchen, skipping pay-after-meal case. Fix: - Updated logic to send all orders to the kitchen when “Pay After Meal” is selected, --------------------------------------------------- Task-5106704 Related PR- https://github.com/odoo/odoo/pull/231005
4 changes
Resolved issues and error corrections
This update ensures browsers fetch the latest spreadsheet data instead of reusing an outdated cached version when a sheet is duplicated. As a result, duplicated tabs now show the most recent edits reliably.
Original PR description
It happens that browser may use a cache if there's no explicit cache control/expiration time: https://httpwg.org/specs/rfc9111.html#heuristic.freshness Steps to reproduce (non-deterministic): - create a new spreadsheet - do some changes, edit a few cells - right click on the tab and hit "Duplicate" => the spreadsheet is not up-to-date on the duplicated tab. The browser loaded the response from "disk cache" instead of fetching the latest data from the server. I'm using Chrom Version 142.0.7444.162 (Official Build) (64-bit) We add an explicit cache control.
Follow-up reminder emails now correctly send any attachments and dynamic reports configured on the email template. This ensures customers receive the full intended reminder message, without missing documents.
Original PR description
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the…
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the page "Content", add an attachment by clicking the "Attachments" button - Under the page "Settings", add a dynamic report - Create an overdue invoice for a partner - Go on the form view of the partner, "Accounting" page - Click "Send", make sure the template used is the one with the attachments - Send - The attachments on the template and the dynamic report are not sent ### Cause: The mail template to send the follow-ups is only used to prefill the wizard. ### Solution: Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments. This commit also refactors how the attachments are computed: The previous code was adding the invoices PDFs then removing them. The whole process was confusing. Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments depending on the options. opw-5147736 Forward-Port-Of: odoo/enterprise#98454
This update adjusts how self-order kiosk software reads image version numbers. It ensures newer date-based version formats are recognized correctly, preventing failures when checking for image updates.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This update corrects how fixed local taxes are shown in Mexico CFDI invoices. Previously, the tax rate could be multiplied by 100 in the XML, producing incorrect values; now the exported information matches the configured tax amount.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807 Forward-Port-Of: odoo/enterprise#98988
31 changes
Enhancements to existing features
The Indian localization now determines whether invoice lines are goods or services directly from the HSN code, reducing unnecessary mismatch warnings. Missing or invalid HSN codes will now block invoice reporting, helping businesses catch compliance issues earlier.
Original PR description
With this **PR**, we remove the warning about mismatches between HSN code and product type. From now on, the product type will be derived directly from the HSN code: if the HSN starts with '99', it will be considered a 'service'; otherwise, it will be treated as 'goods'. This simplifies the user experience by reducing unnecessary warnings. This will also cover cases where the product is service but the HSN is of goods for e.g. Job Work, Discount Line etc. Additionally, invalid/missing HSN on invoice line will now raise a blocking warning. **task**-5061450 Community PR - https://github.com/odoo/odoo/pull/227879 Forward-Port-Of: odoo/enterprise#95108
Point of Sale can now send refund requests to Six payment terminals when an order line has a negative amount. This helps stores process returns through the terminal more accurately and adds safeguards to avoid incorrect automatic refunds from invalid transaction data.
Original PR description
This PR adds the possibility to refund payments with Six terminals which use TIM (Till Integration Module) protocol. When the amount is negative on an order line in PoS, it will now request a refund instead of a payment on a Six terminal This PR also adds the reversals to Six terminals and adds a check for the `transactionType` field to make sure we don't automatically refund if we get invalid data in this field task-3619619
Kenya payroll is being updated so flexible benefit amounts are configured through salary rules instead of separate payroll input records. This makes payroll setup more consistent and prepares the benefits configuration for the newer salary-rule-based flow, with related test and demo data updates.
Original PR description
The main purpose is to adapt the flexible benefits system to use salary rules for its configuration. At this stage, it simply requires converting the payroll inputs into flexible salary rules. . Adapted the record in the hr_salary_rule_data that linked to payroll inputs to become salary rules with condition_select set to property_input. . Removed the obsolete records previously defined in hr.payslip.input.type and converted their purpose into corresponding salary rules in hr.salary.rule. . Modify the existing tests in test_salary_rules and updated demo data to correctly utilize the new salary rule codes for input creation task-5122338
Planning users will now see more readable names when selecting resources and sale order lines in dropdown fields. This makes it easier to identify the right resource or sales line quickly and reduces selection mistakes.
Original PR description
New formatting for M2X selection of: - Resource - Sale Order Line Improved display_name of Resource and Sale Order line in M2X dropdowns by applying formatted_display_name. task-4972325 Examples : <img width="509" height="459" alt="image" src="https://github.com/user-attachments/assets/6cfa9d8a-59d9-4db5-aa6f-812fe9599068" />
When a call activity is completed by placing a call, the related call record is now shown directly in the chatter. This makes it easier for users to review call details and keep communication history connected to the business record.
Original PR description
If a call activity is marked as done by placing a call, we will show the link to the voip.call record in the chatter. Task-5108217
A small display adjustment adds the missing spacing before record counts in account reports when many records are shown. This keeps the view cleaner and more consistent for users reviewing return checks.
Original PR description
To keep the view consistent and clean, we're adding the missing CSS class to the span displaying the records_count when it's more than 20. No task ID.
SEPA payroll payments can now be used without automatically installing the full Accounting app. This keeps Accounting optional while allowing businesses to use Payroll with the free Invoicing module, helping avoid unnecessary plan or pricing changes.
Original PR description
Purpose: Previously, installing Payroll with SEPA payments automatically installed the Accounting app through the `hr_payroll_account` dependency. This forced users out of the OAF plan and added a large module they might not need. This PR includes: - Removed dependency on `hr_payroll_account` from the SEPA Payroll module. - Added dependency on `hr_payroll` instead. - If Accounting is installed, SEPA continues to work as before. Result: With this change, SEPA payroll payments can now work with only the Invoicing module (which is free and doesn’t impact pricing). Accounting remains optional, if already installed, the behavior stays the same. task-5248512
The point-of-sale flow no longer uses a separate receipt screen and now continues through the feedback screen instead. This streamlines checkout while preserving existing receipt, invoicing, localization, IoT, restaurant, renting, settlement, and WhatsApp-related capabilities across affected POS modules.
Original PR description
pos*: l10n_at_pos, l10n_br_edi_pos, l10n_cd_edi_pos, l10n_de_pos_res_cert, l10n_it_pos, l10n_mx_edi_pos, l10n_pe_edi_pos, l10n_se_pos, pos_enterprise, pos_event_iot, pos_iot, pos_restaurant_preparation_display, pos_sale_stock_renting, pos_settle_due, whatsapp_pos This commit aims at removing the receipt screen and replacing it with the feedback screen. Of course, the feedback screen needs some adaptations done in this commit to keep every existing feature. task-id: 5149815 Community PR: https://github.com/odoo/odoo/pull/235316
Invoices and sales orders for Brazilian localization now show a clearer tax breakdown for each line, including tax name, amount, and percentage. This improves transparency for users and their customers, especially when taxes are calculated through Avalara.
Original PR description
*: l10n_br_edi, l10n_br_avatax, l10n_br_edi_sale, l10n_br_edi_pos Purpose: Display the tax breakdown of each line on invoices and sale orders, showing the tax name, tax amount, and tax percentage. This implementation will offer transparency to users and their customers alike. Additional changes: - Refactored duplicate logic to mixin since common methods were used across pos.order, sale.order, and account.move - Added _search_existing_tax so that taxes can be searched based on the response received from Avalara - Added l10n_br_tax_details compute to mixin - Extracted _l10n_br_call_avatax_taxes for pos.order and sale.order - l10n_br_edi_avatax_data should be a Json field and not be cleared task-5117824
Planning schedules now show every employee in a selected department when viewing shifts grouped by resource, including employees without assigned shifts. This makes it easier for managers to spot available people and assign work directly from the Gantt view.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Gantt view - Group by Resource - Search using a Department Now, allocated and unallocated employees are shown when grouping by resource and filtering by department. This helps in easily assigning shifts. task-4377548
Resolved issues and error corrections
Users can now clear the duration type in a Marketing Automation activity without triggering an error. This prevents campaign setup from being interrupted and keeps activity summaries stable when duration details are incomplete.
Original PR description
Currently, an error occurs when removing the interval type or validity duration type in a marketing automation activity. This happens when the system tries to compute the "Activity Summary", which…
Currently, an error occurs when removing the interval type or validity duration type in a marketing automation activity. This happens when the system tries to compute the "Activity Summary", which expects valid selection values but receives False. **Steps to Reproduce:** 1. Install Marketing Automation. 2. Create a new campaign and click on "**Add new activity**". 3. In the "Trigger" field, remove the duration (e.g., "Hours"). **Error:** `KeyError - False` **Cause:** At [1], it tries to get the label from the selection dictionary using the value of `interval_type` or `validity_duration_type`. When either field is `False`, it causes a KeyError. **Fix:** This commit prevents the error by; - Setting an empty summary when required selection values are missing. - Returning 0 for interval standardized when interval type is not set. [1] - https://github.com/odoo/enterprise/blob/bb92db89d3fc1f654dfdff9b2e334b13d81cb7ab/marketing_automation/models/marketing_activity.py#L228-L229 sentry-6957343166 Forward-Port-Of: odoo/enterprise#98367
This fixes an issue that could prevent U.S. Direct Deposit settings from being saved or read correctly after an internal platform change. It helps ensure company payroll direct deposit configuration continues to work as expected.
Original PR description
set_param/get_param don't exist anymore.
Fleet-specific tax reporting checks were moved into the Enterprise fleet accounting module where the required vehicle data is available. This prevents Community build failures while preserving the intended fleet tax reporting behavior for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#99380 Forward-Port-Of: odoo/enterprise#98650
Fixed an issue where Brazil AvaTax installations could fail if the Brazil EDI module was not installed. The tax calculation now uses its own country-code mapping, improving reliability for companies using AvaTax on its own.
Original PR description
Problem: When only l10n_br_avatax or l10n_br_avatax_sale are installed, an AttributeError gets thrown because the field, l10n_br_edi_code, is defined in the dependent module, l10n_br_edi. Solution: A mapping from the country to its EDI code is defined in the mixin so that the required information is still passed into the tax calculation request. This removes the need to use the field l10n_br_edi_code defined in l10n_br_edi. related PR: https://github.com/odoo/enterprise/pull/97845 runbot-build-error-233841
The self-ordering kiosk no longer relies on an outdated IoT Box image version check that cannot handle the newer date-based version format. This prevents supported IoT Boxes from being incorrectly blocked and keeps kiosk setup working with current images.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This fix makes the Sign document dropdown correctly detect when there are no documents to show. It prevents misleading or incorrect dropdown behavior for users working with signature requests.
Original PR description
An empty list is true in JS, so we check the length of the list Forward-Port-Of: odoo/enterprise#99405
Partial credit notes on subscription invoices now reduce the invoiced quantity only by the amount credited, instead of clearing it completely. This keeps subscription records accurate after partial refunds, helping teams avoid billing discrepancies and incorrect subscription status information.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#99326 Forward-Port-Of: odoo/enterprise#91344
This update fixes an access issue when the ISO 20022 accounting feature reads configuration settings. It helps ensure payment journal setup and related actions work reliably for users without requiring unnecessary administrator access.
Original PR description
Forward-Port-Of: odoo/enterprise#99359
This update restores the correct display and calculation of pending bank transactions in bank reconciliation. It fixes a missing template extension and ensures totals are fully calculated before being shown, helping users see accurate reconciliation information.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/1691a9d6ec426566b81537544cafe09d9c62ad78 We added a template to inherit BankRecKanbanRenderer, but we forgot to add the extension. By doing that it broke the pending transaction template override. Also this: https://github.com/odoo/enterprise/commit/5d5a7aca4f0abb4492314324631e8b5463a35332 change the getJournalTotalAmount to use a super instead, but it was missing an await otherwise we just have a promise no task id Forward-Port-Of: odoo/enterprise#99066
Payroll accounting localization packages now install automatically when the matching local payroll app is installed. This prevents missing salary journal settings, helping payroll structures work correctly without manual setup.
Original PR description
Bug: On a runbot, when installing a new loca, the structure doesn't have a salary journal. Cause: If you have hr_payroll_account, you then have payroll and accounting. Then let's say you install l10n_eg_hr_payroll, it will not automatically install l10n_eg_hr_payroll_account because it depends on l10n_eg which is not installed. So the field salary journal exists because of hr_payroll_account but is not populated by the l10n_eg_hr_payroll_account module. Fix: Change the autoinstall modules needed so that only the hr_payroll_account and l10n_xx_hr_payroll account are needed to autoinstall the l10n_xx_hr_payroll_account module. This will automatically install the corresponding l10n_xx module. Task: 5245980
This fix ensures the helpdesk livechat sidebar displays the correct channel name when a new member joins. It uses existing chat history when current participant details are incomplete, reducing confusion for support teams and visitors.
Original PR description
This change introduces the `im_livechat.channel.member.history` model on the client side to properly display the Livechat channel name. In the case of lacking data for current agents or visitors, we use the history records to display the channel name. task-4966319 Related to odoo/odoo#227240
Users can now ask the AI to filter and group records by dates in natural language, such as showing sales from last quarter grouped by month. The update also clarifies the feature as View Builder and improves how the AI interprets available search options, making results more accurate and easier to request.
Original PR description
This merge introduces comprehensive support for date-based filtering and grouping in AI-powered natural language queries, enabling users to express temporal constraints naturally (e.g., "show sales…
This merge introduces comprehensive support for date-based filtering and grouping in AI-powered natural language queries, enabling users to express temporal constraints naturally (e.g., "show sales from last quarter grouped by month"). Key features: - Date filter system supporting dynamic patterns (month+-N, year+-N), named quarters (first_quarter, etc.), and custom options from search views - Date groupby support with intervals (day/week/month/quarter/year) that can interleave with regular field groupbys - New compute_date tool for precise date calculations with sequential operations (navigate periods, find weekdays) and pinning, handling timezone conversions and edge cases automatically - Enhanced schema validation to support nested object types and anyOf for complex tool parameter structures - Renamed "Natural Language Search" to "View Builder" with clearer guidance on when to use View Builder (configure UI) vs Information Retrieval Code quality improvements (from review): - Extracted AI agent utility functions to separate module for better code organization - Reformatted search view representation from XML to markdown for improved LLM comprehension - Adjusted session context placement in prompts to reduce API issues TASK-ID: 5076645
This update corrects how Chilean electronic invoicing data is saved so the system uses the expected internal format. It helps prevent errors when updating accounting documents, improving reliability without changing day-to-day user workflows.
Original PR description
Write values should be normalized to use ORM commands, `list` and `int` instead of recordsets.
The accounting setup wizard now opens without immediately trying to save incomplete information. This prevents users from seeing an unnecessary required-field error when starting the setup process.
Original PR description
When creating the setup wizard, if created beforehand and shown to the user it will try to save when the wizard is opened. Since the opening date has no value and is a required field, it will fail and display the field red. To fix this, we are creating the wizard by passing a default company_id which mean the wizard hasn't been created yet and so it's not trying to save when opening the wizard. odoo/odoo#231956 odoo/enterprise#95760
This fix ensures older payments missing a required tracking ID can still be included in payment batches. When exporting payments, the system now creates the missing ID automatically, avoiding errors for companies with legacy data.
Original PR description
…ayments The migration script [1] for the end-to-end feature creates the `end_to_end_uuid` field even when `account_online_payment` is not installed. In such databases, the field is added but remains NULL for existing payments. If these legacy payments are later added to a batch, a traceback occurs because the batch logic assumes that `end_to_end_uuid` is always set [2]. This commit generates a UUID on the fly when exporting a payment whose `end_to_end_uuid` is empty, ensuring that batch creation works correctly even when `account_online_payment` was not installed. [1]: https://github.com/odoo/upgrade/blob/ed83d47b2aaa63113ea86ea83d1ca2c886f60063/migrations/account_iso20022/saas~18.5.1.0/pre-migrate.py#L10 [2]: https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/account_iso20022/models/account_journal.py#L289 no task-id Forward-Port-Of: odoo/enterprise#99364
Intrastat reports now use the region assigned to the relevant warehouse when one is available, instead of always falling back to the company default. This improves reporting accuracy for businesses operating warehouses in different regions, including sales, purchases, and point-of-sale flows.
Original PR description
* = stock_intrastat_{pos,purchase_stock,sale_stock}
This commit changes the intrastat report to use the warehouse intrastat
region on moves that has a warehouse intrastat region. Previously, the
region applied was the default one in the company's configuration. The
report's query and domain were modified to take into account the warehouse
region if the move has a warehouse intrastat region.
3 new bridge modules were created with pos, purchase stock, and sale stock.
Each bridge module adds the necessary query join and domain to get the region code.
task-5135764The bank reconciliation screen now uses the remaining unpaid amount when adding partially reconciled invoices or bills. This prevents incorrect payment amounts from appearing and helps accounting teams reconcile bank transactions accurately.
Original PR description
A mistake in 0051b2e1cc12112767acb60a451b0c0b40ab9358 made the bank rec widget use the total currency amount instead of the residual currency amount, which lead to incorrect amounts when adding an invoice/bill line that was previously partially reconciled.
This fixes a timing issue in batch barcode scanning that could cause some scan processing to finish out of order or be skipped in certain cases. The change improves reliability for warehouse workflows and prevents intermittent failures when scanning lots in batch pickings.
Original PR description
Commit bc9247d46225c696842bc7b0e3c883320231ab1b has introduced an override of the `processBarcode` method. However, it does not return nor await the super call. In particular, in the case where the super call should be done the overrides returns "undefine" rather than a promess to await and hence that call is not awaited anymore. Note: This error has been noticed from the fact that the test `test_barcode_batch_scan_lots` sometimes fails on step 29/31. runbot-233631 Forward-Port-Of: odoo/enterprise#99303
Report variants that are limited by country are shown correctly again when foreign VAT is not allowed. This restores access to the appropriate accounting reports for companies operating under those local rules.
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/13b28f789e0b1d9c3e266a99aae65c48bb6ce8b6, no variants with the availability condition set to country and not allowing foreign vat were displayed anymore. Forward-Port-Of: odoo/enterprise#99379
Code cleanup and technical improvements
The social push notification feature was updated behind the scenes to use Odoo’s newer frontend framework. This helps reduce reliance on older technology, improving maintainability while keeping the user experience largely unchanged.
Original PR description
In order to remove publicWidgets and jQuery from the frontend, this commit continue the conversion of public widgets to interactions.
This update modernizes how automated tests look for exact text in several Odoo Enterprise areas. It keeps test behavior the same while making the test code easier to read and maintain, reducing future maintenance effort.
Original PR description
This commit replaces all found occurrences where ':contains' (with an exact match regular expression) could be replaced by ':text'. Community: https://github.com/odoo/odoo/pull/234331 Forward-Port-Of: odoo/enterprise#99330 Forward-Port-Of: odoo/enterprise#98772
29 changes
Enhancements to existing features
This update switches several test checks to a more precise text-matching method. It helps make automated tests clearer and more reliable without changing how the product works for users.
Original PR description
This commit replaces all found occurrences where ':contains' (with an exact match regular expression) could be replaced by ':text'. Community: https://github.com/odoo/odoo/pull/234331 Forward-Port-Of: odoo/enterprise#99272 Forward-Port-Of: odoo/enterprise#98772
This change clears the blackbox processing queue whenever point-of-sale data is reloaded. It helps prevent rare situations where queued requests could keep repeating and cause the POS to become unresponsive.
Original PR description
This commit adds a clear of the blackbox queue when reloading data. This could avoid potential unexpected deadloop of calls in the queue. Forward-Port-Of: odoo/enterprise#99252
This update adds a new exact-text selector for automated UI tests, making test expressions easier to read and write. It also updates existing tests to use the clearer form, which improves maintainability without changing business behavior.
Original PR description
This commit adds the ':text()' pseudo-class to the list of supported pseudo-classes in Hoot selectors. Its purpose is the same as ':contains()', with the specificity of being an *exact* match instead of a *partial* one. It effectively replaces ':contains(/^<expression>$/)' by ':text(<expression>)', improving the readability and making the developer experience a bit nicer. Enterprise: https://github.com/odoo/enterprise/pull/98772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235295 Forward-Port-Of: odoo/odoo#234331
This change removes the need for the Sign app to be installed for the accountant knowledge features to work. It simplifies setup and reduces unnecessary dependency between products, while keeping the related templates and embedded signature elements available where needed.
Original PR description
task-5154292
Resolved issues and error corrections
This change moves a fleet-related tax report test and its query logic out of the community edition and into the enterprise module where the required vehicle data is available. It resolves a build failure in the community version while preserving the intended fleet reporting behavior for enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/odoo#235339 Forward-Port-Of: odoo/odoo#234095
The Discuss sidebar now shows the right status icon for call participants when they are muted or have deafen enabled. This fixes a confusing display issue so users can quickly understand each participant’s actual call state.
Original PR description
Before this commit, discuss sidebar call participants had wrong status shown, e.g. when participants are muted it shows non-slashed mic icon instead of slashed mic icon. Steps to reproduce: - Start a call without being muted or deafen - Have another person join the call and mute or deafen => icon shows unslashed mic or headphone This happens because the slash variants were coupled with active button state of call actions, so was based on current session rather than target session. This commit fixes the issue by using specific mute and deafen icon when session is either muted or deafen. Before <img width="1277" height="406" alt="Screenshot 2025-11-13 at 12 20 08" src="https://github.com/user-attachments/assets/c570d0a4-0ab6-48d8-bab6-b191531b2cb6" /> After <img width="1276" height="397" alt="Screenshot 2025-11-13 at 12 19 44" src="https://github.com/user-attachments/assets/2d69e942-7726-4c8c-8921-7635df47dc85" />
This fix prevents a front-end error that could happen when a pro forma is sent for an order that was deleted while the request was still being processed. The system now checks that the order still exists before using it, which avoids interruptions and makes the point of sale more reliable.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback. Forward-Port-Of: odoo/enterprise#99248
Message action icons in chat and message views are now larger and easier to read, while using less horizontal space overall. Hover feedback is also more visible, making the controls easier to notice and use in both light and dark modes.
Original PR description
1) increase size, reduce gap Make icons more readable by being bigger. The gap is reduced so overall this actually takes slightly less horizontal area. 2) More visible hover effect Hover effect was…
1) increase size, reduce gap Make icons more readable by being bigger. The gap is reduced so overall this actually takes slightly less horizontal area. 2) More visible hover effect Hover effect was inexistent due to typo in chat window style leaking to message actions, but still the hover effect was to shy, with 75% => 100% opacity. This is increased to 50% => 100% in addition to true black/white on 100%. Before / After (white) <img width="716" height="128" alt="white-before" src="https://github.com/user-attachments/assets/3829b7cb-8e36-4f28-8d20-78ef9aa31a97" /> <img width="723" height="128" alt="white-after" src="https://github.com/user-attachments/assets/79ec373a-c847-4c8a-96da-4582b54bb393" /> Before / After (dark) <img width="717" height="127" alt="dark-before" src="https://github.com/user-attachments/assets/cdaddee6-8025-46c3-a50b-9c85f9108887" /> <img width="716" height="123" alt="dark-after" src="https://github.com/user-attachments/assets/ddd712b0-407b-427b-b4c6-e3d615b91c27" />
This change prevents tracking from crashing when related records do not have a display name. Instead of showing an error, the system now falls back to a safe default, matching the behavior used in similar cases. This improves reliability for users working with tracked one-to-many and many-to-many fields.
Original PR description
Description of the issue/feature this PR addresses: Addresses: https://github.com/odoo/odoo/issues/178883 Same issue is also in 18.0. Is there a separate PR necessary or will this be ported forward? Current behavior before PR: An error is displayed when tracking is activated on one2many and many2many with records without display_name. Desired behavior after PR is merged: Should not crash and use fallback like in other cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214121
Fixed an issue where opening certain dropdowns on the website could accidentally trigger a page reload in some browsers. This improves the experience for visitors and editors by preventing the page from refreshing before a selection is made.
Original PR description
In some browsers, opening a `<select>` triggers a click event. Because of this when the blog's sidebar "Archive" dropdown is opened, it might reload the page before the selection is actually made. This commit solves this by detecting a distinct event when PostLink is activated on `<select>` element. Steps to reproduce: - Using Firefox - Install `website_blog` - Edit the blogs page - Activate the sidebar - Save - Open the "Archive" dropdown => The page was reloaded Forward-Port-Of: odoo/odoo#233202
The fleet tax reporting test and related query were moved into the Enterprise edition, where the required vehicle-linked data is available. This fixes community build failures while keeping the intended fleet reporting behavior available for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#99288 Forward-Port-Of: odoo/enterprise#98650
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#98892 Forward-Port-Of: odoo/enterprise#91344
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund. 4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines. 5. Check the *Tax Report*(account>tax), including the date of this vendor bill. **Obs
Original PR description
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50%…
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund. 4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines. 5. Check the *Tax Report*(account>tax), including the date of this vendor bill. **Observed behavior:** * Tax lines linked to the current asset account are merged. * Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`). * This mismatch triggers an error in the tax report. **Root cause:** The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles. **Solution:** Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error. opw-5013757 Forward-Port-Of: odoo/odoo#232001 Forward-Port-Of: odoo/odoo#228422
This change allows outstanding accounts to be created even when a company does not use a standard chart template. It helps businesses with manually configured accounting setups avoid errors and continue processing expenses normally.
Original PR description
The creation of outstanding accounts when fallback should not require a chart template, since companies may have manually configured their chart of accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when creating a new branch in Indian databases that do not yet have newly introduced taxes. It ensures the correct fiscal mappings are created for both intra-state and inter-state cases, avoiding failures during setup.
Original PR description
In cases, where new taxes are introduced in stable, and for the fiscal mapping are added as well. But for existing dbs, the new tax might not be available and when creating new branch it might lead to traceback because, we create new fiscals for intrastate and interstate --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents a permissions error that could stop sales orders from being confirmed in branch-company setups, especially when dropshipping is enabled. It ensures Odoo checks company-related taxes in a safer way so users only see records they are allowed to access.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a…
Versions -------- - saas-18.4+ Steps ----- 1. Create a branch company B; 2. create a branch C for the branch company B; 3. change to branch C; 4. create a warehouse; 5. enable dropshipping; 6. add a vendor to a stored product with the Dropship route enabled; 7. log in as a sales user with access to branch C only; 8. add product to a sales order & confirm. Issue ----- > Access Error > Uh-oh! Looks like you have stumbled upon some top-secret records. > Sorry, Marc Demo (id=5) doesn't have 'read' access to: > - Companies, YourBranch (res.company: 3) Cause ----- The error gets thrown during the `_prepare_purchase_order_line` method, specifically on the line which filters `supplier_taxes_id` using `lambda x: x.company_id in company_id.parent_ids`. This passes via the field's `convert_to_record` method, which attempts to access the `active` field of the companies to filter out any that are archived[^1]. [^1]: https://github.com/odoo/odoo/blob/5b911a97a3885283d2f21ac30abb96cb10fe39d9/odoo/orm/fields_relational.py#L608-L612 In previous versions, this wasn't an issue, because the `active` field was still present in cache from the `_compute_parent_ids` which is called with `sudo`, but as of saas-18.4, it attempts to refetch these values, leading to the error. Solution -------- Instead of using `filtered`, use `filtered_domain` using the result of `account.tax._get_company_domain`. opw-5112625 Forward-Port-Of: odoo/odoo#231743
When opening a project from a sales order, the system now automatically focuses on the tasks linked to that specific sales order. This prevents users from first seeing unrelated tasks from the same project, making it easier to find the information they need.
Original PR description
Before this commit, when the user clicks on x projects and x tasks stat button in the sale order form view and that SO is linked to some task and more than one project, the user will be redirected in kanban view of projects and when he will click on a project, he will see all tasks linked to that project instead of seeing the tasks linked to SO inside that project. This commit makes sure a default search is added in the tasks views when the user open a project from an SO to be sure the user will first see the tasks linked to that SO.
This change prevents the chat system from crashing in cases where a member’s profile information is missing. It now uses a more reliable way to identify the current user’s member record, which keeps message tracking working correctly.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
This change prevents the website editor from crashing when it encounters an empty row. It adds a safeguard so the editor skips checks that require columns when none are present, improving stability during page editing.
Original PR description
When a .row div was empty, the _areColsCustomized function was called with an empty HTMLCollection. This caused a traceback when the function tried to access columnEls[0]. This commit adds a safety check to _getNbColumns for avoiding extra calls to _areColsCustomized when columnEls is empty. And we also add a similar check to _areColsCustomized for safety, since it's also being called through the _computeWidgetVisibility. opw-5121738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235555
Opening some activity items from the Activities calendar could fail when the system did not provide enough information to display the record. This fix adds a safe fallback so the correct form view opens instead of showing an error, improving reliability for users.
Original PR description
When opening certain activity items from the Activity Calendar popover,
the backend returns an `ir.actions.act_window` result missing the `views` key.
The frontend attempted to call:
action.views.map(...)
which caused:
TypeError: Cannot read properties of undefined (reading 'map')
This patch adds a safe fallback:
if (!action.views) action.views = [[false, "form"]];
so that the action always has a valid view, preventing a crash and maintaining expected behavior.
Steps to reproduce:
- Go to Activities → Calendar
- Click on different activity items
- Click the "View" button
- JS error occurs for some items
After applying this fix, affected actions open a fallback form view instead of crashing.
This issue also occurs on official demo (demo.odoo.com).This update fixes the Italian e-invoicing setup so share capital is not forced for company types that do not need it. It helps businesses complete their company information more accurately and avoids unnecessary validation errors.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
Saudi invoices could incorrectly show no tax on invoice lines when a Saudi customer was selected. This fix restores the expected tax behavior so invoices calculate and display taxes properly for Saudi Arabia setups.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882 Forward-Port-Of: odoo/odoo#234387
This update fixes two issues in mailing messages: an extra blank paragraph could be added in the email content, and some opened messages could keep expanding the page indefinitely. It improves the reliability of the email editor and makes saved mailings display correctly in read-only view.
Original PR description
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content…
This [commit] introduced 2 issues in `mass_mailing`: - when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content should be enclosed inside the `o_layout` block. - when sending such an email (with the wrong paragraph) and consulting the readonly value in the `mass_mailing` Form view, the view started growing indefinitely. How to reproduce: - create a mailing using the basic editor and send the email - open the mailing in readonly Issues: - there is a paragraph outside the `o_layout` element in the DOM - the page scrolls indefinitely because `o_layout` has `min-height: 100%`. Resolution: - don't force `o_layout` to have a `min-height`, which will prevent the infinite scrolling for mailing that were sent with a wrongly placed paragraph. - configure the mailing so that the editable element has `contenteditable="false"`, and the element with `o_mail_no_options` coming from the basic template gets `contenteditable="true"` so that the editor is informed that the user is only allowed to edit the content of that node, not the outside of it, which will prevent the empty paragraph insertion. [commit]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d task-5263045
The signing process test now runs with a regular user instead of only an administrator, which helps catch permission-related mistakes that were previously missed. This prevents a signing error from slipping through when a salesperson field points to the wrong user and a customer tries to sign a document.
Original PR description
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard. The issue is that, on the model `res.partner`, the field `user_id` is the…
By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.
When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.
A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:
On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.
You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
Operation: read
User: 5
Groups: allowed for groups 'Role / Administrator'This change ensures the system consistently reports when a WebSocket connection is lost and then recovered, even in a rare edge case where the closing process was incomplete. It helps keep connection status events accurate and also resolves an intermittent test failure in the background service.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This change fixes an issue in the Argentine localization where users could not generate a debit note from an existing credit note. It now lets businesses correct mistakes more smoothly by creating the proper reversing document without encountering an error.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
The hamburger-style website menu now inherits the font size set for the header, so submenu labels stay consistent after you change the navbar format. This fixes a display issue where submenu text could remain at the wrong size and not match the chosen header style.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
Documentation and clarification updates
This change records Raj Gohel’s Contributor License Agreement signature so future contributions can be accepted in Odoo. It is an administrative update with no direct impact on business operations or users.
Original PR description
This commit adds my Individual Contributor License Agreement (CLA) signature. Signed, Raj Gohel <rajgohel2018@gmail.com> https://github.com/Rajgohel0312 This CLA is required to validate my future contributions to Odoo.
12 changes
Enhancements to existing features
This update adds the India country marker to several accounting tags used in the local chart of accounts. It makes these tags easier to organize and helps them work more reliably in other reporting and grouping scenarios.
Original PR description
Some account tags specific to India were missing the `country_id`. With this PR, the `country_id` is added to those tags, enabling easier group by and making them usable for other cases also. Forward-Port-Of: odoo/odoo#235424
Resolved issues and error corrections
When a helpdesk refund is created from a sales order, the credit note now contains only the product that was actually selected for refund. This also improves the product dropdown so users only see products related to the original sales order, reducing mistakes and unnecessary corrections.
Original PR description
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we…
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund. Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO. ## Reproduction Steps 1. Create a SO containing 2 different products and confirm it. 2. Create a regular invoice and confirm. 3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams. 4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds". 5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned. 6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund. 7. Click on reverse. ### Expected behavior A credit note containing only the specified product to refund should be created. ### Unexpected behavior The created credit note contains both products originally present on the SO. ## Origin of the issue When issuing a refund from helpdesk_stock_account, this piece of code is called: https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17 which calls the ```reverse_moves``` method in the helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on. Finally, we arrive in the account_move.py file. In the ```_reverse_moves``` of this file, we can see the code: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947 where we simply copy all the lines of the move in the SO without filtering them. As a result, we get the lines of the product we don't want to refund __ opw-5148789
This fix stops a crash that could happen when a user tried to edit a configurable product on a quotation after removing its name. The edit option now only appears when it is actually valid, preventing the error and avoiding a broken user experience.
Original PR description
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** -…
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** - Install Sales module - Create a Quotation - Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**. **Error:** `TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()` `missing 1 required positional argument: 'product_template_id'` **Root Cause:** When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered. [1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13 **Solution:** This commit prevents the error by correcting `depends` on the field `is_configurable_product`, which will ensure that edit button will be only present if the configurable product is selected. Sentry-5741581459, 6925770690
This update fixes the product catalog kanban layout so long attribute labels no longer stretch the card and push images outside the visible area. It keeps the design tidy and consistent, improving the browsing experience for users viewing products.
Original PR description
With these changes, we ensure that the images will always stay within the kanban card, for example, when there’s an attribute that’s too long. Before these changes, when an attribute was too long, it was expanding the size of its container and, as a result, pushing the images out of the kanban card. <img width="1548" height="357" alt="image" src="https://github.com/user-attachments/assets/1661cf6a-6ff7-4ca9-9835-896806734b5e" /> After these changes, the content adjusts to the size of the kanban by applying the overflow: hidden property used by the badge elements. <img width="1587" height="507" alt="image" src="https://github.com/user-attachments/assets/9bccfe27-1fdb-4093-ad34-82140deab76d" /> cc @Tecnativa TT58797 ping @pedrobaeza @carlosdauden --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents long product attribute text from spilling outside product cards in the catalog view. It keeps the layout aligned and makes the product selection screen easier to read and use.
Original PR description
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. Issue: - The product image and attribute value text overflow outside the product card in the kanban view, causing layout misalignment and breaking the UI design. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/afc592bb-e25a-4d81-882b-0e7cc7ad1064" /> Cause: - The inner div containing the attribute text lacked overflow control, allowing long text to exceed the container width and pushing other elements. Solution: - Added the Bootstrap class `overflow-hidden` to the div element to ensure the image and text remain properly contained within the card layout. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/580ce1e5-42bd-4c2d-b6bf-14315759626d" /> opw-5222002
This update makes the description field on eWaybill stock records read-only. It helps prevent accidental changes and keeps the information consistent once it has been entered.
Original PR description
This **PR** makes the description on ewaybill stock readonly. ref - https://github.com/odoo/odoo/pull/228548/commits/285fffe6b0c90b9e37815cb4064b0108a5e8e6ac Forward-Port-Of: odoo/odoo#235456
This update prevents duplicate fiscal country codes from being stored on customer and partner records when the country matches the company’s country. It avoids a display issue in the partner form and keeps the data cleaner without changing expected business behavior.
Original PR description
Recently we started considering `country_code` as part of the `fiscal_country_codes` [1]. Because of this, the field can now contain duplicates. If your active company is a US one, and you set United States as the country on the partner you end up with `US,US`. It breaks some (admittedly fragile) invisible conditions on the `res.partner` form view [2]. Although we could fix those conditions, it would require everyone to update the module, and having duplicate country codes in `fiscal_country_codes` field doesn't serve any purpose anyway. [1] https://github.com/odoo/odoo/pull/229584 [2] https://github.com/odoo/enterprise/pull/62615 opw-5248844 opw-5241556
This update fixes two issues in website editing: one where deleting a replaced image could block saving, and another where using the browser Back button could leave the editor in an error state. It helps users safely discard or save changes without the page getting stuck or showing unexpected errors.
Original PR description
\* : website, web_editor, html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the…
\* : website, web_editor, html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`. Expected behaviour: - Saving should be allowed with a default image, that is similar to other images. This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck. Commit [2]: resolve traceback when leaving edit mode via browser Steps to reproduce: 1. Go to Website > Edit. 2. Open the snippet modal and select any snippet. 3. Press the 'Back' button in your browser. 4. A dialog will appear asking to discard changes; click 'OK'. 5. A traceback error occurs, and an empty space appears in the editor. Issue: - Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange. - Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener. - As a result, the editor is left in an unstable state, causing a traceback error. Solution: - This commit ensures the 'window' event executes before the browser event. - It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser. task-4570164
This update corrects the Italian EDI company settings so share capital is only required for limited liability companies. It avoids unnecessary validation errors for other company types when completing business information.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
This change makes certain report attachments available as local files instead of remote links when they need to be processed later, such as images added from the chatter. It helps prevent broken or unmanageable attachments in reports while also avoiding unsafe access to untrusted links.
Original PR description
During commit #226094, several methods were added to allow fetching remote resources for certain reports. After that commit, we notice that some attachments (like images -> image_src) must need the file localy. To avoid this issue we decided to convert this documents from remote to localy (binary), to be able to manage them. It'll just happen for the reports that need to add attachments from the chatter. OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to refuse a validated leave allocation when there are already approved leaves in the same period. Before this change, the system could wrongly treat those existing leaves as if they belonged to the new allocation, blocking the refusal with an error message.
Original PR description
## Issue: When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later A…
## Issue: When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later A UserError was raised asking to remove the leave even if it should be linked to the first allocation created ## Cause: The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves The leaves will be allocated to the last allocation created, so the last one can't be removed later As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation ## Steps to reproduce: - Create an initial Allocation (that should end after the next created Allocation) - Create a Leave from 22/12/2025 to 31/12/2025 - Create an Allocation including the leave period (01/12/2025 to 31/12/2025) - Validate, then Refuse opw-4900686 Forward-Port-Of: odoo/odoo#222171
This fix prevents subscription invoicing from failing when a previously invoiced order line has been deleted. It keeps invoice generation working normally, including the earlier partial credit note behavior, so customers can continue billing without errors.
Original PR description
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video:…
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view **Steps to Reproduce** 1. Create and confirm a subscription with a recurring product (e.g., Car Leasing) 2. Generate and post the invoice for the subscription 3. Add a new product line to the subscription (e.g., Office Cleaning Service) 4. Delete the original invoiced line (Car Leasing) 5. Attempt to create an invoice for the new product line → Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category." (https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view) **Root Cause** Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation. **Fix** Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation.
2 changes
Resolved issues and error corrections
This fix restores placeholder text in the Related Company field and similar partner autocomplete fields. It helps users understand what information is expected when creating or editing contacts, improving the clarity of the form.
Original PR description
**Issue:** Fields using the res_partner_many2one widget with a placeholder do not display the placeholder text. **Steps to reproduce:** 1. Install `contacts` module 2. Go to Contacts 3. Create new 'Individual' contact 4. Notice just below the name, Related Company field placeholder is not visible. **Cause:** Props are not passed correctly in PartnerAutoComplete component **Solution:** Use the correct prop reference (props.placeholder) when passing the placeholder to the PartnerAutoComplete component, ensuring it is properly rendered. opw-5153125
Documentation and clarification updates
This change updates Vauxoo’s contributor agreement record to include Jonathan Osorio Alcala as an approved contributor. It is an administrative/legal update and does not affect product functionality.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr