Daily updates from Odoo
Tuesday, July 15, 2025
53 changes
10 changes
Resolved issues and error corrections
Restores a missing receipt registration flow for Belgian POS blackbox setups. This ensures kiosk transactions send the required blackbox response back to the server, preventing receipt handling issues in those flows.
Original PR description
- In this commit (f5cea73183c0a25039b44e8a16341095431de029), the `registerReceiptWeb` action was removed from the `pos_blackbox_be` module. This action was useful to call `registerReceipt` and then call `send_blackbox_response`. - This commit restores the `registerReceiptWeb` action in the `BlackBoxDriver`, ensuring that when calling it, we send the blackbox response to the server (which is used for Kiosk flows). task-id: 4901299
View-only users can no longer see or use the PDF split option in Documents. This prevents a confusing error when shared PDF links are opened by users without editing rights, making document sharing smoother and clearer.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451 Forward-Port-Of: odoo/enterprise#89692 Forward-Port-Of: odoo/enterprise#75803
This fixes how the Belgian POS blackbox reads status information from serial-connected fiscal devices. It helps prevent incorrect responses from blocking or disrupting point-of-sale fiscal operations.
Original PR description
As serial drivers use a different way of providing status, we need to check for the right value in the blackbox response. Community PR: odoo/odoo#218203
Belgian POS receipts now show required certification information more clearly, including whether a ticket is valid and whether the sale is a refund. Duplicate date and address details were removed because they are already shown elsewhere on the receipt, keeping receipts compliant and easier to read.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 community PR: https://github.com/odoo/odoo/pull/214394 Forward-Port-Of: odoo/enterprise#87759
When assets are migrated into Odoo with depreciation already recorded in a previous system, Odoo now includes that imported amount in depreciation totals and reports. This gives businesses accurate asset values and depreciation schedules after migration, avoiding understated cumulative depreciation.
Original PR description
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration).…
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration). This depreciation is recorded in each account when starting in Odoo(the original balances) and in Odoo creating Journal Entries are skipped for this imported depreciated amount. Example:- - Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020, Method: Straight Line, Duration: 10 Years, Computation: No Prorata. - Now according to our computation this asset will depreciate \$1000.00 for the years 2020 to 2029 each, and Journal Entries would be created on 31st December each year. - Now someone migrating from other software to Odoo in the year 2025 will put Depreciated Amount: \$5,000.00 . - Now Odoo will create Journal Entries for only years 2025 to 2029 and skip creating Journal Entries for the years 2020 to 2024 as these entries are created in previous accounting package and are recorded in original balances while migrating. Before this commit:- - In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported depreciated amount. - Depreciation Schedule report displays constant \$5,000.00 as depreciated value for the years 2020 to 2024. After this commit:- - In Depreciation Board, imported depreciated amount is added in Cumulative Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till \$10,000.00 for the year 2029. - In Depreciation Schedule Report, `_simulate_imported_depreciation` method will modify report values to simulated imported depreciation amount and skipped Journal Entries. task-4864528 Forward-Port-Of: odoo/enterprise#90214 Forward-Port-Of: odoo/enterprise#88127
This fix ensures that Peruvian point-of-sale refunds for invoiced orders show the required reason dialog before continuing. It prevents staff from being sent to the wrong screen and helps keep the refund flow compliant and consistent.
Original PR description
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in…
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in navbar) - select the previously completed order, apply for refund Observation: you are navigated to Order screen Expectation: A dialog for reason should be open first Issue - after this commit odoo/odoo@3a09ea7 and odoo/enterprise@e3e84bb account_move field is used instead of `invoiced` state of order. But the `account_move` field is always undefined. This is due to fact that when pos_order is fulfilled from `syncAllOrders` function, a call to `missingRecursive` is made, as `account.move` model is never loaded, it is unable to link it to appropriate model and results to undefined Fix - use `order.raw.account_move` instead of `order.account_move` Note: `account.move` is loaded from saas-18.3 by https://github.com/odoo/odoo/pull/201528 opw-4744785 Forward-Port-Of: odoo/enterprise#87283
This update prevents users from deleting or changing key activity types that several business workflows rely on, such as calls, approvals, tax closing, bank synchronization, payroll deferrals, and document uploads. It also makes related processes more resilient when activity types are missing, reducing crashes and workflow interruptions across apps.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#90117
Forward-Port-Of: odoo/enterprise#58164Rental combo products now correctly show available rental dates when stock restrictions apply. This prevents customers from seeing every date as unavailable, reducing blocked online rental sales and customer confusion.
Original PR description
Issue: - Create a rental product (with a rental pricing), - Make it storable and don't allow out-of-stock orders, - Now make it a combo product, - Add a rental combo choice (to be able to save it), - Go to the product's page on eCommerce, - Issue: all dates are unavailable. Cause: The date range picker only relies on `allow_out_of_stock_order` to know whether to compute rental availabilities (but not on `is_storable`). Fix: Also rely on `is_storable` to know whether to compute rental availabilities. opw-4846084 Forward-Port-Of: odoo/enterprise#90116 Forward-Port-Of: odoo/enterprise#90084
This fix ensures Hong Kong payroll HSBC Autopay files use the same rounded payment amounts shown on payslips. It prevents rare discrepancies between employee payroll records and bank payment files, reducing reconciliation issues.
Original PR description
Explanation: In some rare cases, the autopay amount in payslip and the amount in hsbc autopay file doesn't match. This is due to hsbc autopay files are trimming all the decimal places, and the amount in payslip are rounded. Forward-Port-Of: odoo/enterprise#89118
This update fixes a translation-related warning that could occur when checking addresses in the AvaTax integration. It improves reliability for users working in translated environments without changing business workflows.
Original PR description
Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. We replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-159883 Forward-Port-Of: odoo/enterprise#88651
10 changes
Resolved issues and error corrections
This fixes issues where cash rounding amounts were not handled correctly in Colombian electronic invoice files. It helps ensure tax totals and official UBL documents remain accurate when invoices include cash rounding.
Original PR description
#### [FIX] l10n_co_dian: UBL related cash rounding issues In the community PR the UBL XML generation was adjusted to support cash rounding. (See there for more details) This commit adjusts the code in `l10n_co_dian` to be compatible. #### [FIX] l10_co_edi: tax_amls include rounding lines Currently rounding lines (with taxes) are not included in the tax lines. This is fixed in this commit. See the community PR / commits for motivation. #### info task-4854592 Forward-Port-Of: odoo/enterprise#90017 Forward-Port-Of: odoo/enterprise#89439
Address validation in AvaTax could trigger translation warnings because the system could not reliably determine the user language in this case. The fix updates how translated text is handled, making AvaTax address checks more stable without changing business workflows.
Original PR description
Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. We replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-159883 Forward-Port-Of: odoo/enterprise#88651
This fixes rare cases where Hong Kong payroll payslip amounts did not match the HSBC autopay file because decimals were handled differently. The autopay export now aligns with the payslip rounding, reducing payment reconciliation issues.
Original PR description
Explanation: In some rare cases, the autopay amount in payslip and the amount in hsbc autopay file doesn't match. This is due to hsbc autopay files are trimming all the decimal places, and the amount in payslip are rounded. Forward-Port-Of: odoo/enterprise#89118
The Field Service product availability check no longer triggers an error when opened from a task's product list. This helps service teams reliably view product forecasts before planning or confirming work.
Original PR description
-master Steps to reproduce: - Open Field Service app - Select any task in app - Click on Products stat button on the top - Click on overflow menu of any product and click on Check Availability option Issue: - When you press on the Check Availability option an Odoo error is thrown. Cause: - The cause is that when we are trying to set the context into our action we are having a Type Error because the context available which should of empty Dictionary is of type String. - Because of this when we use update method which is exclusive for sets and dictionaries throws that update method cant be used on a string. Solution: - Rather than using the update method we can replace the context in the action because we always receive a empty context from the super call and we need fill the context so that it shows the product forecast. task-3707563
Unused code from an earlier spreadsheet version history approach was removed after the feature was refactored. This reduces maintenance risk without changing how users access or use version history.
Original PR description
Some leftover code was left from when we refactored the version history feature to load a new model instead of using undo/redo for the revisions. Task: [4942548](https://www.odoo.com/odoo/2328/tasks/4942548)
Helpdesk rating views now display when a rating was given instead of when the record was created. This makes customer feedback timelines clearer and avoids confusion when reviewing service performance.
Original PR description
Changed new field of view to show the rating date. Task-4023246
Removing the Dispatch Management System no longer leaves behind views that can break the Batch / Wave Transfers screen. This prevents users from encountering an error when reopening inventory transfer planning after uninstalling DMS.
Original PR description
Previously, if the user enabled the DMS (Dispatch Management System) in the Inventory module, the Gantt view would appear in the Batch / Wave Transfers view. However, upon uninstalling the DMS, reopening the Batch / Wave Transfers view would raise a UserError. This issue is now resolved by using an uninstall hook to remove the views introduced by the DMS module. task-4804805
Customers who choose a non-default subscription plan now get the correct pricing applied in their cart. This prevents confusion at checkout and ensures the selected plan is honored during purchase.
Original PR description
Selecting another plan than the default one didn't work because it wasn't considered when looking for the applicable pricing. Forward-Port-Of: odoo/enterprise#90167
This change prevents important activity types such as calls, approvals, tax tasks, payroll leave deferrals, and bank synchronization reminders from being removed or incorrectly changed. This helps keep automated workflows stable across apps and avoids errors when expected activity types are missing or misconfigured.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#90200
Forward-Port-Of: odoo/enterprise#58164This fix ensures rental combo products only calculate availability when the product is actually stock-managed. Customers can now select valid rental dates instead of seeing every date incorrectly blocked, improving the online rental purchase flow.
Original PR description
Issue: - Create a rental product (with a rental pricing), - Make it storable and don't allow out-of-stock orders, - Now make it a combo product, - Add a rental combo choice (to be able to save it), - Go to the product's page on eCommerce, - Issue: all dates are unavailable. Cause: The date range picker only relies on `allow_out_of_stock_order` to know whether to compute rental availabilities (but not on `is_storable`). Fix: Also rely on `is_storable` to know whether to compute rental availabilities. opw-4846084 Forward-Port-Of: odoo/enterprise#90197 Forward-Port-Of: odoo/enterprise#90084
33 changes
Resolved issues and error corrections
This fix prevents the Point of Sale from crashing when an employee logs in and the page is reloaded without an internet connection. It ensures employee login data is prepared earlier, improving reliability for stores operating with unstable connectivity.
Original PR description
Steps to reproduce: =================== - Enable Login with Employee in POS settings - Open POS and log in with employee - Turn off the internet connection - Reload the POS page Issue: ====== - POS crashes with the following error: `TypeError: Cannot read properties of undefined (reading 'push')` - At that point, employeeBuffer is still undefined Cause: ====== - The method `set_cashier()` is triggered during the parent `setup()` - `employeeBuffer` was only initialized after `super.setup()` - In offline mode, this sequence still executes, leading to an exception when trying to .push() into an undefined buffer Fix: ==== - Moved the initialization of `employeeBuffer` to the beginning of the setup() method Task: 4850543 Runbot Error: 227777
Point of Sale now calculates available lot quantities only from the configured source location and its internal child locations, instead of counting stock from all locations. This prevents staff from seeing or selling quantities that are not actually available for that PoS location.
Original PR description
The get_existing_lots function previously returned product_qty based on stock.lot's computed field, which sums quantities from all locations. This led to incorrect available quantities in the PoS, as it should only consider stock in the configured PoS source location and its child internal locations. opw-4865777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Google Calendar sync issue where an invited attendee could incorrectly become the organizer of an event when starting or resuming synchronization before the original owner. Events now wait for the actual organizer to sync first, keeping ownership consistent between Odoo and Google Calendar.
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Google, when the synchronization of user A starts or resumes, the event will be synchronized with the user A as organizer in Google. In the meanwhile, in Odoo, the event ownership will be shown as user B, mismatching the organizer field between the two ends. This is problematic because the ownership of the event will be forever wrong in Google. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Google, it will be correctly synchronized in Google as well. Recently, we had to revert this PR due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back. task-4269432
This fixes an issue where Point of Sale orders could receive references containing an incorrect `000` segment when the same session was used on multiple devices. The change keeps order references and other session-based actions consistent by using a reliable login number source.
Original PR description
Before this commit, it was possible for the session to assign `0` as a login number. This resulted in order references containing `000` in the middle, leading to various issues. Additionally, other…
Before this commit, it was possible for the session to assign `0` as a login number. This resulted in order references containing `000` in the middle, leading to various issues. Additionally, other parts of the code that relied on the session's login number were also using an incorrect value. This problem occurred because the `session.login_number` is not stable; it gets updated whenever the PoS session record itself is modified, potentially overriding a valid login number with `0`. The fix involves changing the code to use `odoo.login_number` instead, which provides a reliable and consistent login number. To reproduce the issue: 1. Open one PoS session on two different devices. 2. Log in with an employee on the first device. 3. Log in with a different employee on the second device. 4. Create a new order on the first device. You would observe that the login number in the order reference is `0`. opw-4861456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now avoids sending invitation or update emails for calendar events that have already ended. For events synced with Google or Microsoft calendars, reminders are left to the external calendar provider, preventing duplicate or unnecessary notifications.
Original PR description
Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. Recently, we had to revert the two original PRs due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-4684432, 4316693
Regular users can now filter email templates by category without seeing an access error. This fixes a problem in the email sending flow, such as choosing templates for sales or purchase emails, making template selection more reliable.
Original PR description
Since commit 42be7cebc84ac4af36104b6d2eba9d3e5d115005, filtering mail templates on their category triggers a search on `ir.model.data` to avoid a memory error on a database having a lot of mail…
Since commit 42be7cebc84ac4af36104b6d2eba9d3e5d115005, filtering mail templates on their category triggers a search on `ir.model.data` to avoid a memory error on a database having a lot of mail templates. However, regular users don't have a read access to this model, so when a user tries to filter on the template category, they get an `AccessError`. With this commit, we add a `sudo()` on the search on `ir.model.data`, so that this error doesn't occur any more. To reproduce the issue on a runbot, follow these steps: - connect as *demo* on a 18.0 database - open a *Sale Order* or a *Purchase Order*, and click on *Send by email* - in the modal dialog, click on the vertical three dots to select a template - if *Search More...* is not available, save the template several times with different new names until *Search More...* appears on the list - click on *Search More...* - in the *Search...* field, click on one of the *Base Templates* or *Custom Templates* filters - boom! `Access Error, You are not allowed to access 'Model Data' (ir.model.data) records.`
This fixes cases where notification details could be read incorrectly when optional message values were empty. It helps ensure accounting and discussion notifications use the right message information, reducing confusing or inconsistent alerts for users.
Original PR description
Beware values may be Falsy, in that case we have to fallback on message itself. account: correctly check values or messages values in notification discuss: fix values usage in discuss methods mail: fix values / msg non coherency for scheduledDatetime, should always be Falsy if not given in values or message Task-4845982
Refunded point-of-sale orders now receive the expected “REFUND” label in the backend order list. This makes it easier for staff to identify refunds and avoid confusing them with regular sales.
Original PR description
Currently, when refunding an order the name of the order does not show "REFUND". Steps to reproduce: ------------------- * Open pos session * Make an order * Refund the order * Go to the backend and see all orders > The refund orders does not show the "REFUND" label Why the fix: ------------ In previous version, when in `sync_from_ui` the state of the order in vals was 'draft'. In this version the state in vals is `paid`. This difference leads to the name being computed in `_complete_values_from_session`. This means that `_compute_order_name` is called before the order is fully created and thus `refunded_order_id` is not yet set and we're always using the next sequence to compute the order name. Now, when we already know the order is a refund we will not compute the name in `complete_values_from_session`. The name will get computed in `write`, which is called by `action_pos_order_paid`, as in previous version. opw-4521070
This fixes an issue where labels for grouped repair records could appear in the wrong language. Users will now see the correct translated label based on their active language, improving clarity in repair workflows.
Original PR description
The `_()` function doesn't work in listcomp as it can't find the env to get the active lang.
The web editor now blocks direct changes to its history records and avoids copying those records during duplication. This prevents errors and helps keep editor history data consistent when content is copied or modified.
Original PR description
This commit prevent direct write to history, also, removes it from copy_data as it would fail anyway when trying to write the history Forward-Port-Of: odoo/odoo#217167
This update fixes several color selection problems in the HTML editor. The color picker now hides correctly when the toolbar scrolls out of view, works reliably with gradient-colored text, and replaces only the relevant gradient when applying a new text or background color.
Original PR description
**Current behavior before PR:** **Issue 1:** - Have a long text content in editable, making the container scrollable. - Select first line of the text, in toolbar open color selector. - Scroll down…
**Current behavior before PR:** **Issue 1:** - Have a long text content in editable, making the container scrollable. - Select first line of the text, in toolbar open color selector. - Scroll down until the toolbar overflows and becomes hidden. - Notice that the toolbar disappears when it overflows its container while color picker remains open, floating at the top of container. **Issue 2:** - Select a text having gradient text color. - Open text color selector, switch to custom color picker. - Notice that hex and rgba fields are empty and user is not able to apply color through it. In colorpicker.js, the convertCSSColorToRgba method fails when attempting to convert a gradient color to RGBA. As a result, colorComponents does not receive valid values and colorpicker doesn't work as expected. **Issue 3:** After merging commit [1], text color can be applied without removing or affecting the existing gradient color. In result, if gradient is fully selected then applying text color creates a new font tag inside gradient instead of replacing the gradient. **Desired behavior after PR:** **Issue 1:** Now, when the toolbar overflows and gets hidden, the color selector becomes hidden along with toolbar. **Issue 2:** Now, if `convertCSSColorToRgba` fails to convert selected color to rgba color then default color `#FF0000`is assigned to color components. This ensures that the colorpicker functions correctly. **Issue 3:** Now, if gradient is fully selected then, - Applying text color removes existing text gradient. - Applying background color removes existing background gradient. - Applying text color doen't remove the existing background gradient. - Applying background color doesn't remove the existing text gradient. [1]: https://github.com/odoo/odoo/commit/938995744b15f345958a2d78a6c844dd5bf1ae6c Enterprise PR: https://github.com/odoo/enterprise/pull/84579 task-4581884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices automatically created after an online payment now use the invoice email template configured in Sales settings. This ensures customers receive the intended message and keeps automated payment follow-up consistent with company preferences.
Original PR description
When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system…
When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system parameter. This was due to the `_send_invoice` method in `payment_transaction` calling `_generate_and_send_invoices` without passing the configured template. This commit modifies the `_send_invoice` method to retrieve the 'sale.default_invoice_email_template' system parameter. If found and valid, the corresponding mail template record is passed in the context to `_generate_and_send_invoices`, ensuring the correct email template is used for auto-sent invoices after online payments. Added unit tests for the different scenarios. ## Reproduction Steps: 1. **Enable Auto-invoicing:** Go to Sales > Configuration > Settings. Under "Invoicing," enable "Automatic Invoicing." Set a specific email template in "Invoice Email Template" (e.g., "Customer Invoice"). Save. 2. **Configure Payment Acquirer:** Go to Invoicing > Configuration > Payment Acquirers. Activate and configure any payment acquirer (e.g., Bank Transfer). Ensure it's published. 3. **Create Sales Order:** Go to Sales > Orders > Quotations. Create a new SO, add a product, and Confirm it. 4. **Simulate Online Payment:** As a customer, navigate to the SO's public portal link. Click "Pay Now," select the configured acquirer, and complete payment. 5. **Observe the Issue:** Check the communication history on the generated invoice. The email will have been sent using Odoo's default invoice template, ignoring the configured setting. opw-4865475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where returning an intercompany dropship order could incorrectly increase the delivered quantity on the original sales order instead of reducing it. Businesses will see more accurate sales fulfillment and return tracking for dropship workflows, especially when companies sell to each other internally.
Original PR description
**Current behavior:** Returning an intercompany dropship (product vendor is another `res.company`) increases the original sale order line's delivered qty. **Expected behavior:** The delivered qty…
**Current behavior:** Returning an intercompany dropship (product vendor is another `res.company`) increases the original sale order line's delivered qty. **Expected behavior:** The delivered qty should decrease once the return is completed. **Steps to reproduce:** 1. Create two companies, enable all the inter-company synchronization rules 2. Create a product with the dropship route and set the other company as the vendor 3. Create a sale order for the dropship product, confirm 4. Confirm the corresponding purchase order -> validate the dropship picking 5. Return the dropship picking 6. See the sale order line's delievered qty is wrong **Cause of the issue:** The dropship return move(s) are incorrectly flagged as outgoing. **Fix:** Use the `_is_dropshipped_returned()` method to filter these moves from being considered outgoing. Also added on to an existing dropshipping test so that there is now coverage for this use-case when the vendor is not another company, as this was previously not covered. opw-4526750
This fixes an internal test condition so it checks for the current accounting enterprise module name instead of an outdated one. It helps keep automated checks accurate during upgrades and reduces the risk of false test failures, with no direct impact on day-to-day users.
Original PR description
This [commit](https://github.com/odoo/odoo/commit/266c6bd8f4d7c64d1f0e02207a3e1bed4f75397d) added a test to skip if the enterprise module `accountant` is not installed. It uses the old name o the module `account_accountant` because the forward port was not adapted.
This fix makes an automated mail test select the correct message when checking edit and reaction actions. It reduces random test failures, helping keep the mail feature validation stable without changing user-facing behavior.
Original PR description
Before this commit, "test_discuss_channel_public_page_as_internal" tour would fail non-deterministically at following step: ``` FAILED: [21/33] Tour discuss_channel_public_tour.js → Step Click on edit (trigger: .o-mail-Message-moreMenu [title='Edit'], .o-mail-Message [title='Edit']). ``` This happens because this tour is run twice, and in the 2nd run the selector to hover and click on 'Expand' is just targeting the 1st message. This works fine in the 1st run, but in the 2nd run this picks the message of previous test instead of the 2nd one. A full run of tour posts a message "cheese" and edits its content to "vegetales", so targeting the message with content "cheese" ensures the right message is picked, which is what this commit does to fix the issue. This commit also properly targets the right message for message reaction. Fixes runbot-error-227756
This draft fix explores a more reliable way to keep loyalty coupons in sync between different Point of Sale and restaurant sessions. It aims to prevent mismatched or missing coupon information when staff work from multiple POS devices or sessions.
Original PR description
this commit is still in draft form, and is used to try and find a way to fix the synchronization of coupons between different sessions in a stable way. If it's accepted, tests and a clearer message will be made.
Quote PDFs now correctly reflect changes made to quotation templates. If a document is removed from a template after being selected on a quote, it will no longer appear in the generated PDF, preventing outdated or unintended content from being sent to customers.
Original PR description
## Version 18.0+ ## Issue On a quotation setup with a template, when a document is selected in the quote builder and then deleted from the template, it still appears when rendering the quote PDF. ## Steps to reproduce - Create a new quotation template with a header document - Create a new quote using the quotation template: - Under the 'Quote Builder' tab, select the header document - On the quotation template, delete the header document - Come back to the quote - *(Optional: check the 'Quote Builder' tab - it should be empty)* - Print the PDF: - The header appears on the document opw-4712958
Internal users who have a passkey can now complete the portal identity check without the process switching to an unsupported verification method. This prevents a rare but disruptive issue that could block internal users from accessing portal features.
Original PR description
When an internal user has a passkey and attempts to pass the portal identitycheck, then the identitycheck's auth_method is set to webauthn which breaks the flow since portal's identitycheck only supports passwords. This scenario is unlikely to occur but it does break the internal users' portal. This is a temporary solution because once I implement passkeys for portal users, I will allow portal users to use webauthn to verify their identity.
Fixed an issue where printing a Bill of Materials could fail if a byproduct was entered with a quantity of zero. The report now handles that case safely and shows a zero cost instead, helping manufacturing users generate BOM reports without interruption.
Original PR description
**Issue**:
Printing the BOM crashes when one of the byproduct quantity is set to 0
**Steps to reproduce**:
- Open the manufactoring app
- Go to settings and activate by-product settings
- Go to Products > Bills of Materials
- Open a BOM
- Put the quantity of one the by-product by 0
- Click on overview
- Click on the print button
**Cause**:
In the `mrp_report_bom_structure.xml` template, there is this division:
- `<td class="text-end" t-esc="byproduct['bom_cost'] / byproduct['quantity']" t-options='{"widget": "monetary", "display_currency": currency}'/>`
without checking if `byproduct['quantity']` is different than 0.
**Solution**:
Added the check on `byproduct['quantity']` in the foreach
**Additional notes**:
Since it makes no real sense to have a non-zero BoM cost associated with a byproduct whose quantity is zero, the cost is set to 0 when the quantity is 0.
opw-4853525
Forward-Port-Of: odoo/odoo#213936Website editor illustrations are now recognized correctly even when their file type includes character encoding details. This restores dynamic color options for SVG illustrations, so users can customize them as expected instead of having them treated like regular uploaded images.
Original PR description
When illustrations mimetypes changed from simple `image/svg+xml` to `image/svg+xml; charset=utf-8`, `html_editor` was not used for website pages yet - and it therefore missed the fix in [1]. Because of this, when an illustration is selected, it is detected as an uploaded image, and the dynamic colors are not available. This commit adapts the mimetype detection. [1]: https://github.com/odoo/odoo/commit/af11070a6d4eeb69ee49c28435341a220eb64203
This fix updates passkey-related automated tests so they work correctly when the HR module is installed. It prevents false test failures caused by differences in how the user preferences screen reloads, helping keep passkey functionality reliably validated.
Original PR description
The HR module caused the tests to break due to the difference in the user preference screen. The user preference screen normally closes after creating a passkey but in the case where HR is installed then the user preferences DOM is still visible while it's reloading the page. Quick bugfix for 18.0 only, the others will be fixed in the forward ports of https://github.com/odoo/odoo/pull/217583
The HR departure process now properly removes a departing user's approver links even when they are only assigned to some approval roles. This prevents archived employees from remaining incorrectly linked as approvers for time off, expenses, or timesheets.
Original PR description
Currently, a user needs to be time off, expense and timesheet approver of an employee for those links to be removed by the departure wizard. If not all the approver fields are the same user, that link will not be removed. Steps to reproduce: - Set Marc Demo as only Time Off approver on an employee. - Archive Marc Demo's employee (This does not remove time off approver from the previous employee) To rectify this issue, we correctly group the `user_domain` so that their contents are properly OR'd. Forward-Port-Of: odoo/odoo#213513
This fix prevents product tag areas from being duplicated when shoppers view or switch product variants in the online store. It keeps product pages cleaner and avoids confusing page structure issues that could affect display or maintenance.
Original PR description
Steps: - Open Odoo 18. - Go to Website > Shop. - Open any product with tags. - Inspect the DOM. Issue: - The `.o_product_tags` div was duplicated. - This resulted in a nested `.o_product_tags` block in the DOM. Reason: - The system was inserting the full HTML tags, including its wrapper, causing the nesting. Solution: - Now only the inside content of the tags is updated, not the whole wrapper. - This keeps the structure clean and avoids duplication. Result: Now, there will be no duplication in the `.o_product_tags` block div section. OPW:4863967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates Turkish Nilvera e-invoice XML so subscription invoice periods are placed at the document level, matching the required UBL TR 1.2.1 format. It also warns users and blocks sending when subscription lines in the same invoice have different date ranges, helping prevent rejected e-invoices.
Original PR description
The UBL TR 1.2.1 format does not support \<InvoicePeriod\> element in invoice lines in the XML generated for e-invoice. This commit moves the \<InvoicePeriod\> element from invoice lines to document level. It also validates that the start and end dates of all subscription invoice lines in one invoice should be same, or else it shows warning and disables the `Send & Print` wizard button TaskId:4885865 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215819
Changing a live chat chatbot step from a question selection to another step type now removes the old answer options when saved. This prevents outdated or irrelevant answers from staying attached to chatbot flows, reducing confusion for website visitors and staff configuring chatbots.
Original PR description
**Current behavior before PR**: When the step type was changed from "question selection" to another type and the step was saved, answers were not cleared. **Desired behavior after PR is merged**: Now, when the step type is changed from "question selection" to any other type and the step is saved, the answers are cleared. **task**-[4510555](https://odoo.com/odoo/all-tasks/4510555) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice summaries now show “Reversed on ...” when an invoice is settled through a credit note rather than an actual payment. This prevents users from mistaking reversals or credit notes for cash or bank payments.
Original PR description
Before this PR: -------------------------------------------------- In the invoice summary, the label `Paid on ...` was always shown whenever the invoice was reconciled, regardless of whether the reconciliation was made through an actual payment (bank/cash) or through a credit note or journal entry. This led to misleading information: - Credit note reconciliation (partial or full) showed `Paid on ...` - Even though no real payment occurred - Full reversals correctly showed status 'Reversed', but the label still said `Paid on ...` After this PR: -------------------------------------------------- - The label is now shown as `Reversed on ...` when the reconciliation is done with credit note. - This avoids confusion and better reflects the actual accounting status of the invoice This change ensures users are not misled by incorrect payment indications when only a reversal or credit note is involved. task-4920349
The website editor sidebar now displays layout options correctly when using longer translated labels, such as Spanish. This prevents unwanted horizontal scrolling and makes editing page snippets smoother for users working in different languages.
Original PR description
Step to reproduce: - Set the odoo backend language to spanish (tested in V16.0) - Go to edit mode - Drop "Text-Image" snippet. - Click on Image from dropped snippet. - Bug: The sidebar "Layout" menu overflows, there is a horizontal scrollbar. Issue: There was an issue with the dynamic width of the we-buttons within the button group. The text in the "Layout" options was overflowing, causing the sidebar to overflow. Solution: This commit addresses the specific issue with the layout option. Without altering any other styles and assuming this is the only case, we equally divide the available space between the buttons using the grid template. task-4378522 Forward-Port-Of: odoo/odoo#217722 Forward-Port-Of: odoo/odoo#189856
This fix prevents the Knowledge app from failing when optional information is missing. It improves reliability by safely handling cases where expected details are not provided.
Original PR description
Just be sure when using an argument that can be False instead of a dict. Task-4845982
This fix prevents an error message from appearing when users validate deliveries that print carrier labels through an IoT-connected printer. Shipping labels and related documents can now be sent to the correct printers without confusing on-screen warnings.
Original PR description
When trying to print shipping labels using the iot an error appears on the screen. Although it still allows to print.
Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> An error is shown, Undefined
Why the fix:
------------
When looking in the console we see a bit more detail about the error.
> send_to_controller(self.connection_type, {'print_id': data['print_id'], 'device_identifier': self.device_identifier})
The module `delivery_iot` was not sending any information related to print_id.
opw-4788871The restaurant appointment editor now closes the text color picker when its formatting toolbar scrolls out of view. This prevents a floating control from remaining on screen without its toolbar, making the editing experience cleaner and less confusing.
Original PR description
**Current behaviour before PR:** Steps to reproduce the issue: - Have a long text content in editable, making the container scrollable. - Select first line of the text, in toolbar open color selector. - Scroll down until the toolbar overflows and becomes hidden. Notice that the toolbar disappears when it overflows its container while color picker remains open, floating at the top of container. **Desired behaviour after PR:** Now, when the toolbar overflows and gets hidden, the color selector becomes hidden along with toolbar. Community PR: https://github.com/odoo/odoo/pull/202889 task-4581884
Facebook removed an activity metric that Odoo previously used, causing errors and making other statistics appear as zero. This update stops using that unavailable metric, so Facebook social dashboard statistics remain reliable, though the removed “stories” statistic is no longer shown.
Original PR description
Bug === `page_content_activity` has been deprecated, so the API return an error and the other statistics are set to zero. https://developers.facebook.com/docs/pages-api/changelog Now, the only equivalent is `post_activity_by_action_type`, but it needs to be called on all posts, and it does not support periods (so even if we call it for each post, we won't be able to compute the trend). So we simply removed the `stories` statistics for Facebook. Task-4914555 Forward-Port-Of: odoo/enterprise#89524 Forward-Port-Of: odoo/enterprise#89230
Fixed an issue where shops using an Urban Piper payment method could complete a sale but then be unable to close the point-of-sale session. The closing process now avoids duplicate payment method entries, preventing the session closing screen from freezing or failing.
Original PR description
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up…
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up urban piper (no need for credentials) testing with random keys will do * Go into the payment methods and take one of the urban piper one and assign it to a shop * Open that shop * Place an order and use the urban piper payment method * Validate * Try closing the session > Observation: Nothing happen, we're now unable to select the menu. If doing the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach Why the fix: ------------ The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method. Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method. opw-4874699
This fix corrects how accident insurance-related days are calculated in Swiss payroll. It helps ensure payroll results and related reporting use the right day counts, reducing the risk of inaccurate employee payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#90153