Daily updates from Odoo
Tuesday, October 28, 2025
30 changes · saas-18.4
Resolved issues and error corrections
This fix prevents users from adding tax tags to journal items dated before the tax lock date. It helps ensure locked tax reports cannot be changed unintentionally after a reporting period is closed.
Original PR description
Despite the tax lock date, users are able to modify the tax report by adding tags.
**Steps to reproduce:**
Ensure the tax lock date is set
1. Journal Items list view
2. Edit one/many lines that
- have a date before the tax lock date,
- don't have a tax,
- nor tax tags,
- and is not a tax line.
3. Add a new tax tag
**Issue:**
The tax tags are added and might impact a tax report, when you should have received a user error.
**Cause:**
The `write` function calls the `_check_tax_lock_date` which in turn only checks the existing line instead of the values given in the `write` parameters. Since the line has no existing tax tags the check does not fail.
**Solution:**
Call the tax lock check both before and after writing the move line.
Task-5169152
Forward-Port-Of: odoo/odoo#233032
Forward-Port-Of: odoo/odoo#232380Fixed a point of sale issue where selecting details within an order line could make the numpad open and immediately close. Cashiers can now use the numpad reliably when working with order line details such as eWallet balances.
Original PR description
Steps to reproduce: =================== - Click on an orderline - Then click on a detail inside it (e.g., eWallet Balance line) - The numpad first opens and then closes right away Issue: ====== - Clicking on a detail inside the orderline makes the numpad open and close at the same time - This makes it impossible to use the numpad properly Cause: ====== - The click from the child element also reaches the main orderline click - Because of this, the numpad gets two clicks (open and close) Fix: ==== - Added `stopPropagation` in the click handler to block event bubbling - Now the numpad only reacts once and stays open as expected Task: 5000327 Forward-Port-Of: odoo/odoo#232197 Forward-Port-Of: odoo/odoo#227675
This update removes duplicate validation rules for mail link previews that could interfere with database restores between PostgreSQL versions. It helps prevent restore issues for future databases while keeping the existing mail behavior unchanged.
Original PR description
Same as #229274 these constraints are redundant with `required=True` and cause issues when restoring a dump from pg17 to pg18. And much like #229274 this only fixes databases going forward, on existing databases the constraints have to be dropped on the source. Forward-Port-Of: odoo/odoo#233186
Creating invoices from multiple sales orders now keeps orders with different fiscal positions on separate draft invoices. This prevents incorrect tax or account calculations caused by combining orders that must follow different fiscal rules.
Original PR description
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft…
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft invoice. An invoice can only have one fiscal position. This merging causes unexpected behavior, as the accounts and taxes are computed based on the single (and potentially incorrect) fiscal position of the final invoice, rather than the respective fiscal positions of the originating SOs. Solution: This commit modifies the 'Create Invoices' action to group the selected sale orders by their `fiscal_position_id`. It will now create as many separate draft invoices as there are unique fiscal positions among the selected orders. task: 5188965 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233119 Forward-Port-Of: odoo/odoo#232821
Repair service products that are published for sale now show up correctly in the website shop. This fixes a visibility issue that prevented customers from finding and buying services configured to create repair orders.
Original PR description
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product…
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product is ordered 4. Publish the product from the Sales tab 5. Open the website without being signed in 6. Search for that product Observation: ------------------------- The product is not visible on the website shop. Issue: ------------------------- The method `_get_saleable_tracking_types(self)` is used to determine which product service tracking types are considered saleable on the website. However, this method was not defined for repair products, causing them to be excluded from the domain used to fetch saleable products. https://github.com/odoo/odoo/blob/b0203ae02d472bd7522bc21971f0e659766eaffe/addons/website_sale/models/website.py#L301-L308 Solution: ------------------------- Define the `_get_saleable_tracking_types(self)` method for repair products so they are properly included in website listings. opw-5102204 Forward-Port-Of: odoo/odoo#232154 Forward-Port-Of: odoo/odoo#231000
This fixes an issue where some browser pages could make Odoo mistakenly think the signed-in user had changed, causing real-time notification channels to be cleared. Users should now keep receiving their own presence updates reliably, including when sessions are opened or closed in other browser windows.
Original PR description
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing…
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing the worker to incorrectly mark the user as changed. This clears previous channels, which may never be added back. This is particularly noticeable with presence channels: the user's own channel can be lost, preventing them from receiving their own presence updates (e.g. when another browser closes, the user cannot see they are disconnected and cannot correct the value). The user's own presence channel should be added server-side, so the first subscription immediately returns the user presence and the DB should not be taken into account if ommited. task-5096212 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233182 Forward-Port-Of: odoo/odoo#232984
This update prevents an accounting process from failing when it encounters an empty value where a number is expected. It improves reliability by avoiding an unnecessary error for users working with accounting entries.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232965
Bank reconciliation models now correctly apply label rules that exclude specific text, even when some transaction details are empty. This helps accounting teams rely on automated matching rules more consistently and reduces missed reconciliation matches.
Original PR description
Currently bank reconciliation model match only the label type “Contains” The “not contain” type is not working Steps to reproduce: - Open Accounting Dashboard - Access Bank journal reconciliation models (3dots > Models) - Open a [Model] and set: - Label "Not Contains" "Test" - Add a Bank Statement with any label Issue: [Model] won't match Analysis: This occurs because in case the payment_ref or transaction_details contains a NULL value the ILIKE operations will evaluate to NULL, not TRUE or FALSE. Any other comparison involving NULL value will result in NULL and the whole condition will fail opw-5065006 [Task link](https://www.odoo.com/odoo/project/49/tasks/5065006) Forward-Port-Of: odoo/enterprise#97745
Sale orders that use only fixed taxes can now be read through XML-RPC without serialization errors. This prevents integrations and external tools from failing when accessing orders or invoices with this tax setup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232955 Forward-Port-Of: odoo/odoo#232517
Draft sales orders now keep product lines editable when users return to an order. This prevents clicks on a product line from unexpectedly opening the product record, making it easier to change products or add descriptions.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a sales order; 2. add a product that doesn't have an extra description; 3. save & exit view; 4. go back to view; 5. add a description or change the product on the line. Issue ----- Clicking on the product field opens the product record instead of edit mode. Cause ----- It opens the product record because the `canOpen` property is set to `true`. As this is the default value, and isn't getting changed anywhere, the line will always open the product record outside of edit mode. Solution -------- Instead of using OR, check `props.canOpen` AND additional checks. opw-5172115 Forward-Port-Of: odoo/odoo#232861
Creating a new warehouse could accidentally generate many duplicate replenishment routes when an existing global route had been renamed. This fix ensures Odoo reuses the intended route instead, keeping route lists clean and avoiding confusion for inventory teams.
Original PR description
In _find_or_create_global_route, use the asked 'route_name' instead of the potentially modified name of `data_route`. This ensures that if '_find_or_create_global_route' is called with the exact same values a new route will not be re-created. https://github.com/user-attachments/assets/815adf60-aa2d-4699-a79d-f9ad9607cbea ## How to reproduce (in runbot 17.0): - Enable "Multi-steps Routes" - Unarchive route "Replenish on Order (MTO)", change the name, set company to "My company (San Francisco)" - Go to "My Company (Chicago)" - Create new Warehouse => Check all the routes: ~100 MTO routes with the modified name have been created. OPW-5149842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232829 Forward-Port-Of: odoo/odoo#232613
Batch invoice sending now alerts users when the required scheduled process is turned off, instead of failing silently. Administrators are guided to the relevant configuration so they can re-enable it, helping prevent missed invoice deliveries.
Original PR description
This commit raises a RedirectWarning to the cron configuration to inform the user that the batch invoice cron must be enabled. Batch invoices cannot be sent if cron is disabled. task-5122707 Current behavior before PR: If batch invoice send is called and cron is disabled, then it will silently fail and not send. Desired behavior after PR is merged: If batch invoice send is called and cron is disabled, then it will raise a RedirectWarning to the cron configuration. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229318
Quality checks could fail in setups where manufacturing quality is installed without work orders. This change avoids checking a work-order-specific field unless the related module is available, preventing errors when creating or validating quality points.
Original PR description
**Issue:** The attribute operation_id for quality.point is defined in the mrp_workorder module. However, quality_mrp module does not list mrp_workorder in its dependencies. As a result in a system where quality_mrp is installed but mrp_workorder is not, the following error is raised when evaluating the constrain for quality points mesured on Operations. `"'quality.point' object has no attribute 'operation_id'"` **Proposed solution:** Override the constraint in quality_mrp_workorder to include conditions related to operation_id, ensuring that it is only evaluated when the field is available. Forward-Port-Of: odoo/enterprise#97801 Forward-Port-Of: odoo/enterprise#97338
RFQs created from approvals now use the currency configured on the product's vendor instead of defaulting to the company's currency. This keeps purchase requests consistent with other RFQ creation flows and helps avoid pricing or currency mismatches when working with vendors.
Original PR description
Issue: When creating an RFQ from an approval, the created purchase order does not use the currency set on the vendor of the product. Rather, it uses the currency of the company, with the value converted based on the vendor's currency to get the price. This is not consistent with other ways we create RFQs, which all respect the vendor currency. Solution: Pass the vendor's currency into the values sent when creating the purchase order. In the case of modifying an existing purchase order, only modify purchase orders matching vendor's currency. opw-4549937 Forward-Port-Of: odoo/enterprise#97069
This update fixes an intermittent automated test failure in the barcode module by ensuring the screen has finished updating before checks run. It improves confidence in release validation without changing any customer-facing barcode behavior.
Original PR description
This commit fixes a test that sometimes failed, because we didn't wait for an animationFrame after the macro was complete. As a consequence, there was no guarantee that the form view had been updated before the check. runbot error~226829 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233153
Contacts can no longer be deleted when they are already connected to point-of-sale orders. This preserves customer information on past sales records and prevents accidental loss of order history links.
Original PR description
Before this commit, it was possible to delete a contact record even if it was linked to PoS orders, which would cause it to be unlinked from those orders. opw-5164368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231812 Forward-Port-Of: odoo/odoo#231442
UPS shipping labels could fail to generate in production when the sender or shipper did not have a VAT number set. This fix avoids sending an empty tax ID to UPS, so label creation can continue normally for affected shipments.
Original PR description
Only in production mode, if the sender or the shipper's VAT was not set, the UPS answer would be an error, preventing the label generation altogether. This is because we send an empty string if the VAT was not set, and UPS couldn't process it. Forward-Port-Of: odoo/enterprise#98227
This update adds a safeguard to ensure changes to a company's phone number do not unintentionally alter employee information. It helps keep employee contact details stable and prevents confusion when company-level contact data is updated.
Original PR description
Added a test to complement the fix made in this PR: https://github.com/odoo/odoo/pull/229010 opw-5072108
The Documents details panel now consistently shows the email alias management section in list view when an alias is configured. This fixes a regression that could hide alias information and improves stability by ensuring the panel always receives the fields it needs.
Original PR description
Steps to Reproduce =================== 1. Set an alias in settings. 2. Go to a folder in Documents. 3. Open document right panel in list view. -> The email alias section in the document detail panel is missing in the list view. Issue ======= The commit [1] unintentionally change few lines of code in forward-port conflict. It removes `mail_alias_domain_count` from the view and we get undefined in JS. After this commit ================== Added required fields for the details panel to the controller mixin in JS to make it stable friendly and simplify usage regardless of view arch. Adapt selectors of `documents kanban: select a range with SHIFT key` test as we always pass `type` from js which groups documents into folder and file. [1] https://github.com/odoo/enterprise/commit/d278f9013113c6de4b3425fecad5d54a9d4d22b9 Task-5045288 Forward-Port-Of: odoo/enterprise#93401
A bug was fixed where some company accounting setups could fail during upgrades because a missing bank account prefix was handled incorrectly. The system now treats the missing value safely, helping affected localizations complete their accounting migration without interruption.
Original PR description
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False. ```traceback…
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False.
```traceback
module l10n_co: Running migration [$1.0] end-migrate_update_taxes
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/18.0/addons/l10n_co/migrations/1.0/end-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('co', company)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
return self._load(template_code, company, install_demo, force_create)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
self._setup_utility_bank_accounts(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 845, in _setup_utility_bank_accounts
accounts = self.env['account.account']._load_records([
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5526, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5430, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-208>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 997, in create
start_code = prefix.ljust(digits - 1, '0') + '1' if len(prefix) < digits else prefix
TypeError: object of type 'bool' has no len()
```
Databases affected by this traceback error:
https://upgrade.odoo.com/odoo/request/3191023/tbg/2150
task-5167397
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232169This update makes tax calculations more predictable when preparing discounts, down payments, and future combo product flows. It fixes several edge cases where tax details could be reused or shaped incorrectly, reducing the risk of incorrect totals in sales and accounting documents.
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 Forward-Port-Of: odoo/odoo#232284
Refreshing a signature document no longer hides the key action buttons or replaces the document name with a generic label. This keeps the signing flow clear and reliable for users who reload the page while reviewing or signing documents.
Original PR description
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel…
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs - The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error. - Breadcrumbs were not getting set properly on reload. After: - Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context. - Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`. Impact: - Buttons remain visible after refresh. - Correct document name is shown in breadcrumbs. - Ensures a smoother and more stable user experience when viewing documents. task-4805166 Forward-Port-Of: odoo/enterprise#97837 Forward-Port-Of: odoo/enterprise#93589
Fixes an issue where website forms configured to send an email could fail on submission and log an error. The form builder now includes required hidden default values when the email action is selected, helping ensure visitor submissions are processed reliably.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. **Steps to Reproduce:** - Install the `website` module. - Go to `website` > `Click on Edit` > `Drag and drop form.` - Click the form…
Currently, an error occurs when submitting the 'Send Email' form. **Steps to Reproduce:** - Install the `website` module. - Go to `website` > `Click on Edit` > `Drag and drop form.` - Click the form and in actions select again `Send an E-mail` action and `save`. - `Submit the form`, and the error appears in the logs. **Error**: KeyError: 'website_form_signature' **Cause:** This error occurs when submitting the "Send Email" form from the website. When the user chooses the model Outgoing Mails (mail.mail), the email_to hidden field is not added. This is because email_to is only added when the recipient email value is changed from the sidebar via apply [1]. As a result, the email_to hidden field is missing from the form. And the website_form_signature is added from [2], but due to the condition at [3], the code at [2] is not executed. When it is accessed at [4], KeyError is raised. **FIX:** This commit ensures that when the user selects the action model, if there are hidden field , it is added to the form with its default value. [1]: https://github.com/odoo/odoo/blob/3b16debc6d6557334082fdf841b20ef0e31fc9d2/addons/website/static/src/builder/plugins/form/form_option_plugin.js#L863 [2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 sentry-6746753251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the website preview and builder-related files are included in automated quality checks. It helps reduce future issues in the website editing experience by catching code problems earlier before release.
Original PR description
[FIX] web: correctly lint website_preview The goal of this commit is to correct the `_eslintignore` file in order for the linting to correctly lint the `website_preview` files. task-5110180 --------------------------------------------------------------------------------------------------------------------------------------------------------- [LINT] html_builder, website: lint builder related files The goal of this commit is to lint the builder related js files. task-5110180
Fixes an issue where certain website editor placeholders could remain visible after content changes were undone. This keeps the page editing experience accurate and prevents confusing stale elements from staying on screen.
Original PR description
invalid Before this commit, the `selectorHas` and `selectorNotHas` conditions of interactions were ignored when calling `stopInteractions` on a sub-element of the interaction target. For example, in…
invalid
Before this commit, the `selectorHas` and `selectorNotHas` conditions of interactions were ignored when calling `stopInteractions` on a sub-element of the interaction target.
For example, in edit mode, adding or removing a node could invalidate `selectorHas`/`selectorNotHas`, but the interaction would not be stopped as expected.
With this commit, when calling `shouldStop` on an interaction, we now check that `selectorHas` and `selectorNotHas` are still valid. If they are not, `shouldStop` returns true so the interaction is properly stopped.
How to reproduce:
- Edit a website page
- Add an Image Gallery snippet
- Remove all images → The `ImageGalleryEdit` interaction activates to display a placeholder allowing the user to add an image
- Perform an undo
Before this commit:
The `ImageGalleryEdit` placeholder remained visible.
After this commit:
The `ImageGalleryEdit` placeholder correctly disappears.
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-prThis change fixes unreliable automated checks in appointment CRM and helpdesk areas when pages reload or redirect. It helps keep validation runs stable, reducing false failures during releases without changing customer-facing behavior.
Original PR description
\* = helpdesk, website_helpdesk ### Issue: - `appointment_crm_forced_staff_user_tour` fails on steps triggering page unload without `expectUnloadPage: true`. - In `helpdesk_search_ticket_on_portal_tour`, a specific step is failing for `helpdesk` but works when `website_helpdesk` is installed, as the step does not trigger the `beforeunload` event in that case. ### Fix: - Added `expectUnloadPage: true` to steps that trigger a page unload. - Introduced `HelpdeskSearchTicketSteps` class with `_searchTickets` so that the step can be overridden in `website_helpdesk`, removing the `expectUnloadPage` property when installed, since no `beforeunload` event is triggered in that case. runbot-[232987](https://runbot.odoo.com/odoo/runbot.build.error/232987)
This fixes cases where parts of website and HTML editor content that should be editable were incorrectly treated as locked. It helps users edit intended sections more reliably in the website builder and related HTML editing tools.
Original PR description
[FIX] html_builder, *: set contenteditable attribute on correct elements *: html_editor, website The goal of this commit is to fix the behavior of the `extra_contenteditable_handlers` resource; its goal is to mark as editable an element that is inside an `.o_not_editable`. The problem is that this was not working as intended as the elements given as argument to the handler were a list that was filtered of the elements that have an `.o_not_editable` ancestor. Note: even if it is in stable, the `force_editable_selector` resource has been renamed as `content_editable_providers` as a provider is needed in some cases. Because it has become a provider, the `force_not_editable_selector` resource has also been renamed and becomes a provider. This choice has been made to maintain consistency throughout the plugin.
Companies without an applicable VAT number can now connect to CodaBox using their company registry number instead. This prevents connection issues for non-taxable Belgian companies whose VAT field is marked as not applicable.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155 Forward-Port-Of: odoo/enterprise#98162 Forward-Port-Of: odoo/enterprise#98025
This update documents an old, unused speaker biography section in the event website builder so its presence is understood and does not cause confusion during maintenance. There is no expected change for users or websites, as the section was already inactive and had no related styling or behavior.
Original PR description
Problem introduced at [1] (see [2]). In stable, this comments the code to explain the dead code presence. In master, that snippet will be removed, as nobody seemed to have missed him for 4+ major versions and its structure is not perfect (overflow hidden...). Thankfully it should not come with any compatibility issue as it was not associated with any JS/CSS). Maybe a new equivalent will be introduced in master later on. [1]: https://github.com/odoo/odoo/commit/b5c87d86cad1aa2b44f805da0b2d6635aeb85b96 [2]: https://github.com/odoo/odoo/pull/68644#discussion_r903721785 task-4084801 Forward-Port-Of: odoo/odoo#233203
The Field Service map task list now shows appointment times as a single readable value instead of splitting them across lines. This makes task schedules easier to scan for field service users without changing the underlying workflow.
Original PR description
### Steps to Reproduce 1. Open Field Service app 2. Navigate to My Tasks -> Map 3. Observe task pins in the left sidebar list 4. Notice time displays like "10:00" break across multiple lines ### Issue The formatted time display in FSM task map pin list items wraps to multiple lines. ### Current Behaviour Time displays like "10:00" break into separate lines. ### Expected Behaviour Time should display on a single line as one readable unit ### Fix Add text-nowrap class to the time display span in FsmTaskMapRenderer template. This prevents line breaks while preserving the existing layout structure. Task - 5079360 Forward-Port-Of: odoo/enterprise#94778