Daily updates from Odoo
Thursday, November 20, 2025
66 changes · 19.0
Enhancements to existing features
This change lets users specify the place where a service was delivered using the delivery address on a sales order or invoice. That address is now sent to the Brazilian tax and e-invoicing flow, so the issued service invoice can show the correct city where the service was provided.
Original PR description
Purpose: In Brazil, it is common for companies to sell services in one city and provide the services in another city, thus, it is necessary to inform the place of service provision in NFS-e. Users can specify where the service was provided through the delivery addresss on either sale order or invoice. The delivery address will be sent in the request to the tax calculation and edi. Outline of additional attributes being sent: - header.locations.rendered.address.street --> partner_shipping_id.street - header.locations.rendered.address.neighborhood --> partner_shipping_id.street2 - header.locations.rendered.address.zipcode --> partner_shipping_id.zip - header.locations.rendered.address.cityName --> partner_shipping_id.city - header.locations.rendered.address.state --> partner_shipping_id.state_id.code - header.locations.rendered.address.countryCode --> partner_shipping_id.country_id.l10n_br_edi_code task-5124608
The Philippine location database now includes all official provinces as states. This improves address accuracy and makes it possible to configure payroll and other processes at the province level.
Original PR description
Before: -The Philippine localization lacked province data in res.country.state. -Address and payroll setups couldn’t use province-level information. After: -Added all official Philippine provinces as states under the Philippines. Impact: -Improves address accuracy and enables province-based payroll configuration. task-5257793
The IoT service now loads IoT Box information in advance, which helps requests keep working even when connectivity is limited. It also reduces the number of database calls, improving responsiveness and lowering system load for related POS and self-order flows.
Original PR description
In order to allow iot requests to work offline, and also reduce the amount of orm requests sent to the db, we now preload IoT Box records in the `iot_http` service. Task: 5258886 Forward-Port-Of: odoo/enterprise#99910
This update clears existing UrbanPiper menu links and rebuilds them from scratch during synchronization. It helps keep the restaurant menu shown in UrbanPiper accurate and reduces the risk of outdated or duplicated menu connections.
Original PR description
Following this commit: - Flush out all existing UrbanPiper product menu linkages and performs a fresh menu sync. task-5231247 Forward-Port-Of: odoo/enterprise#98994
When half-day or hourly time off was moved to the next month, it could be treated as a full-day absence by mistake. This update keeps the deferred work entry aligned with the actual leave duration, improving payroll accuracy.
Original PR description
When deferring half-day or hourly leaves to the next month, the work entry was incorrectly replaced with a full day duration instead of the actual leave duration. Now splits the work entry to match the exact leave hours when necessary. task-5258753
The transcript download button is now available from the live chat info panel during an active conversation. This makes it easier for internal users to access and save chat records without waiting until the session ends.
Original PR description
Previously, the 'Download Transcript' button was only visible to visitors at the end of a live chat session. This limitation caused confusion since internal users could not download the conversation transcript from the interface. This PR adds the 'download transcript' button to the info panel, ensuring it is accessible from within the chat session as well. Task-5262296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock return wizard now shows one main action button, with the other options styled as secondary actions. The cancel action is also relabeled to "Discard," and users get clearer feedback when trying to return items with zero quantity, making the flow easier to understand and use.
Original PR description
Previously, the return wizard displayed multiple primary buttons, which could confuse users and affect the clarity of actions. This commit updates the wizard to have a single primary button, with all other action buttons changed to secondary for better user experience. Additionally, some button labels have been updated for clarity: - `Cancel` → `Discard` These changes make the return wizard more consistent, intuitive, and easier to use for all types of stock operations. This commit also enables improved user error when attempting to return products with zero quantities. Task - 5144914
This change makes large financial reports compute much faster by reusing already calculated account balances instead of recalculating the same data many times. It reduces waiting time for users running reports, especially on big databases, while keeping the result unchanged.
Original PR description
### Issue Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually…
### Issue
Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).
### Analysis
Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.
### Solution
Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.
For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.
### Benchmarks
Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types
| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |
### References
opw-5130725Resolved issues and error corrections
Website visitors with translation enabled can now edit translatable fields again, such as product names on translated pages. This fixes a regression that prevented some content from being updated in the right language while keeping menu translation behavior working correctly.
Original PR description
[FIX] html_builder, website: allow user to translate a field Steps to reproduce the problem: - With french installed on a website, go to `/fr/shop`. - Enter in translate mode. -> You can not edit…
[FIX] html_builder, website: allow user to translate a field Steps to reproduce the problem: - With french installed on a website, go to `/fr/shop`. - Enter in translate mode. -> You can not edit product names. The problem is that since [1], regular fields are not translatable. This commit does two things: - It modifies the `o_editable_selectors` selector in edit mode to allow translation of regular fields. - Because we revert the logic of [1], the problem that was solved by this commit (translation of a mega menu item) still has to be fixed. To do so, the `o_editable` or `o_editable_attribute` is removed when setting the `data-oe-readonly` attribute on cascaded branded elements. The idea is to follow the same logic than in the `SetupEditorPlugin` where elements with the `data-oe-readonly` attribute are filtered before adding the `o_editable` class. task-5265949 [1]: https://github.com/odoo/odoo/commit/d4d428ff1d5be46135973aa806f206a1076bfcf7 Forward-Port-Of: odoo/odoo#235800
This change adjusts an automated test so it follows the same product-editing flow a user would use in the interface. As a result, the system now correctly detects and reports invalid event ticket settings during testing, preventing false test failures.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL:…
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL: TestEventProduct.test_ensure_event_service_tracking > AssertionError: ValidationError not raised Cause ----- The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30 This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183 As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised. Solution -------- Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected. runbot-234024 Forward-Port-Of: odoo/odoo#236045
This update makes the Discuss app look cleaner on desktop by reducing extra header spacing, fixing a clipped badge in the sidebar, and lowering the message composer. It also aligns typing and livechat guidance with the standard chat window behavior, making the interface feel more consistent and easier to use.
Original PR description
Minor style improvements to discuss app in desktop: - less vertical padding of the header - no cropped badge on mailbox below "New meeting" in sidebar compact - composer is lower The composer was…
Minor style improvements to discuss app in desktop: - less vertical padding of the header - no cropped badge on mailbox below "New meeting" in sidebar compact - composer is lower The composer was higher to give room for "is typing" and "Tab to next livechat" features that were at bottom of composer in discuss app. They were changed to match chat window style: - "is typing" is above composer - "Tab to next livechat" is suggested in placeholder of composer Before (left) / After (right) <img width="1521" height="792" alt="Screenshot 2025-11-18 at 19 05 55" src="https://github.com/user-attachments/assets/216dd9de-601b-44fe-9169-66f50a243992" /> Before <img width="959" height="997" alt="Screenshot 2025-11-18 at 18 23 27" src="https://github.com/user-attachments/assets/9d9dfef0-8412-4a38-b0c7-7f9c66b084e5" /> After <img width="958" height="993" alt="Screenshot 2025-11-18 at 19 05 12" src="https://github.com/user-attachments/assets/cd6a9d14-e058-4159-920c-69778c6b3ec9" />
This fix restores the missing expand/collapse icon in email-style messages when quoted content is shown with a read more/less control. It improves the readability and usability of messages in the web interface by making the toggle button visible again.
Original PR description
Before this commit, when a message is of type "email" and contains parts are in foldable with more/less (like `<quote>`), the icon of the button for fold/unfold is missing. This happens because the icon is `.oi` and requires `odoo_ui_icons`. Message of type "email" have their content inside a shadow DOM, because we want to preserve the style of email inside the web client, at least in white theme. Shadow-DOM prevents the parent document to pass `odoo_ui_icons` thus the Shadow-DOM could not apply expected style on `.oi` icons. This commit fixes the issue by passing the required CSS as stylesheet to the shadow DOM, so that `.oi` icons are working inside the shadow DOM of message content of type "email". Forward-Port-Of: odoo/odoo#228741
This change prevents an error in payroll-related calculations when an employee contract does not have a start date. It makes the system handle incomplete employee data more safely, which helps tests and background updates run reliably.
Original PR description
The test_version_cron_update_no_fields from hr/tests/test_hr_employee.py didn't pass on runbot saas-18.4 due to the absence of a start date of contract leading to an error when trying to substract False to a datetime object. I added a verification in the concerned compute function in order to ensure the employee has a contract_date_start. If it's not the case, I set it to 0 as the compute method needs to compute the target field. Runbot error: 233590 Forward-Port-Of: odoo/enterprise#99815
When a Stripe payment fails because of a server-side validation or API issue, the point of sale now shows the error message to the user instead of hiding it. This helps staff understand what went wrong and resolve payment issues faster.
Original PR description
Before this commit: =================== Previously, Stripe-related RPC calls used `silentCall`, which suppresses backend errors and prevents them from being displayed in the POS UI. As a result, users were unable to see important validation or API failure messages coming from the server After this commit: ====================== Use `call` instead of `silentCall`. Using `call` allows backend exceptions and validation errors to be propagated to the POS frontend, ensuring that the user receives clear feedback when a Stripe request fails. Task-4976972 Forward-Port-Of: odoo/odoo#236009
This update makes the rating cards in Website Slides use the same background color as the rest of the page. It improves visual consistency so the interface looks cleaner and better aligned with the site theme.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" /> Forward-Port-Of: odoo/odoo#236527
The POS now loads only draft delivery orders when a session starts, instead of pulling in every order. This reduces startup delays and makes the delivery flow smoother. A small console warning in the delivery button was also removed.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904This fix prevents the warehouse setting from being reset when users toggle inter-company order options. It ensures the warehouse they already chose stays in place, avoiding accidental changes to a different warehouse and reducing setup errors in multi-company environments.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
When users open the shop floor from a Manufacturing Order, the app now starts on the correct work center and shows the current order. This avoids landing on the wrong screen and makes returning to the shop floor app behave consistently for users.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#99855 Forward-Port-Of: odoo/enterprise#93841
This fixes a problem where group payments could attach foreign-exchange adjustments to the wrong invoices. As a result, invoice reconciliation now shows the correct exchange difference for each invoice, improving accounting accuracy and reducing confusion.
Original PR description
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create…
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create a group payment dated today. Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices. Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed. It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`. In a group payment scenario: - Two partials are created (one per invoice). - Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line). - As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment. opw-5147281 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#235324
This fix prevents Manufacturing orders from crashing when a move line has no product name or unit of measure assigned. It ensures users can still change the scheduled date without triggering an error, improving stability during order updates.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234884
This fix ensures invoices in foreign currencies are rounded consistently when tax totals are recalculated. It prevents small but important differences in journal entry amounts when the exchange rate is set in different places, which helps keep accounting results accurate and consistent.
Original PR description
- Set the tax rounding method to `'global'` in the settings. - Create an invoice in a foreign currency with: - Quantity: `0.80` - Unit Price: `894.34` - Currency rate set on the invoice: `1 / 1189.5` - This results in a journal entry balance of **851,051.57**. - Now set the currency rate directly on the currency instead. - Duplicate the invoice: the journal entry balance becomes **851,053.94**. The issue arises because _sync_tax_lines, triggered when setting the currency rate directly on the invoice, was computing the journal entry balance on a per-line basis, even though the tax rounding method was configured as global. opw-5012817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225407
When importing bank statement CSV files, the system now preserves the statement lines even if an automatic reconciliation step raises a user-facing error. This means users can still see and process the imported lines manually instead of losing the import altogether.
Original PR description
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install…
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install "account_bank_statement_import_csv" - In the bank journal configuration: - Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account - Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account - Create a new transaction for $333.0 for example - Find its Journal Entry and change its reference to 'testref' - have a CSV file like this: ``` label, amount testref,333 ``` - Import this file - Make sure label is linked to label and amount to amount - Import - An error shows, no lines are imported ### Cause: On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192). This rollback cancels the transaction, including the creation of the statement lines. ### Solution: If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward. Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable. Test is not possible as we don't roll back during tests. opw-5138855 Forward-Port-Of: odoo/enterprise#99073
This update prevents regular users from triggering a signature-related option that they are not allowed to access. As a result, the signing flow no longer breaks for non-administrators when this feature is unavailable to them.
Original PR description
This pr is a wip onchange on only_autofill_readonly need to access a field only accessible to system administrator. Disable the feature is the user is not system administrator
This fix prevents overtime work entries from being generated when an overtime ruleset has no rules marked to pay extra hours. It ensures payroll records only include overtime that is actually meant to be compensated, avoiding incorrect work entries and possible payroll confusion.
Original PR description
## Steps to Reproduce 1. Create a Overtime ruleset with **none** of the rules have "Pay Extra Hours" checked. 2. Assign this ruleset to an employee. 3. Generate attendances that normally produce overtime. 4. It will create work entries based on these attendances. Navigate to work entries in payroll. ## Issue Even when none of the rules are checked as "Pay extra hours", It will still generates overtime work entries. ## Fix Filtered out work entries inside `hr.work.entry` create() method: - When the ruleset linked to work entry's version has no paid rules, overtime work entries are skipped and not created. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents an error when validating a Sendcloud delivery on orders that include a down payment invoice. It skips non-product sales lines during customs price calculation, so deliveries can be completed normally without a traceback.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This fix makes JSON fields more tolerant when they receive common business objects such as domains or frozen dictionaries. It reduces the risk of errors when storing and retrieving unstructured data in the system.
Original PR description
The field did not change for quite some time. It mainly serves as a way of storing and retrieving some unstructured data. Use default serialization function when assiging values to Json fields. Some business code may assign domains or frozendicts to json fields. That should not fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix lets users who are not HR officers send feedback requests without running into access errors. It improves the appraisal workflow by allowing employee information to be read safely for this specific action, so the process works as expected for more users.
Original PR description
Since we cannot ask a feedback when we are not an HR officer because we don't have acces to employees and we get an access right error when we try to ask feedback. So we use the hr.public.version mecanism to allow too read the employees without rights.
This update fixes an issue where the push-to-talk microphone could stay active after switching away from the call tab, even if the key had been released. It makes calls more reliable and prevents users from being unintentionally heard after changing tabs.
Original PR description
Before this commit, when using push-to-talk in a discuss call, sometimes the push-to-talk was kept on although user had it released. Steps to reproduce: - do not use discuss extensions' push-to-talk key - start a call - enable push-to-talk with chosen shortcut - press and hold the push-to-talk key - switch to another browser tab while keeping the push-to-talk key pressed (e.g. alt-tab while holding push-to-talk) - release push-to-talk key => Even after a long time and coming back to the call tab, the push to talk is still on This happens because the release of push to talk is designed with keyup intercepted on the call tab. While this happens most of the time, sometimes the keyup is triggered outside of call tab and never in call tab, thus the push-to-talk is not released. This commit fixes the issue by triggering a push-to-talk release when unfocusing the tab. task-[4707634](https://www.odoo.com/odoo/project/1519/tasks/4707634)
Reprinting a previous receipt in the Italian POS now prints the selected order instead of always printing the most recent one. This fixes a customer-facing issue that affected order lookup and receipt reprints at the point of sale.
Original PR description
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian…
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian POS 2. make 2 sales with a different product (easier tracking) 3. open the "orders" view 4. try to reprint the ticket of the firt order result: the receipt of the second order is printed the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt. With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt. IMPORTANT NOTE: In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner. opw-5008702 opw-4882480 Forward-Port-Of: odoo/enterprise#99842 Forward-Port-Of: odoo/enterprise#96122
This change relocates a portal-related customization from the Rating module to the Portal Rating module, where it belongs. It keeps the module structure consistent and reduces the risk of dependencies being mixed up in future updates.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236436 Forward-Port-Of: odoo/odoo#236249
This fixes an issue where the message composer could fail when there was no existing message linked to it. The update makes suggestion loading more reliable, preventing an internal error and improving the user experience.
Original PR description
This commit solves a runbot issue created by the debounced nature of the suggestion fetch. A composer could not have a message associated with it and was therefore failing to find the related thread. Now, the thread is set to undefined in that case since we do not need the result anyway. fixes-runbot-230311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236262
This update makes the Swiss payroll transmission tests work independently from accounting-specific setup. It reduces test coupling, making the payroll module easier to validate and less likely to fail because of unrelated accounting configuration changes.
Original PR description
Forward-Port-Of: odoo/enterprise#99748 Forward-Port-Of: odoo/enterprise#98672
The activity counters in the top bar now show the correct number of late, due today, and future items for Tasks, To-Dos, and Mailings. Previously, multiple activities on the same record could be counted more than once, making the counts appear too high and less reliable.
Original PR description
Issue: When multiple activities were created on a single record (e.g., a Task, To-Do, or Mass Mailing), the systray counters for late/today/future activities would incorrectly count *all* of them. The standard behavior is to count only one (the most urgent) per record. Cause: Modules that split activity groups: `project` (for Tasks/To-Dos) and `mass_mailing` (for Email/SMS), used custom counting logic. This logic was outdated and did not follow the "one count per record" rule. Solution: Refactor the custom activity-grouping logic to make the count conform to the general rule again. This aligns all systray counters, ensuring Tasks, To-Dos, and Mailings are now correctly counted only once, based on their most urgent activity. Task-5059640 Forward-Port-Of: odoo/odoo#226940
This change prevents an error that could appear when opening payments from a batch invoice view. The system now only applies invoice-specific details to invoice records, avoiding confusion and interruptions for users working with payments.
Original PR description
Repro: - Create DDM for a client - Create 4+ invoices for him - Pay with SEPA - Go to batch payment set it with SEPA - Add all the invoices and set the date to any date <5 days from today. - A yellow line will appear along with (View All).. / click it - From the view click on any payment. - Exception arises saying made_sequence_gap not found in account.payment Issue: made_sequence_gap belongs to 'account.move' incompatible with 'account.payment' causing the exception. Solution: Here the view_duplicated_moves_tree_js view is intended for account.move elements not for account.payment ones, So I included it only when the resModel is account.move. opw-5149260 Forward-Port-Of: odoo/odoo#233450
This fix closes a gap that could let live chat visitors initiate calls, even though the button was already hidden in some cases. It ensures the server also blocks these calls, keeping live chat behavior consistent and preventing unauthorized call starts.
Original PR description
In [1], we fixed an issue where the start call button would be visible to portal partners. We do not want visitors to initiate calls on live chats. However, there also is a guard in the `rtc` controller which only checks that public users cannot start calls. The server code should also be adapted to properly ensure no live chat visitor can start a call. [1]: https://github.com/odoo/odoo/pull/236272 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#236495
The calendar day view now keeps event titles visible instead of cutting them off on mobile devices. This makes it easier for users to quickly identify what each event is without opening it.
Original PR description
Before this commit, when the user goes to a calendar view in day to check what he have to do. He cannot see the event title properly in his mobile phone since the title is truncated. This commit makes sure the event title is not truncated to clearly see the whole event title. Before the fix: <img width="1172" height="802" alt="image" src="https://github.com/user-attachments/assets/f85a4a03-89a3-48c8-bda7-38e72854ce1f" /> After the fix: <img width="1179" height="808" alt="image" src="https://github.com/user-attachments/assets/7b0b31ba-10f5-412b-837b-8399c78c5bac" /> Forward-Port-Of: odoo/odoo#235823
This fix prevents an error in Documents when a CRM lead linked to an upload request has been deleted. The related document now handles the missing record safely, so users can open Documents without seeing a traceback.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
This update prevents a crash that could happen when users open agent report charts grouped by help status in live chat. It makes help-related chat sessions load normally again, improving reliability for support teams reviewing chat activity.
Original PR description
The `help_status` field of the channel member history model is used to quickly find sessions where help was requested/provided. However, the field exposes a `_search` method that doesn't exists which lead in a crash when clicking on the agent report bars when grouping by `help_status`. This field is stored so we don't need the search. 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#236648
This update keeps the external tax sales feature aligned with recent changes in the core Odoo community code. It helps prevent test or behavior mismatches so the sales experience remains reliable.
Original PR description
See Also: - https://github.com/odoo/odoo/pull/227241
The sign sending wizard now avoids checking another user’s signature or initials unless it is actually needed. This prevents a permissions error when preparing documents with multiple roles and multiple internal users, making the signing flow open reliably.
Original PR description
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions: - sign.template with signature/initials fields and more than one…
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions:
- sign.template with signature/initials fields and more than one role
- more than one sign user (internal user)
```
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 341, in _compute_only_autofill_readonly
not (item.type_id.name == 'Signature' and request._get_user_signature(user, 'sign_signature')) and
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 323, in _get_user_signature
return user[signature_type]
~~~~^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 6680, in __getitem__
return self._fields[key].__get__(self)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/fields.py", line 1646, in __get__
record._check_field_access(self, 'read')
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 3426, in _check_field_access
raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
```
This commit ensure that we don't try to access the signature/initial field of another user when it is not necessary.
task-5271648This fix corrects the timesheet total displayed on Helpdesk team pages when timesheets are configured in days or half-days. It prevents values from being overstated, so users now see an accurate summary of logged time.
Original PR description
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4.…
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4. Open the team’s settings and observe the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the team’s settings and observe the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------ After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed. Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36 For ex: Consider unit_amount = 20 minutes: **Before** Case 1: Encoding method = Hours/Minutes (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 1 = 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 8 = 160 Days --> INCORRECT **After** Encoding method = Days/Half-days (unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor (20 * 1) / 8 = 2.5 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. **NOTE:** Before this change, when the user opened the timesheet sublist view in debug mode and clicked the View button, it opened the default form view of the `account.analytic.line` model instead of the intended timesheet form view. This allowed editing of the Unit of Measure (product_uom_id) field also. To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41). Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related community PR: https://github.com/odoo/odoo/pull/233803 Forward-Port-Of: odoo/enterprise#98545
The LinkedIn integration was updated to use a newer API header version after the previous one was sunset. This helps keep social account publishing connected and working with LinkedIn’s current API requirements.
Original PR description
This commit updates the linkedin version header so that we can use the version of the API. Our actual version was recently sunset, needing the change of version to be done. task-5271712 Forward-Port-Of: odoo/enterprise#99759
The project dashboard now shows the correct timesheet totals when time is entered in days or half-days. This fixes a display error that could make the stat button show much larger values than expected, helping teams trust the figures they see at a glance.
Original PR description
Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 20 hours) 4. Open the project dashboard…
Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 20 hours) 4. Open the project dashboard and check the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the project dashboard and check the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------- After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143 The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234 **Before** Case 1: Encoding method = Hours/Minutes Consider allocated_hours = 80 Hours, total_timesheet_time = 20 Hours Then: uom_ratio = 1/1 => 1 allocated = 80/1 => 80 Hours effective = 20/1 => 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days Consider allocated_hours = 80 Hours, total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it) Then: uom_ratio = 1/8 => 0.125 allocated = 80/.125 => 640 Days effective = 2/0.125 => 16 Days --> INCORRECT **After** Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method) and total_timesheet_time = 2 Days (already in days, no conversion). Then: uom_ratio = 1/8 => 0.125 allocated = 80*.125 => 10 Days effective = 2 => 2 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related enterprise PR: https://github.com/odoo/enterprise/pull/98545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233803
The “View Quotation” button in purchase order emails now sends recipients to the correct company website instead of the default site. This prevents confusion for users working across multiple websites or companies and ensures customers land on the expected page.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Host a server with demo data on localhost; 2. create & switch to a second company; 3. have a website linked to the second company; 4. set the website's domain to http://2.localhost:8069; 5. create a purchase order; 6. send order via email; 8. open mail via Settings / Technical / Email / Emails. Issue ----- The "View Quotation" button links to the default URL instead of the second company's website. Cause ----- The button added via `_notify_get_recipients_groups` only adds a relative URL, which then defaults to the database's base url when sent. Solution -------- Use an absolute URL, using the order's `get_base_url` method. opw-5035391 Forward-Port-Of: odoo/odoo#236598 Forward-Port-Of: odoo/odoo#233255
This update makes section and optional-line handling more consistent in sales and accounting screens. It fixes visibility rules, move/reorder behavior, and default quantities so users see fewer confusing actions and get more predictable totals and section states.
Original PR description
This PR consolidates multiple fixes and improvements across **account**, **sale_management**, and **sale** to make the section widget more internally consistent. It addresses visibility rules,…
This PR consolidates multiple fixes and improvements across **account**, **sale_management**, and **sale** to make the section widget more internally consistent.
It addresses visibility rules, optional section logic, resequencing behavior, and some configurator quirks.
---
### **1. Section Widget: Hide Prices / Hide Composition Logic**
* Subsections under a hidden section now correctly disable both *Hide Prices* and *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices, but may still hide composition.
* Mutually exclusive states: a section cannot have *Hide Prices* and *Hide Composition* active at the same time.
* Resequencing a subsection under a *Hide Composition* section resets all its state flags.
* Removed confusing buttons:
* “Add a Section” inside a section
* “Add a Subsection” inside a subsection
---
### **2. Optional Section Behavior (sale_management)**
* Optional sections and subsections cannot activate *Hide Prices* or *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices or become optional (but can hide composition).
* Resequencing into a section with *Hide Composition* resets all child states to `false`.
* New lines inside optional sections default to quantity **0**.
* Setting a section as optional resets all nested `collapse_*` states.
---
### **3. Resequencing Logic for Optional Sections**
Improved behavior when moving sections and lines:
* **Quantity rules**
* Moving a line **into** an optional section → qty → `0`
* Moving a line **out** of an optional section → qty → `1`
* Same logic applies when moving entire sections that change which lines fall under them.
* **Recalculation rules**
* Moving a section **up**:
* Recompute all lines under the moved section.
* Recompute all lines between old/new positions.
* Moving a section **down**:
* Recompute all lines under crossed sections.
* Recompute all lines between old/new positions (excluding overlaps).
---
### **4. Combo Line Move Fix (sale)**
* Unsaved combo lines were missing *Move Up/Down* due to `virtual_id` not being considered.
* Updated logic to include `linked_virtual_id` so combos can be moved even when unsaved.
---
### **5. Other Fixes**
* Made dynamic conditional labels translatable (Hide/Show Prices, Hide/Show Composition, Set/Unset Optional).
* Updated the relevant XPath introduced in earlier commits.
* Removed an archived product from quotation template demo data.
* Added mobile UI controls for section toggles (`collapse_prices`, `collapse_composition`, `optional`).
* Configurator adjustments for optional-section products:
* Hide quantity controls, price, and total.
* Added products default to qty `0` inside optional sections.
See Also:
- https://github.com/odoo/enterprise/pull/99188
task-5082193This update adds automated coverage for mention suggestions inside channels that are limited to specific groups. It helps ensure users continue to see the correct mention behavior in these restricted discussions after future changes.
Original PR description
This commit adds a test for mention suggestions in group-restricted channels (`group_public_id`). task-5258925 Forward-Port-Of: odoo/odoo#235478
This update fixes two issues on the recruitment website: visitors who are not logged in will now be redirected to the correct local job page, and job counts will display correctly even when users cannot access all underlying records. It also corrects a counting error that could show the wrong number of open jobs when results were grouped in a different way.
Original PR description
This commit fixes 2 bugs: When you are not logged in and geolocalized, we don't redirect the visitor to the right country because the visitor cannot read hr.job, so the count will always be 0. Now we use sudo to have the count whether you are logged in or not. Another bug is in compute_filter_selection_counters: in case you provide a key_getter that is not the same as the grouping_field, when we count, we only keep the last count in case of duplicates. Eg, if you group by address_id and count the address_id.country_id, you will get the count of hr.job open in the last office you iterate over. Forward-Port-Of: odoo/odoo#234713
The Italian monthly VAT report now calculates the VP6 due/deductible line correctly. This fixes cases where the report could show an inflated total, helping ensure more accurate VAT reporting.
Original PR description
The VP6 - VAT due/deductible line of the Italian Monthly VAT Report, introduced in https://github.com/odoo/odoo/commit/51a72ab42d118d6fb0eb3e3545a09e10019b9140, was using an incorrect `formula`. For instance, €200 due and €100 deductible resulted in €300 instead of the expected €100. This commit fixes the computation. Ticket [link](https://www.odoo.com/odoo/project.task/5178831) opw-5178831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The helpdesk ticket view was updated so the status badge uses the new widget setup correctly. This keeps the interface working smoothly after an internal performance-related change and helps avoid display issues for users.
Original PR description
This commit adapts the definition of the field using the `badge_rotting` widget since that widget no longer extend to SelectionBadge widget due to a perfomance issue.
This update changes how stage/status badges are shown in list views so they no longer trigger extra background requests for each project. The result is smoother performance when users review and update many records at once, especially in task, lead, and applicant lists.
Original PR description
Before this commit, the rotting feature uses the selection_badge widget to be rendered in the list view. The problem is the selection_badge will do one rpc per project for the tasks displayed in the list view of all tasks to have all available stages when the user wants to update the stage. This commit changes the widget used to use a custom many2one field widget for rotting in list view to make sure no extra rpc is made.
When processing kit components in the barcode app, scanning an available serial/lot now updates the originally reserved line instead of creating a separate one. This prevents unnecessary backorder prompts and makes delivery validation behave as users expect.
Original PR description
### Issue: Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that…
### Issue:
Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.
### Steps to reproduce:
- Create a kit product with a kit BOM:
- 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation
### Cause of the issue:
Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does, the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921
### Fix:
In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.
opw-5100026
Forward-Port-Of: odoo/enterprise#99845
Forward-Port-Of: odoo/enterprise#98589Mail information is now fetched using the correct company access rules, so users only receive the data they should see. The broader access was kept only for avatar cards, where it is needed, which helps avoid loading extra information by mistake.
Original PR description
Before this commit, all mail data were retrieved with a context containing all companies ids, which therefore was fetching more data than expected. This behaviour was the desired one only for the `avatar_card`. With this commit, we revert the context to what was existing previously and only apply the all companies context to the avatar card. task-5322823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
We fixed an issue that added unwanted blank space around horizontal lines in mass mailings. This makes email layouts look cleaner and prevents spacing problems when using certain content snippets.
Original PR description
This [commit] introduced an issue in `mass_mailing` where `[data-selection-placeholder]` paragraph take up vertical space when they were not designed to. How to reproduce: - create a new mass_mailing - add the snippet "pricelist" Issue: - Horizontal lines have extra blank space around them (empty `[data-selection-placeholder]` paragraphs Resolution: - Use the related style asset for these nodes from html_editor, and add `!important` on the margin-bottom style property value, to ensure that the Design Tab does not override it. - Since `mass_mailing` does not use `web.assets_frontend` anymore, files from new features in the `html_editor` may not automatically be included in `mass_mailing` bundles. A future task will refactor assets bundles so that this problem does not occur again. [commit]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d task-5265692
This update makes the Belgian POS black box communication more resilient by retrying when the device returns an invalid response or a NACK. It also enforces the documented 1.5-second maximum timeout, helping reduce failed transactions caused by temporary device communication issues.
Original PR description
Following documentation, max timeout should be 1.5s and we should retry 3 times on every bb NACK/invalid data. Forward-Port-Of: odoo/enterprise#99911 Forward-Port-Of: odoo/enterprise#99705
This fix prevents an error that could appear when a helpdesk ticket is moved to Done or Canceled after SLA working hours were cleared. It ensures the system only checks working hours when that setting is actually enabled, avoiding interruptions for support teams.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
This change prevents a crash that could happen when reopening a Point of Sale register with the default preset set to Takeout. It ensures the register only creates a new order at the right stage, so users can reopen the register normally without seeing a traceback.
Original PR description
STEPS TO REPRODUCE: -------- 1. Set default preset as Takeout in configuration. 2. Open a register than Close the register. 3. Reopen the register. 4. Observe traceback. CAUSE: ----------------- LoginScreen created an order before the ProductScreen was loaded causing preset logic to access undefined order data. FIX: ----------------------------- Create a new order only when the selected screen is ProductScreen: Task-5237713 Forward-Port-Of: odoo/odoo#234494
This update fixes an issue where card images could show white borders when a hover animation was applied on the website. It improves the visual presentation of image cards so they stay properly filled and look clean when users edit and preview pages.
Original PR description
Step to reproduce: 1. Open website 2. Click edit button and drop s_three_columns snippet 3. Click image and change animation option into hover 4. Some extra white space shown. Before this commit: Applying a hover animation on card images caused the `object-fit` property to unintentionally switch from `cover` to `contain`, resulting in visible white borders around the image.This happened because of the `geo_square` shape, which is automatically injected when a hover effect is applied and no user shape is chosen. This behavior was intentionally introduced in PR [1]. After this commit: Now cropped images use object-fit: contain to preserve the visible properly. and after stretch option apply it can take cover of this container. so his ensures the image fully covers its container without leaving any white gaps. [1]:https://github.com/odoo/odoo/pull/119197 task:4875770 Forward-Port-Of: odoo/odoo#215766
This change corrects missing test information in the VoIP test suite so automated HOOT runs no longer fail on invalid component data. It improves test reliability and helps ensure VoIP checks complete successfully during development and validation.
Original PR description
Before this commit, running VoIP tests in HOOT results in this error: > Global OwlError: Invalid props for component 'TabEntry': 'title' is not a string, 'phoneNumber' is not a string This is because one of the test is setup with incomplete data (no phone number). After this commit, test data is correctly set with a phone number, fixing the props validation error.
This change fixes an issue in the HTML editor where using Select All and Backspace could leave part of a mention behind. It ensures mentions are removed correctly when users clear the entire message, making editing behave as expected.
Original PR description
currently, when selecting all content (ctrl+A) in the html composer and deleting it (Backspace), if there is a mention in the content, only the text part of the selection is deleted, the rest remains. To reproduce: 1. mention a partner in the html composer, type some text after. 2. selecting all content (ctrl+A) and delete it (Backspace). 3. only one character will be deleted, the rest remains. This is the select all selects the deepest text nodes, meaning that the ndoe in the mention link will be selected. However, it is inside a protected node, so will lead to this issue. This commit fixes the issue by overriding the select all behavior when the selection contains protected nodes, to select the whole protected node instead of its content. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how changes made in the document sharing wizard are saved when allowing link access. As a result, link-sharing settings are now applied properly and users can rely on the updated access options being kept.
Original PR description
This commit fix the 'action_allow_link_access' method in 'documents.sharing' model by adding the 'WRITE_VALUE_PREFIX' to the updated fields. Otherwise the changes wasn't taken into account. Task-5220965
Mentions placed directly in the message editor are now automatically wrapped correctly, which prevents them from becoming stuck or difficult to edit. This improves the reliability of typing and editing messages, especially when working with mentions.
Original PR description
In some cases, mentions can be inserted directly into the editable area without being wrapped in a base container. This can lead to issues when trying to edit or delete the mention, as the mention is a protected node. This commit updates the MentionPlugin to ensure that any mentions found directly under the editable area are wrapped in a base container. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents conditional display rules from reappearing incorrectly after changing the recipient model and using undo/redo in the mass mailing editor. It keeps the snippet state accurate, avoiding invalid rules that no longer match the selected model.
Original PR description
There is an issue with conditionally visible snippets in `mass_mailing` where a user is able to undo in the editor the reset of a filter caused by a recipient model change. How to reproduce: - Create a mass_mailing and add a conditional display rule on a snippet - Change the recipient model - undo, then redo Issue: - The rule appears again on the element, even though the model still has the new value. The domain is invalid, since it applied only on the previous model Resolution: - Make the `data-filter-domain` a `system_attribute` so it is not registered in the editor history. To inform the view that there was a change, `onChange` is called directly when the attribute value changes. task-5263043
This change reverts a recent update that was causing some journal entry lines to be calculated incorrectly when users added new lines. It helps ensure debit and credit amounts are computed reliably again during editing, preventing accounting errors in the interface.
Original PR description
This reverts commit 17d0e67106a30a46d608331680e5094dbc44e2e0. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. no-task Forward-Port-Of: odoo/enterprise#99875
This update reverts a change that was causing journal entry lines to behave incorrectly when users added or edited entries. It restores reliable automatic calculation of debit and credit amounts, which helps prevent posting and entry issues in accounting workflows.
Original PR description
This reverts commit 6ed1e43b3f7d53c6a45fe24a1c68f8386e6adf8e. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. In stable versions, `journal_line_ids` is: * Kept but deprecated. * Made non-exportable. The field will be removed in `master`. task-5241650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236457
This fix prevents Point of Sale refund orders from breaking after an upgrade when they were created with older data patterns. It ensures existing refund records can still be opened and processed normally, reducing upgrade-related errors.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224515 Forward-Port-Of: odoo/odoo#221355
Documentation and clarification updates
This change adds a signed contributor license agreement record for Trung Tin Nguyen. It is an administrative update that confirms the contribution can be accepted under Odoo's contribution rules.
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