Wednesday, April 29, 2026
29 changes · 19.0
Enhancements to existing features
This update ensures the scale certification icon is displayed in Odoo Enterprise v19.0. This change reflects our recent certification achievement and provides users with clear visual confirmation of our compliance.
Original PR description
This PR makes the scale certification icon visible in v19.0 since we are now certified for this version
Resolved issues and error corrections
Fixes an issue in the HTML editor where choosing a list option from the toolbar could make selected text flicker and sometimes fail on the first try. This makes composing messages smoother and more reliable for users working with formatted text.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the French certified Point of Sale flow where the “Old Unit Price” could show the newly edited price instead of the original price. This helps ensure receipts and order summaries accurately reflect price changes for compliance and customer clarity.
Original PR description
**Steps to reproduce:** - Go in the french localization - In the PoS, click an item, click price and change it's price - The section "Old Unit Price" will display the current price, instead of the original price **Why the fix:** Currently, the Old Unit Price section displays the line's currentDisplayPrice, which is the price that has been modified in our case, meaning we display the same price 2 times. This was introduced in 9538698 where the tax calculation was removed. It seems like the *getTaxedlstUnitPrice* function is still needed in l10n_fr so this commit reintroduces it in l10n_fr only. With this function back, we can compute the old unit price like it was done before and display it in the Old Unit Price section. opw-5378158
New batch transfers created from the Barcode app or saved from forms are now automatically given the proper sequence-based name instead of keeping the placeholder "New". This helps warehouse teams identify and track batch operations consistently.
Original PR description
Steps to reproduce 1. Open the Barcode app. 2. Tap a picking-type tile that targets batch transfers (e.g. Delivery Orders) and click "New". 3. Pick an operation type, select transfers, and confirm.…
Steps to reproduce
1. Open the Barcode app.
2. Tap a picking-type tile that targets batch transfers (e.g. Delivery Orders) and click "New".
3. Pick an operation type, select transfers, and confirm.
Issue
The created batch keeps the placeholder name "New" instead of being renamed to ``BATCH/<TYPE>/000NN``.
Two distinct call sites bypass the sequence rename in ``create``:
* The barcode kanban "New" button calls ``open_new_batch_picking``, which runs ``Batch.create({})`` while the action context carries ``default_picking_type_id`` (set by ``stock.picking.type._get_action`` at https://github.com/odoo/odoo/blob/8eda2bf66fed25aa2ab1fc799011cb44c52925df/addons/stock/models/stock_picking.py#L421). ``vals`` doesn't carry ``picking_type_id``, so the rename is skipped; ``super().create`` then applies the context default and ends up with ``picking_type_id`` set but ``name='New'``.
* Form-based saves send the field's default value ``_('New')`` back as ``vals['name']``, so ``vals.get('name', '/') == '/'`` at https://github.com/odoo/odoo/blob/5883e300bc9e7ee125dad5b747cf955f4d682f81/addons/stock_picking_batch/models/stock_picking_batch.py#L182 is false and the rename branch is skipped.
Solution
Treat the placeholder default ``_('New')`` like the legacy ``'/'`` and fall back to ``default_picking_type_id`` from context when ``vals`` doesn't provide one, so the sequence-based name is assigned in both paths.
opw-6168320Users with home or office locations now see the correct status icon on the dashboard instead of a grey question mark. This makes employee availability and work location clearer at a glance.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997Deleting or changing a public holiday could fail when it overlapped with time off for an archived employee. This fix ignores archived employees during timesheet regeneration, allowing holiday changes to complete while preserving the employee’s historical time-off records for possible future reactivation.
Original PR description
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should…
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should affect the timesheets). 2. Create a new public holiday (global time off) that overlaps with Employee A’s time off. 3. Archive Employee A. 4. Delete the public holiday created in step 2. 5. An error related to timesheet generation appears. ## Expected Behavior: - The public holiday / global time off should be deleted without any error. # Desired behavior after PR is merged: ## Fix (Implemented): When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees. ## Alternative Fix (Not Implemented): Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved. ## Version: This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0 but didn't directly test ## Task: [5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261412 Forward-Port-Of: odoo/odoo#244203
Power buttons in the HTML editor are now hidden when the editor area is too narrow, rather than only on mobile screens. This prevents visual overlap with other controls, making settings forms easier to read and use on smaller layouts or with longer translated text.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259094
This update tightens internal code quality checks by enabling more warning detection while filtering known third-party compatibility notices. It also fixes resource handling and updates outdated time-related code, reducing maintenance risk without changing everyday user workflows.
Original PR description
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
The accounting settings now include Other Expense accounts when selecting default accounts for exchange losses and early payment discount gains or losses. This prevents valid accounts from being omitted, making setup more accurate and less confusing for finance users.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375
The HTML editor table menu now refreshes its options when a user selects a different table cell. This prevents outdated row or column actions from appearing, making table editing more reliable for users.
Original PR description
After this commit [1], setup is executed only on the initial mount of the table menu and not on subsequent target cell changes. As a result, colItems, rowItems, and other values found in setup become stale, causing the menu to display options that do not reflect the current target cell. This commit moves the necessary values from setup into useEffect so they update correctly when the target cell changes. task-6111986 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Backport of Commit https://github.com/odoo/odoo/commit/729c45ddf3d1e377507d93997c5ca45984d64d75 Forward-Port-Of: odoo/odoo#259929 Forward-Port-Of: odoo/odoo#258590
Canceling an empty restaurant order in Point of Sale no longer triggers an error when loyalty or eWallet programs are enabled. This prevents interruptions for staff and keeps the checkout/table workflow stable.
Original PR description
Steps to reproduce: = - Enable loyalty in the POS configuration. - Add an eWallet program for this POS. - Open a table and cancel the (empty) order using the "Cancel Order" control button. Issue: = - A traceback occurs: `TypeError: Cannot read properties of undefined (reading 'getTotalWithTax')` Reason: = - When clicking "Cancel Order", the order is deleted and `currentOrder` becomes `undefined`. - During the re-render of `ControlButtons` on the product screen, there is no active order, which leads to the traceback. Fix: = - Ensure the `ControlButtons` dialog is closed before deleting the order to prevents the re-render of `ControlButtons` without an active order and avoids the traceback. task-6030182 Forward-Port-Of: odoo/odoo#261670 Forward-Port-Of: odoo/odoo#254337
The IoT drivers module now reads the Egyptian token from the correct configuration section. This prevents setups that rely on this token from failing due to the value being looked up in the wrong place.
Original PR description
This PR fixes the section used to retrieve the egyptian token in odoo.conf file for it to be "options" instead of "default" Related PR: https://github.com/odoo/odoo/pull/255121
Sales quotation previews and PDF reports now show product line amounts consistently with the company’s tax pricing setting. When prices are configured as tax included, customers will see the tax-included amount instead of a lower tax-excluded value, reducing confusion and mismatches with the quotation screen.
Original PR description
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a…
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a quotation with this product. - Confirm the line amount shows 10 (tax included). - Click on preview. **Observation:** - In the preview, the product line amount is shown as tax excluded. **Root cause:** - At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`. - This logic is not applied in the portal preview and PDF report. **Solution:** - Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`. [1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663 Before: --- <img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" /> After: --- <img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" /> opw-6089473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258551
This fix ensures that when a returned delivery is partially processed and a backorder is created, that backorder remains linked to the original return. Users can now see the full return history from the delivery, reducing confusion and improving traceability in inventory operations.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259921 Forward-Port-Of: odoo/odoo#259804
This fixes a timing issue where repeated checks for the active browser tab could leave one request waiting indefinitely. Users benefit from more reliable real-time behavior when multiple Odoo tabs are open.
Original PR description
Whenever `isOnMainTab` is called, it creates and returns a new promise that will be resolved once the shared worker sends its response. However, if `isOnMainTab` is called twice in quick succession, before the shared worker answers, only the last promise is resolved, leaving the first one hanging forever. This commit fixes the issue by not recreating a promise if there is already one pending.
This change adds a disabled-by-default setting that lets support teams log point-of-sale order data when investigating synchronization issues. It also includes the receipt order reference in those logs, making it easier to match log entries to specific transactions while limiting routine exposure of sensitive data.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Paid point-of-sale orders linked to loyalty cards now load correctly even if the related loyalty program has been archived. This prevents an error when opening the customer list, helping staff access past orders without interruption.
Original PR description
Before this commit, when loading a paid order with a loyalty card that its program had been archived, an error was raised when opening the partner list due to the missing program. opw-6166079 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing kiosks from communicating correctly with the new IoT box images. The fix ensures the correct message format is used, allowing the IoT box to receive and process data properly. This improves compatibility and functionality for kiosk users.
Original PR description
The new IoT box images expect the websocket messages to contain just `iot_identifier` and `device_identifier` instead of a list of `iot_identifiers` and `device_identifiers`. This method that the kiosk calls to send a message to the blackbox was not updated, causing the IoT box to ignore the message. This commit fixes the issue by adding the `iot_identifier` and `device_identifier` to the message.
This update fixes an error in how emission factors are converted within the ESG module. The previous system incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update fixes an issue where the IRN number, generated during e-invoicing, wasn't being saved to the customer invoice. Now, the IRN number is correctly displayed in both the invoice PDF and the invoice form view after the EDI submission process, ensuring accurate record-keeping for GSTR reporting.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#114350
This update resolves an issue preventing the generation of VAT Books in the Spanish version of Odoo Enterprise. A change in the button logic required updating the XPath expression to avoid errors. The VAT Books now open successfully after this fix.
Original PR description
After an update, the t-if of the button was changed, and it was necessary to adapt the xpath to avoid errors After the change, the VAT Books opened without problems task-6170173
This update resolves a minor visual issue where the bank reconciliation popover was incorrectly displayed on all lines, even those without relevant transactions. The fix ensures the popover only appears when appropriate, improving the user experience and preventing unnecessary visual clutter. This is a low-impact fix.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/5d88ae9fc1e1f43797fe7d9118a0582f949dc7be we changed the way the popover was working to make it display on hover but forgot to add the condition to display the popover. It means that it was display for every line even the one without exchange move or partial reconcile, so there was a small visual glitch no task id
This update corrects a bug in the appointment booking process for flexible scheduling. Previously, a 20-minute slot was incorrectly serialized, leading to a 404 error. The fix ensures accurate slot duration calculation, resolving the booking issue and improving the user experience.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312
This update fixes an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that partner balances accurately reflect all transactions, resolving inconsistencies between totals and subline amounts. This improves the reliability of financial reporting.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update corrects a technical error that prevented users from editing appointment pages in the website builder. The issue stemmed from an unnecessary attribute being included in the BuilderContext component, which was flagged by debug mode. This change ensures a smoother editing experience for all users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741 Forward-Port-Of: odoo/enterprise#115242
This pull request addresses a problem with invoice testing related to rounding calculations within the l10n_mx_edi module. It reverts a previous change that introduced the issue and implements a fix. This ensures accurate invoice generation and reporting for Mexican tax purposes.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115608
This update resolves an error that occurred when exporting VSME reports if the base year was not a valid 4-digit number. The fix ensures that only valid years (1000-9999) are accepted, preventing a data processing error and ensuring report generation functionality.
Original PR description
Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year. **Steps to Reproduce:** 1. Install the `esg_csrd` module with demo data. 2. Create new "**VSME Reports**" with `Base Year = 1`. 3. Now, click on "**Print**". **Error:** `ValueError - Invalid isoformat string: '1-01-01'` **Cause:** The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format. **Fix:** - Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records. - Adds a **helper validation method** to verify base year before performing computations on existing records. sentry-7419431039
This update resolves an error preventing users from accessing the Spain VAT Books report within Odoo. The issue stemmed from an outdated template referencing a removed condition, which caused a search error. This fix ensures the report functionality is restored for Spanish companies.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath…
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree` **Root Cause:** After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the inherited template `l10n_es_reports.VatBooksLineName` was not updated accordingly and still references the old condition, which leads to the error. **Fix:** This commit prevents errors and ensures that users can open the `VAT Books` report by applying a fix similar to [2]. [1]: https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a [2]: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81 opw-6169697 opw-6170173
This update resolves a potential issue where duplicate Odoo databases would retain active connections to ARCA web services. This prevented users from accurately testing the system without impacting live production connections. The change ensures ARCA connections are cleared when credentials are updated, improving testing and stability.
Original PR description
Problem and Cause: When duplicating a database with existing ARCA connections, the connections to ARCA webservices are not cleared. Users using the duplicate database may not realize that the ARCA connections are still present. This may lead to production connections getting used while users are testing. Solution: Clear connections to ARCA webservices when updating the credentials.