Daily updates from Odoo
Monday, November 24, 2025
48 changes · master
Enhancements to existing features
Signing templates now organize their field definitions in a dedicated extension point, making future adaptations easier to maintain. This mainly helps teams and partners customize signing workflows with less risk when applying updates.
Original PR description
Introduced a dedicated _getTemplateFields() method to make easier to override or extend the fields in patches. Forward-Port-Of: odoo/enterprise#100096 Forward-Port-Of: odoo/enterprise#95722
The spreadsheet version history panel now uses tile colors with better contrast in dark mode. This makes previous versions easier to read and reduces visual strain for users working with dark mode enabled.
Original PR description
Change the color of the tiles of the version history to have a better contrast in dark mode. Task: [5265478](https://www.odoo.com/web#id=5265478&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Sent email records now keep the exact address used when contacting a recipient. This prevents past notification details from changing if the recipient's partner email is updated later, improving auditability and clarity.
Original PR description
Purpose ======= When we send an email to a partner, we don't store the email used. So if we change the email of the partner, then the email shown in the mail notification won't be accurate anymore. Now, we store that email in `mail_email_address`. Task-5215602
Toolbar buttons in Web Studio now display their matching keyboard shortcuts in their tooltips. This helps users discover faster ways to work and makes common editing actions easier to learn.
Original PR description
This PR updates toolbar button tooltips to display their corresponding keyboard shortcuts. Community PR: https://github.com/odoo/odoo/pull/233741 task-5160025
Field service products no longer carry a separate worksheet template setting when task templates can already provide the worksheet. This reduces duplicate configuration and helps ensure generated tasks consistently use the worksheet defined on the selected task template.
Original PR description
…om product Before this commit, since the adding of a task template in the product settings when the service product will generate a task in a project selected a project with worksheet feature. The user can set a worksheet template and a task template in that product form view. The task template can actually have a worksheet template set to give it to the task that will be generated once a sale order contains that product and is confirmed. And thus, the worksheet_template_id field in the product form view is a bit redundant with the task template. This commit removes the worksheet_template_id field from the product model to let the task template doing the job. task-5213862
Users can now start an AI chat directly while viewing an attachment, with the selected file automatically included as context. This makes it easier to ask questions about documents without manually adding or moving files, while keeping those temporary context files out of the permanent message attachments.
Original PR description
## Summary - Introduced a new AI composer `file_viewer_ai_button` to allow launching AI chat directly from the file viewer. - The selected file is sent as a context attachment along with the message to the LLM. - Context attachments are linked to the message temporarily for AI processing but not stored in `message.attachment_ids`. task-id-5125822
Shop floor users can now adjust the production quantity or split a manufacturing order directly from the Shopfloor interface. This helps teams react faster to changes in demand without leaving their operational workflow.
Original PR description
Add a new menu in Shopfloor to allow changing product_qty and splitting MOs. Task: 5153835
Internal users can now write and edit messages with a richer HTML editor in chatter, Discuss, and live chat. This improves day-to-day communication by making formatting and suggestions more consistent across messaging areas.
Original PR description
This commit enables the html composer for internal users.
This allows internal users to use the html composer to write/edit
messages in the chatter, discuss, and livechat.
1. Uses wysiwyg for internal composer;
2. Adds composer plugin to bind the handlers so that we don't need to
redo it for textarea composer;
3. Adds suggestion plugin to replace the navigable suggestion list;
4. Uses the suggestion plugin in full composer;
task-4454078
https://github.com/odoo/odoo/pull/199806The message composer is being updated to support a richer writing experience, making it easier for users to format and prepare messages. Related tests were adjusted across Documents, Mail, and Helpdesk Live Chat to ensure the improved composer works reliably in key communication flows.
Original PR description
task-2593397
VOIP calls now keep their duration as a stored value, making it easier to filter, group, and total call activity in reports. The call end time is calculated from the start time and duration, helping keep call records consistent and reducing duplicate stored data.
Original PR description
Persist call duration to enable filtering, grouping, and aggregation, and compute end_date on the fly from start_date + duration instead of storing it explicitly. Add a regression test ensuring the stored duration and computed end date stay in sync. upgrade: https://github.com/odoo/upgrade/pull/8891 task-5187543
The return workflow has been streamlined by removing the separate “Validate” step before submission. This reduces extra clicks and makes tax and payroll return processing faster while keeping related submission and locking flows aligned across affected localizations.
Original PR description
task-5155703
Manufacturing orders that require a lot or serial number can now complete without users manually entering one first. This reduces interruptions on the shop floor and ensures related print actions include the newly generated lot or serial information.
Original PR description
Marking a manufacturing order as done without a provided/generated lot/serial number raises with the message "You need to supply a Lot/Serial number for product ...". We want this information to be populated automatically. The automatic report printing actions had to be reworked to include these generated lots/serials, as well as the mrp.batch.produce which previously did not handle them. task: 4595752 See odoo/odoo#209659
Quality checks for repair orders are now generated when the order is confirmed, rather than at initial creation. This avoids unnecessary checks for repairs that are never processed and keeps product or lot-related checks aligned with confirmed work.
Original PR description
- Generate quality checks when a repair order is confirmed rather than when it is created. This ensures that quality checks are only created for repair orders that are actually being processed. - Product and lot updates quality checks only after confirmation. Task [5227065](https://www.odoo.com/odoo/project/966/tasks/5227065) Forward-Port-Of: odoo/enterprise#98815
GSTR-2B processing now recognizes an additional recoverable warning condition and avoids reprocessing return periods already marked with blocking errors. This reduces unnecessary automated retries and helps keep India GST reporting workflows focused on records that can still be processed.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100281 Forward-Port-Of: odoo/enterprise#99378
Signature blocks are now registered in a shared editor category so they can work reliably across different editing experiences. This ensures signatures remain available in Mass Mailing and simple editors, reducing disruption when preparing communications.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624 Forward-Port-Of: odoo/enterprise#75612
Resolved issues and error corrections
Returned deliveries for subscription products are now correctly counted when calculating delivered quantities. This prevents subscription sale orders from showing inaccurate delivery status after a customer return is processed.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
Uninstalling the Databases module no longer leaves behind a project access rule that refers to removed database fields. This prevents an error during uninstall and helps keep the system stable when customers remove the module.
Original PR description
Currently an error occurs when user uninstalls the `databases` module. **Steps to replicate:** * Install and uninstall databases **Error:** `ValueError: Invalid field project.project.database_hosting…
Currently an error occurs when user uninstalls the `databases` module.
**Steps to replicate:**
* Install and uninstall databases
**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`
**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.
**Solution:**
* Revert the domain back to the one defined in project module.
[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26
sentry-7035410943
Forward-Port-Of: odoo/enterprise#99987The subscription customer portal now uses the billing periods configured in the system instead of relying on a fixed list. This prevents errors when businesses add custom billing options, such as daily subscriptions, and makes future changes easier to support.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
Budget values in accounting reports now show the same rounded amount when viewed and edited. This prevents confusing extra decimal digits from appearing in budget input fields, making report updates clearer for users.
Original PR description
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the…
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the correct rounded value. **Steps to Reproduce:** 1. Go to Accounting → Reporting → Profit and Loss Report 2. Enable Column Budget 3. Enter budget value: 5.00 4. Save → Value displays correctly as: 5.00 ✓ 5. Click to edit the same cell 6. Input field shows: 5.000000000174602 ✗ (instead of 5.00) 7. Save without changes → Display shows: 5.00 ✓ 8. Edit again → Still shows: 5.000000000174602 ✗ **Root Cause:** The frontend reads from cell['no_format'] when populating the edit input field. This field receives the raw column_value which contains floating-point precision errors accumulated during aggregation operations. While the display formatting applies rounding, the edit mode receives the unrounded value. **Solution:** Round column_value using float_round() immediately after detecting an editable budget column, before the value is used anywhere. This ensures both the display path and edit path receive the same properly rounded value based on the company's currency decimal places. opw-5158862 Forward-Port-Of: odoo/enterprise#98478
DHL shipments and return labels now use the field names and date-time format expected by DHL. This prevents failed label creation when customer references or return shipments are involved, improving reliability for DHL deliveries.
Original PR description
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes…
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API. In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL. Steps to reproduce spelling issue: 1. Create a Sales Order with a customer reference and a deliverable product. 2. Validate the SO. 3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key [recepientReference] is not permitted. Steps to reproduce datetime issue: 1. Create a delivery using the DHL carrier. 2. Confirm the delivery. 3. Return the delivery. 4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted (expected format: '2010-02-11T17:10:09 GMT+01:00'). Official DHL documentation: https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml opw-5024363 Forward-Port-Of: odoo/enterprise#98981
Invoice reports now keep section amounts aligned correctly when the Country of Origin column is displayed. This prevents confusing invoice layouts and helps users read totals accurately.
Original PR description
Before this commit when having section and the country of origin column, the amount was is the wrong place. The solution is to add 1 to the line colspan when display origin is set. opw-5333624 Forward-Port-Of: odoo/enterprise#100012
This update removes duplicate internal methods identified by automated code checks. It helps keep the affected HR payroll, salary contract, and expense processing areas easier to maintain, with no expected change for day-to-day users.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#100078 Forward-Port-Of: odoo/enterprise#99809
The fix ensures the Italian “Libro Giornale” PDF layout only applies to the intended Italian journal report. This prevents regular journal report exports from losing journal names when the Italian reporting module is installed, improving report reliability for affected companies.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
Swiss Federal Tax Administration exchange rates are now saved with the correct publication date instead of a later validity date. This prevents rates from appearing under the wrong day, improving accuracy for companies using Swiss currency rate updates.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
Quality checks in the barcode app now only appear for items that were actually picked or scanned, including the correct serial or lot-tracked unit. This prevents staff from being asked to complete checks for products that are not being received yet, reducing confusion and avoiding blocked validations.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764
Forward-Port-Of: odoo/enterprise#99799
Forward-Port-Of: odoo/enterprise#99565Hong Kong payroll now respects manually entered Average Daily Wage amounts instead of replacing them with an automatic calculation. This prevents incorrect payslip results when payroll teams need to use a specific manually provided value.
Original PR description
The current logic is incorrect and while it does pick the ADW from the input line, it then proceeds to override that amount with the calculated one. In cases where the manual input is needed, this is a big issue. Forward-Port-Of: odoo/enterprise#100262
German Datev exports now use the manually adjusted tax totals from vendor bills instead of the original calculated amount. This helps ensure exported accounting files match what users see in the ledger and reduces reconciliation errors.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100244 Forward-Port-Of: odoo/enterprise#98684
Spanish balance sheet users can now open the Accounts Coverage Report without encountering an error. The underlying report data is loaded in the correct order and stored properly, improving reliability for Spain localization reporting.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745Swiss payroll test coverage was adjusted so it no longer depends on accounting configuration being present. This helps ensure payroll validation and related declarations can be tested more reliably without unnecessary accounting setup requirements.
Original PR description
Forward-Port-Of: odoo/enterprise#99853 Forward-Port-Of: odoo/enterprise#98672
This update fixes how default filing deadlines are configured for multiple country-specific Intrastat and tax return reports. It helps ensure each company uses the correct return deadline settings, reducing configuration errors in localized reporting.
Original PR description
The fields default_deadline_periodicity and default_deadline_days_delay have been added on the return type model because they handle the company dependant property of their associated field, and they are the ones that should be used in the xml. Forward-Port-Of: odoo/enterprise#99793
This fix restores the expected handling of ISO20022 bank payments by applying the normal service level to standard non-SEPA payment flows. It helps ensure international or non-standard currency payments are generated in the format banks expect, reducing the risk of payment processing issues.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
Fixes an issue where edited or deleted partners on multi-line bank statements could be recalculated unexpectedly during reconciliation. This helps accounting users keep their intended partner assignments and reduces incorrect reconciliation changes.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670 Forward-Port-Of: odoo/enterprise#99999
Fixed an issue that caused point-of-sale scales using fallback connectivity to send rapidly multiplying requests after each weight change. This prevents request failures and keeps scale weighing reliable during checkout.
Original PR description
Steps to reproduce: 1. Setup a scale in a POS. 2. Disable the WebRTC connection so that longpolling is used. 3. Try to weigh with the scale in the POS. Expected behaviour: - There is one HTTP call per weight event, and the scale continues to work no matter how many times the weight changes. Actual behaviour: - The amount of HTTP calls doubles every time the weight changes. Before long, a limit is reached and the requests start to fail. This behaviour was due to the `addListener` method being called again inside the listener callback, calling the poll method. The original poll call would also start to poll again, leading to two polling requests. The fix is to check in the poll method that listening has not restarted during the handling of the callback. If so, we don't try to poll again.
Spreadsheet version history tiles now use colors with better contrast in dark mode, making past versions easier to read. Related spreadsheet document tests were also updated to match the latest resizing behavior, helping keep the feature reliable after the spreadsheet engine update.
The update corrects an internal test for Belgian SODA accounting imports by ensuring the needed analytic setup is created during the test. This helps keep automated quality checks reliable and prevents false failures in development pipelines.
Original PR description
This https://github.com/odoo/enterprise/commit/e01d865d922d47d8ba1638a48e6d481363fc1f04 introduced an error while running the test without enough analytic accounts. We instead manually create the analytic plan and accounts required for the test. runbot-234353
The VoIP keypad input now uses a better font size when it is empty, so its placeholder text displays correctly. This makes the calling interface clearer and avoids confusing clipped guidance for users entering a number.
Original PR description
In https://github.com/odoo/enterprise/pull/99877, the font size for the Keypad input was fixed to a value suitable for most cases. Still it is problematic when the input is empty: the placeholder is not fully displayed. Here we set an appropriate value for the font size in that later case.
This fixes an issue in the Sign app where a signer could see date placeholders meant for later signers. The change helps keep the signing experience clearer and avoids confusion during multi-signer document workflows.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970 Forward-Port-Of: odoo/enterprise#100252 Forward-Port-Of: odoo/enterprise#98256
French financial reports now include balances from deprecated income and expense accounts when calculating retained earnings. This prevents balance sheets from becoming unbalanced for companies moving from the 2024 French chart of accounts to the legally required 2025 version.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
Opening the translation widget for invoice terms and conditions no longer triggers an error when those terms are made translatable by GCC invoice localization. This helps users edit translated invoice text without interruption.
Original PR description
With l10n_gcc_invoice, the narration field on invoice (the Terms & Condition part) becomes translatable. However, when opening the translation widget, a traceback happens as the "fields" (the text-to-fill part) to load don't have a specified name. opw-5269869 Forward-Port-Of: odoo/enterprise#100003
Composite financial reports now apply the analytic grouping filter consistently to their underlying sections. This ensures the filter appears in the interface when enabled, giving users the expected reporting options without extra setup.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100135
This fixes an internal payroll accounting test so it uses the right company when checking account-related partner settings. It helps ensure Belgian payroll accounting remains reliable in multi-company situations, reducing the risk of incorrect accounting configuration going unnoticed.
Original PR description
We are now testing for consistency between the company properties set on partners related to accounting values. opw-5127901 Forward-Port-Of: odoo/enterprise#100192
This update prevents an error when Stripe webhook events include virtual cards with no shipping details. It helps expense card events process reliably instead of failing on missing shipping information.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict Forward-Port-Of: odoo/enterprise#100291
This update resolves an issue where account return tours were failing in nightly builds due to incorrect configurations and outdated code. Specifically, the tour was dependent on optional modules and a legacy feature was removed as it's no longer needed with the new workflow, ensuring the account return process functions correctly.
Original PR description
There were 3 issues. One was that we tries to target a return which was only available when l10n_us_reports was installed. Another one is that we did not have the account_user group set because accountant was not installed. And lastly, the tax return journal was not setup on the company because it is a hook that is called when accountant is installed which was not the case on those nightly build. Also, we had to remove a condition from the return view. Because we could not see the submit and pay button. This was used before the stats_workflow mechanism was present. Now that it is present, it is useless. Runbot error: 234172
Code cleanup and technical improvements
The WhatsApp integration was updated to stay aligned with recent internal changes to how conversation member lists are handled. This keeps WhatsApp-related discussions working consistently after the underlying platform refactor, with no expected change for end users.
Original PR description
This commit adapts the whatsapp code to account for the refactoring of `hasMemberList`. Pr community: https://github.com/odoo/odoo/pull/236510
This update standardizes how XML files are checked and refreshed in electronic invoicing tests for Guatemala and Mexico. It helps developers maintain these compliance-related tests more reliably, reducing the risk of errors when invoice formats or rules change.
Original PR description
This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an…
This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework. This approach has a few major benefits: ### Assert / Save XML When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags. ### Better test naming and optional subfolder management To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`. ### Better `___ignore___` management in assertion XMLs Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so. With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder. ### Save "pure" XML (before applying `___ignore___`) in temporary folder When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons. In addition, this commit also: - add `edi_tags` helper to save all the common tags for EDIs, which also enables `EXTERNAL_MODE` testing inspired by `l10n_mx_edi` - convert some non-assert XML test helpers into a class method - add `XmlCollector` exception to be used to stop a method and collect an XML data for tests in EDIs. (see `l10n_gt_edi`) - refactor `l10n_mx_edi*` modules to use these helpers related-community-PR: https://github.com/odoo/odoo/pull/235565 task-4891206
This update removes an outdated internal messaging function from WhatsApp and Mexican e-invoicing areas. It aligns Enterprise code with the main Odoo platform cleanup, reducing maintenance overhead without expected changes for end users.
Original PR description
\* = whatsapp, l10n_mx_edi Enterprise counter-part. task-5347566 https://github.com/odoo/odoo/pull/236778
This change reorganizes how WhatsApp conversation member online and offline status information is stored in the messaging system. It should not change day-to-day behavior for users, but it helps keep the codebase cleaner and easier to maintain for future improvements.
Original PR description
PR community: https://github.com/odoo/odoo/pull/235248
The option for preparation printers connected through IoT has been moved into the dedicated POS IoT module. This keeps point-of-sale IoT features organized in the right place, making configuration and maintenance more consistent without changing the overall business workflow.
Original PR description
In order to improve consistency between modules, we moved the IoT preparation printer option to the `pos_iot` bridge module. see odoo/odoo#234883 Task: 4954046