Daily updates from Odoo
Friday, July 31, 2026
36 changes · master
Enhancements to existing features
Quality managers can now find existing Quality Spreadsheet Templates in the spreadsheet selector when templates are available. This makes it easier to insert list views into quality reporting templates and reuse them without extra workarounds.
Original PR description
Before this commit: - Quality Spreadsheet Templates were not available in the spreadsheet selector. - Quality managers could not insert list views into existing Quality Spreadsheet Templates. After this commit: - Quality Spreadsheet Templates are exposed in the spreadsheet selector when at least one template exists. - The session `can_insert_in_spreadsheet` flag is enabled for Quality managers in that case. Task: [6321126](https://www.odoo.com/odoo/project/2328/tasks/6321126)
The Documents app interface has been updated to make common actions easier to find and reduce visual clutter. This improves day-to-day document management by presenting a cleaner, more focused experience for users.
Original PR description
Task-6313958
The French localization reporting screens have been updated to work with the latest interface framework used by Odoo. This keeps fiscal declaration and reporting features maintainable and aligned with platform upgrades, with little expected change for end users.
Original PR description
Update the code of l10n_fr_{pdp,reports} to follow the new Owl 3.
task-6353237
Linked:https://github.com/odoo/odoo/pull/278004Online rental bookings now use a working-time calendar instead of simple unavailable-day rules. Customers see date-only selection plus available pickup and return times, reducing booking errors caused by inconsistent rental schedules.
Original PR description
Replace the unavailability days with a resource calendar. Dates are considered valid if the start and return dates are within the working intervals. For non hourly-period products, only the date is checked, while for the hourly-period products, the exact time matters. This prevents misconfiguration issue with a calendar not coherent with the pickup and return times encoded on products. The display of the datepicker is adapted: only display dates. 2 new time selectors are added with the available hours of the linked day. Upgrade PR: https://github.com/odoo/upgrade/pull/9880 task-5083109
Payroll managers can now configure a recurring monthly child bonus directly in an employee's benefits. The amount is automatically reflected in payslip calculations, shown separately on payslips, and included in the relevant net pay, accounting, and withholding tax bases while staying excluded from ONSS.
Original PR description
Before this commit, there was no dedicated way to configure a recurring additional child bonus. Payroll managers had to handle this amount outside the employee's salary package, and it was not automatically included in payslip calculations. After this commit, payroll managers can configure the monthly child bonus from the employee's benefits. Updating the amount triggers a payslip recomputation, and a dedicated salary rule displays the bonus separately on the payslip. The bonus is added to the employee's net-pay and accounting remuneration bases. It is also included in the withholding tax base, while remaining excluded from the ONSS base. Task-6392125
Belgian payroll now makes it easier to monitor voluntary overtime by grouping related entries and adding direct access from employee records. The update also enforces overtime hour limits with validation warnings, helping payroll teams stay compliant and avoid threshold overruns.
Original PR description
Add follow up support for voluntary overtime in Belgian payroll: - Add a salary rule category "Overtime", give it to the overtime time types (VOLOT150/VOLOT200/VOLOTNET and Overtime Belgium) + the voluntary overtime rules - Add a smart button `Overtime` on the employee form view to show all overtime leaves of the employee, grouped by year then by type - Add/adjust the voluntary overtime threshold hours and show a validation error when the employee exceeds the threshold. TaskID: 6048398
Payroll officers now receive warnings on the payroll dashboard when employee data or work schedules may not meet Belgian DMFA requirements. This helps teams correct issues earlier and reduce the risk of payroll reporting blocks later.
Original PR description
In order to aid the payroll officers with their daily tasks and ensure that work schedules and employees personal data are up to the DMFA standards and avoiding any blockings in the future, few warnings have been added to the payroll dashboard. Task: 6299170
Resolved issues and error corrections
When the same delivery order is processed from two open POS sessions at the same time, the system now shows a proper user-facing warning instead of a technical error. This helps staff understand that the order was already printed and avoids confusing error messages during automated Urban Piper order handling.
Original PR description
`* = pos_platform_order, pos_urban_piper` ## Steps to Reproduce: - Install POS Restaurant. - Configure Urban Piper. - Enable "Auto Acknowledge Orders" for a platform(e.g; Zomato) to automatically print delivery orders. - Configure a printer for the POS shop. - Open the same POS session in two different browsers. - Place a test order from Atlas (UrbanPiper). ## Error: `ValueError - This delivery order has already been printed automatically.` ## Cause: When the same delivery order is processed concurrently for both sessions, the backend raises an error when it attempts to print the order again. ## Fix: Replace ValueError with UserError and mark the error message as translatable. sentry-7609743093 Forward-Port-Of: odoo/enterprise#124304
This fix updates Swedish ISO 20022 payment files so they use bank identifiers and party IDs in the format expected by Swedbank. It helps reduce rejected payment files and improves compatibility for Swedish bank payment processing.
Original PR description
Fix some issues with the iso20022 XML file for Sweden:
1. Swedbank doesn't allow the us of `CUST` value in the `SchmeNm`
node but force the `BANK` value.
2. Currently, we use the same Id in both `InitgPty` & `Dbtr`, which
looks to be wrong with Swedbank. The format for Swedbank is
`06{company_registry}B001`.
opw-5395736
Forward-Port-Of: odoo/enterprise#125751
Forward-Port-Of: odoo/enterprise#122119Invoices using Brazil's fiscal reform flow now include the required commercial export tax unit conversion factor when sent to Avalara. This helps ensure tax calculations and reporting use the expected quantity conversion data, reducing the risk of invoice processing errors.
Original PR description
This commit adds the comexTaxUnitFactor to the json sent to Avalara when sending an invoice. comexTaxUnitFactor is a factor that convert sales quantity to comexTaxUnit, its value should be the same as cbsIbsUnitFactor. opw-6396462 Forward-Port-Of: odoo/enterprise#125695
The Payroll dashboard no longer crashes when a payroll structure type has no scheduled pay configured. A safe fallback keeps the dashboard available, helping payroll teams avoid disruption from incomplete configuration.
Original PR description
If one of the Payroll Structure Types has the Scheduled Pay field unset, opening the Payroll dashboard raises a traceback. Steps to reproduce the error: - Install ``hr_payroll`` module - Go to…
If one of the Payroll Structure Types has the Scheduled Pay field unset, opening the Payroll dashboard raises a traceback. Steps to reproduce the error: - Install ``hr_payroll`` module - Go to Payroll > Configuration > Settings > Set Payroll Closing Date > Save - Go to Payroll > Configuration > Structure Types > Create a new Structure Type > Unset Scheduled Pay - Open Dashboard Traceback: ```py AttributeError: 'bool' object has no attribute 'title' ``` https://github.com/odoo/enterprise/blob/9a3ea83a432f42f62076a50fca6bc771a2de96bf/hr_payroll/models/hr_payroll_warning.py#L413-L419 The dashboard collects the scheduled pay values from all structure types and later calls ``schedule.title()`` to build the labels. When a Structure Type has no Scheduled Pay configured, so ``schedule`` becomes ``False``, leading to the traceback. ``_get_schedule_pay`` method can return False at [1], So, It will generate the traceback from below line also. https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L401 Solution: Added a fallback value when default scheduled pay is False. [1]: https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L149-L154 sentry-7583037488 Forward-Port-Of: odoo/enterprise#126127 Forward-Port-Of: odoo/enterprise#122492
Ecuadorian electronic invoices that include Special Consumption (ICE) taxes no longer fail during processing. The update ensures the correct tax information is included in the electronic invoice, helping businesses stay compliant and avoid blocked invoice workflows.
Original PR description
Currently, an error occurs when processing Ecuadorian EDI invoices that use taxes from the `Special Consumptions (ICE)` tax group. **Steps to reproduce:** - Install `l10n_ec_edi` and switch to an EC…
Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.
**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.
**Error:**
```
File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```
**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.
At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.
**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is
that it is not working on the versions where we already introduced the feature.)
[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38
[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377
[here]:
https://www.odoo.com/mail/message/1121493378
opw-6373984
opw-6430589
opw-6423812
Forward-Port-Of: odoo/enterprise#123918Restaurant appointment views no longer crash when a table has no linked resource. This helps staff keep using the schedule reliably even when some table setup details are missing.
Original PR description
When a table doesn't have a resource, the appointment_resource_id is undefined and the gantt renderer was crashing when trying to access its id. This commit adds a check to ensure that the appointment_resource_id exists before trying to access its id. Forward-Port-Of: odoo/enterprise#125331
This fixes an automated test for Mexican point of sale invoicing by ensuring an order is fully synchronized before a refund is started. It helps keep validation of the refund workflow stable and reduces false test failures, without changing day-to-day user functionality.
Original PR description
In this commit: =============== - Fix the `test_mx_pos_invoice_order_and_refund` tour, which fails with the warning: `The amount of the order must be positive for a sale and negative for a refund`. - The failure is caused by the refund flow starting before the original order has been fully synced with the backend. - A previous attempt to fix this in odoo/enterprise#109362 by waiting for `FeedbackScreen.isShown()` was not sufficient. Fix: ==== - Add a `Chrome.waitForOrdersSync()` waiting step to the tour to ensure the original order is fully synced before starting the refund flow. Error: 237980 Forward-Port-Of: odoo/enterprise#124948
New contacts assigned a Partner Level now automatically receive a barcode when they are saved. This ensures front desk partnership processes have the needed barcode immediately, avoiding manual fixes or missing access details.
Original PR description
Steps to reproduce: - Go to Contacts. - Create a new contact and assign a Partner Level before saving. - Save the record. Current behavior: - When creating a new contact with a Partner Level, the barcode is not generated automatically. Solution: - Add barcode generation logic to the create() method so that a barcode is automatically generated when a new contact is created with a Partner Level. TaskId-6236375 Forward-Port-Of: odoo/enterprise#125967
Users can now create Google Booking merchant records without errors when the website app is not installed. The change prevents the system from relying on a website-specific field unless it is available, improving reliability for appointment setup.
Original PR description
Currently, an error occurs when a user creates a Google Reserve Merchant record. **Steps to Reproduce:** - Install the `appointment_google_reserve` module. - Go to `Appointments` > `Configuration` >…
Currently, an error occurs when a user creates a Google Reserve Merchant record. **Steps to Reproduce:** - Install the `appointment_google_reserve` module. - Go to `Appointments` > `Configuration` > `Google Booking`. - Click `New` to create a record. `AttributeError: 'website' object has no attribute 'homepage_url'` After this [recent commit], as part of the context-based website resolution refactoring, the `default_website` record is now available even without the `website` module because it is created in `base` [1]. When a user creates a Google Reserve Merchant record, it attempts to set the default URL using the default website from `base`. However, it then tries to access the `homepage_url` field, which is defined in the `website` module [2]. Since the `website` module is not installed, this raises the error [3]. This commit ensures that before accessing `homepage_url`, it first checks whether the `homepage_url` field exists when creating the merchant record, since this field depends on the `website` module. [recent commit]: https://github.com/odoo/odoo/commit/ae81b6f6074632d1a609387e53f97a61ee6c95f4 [1]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/odoo/addons/base/data/website.xml#L5-L9 [2]: https://github.com/odoo/odoo/blob/ea0e2750a43e337bc6d9a00489a30df3fc0616c7/addons/website/models/website.py#L168 [3]- https://github.com/odoo/enterprise/blob/01b0cf4e2f2e2c63c02c3429d029c90639de1322/appointment_google_reserve/models/google_reserve_merchant.py#L21-L22 Task-6395376 sentry-7630852653 Forward-Port-Of: odoo/enterprise#125680
The Accounting reports now handle cases where a grouped tax used on past journal items has later been changed to a regular tax. This prevents the Journal Report from failing and helps users continue reviewing audit data without interruption.
Original PR description
**Steps to reproduce:** - Install account_reports - Create a tax * Tax Computation: Group of Taxes * Definition: [Add a tax] - Create an invoice with that tax - Confirm the invoice - Edit the tax by changing "Tax Computation" to "Percentage" - Go to "Accounting / Reporting / Audit Reports / Journal Report" **Issue:** A KeyError is raised. **Cause:** While generating the data, a group of taxes is found in the journal items. When trying to retrieve its info from the dict listing the groups of taxes, its ID is not found but the system assumes that it's present. opw-6377465 Forward-Port-Of: odoo/enterprise#125291
Saudi payroll now calculates GOSI contributions without incorrectly reducing them for partial periods. This helps ensure payslips and related accounting tests reflect the expected statutory contribution amounts.
Original PR description
task-id: 6380239 Forward-Port-Of: odoo/enterprise#125349 Forward-Port-Of: odoo/enterprise#124122
Hungarian Intrastat tax returns now work with recent changes to the Hungarian tax report structure. This prevents errors during return generation and helps businesses continue submitting Intrastat information reliably.
Original PR description
Here https://github.com/odoo/odoo/pull/253556, we made few changes in the `l10n_hu` report. We basically split some expresions into multiple small one. This has been done for the integration of ec sales list (a60). But hu intrastat was still using the old expressions, leading to an error. This commit aims to adapt the intrastat code to fit with the new a60 expressions. no-task Forward-Port-Of: odoo/enterprise#122662
This fix ensures German POS fiscal transaction cancellations can proceed even when the original active transaction has missing receipt details. It prevents rejection by the fiscal service while keeping existing transaction data unchanged when available.
Original PR description
When cancelling active transactions, the schema was forwarded as-is from the listed transaction. ACTIVE transactions can have an empty schema, and Fiskaly rejects the cancellation PUT with:
{
"code": "E_TX_NO_TYPE_DEFINED",
"message": "`schema.raw.process_type` must be defined for
updating or finishing a transaction",
"status_code": 409,
"error": "Conflict"
}
Fall back to a minimal CANCELLATION receipt schema when the transaction has no schema, while preserving any schema that is already present.
opw-6345005
Forward-Port-Of: odoo/enterprise#122130The AI icon now appears consistently in areas such as Knowledge, Discuss, Website SEO, and Social posting. This fixes a visual issue where the icon could be missing or incorrectly treated as a custom icon, improving clarity for users interacting with AI features.
Original PR description
__Before commit__ Following odoo/enterprise@866597419, the AI icon was not showing in the Knowledge WysiwygArticleHelper because the icon was set in the CSS on the `.oi-ai-logo` elements. __After commit__ The AI icon is now set everywhere using `data-icon="oi-ai-logo"`. <img width="1129" height="530" alt="image" src="https://github.com/user-attachments/assets/572e4d3b-2926-40e8-bfd2-cd6d1aa47e11" /> task-6377407
Payroll decimal precision settings will no longer be reset to default values when the module is upgraded. This protects company-specific payroll configuration and prevents silent loss of user adjustments.
Original PR description
decimal.precision records are user-configurable settings that may be adjusted per company needs. With noupdate="0", every module upgrade resets the 'Payroll' and 'Payroll Rate' precision values back to their defaults, silently discarding any customization made by the user. This is inconsistent with the standard pattern used across Odoo modules. For example, the 'quality' module correctly loads its decimal.precision records with noupdate="1". The same convention is followed in core addons such as 'product' and 'account'. The forcecreate="True" attribute already ensures the records are created on fresh installations, so noupdate="1" only prevents overwriting existing values on upgrade — which is the expected behavior for configuration data. Forward-Port-Of: odoo/enterprise#120509
Fixes an issue where the Payroll dashboard could crash when checking the “Employees Under Minimum Wage” warning for Belgian companies with multiple CP200 employees. This ensures payroll teams can open the dashboard reliably after employee contract changes.
Original PR description
Opening the Payroll dashboard may crashes with an error: - Have a Belgian company with 2 or more CP200 employees having active contracts - Create or modify a contract for at least 2 of them (this marks l10n_be_computed_seniority_years as dirty for the batch) - Open the Payroll dashboard, the "Employees Under Minimum Wage" warning evaluation crashes In _compute_l10n_be_computed_seniority, the for version in cp200_versions loop was incorrectly referencing self instead of version. Since self is the full batch recordset, self.employee_id returns a multi-record set, causing ensure_one() to fail inside _get_first_version_date. task-6358718 Forward-Port-Of: odoo/enterprise#123000
This fix makes status labels in payroll-related dropdown badges readable again, such as states shown on employee forms. It helps users quickly understand record statuses without confusion or visual obstruction.
Original PR description
Users are unable to read the text labels for record states (such as employee form state). This fixes the problem. task-6432088
This fixes a false collaboration error that could appear while automated Knowledge tours were running, even though collaboration was not involved. The change helps keep test results reliable and reduces noise in build validation.
Original PR description
This aims to fix Runbot build error #937788 ([1]) which wasn't fully fixed by commit [2] (see error #944595 ([3])). A collaboration error was thrown during a tour which makes no use of collaboration. Commit [2] made sure the bus from the previous test didn't persist when running this tour so it doesn't interfere, but it didn't fully reset it. [1]: https://runbot.odoo.com/odoo/runbot.build.error/937788 [2]: https://github.com/odoo/enterprise/commit/a6050dd60c587d09443907bdf955805159dbdb2e [3]: https://runbot.odoo.com/odoo/runbot.build.error/944595 Forward-Port-Of: odoo/enterprise#126195
Studio report editing now preserves an empty paragraph when a user deletes its last character. This prevents accidental layout changes and makes report editing behave more predictably, matching the website builder experience.
Original PR description
Problem: In Studio reports, deleting the last character of a paragraph removes the entire paragraph. Cause: `cleanEmptyStructuralContainers` removes the empty paragraph because it is considered empty. Solution: Disable `cleanEmptyStructuralContainers` for reports same as website builder. Steps to reproduce: - Create a new report. - Add multiple paragraphs. - Leave one paragraph with a single character. - Delete the character. - Observe that the paragraph is removed. task-6368965 Forward-Port-Of: odoo/enterprise#126200 Forward-Port-Of: odoo/enterprise#124834
Polish JPK tax exports now use the vendor bill reference in the purchase document field when that reference is available. This helps exported tax files match official guidance and reduces the risk of mismatched purchase documentation during reporting.
Original PR description
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting >…
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting > Reporting > Tax Report and select `This Month`. - From the dropdown, click `JPK` > `Export XML`. - Open the generated XML file and observe the `DowodZakupu` field. **Observation:** `DowodZakupu` contains the vendor `Bill Number` even when a `Bill Reference` is set. **Root Cause:** At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) instead of using the `Bill reference`(`ref`) when available. **Fix:** This commit ensures `DowodZakupu` contains the `Bill Reference` when it is available in JPK exports. **Reference:** https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41) [1]: https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208 opw-6299827 Forward-Port-Of: odoo/enterprise#126113 Forward-Port-Of: odoo/enterprise#121117
This fix ensures Mexican electronic payment documents calculate invoice balances correctly when payments involve exchange rate differences or credit notes. It helps prevent incorrect payment XML values for fully settled invoices, improving tax document accuracy.
Original PR description
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled.…
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled. https://drive.google.com/file/d/1ntQny0o8bkkfYtY5ZNBK0Yq7Rq0I-yfz/view ### Fix: Sorting partials by "not exchange_move_id" first broke the chronological order whenever the invoice/payment partial itself carried an exchange difference (e.g. a foreign currency payment settled at another rate). This made the residual-chain algorithm consume the credit note's "other_residual" on the wrong payment, so ImpSaldoAnt/ImpPagado/ ImpSaldoInsoluto in the payment CFDI's DoctoRelacionado stayed wrong even though the invoice was fully paid. Populate the exchange move mapping in a separate first pass and sort the partials purely by date/id, so credit notes are always deducted from the correct payment. task-id:[6363092](https://www.odoo.com/odoo/project/49/tasks/6363092) Forward-Port-Of: odoo/enterprise#126061 Forward-Port-Of: odoo/enterprise#124882
Ri.Ba. payment validation now accepts valid San Marino bank accounts in addition to Italian ones. This prevents batch payment validation failures for companies using San Marino IBANs and ensures generated payment files keep the required format.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820 Forward-Port-Of: odoo/enterprise#126208 Forward-Port-Of: odoo/enterprise#121439
Fixed an issue that caused Belgium payroll DMFA reports to fail for student employees. The report now uses the correct student contribution value, helping payroll teams generate required declarations reliably.
Original PR description
[FIX] l10n_be: fix DMFA bug
Bug reproduction:
1 - Go to master → new employee → make it student → joint committee=200
2 - Create payslip -> generate DMFA report
3 - Traceback is there.
Bug cause:
1 - contribution.amount is used for student in DMFA report. 2 - DMFAStudentContribution hasn't amount
2.1 - it has student_contribution_amount field
Bug solution:
1 - Use student_contribution_amount for students instead of amount
task-6410338This update fixes several visual issues where AI and call-related icons could appear misaligned, incorrectly sized, or fail to show in parts of Odoo. Users should see a more consistent interface across AI, Knowledge, Social, Website, Discuss, and VoIP features.
Original PR description
task-6377407
Features or functions removed from Odoo
The old Belgian POS Restaurant fiscalization module has been removed because it is deprecated. Businesses using Belgian blackbox fiscal hardware should move to the replacement module for the newer V2 hardware.
Original PR description
Remove depreciated `pos_blackbox_be` module, which was used for Belgian fiscalization in POS Restaurants. This module is now replaced by `l10n_be_pos_blackbox` in order to operate with the new blackbox V2 hardware.
Code cleanup and technical improvements
This update keeps IoT-related screens and controls aligned with a renamed internal interface in the underlying web framework. It is a technical cleanup that helps maintain compatibility and should not change day-to-day user workflows.
Original PR description
In this commit: - The Owl props API has been renamed to useProps. - Updates the affected IoT-related modules accordingly by renaming imports and replacing `props(...)` with `useProps(...)`. Task:6403054 Community PR : https://github.com/odoo/odoo/pull/278327
This update cleans up AI Website code to match project quality standards without changing business functionality. It helps keep the website-building tools easier to maintain and reduces the risk of small code-quality issues affecting future changes.
This update modernizes parts of online bank synchronization and online payment screens to align with the latest Odoo web framework. It is mainly an internal technical refresh, helping keep banking features reliable and maintainable without introducing notable business workflow changes.
Original PR description
- Replace useService("orm") with usePlugin(ORM)
- Convert account_duplicate_transaction_service into
account_duplicate_transaction_plugin; rename
useCheckDuplicateService -> useCheckDuplicatePlugin
- Replace `static props = {...}` with `props = useProps(...)`
- fetch_missing_transactions_cog_menu uses `orm.unscoped.call` instead
of `orm.call` to keep the RPC alive after component
destruction.
task-6350965This update aligns several enterprise app components with a broader internal restructuring of the communication framework. It should not change day-to-day behavior for users, but it helps keep Approvals, Documents, and Knowledge easier to maintain and evolve.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/279133