Daily updates from Odoo
Wednesday, April 22, 2026
57 changes · saas-19.2
Resolved issues and error corrections
Fixed an issue on invoices where choosing today’s date for a currency rate did nothing. Users can now select today and have the correct rate applied, making currency conversion selection behave as expected.
Original PR description
On an invoice, using the date picker to choose the currency rate did not allow picking today's date. Steps to reproduce: - Activate a currency - Add currency rate for today, yesterday and tomorrow - Create a new invoice - Select the newly activated currency - Pick yesterday's date - Pick today's date Current behavior: picking today's date close the date picker without doing anything Expected behavior: picking today's date close the date picker and apply today's currency rate (or latest if today's doesn't exist) Cause: The date picker was opened with today's date selected, preventing selecting it again. Opening the date picker with the right date selected isn't possible as we don't save the currency rate date. It would require doing a reverse search among the currency rate date which might be wrong as the currency rate can be customized. opw-6046169 Forward-Port-Of: odoo/odoo#258368
The currency rate service now uses a configurable timeout when contacting mindicador.cl instead of a fixed 30-second limit. This helps avoid missed daily exchange rate updates when the external service is slow, reducing gaps in stored currency rates.
Original PR description
The mindicador.cl provider had a hardcoded 30s timeout on its HTTP requests. The mindicador.cl service is sometimes slow around rate publication time, causing read timeouts that make the cron silently skip currency rate creation for the day due to HTTP Timeouts, leaving permanent gaps in res.currency.rate. Make the timeout configurable through the `mindicador_api_timeout` system parameter (defaults to the previous 30s). opw-6126027 Forward-Port-Of: odoo/enterprise#114153
This fix ensures that employee working schedule hours are recalculated when the day period is changed. It prevents errors in attendance views and keeps schedule data accurate after edits to lunch, morning, afternoon, or full-day periods.
Original PR description
Since #217895, `duration_hours` is now stored and needs to be recomputed when we change the attendance's `day_period` from lunch to morning/afternoon/full_day otherwise we will run into division by 0 in `_get_attendance_intervals_days_data`. ### Steps to reproduce 1. Change the day period of one of the working hours of a working schedule from Lunch to Morning. 2. Open the attendance overview including the attendances of an employee that has the working schedule from step 1. opw-6129881 Forward-Port-Of: odoo/odoo#259904
Approval request printouts now fall back to the request owner’s language when no contact is set, instead of losing translations. This ensures printed approvals appear in the expected language even when the contact field is optional.
Original PR description
Steps to reproduce: ------------------ 1. Install Approvals. 2. Select an approval type from Approvals > Configuration and ensure the 'Contact' field is not required. 3. Install a second language (e.g., Arabic) and switch the user's language. 4. Create a new approval request with this approval type and set user as the request owner. 5. Try to print the approval request. Current behavior: ----------------- The report is only translated when partner is present because it translates using `partner_id.lang`. Since the partner is not required in all cases, `lang` can evaluate to False when it is missing, causing the report to bypass translations. Expected behavior: ------------------ The report should fall back to the request owner's language or the system's default language if the partner is not available. opw-6010222 Forward-Port-Of: odoo/enterprise#112476
Mobile portal users can now upload files into shared document folders reliably. This fixes an issue where selecting a file did not complete the upload on phones because the upload menu closed too early.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Create a portal user and share a document folder with edit access 3. Log in as the portal user on a mobile device 4. Try to upload a document inside the…
Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder
Issue:
- After selecting a file from the file picker, the document is not uploaded.
Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view
Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`
opw-5937105
Forward-Port-Of: odoo/enterprise#108486This fix prevents an error when exporting the General Ledger for a Peruvian company that includes draft invoice entries. Users can now complete the export normally, even when some accounting entries are not yet finalized.
Original PR description
**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117 Forward-Port-Of: odoo/enterprise#113405
This change prevents access errors that could appear when users set or update suppliers in replenishment for products shared across multiple companies. It ensures only the appropriate company’s suppliers are used, so users can work without unexpected interruptions.
Original PR description
Issue before this commit: ------------------------------------------ In replenishment (multi-company setup), a 'read' access error occurs while setting the supplier, changing the replenishment unit,…
Issue before this commit: ------------------------------------------ In replenishment (multi-company setup), a 'read' access error occurs while setting the supplier, changing the replenishment unit, or changing the min/max when there are suppliers across multiple companies. Steps to reproduce: ------------------------------------------ 1. Install purchase_stock. 2. Create a storable product. 3. Add one vendor for company A and one vendor for company B. 4. Make sure that only company A is active. 5. Create an orderpoint for company A (min/max = 0) and set the route to 'Buy'. 6. Try to set the vendor. Notice that an access error occurs. Cause of the issue: ------------------------------------------ This issue occurs because the `seller_ids` cache gets polluted with suppliers from multiple companies. As a result, when `self.seller_ids` is accessed [1], it returns vendors from both active and non-active companies, ignoring the current company context. [1] https://github.com/odoo/odoo/blob/47deb9f13627a26d6a3179399bd965f639fde436/addons/product/models/product_product.py#L1016 Since users are not allowed to read records from non-active companies, this leads to a read access error when those supplier records are accessed. * Cause of the cache pollution: The cache gets polluted with records from another company because `product.seller_ids` [2] is accessed in a `sudo()` environment. This happens due to the `qty_to_order_computed` field, which is stored and computed. By default, stored computed fields use `compute_sudo=True`, causing the computation to run in a `sudo()` environment and cache cross-company sellers. [2] https://github.com/odoo/odoo/blob/d11b56f9272be39169d382007d19d63739617a8a/addons/purchase_stock/models/stock_rule.py#L169 Solution: ------------------------------------------ Filter the sellers in sudo mode as well, since the `seller_ids` cache will otherwise always be polluted due to the sudo environment. opw-6034990 Forward-Port-Of: odoo/odoo#259403
This update fixes an issue that could stop users from creating accrual entries after changing the review date. The system now handles the date consistently, preventing a type mismatch error and allowing the process to complete normally.
Original PR description
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the…
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the quantity to 1, and `confirm` it. - Navigate to Accounting > Review > `Billed Not Received`. - Change the `date` from the top left. - Select a record and click `Create Accrual Entries`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'str'` **Root cause:** At [1], the `accrual_entry_date` is set in the context as a `string`. Later, at [2], this value is retrieved from the context and used directly in a comparison with `ivl.date`, which is a `datetime.date`. **Fix:** This commit converts `accrual_entry_date` to a `datetime.date` object at [2], allowing users to create accrual entries without errors. [1]: https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76 [2]: https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188 opw-6110907 Forward-Port-Of: odoo/odoo#260415 Forward-Port-Of: odoo/odoo#259047
When a vendor bill is created using Auto-complete from a previous bill, the Intrastat transaction information is now preserved on the new bill lines. This prevents missing reporting data and helps ensure EU trade declarations remain accurate without manual re-entry.
Original PR description
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to…
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to reproduce:** - Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`. - Create a vendor bill for an `EU partner`, add a product, and set an `Intrastat` (enable from the optional column if needed). - `Confirm` the bill and note its number. - Create a new vendor bill for the `same partner`. - Use the `Auto-complete` feature by selecting the previous bill. - Check the invoice lines. **Observation:** The `Intrastat` is missing from the generated invoice lines. **Root Cause:** - On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] copies invoice lines using `copy_data()`. - However, in `account_intrastat`, `copy_data()` at [2] removes `intrastat_transaction_id`. **Fix:** This commit ensures that `Intrastat` is properly set when creating a vendor bill using the auto-complete feature based on a previously created vendor bill for an EU customer. [1]: https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820 [2]: https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83 opw-5936869 Forward-Port-Of: odoo/enterprise#114520 Forward-Port-Of: odoo/enterprise#112857
This fix ensures return names show the correct calendar year when a return spans the start of a year. As a result, users will no longer see labels like "Jan 2022 - Apr 2023" for periods that actually start in January 2023.
Original PR description
Steps to reproduce: - Create a return from Jan 2023 to April 2023 -> the dates displayed in the name will be Jan 2022 - Apr 2023 The display is incorrect because we used the wrong date format, and therefore switch from using YYYY to yyyy as the first one is the ISO standard year and the second the calendar year. They might differ on the result here because 01 Jan 2023 falls on a Sunday, but ISO week starts on Monday, so it took the previous year (2022) Forward-Port-Of: odoo/enterprise#114428
This fix prevents the IoT box from overwriting a printer’s manually chosen subtype when devices are sent again after a restart. As a result, user settings stay intact and the printer keeps the correct configuration instead of reverting unexpectedly.
Original PR description
Steps to reproduce: 1. Connect a printer to the IoT box and pair with a DB 2. Manually change the subtype of the printer in the DB 3. Restart the IoT box so it resends its devices. **Expected behaviour**: Subtype remains as the user-set value. **Actual behaviour**: Subtype is reset to the original value. To fix this issue, we simply remove any check for subtype in the device updating condition. Now, a device will only reset if its type changes. Forward-Port-Of: odoo/enterprise#114416
Generating a W-2 CSV now works even when the End Date is left blank. If no end date is provided, the system automatically uses the current year for the file name instead of failing, which avoids a blocking error for users.
Original PR description
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click…
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.
Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.
Error:
```
File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```
Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.
Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.
[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248
No ID
Forward-Port-Of: odoo/enterprise#114363
Forward-Port-Of: odoo/enterprise#113408This update removes a duplicate credit note selection in the Colombian e-invoicing setup. It prevents an error that could stop the invoice form from opening correctly when creating a credit note.
Original PR description
The `l10n_co_edi_operation_type` field on `account.move` had two entries with the same selection value `'23'`:
('23', 'Nota Crédito para facturación electrónica V1 (Decreto 2242)'), ('23', 'Inactivo: Nota Crédito para facturación electrónica V1 (Decreto 2242)'),
This caused an OWL crash when opening the invoice form:
"Got duplicate key in t-foreach: 23"
__Steps to reproduce:__
1- Install the l10n_co_edi module
2- switch to colombian company
3- Activate the developer mode
4- Go to Credit Note > Create
__NOTE__: The javascript error is only visible on version 18.4 but the duplicate selection is present since 17.0.
opw-5969595
Forward-Port-Of: odoo/enterprise#112841This update adjusts the width and layout of grid columns in monthly timesheet views. It prevents icons and overtime values from overlapping or wrapping awkwardly, making the display clearer and easier to read.
Original PR description
# [FIX] web_grid: column width with new time widget in month This commit increases the default width of the grid columns. Prior to this, the magnifying glass in Timesheets overlapped with the times in month scale, because the columns were too small. # [FIX] timesheet_grid: column overtime layout Without this commit, the overtimes were spanning two lines because the columns were too small. This commit changes the layout so that it spans one line to be consistent with the grid values. task-6121017
This change updates the packaging setup so Windows builds include the optional dependencies they need. It helps prevent installation or runtime issues for users deploying Odoo on Windows.
Original PR description
Forward-Port-Of: odoo/odoo#258320 Forward-Port-Of: odoo/odoo#258128
Self-billed invoices are now matched to the correct company when multiple companies are registered on Peppol. This prevents invoices from being assigned to the wrong business entity and helps keep accounting records accurate.
Original PR description
Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company. Steps to reproduce: - Create a database with 2 companies, both on Peppol - Receive a self-billed invoice from a random other company on Peppol - The received invoice will potentially be assigned to the wrong company This is only a test forward-port of #257380 opw-6045669 Forward-Port-Of: odoo/odoo#259524 Forward-Port-Of: odoo/odoo#259072
Images added to the company document layout now print correctly even when their width is set as a percentage. This prevents logos or other inserted images from disappearing in PDF output, improving the reliability of printed documents.
Original PR description
Problem: When adding an image in the `company_details` field via **Settings > Configure your document layout** and resizing it to a percentage width (e.g. 50%), the image is not visible when printed. Cause: Since fa55c2d1, `wkhtmltopdf` fails to correctly calculate percentage-based image widths because none of the ancestor elements have an explicit width defined. Solution: Force the wrapping table to `width: 100%`, giving `wkhtmltopdf` a concrete width to resolve percentage values against. Steps to reproduce: - Go to **Settings > Configure your document layout** - In the address field, add an image via `/media` - Resize the image to 50% - Print the document - Image is missing in the PDF output opw-6102568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259077
This update fixes the exemption code and exemption reason used for the Belgian 0% S tax. It helps ensure invoices and tax reporting use the correct legal classification, reducing the risk of incorrect records or submissions.
Original PR description
The tax 0% S had a wrong tax exemption code and tax exemption reason. This commit corrects it. Task-6127195 Forward-Port-Of: odoo/odoo#259639
Fixed an issue in the Time Off Gantt multi-create flow where the Time Off Type dropdown could appear empty after selecting multiple dates. The form now correctly refreshes its fields, so users can choose the right time off type and create requests smoothly.
Original PR description
**Steps to Reproduce:** 1. Open Time Off App->Management->Time Off->Gantt View 2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set". 3. Open the "Time Off Type"…
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown. The dropdown appears empty.
**Bug Cause:**
When forceFullDuration is true and request_duration is pre-populated in initial values, the form detects no field changes and skips triggering onchange. This prevents computed fields like allowed_work_entry_type_ids from being evaluated, resulting in an empty domain filter ('id', 'in', []).
**Solution:**
Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option.
By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option. By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the allowed_work_entry_type_ids correctly.
**Task:** 6109569This update corrects how Belgian NISS "bis" numbers are read when deriving an employee’s birth date. It prevents invalid dates from being generated, which helps payroll data stay accurate and avoids errors during processing.
Original PR description
…fset) in birthday parsing The NISS month field can be increased by 20 or 40 for "numéros bis". This caused invalid date parsing. Use modulo 20 to normalize the month before constructing the birthday. task-6144297
Copying a helpdesk ticket no longer fails for users who do not have stock permissions. The system now avoids carrying over a stock-related product when duplicating the ticket, so business users can duplicate records normally.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#114266 Forward-Port-Of: odoo/enterprise#101338
When users type an email address in the editor, it now automatically becomes a clickable email link as soon as they add a space. This makes it easier to create correctly formatted contact links without extra manual steps.
Original PR description
Before this commit: when typing an email address, it's not converted to a mailto link after spacing. After this commit: the mailto link is created after spacing. task- 6053993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258736 Forward-Port-Of: odoo/odoo#257497
This update prevents loyalty points from being incorrectly rounded down when a company uses a currency with a large rounding factor. As a result, point-based reward programs will work as expected and rewards will remain claimable, while money-based programs still use currency rounding where appropriate.
Original PR description
`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable. Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules. opw-6111622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259660
This change stabilizes an automated test in the HTML editor so it no longer fails unpredictably. It helps ensure more reliable quality checks without changing the user-facing editor behavior.
Original PR description
My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones. runbot-242333 Forward-Port-Of: odoo/odoo#259978 Forward-Port-Of: odoo/odoo#259544
This update fixes an unstable automated test in the HTML editor by waiting based on elapsed time instead of a fixed animation frame. It makes the test more dependable on slower systems and reduces false failures without changing the product’s behavior.
Original PR description
Waiting for a full animation frame is too dangerous. In the general case, an animation frame happens every 16ms, in which case the power buttons haven't been updated yet since they have a debouncing timeout of 30ms. However, when the runbot is slow, more than 30ms may very well have elapsed between two animation frames. When that is the case, the power buttons are displayed and the test fails. This commit changes the forced awaiting of an animation frame to a waiting pased on the time passed. In the general case, an animation frame will have happened in 20ms, so the test will still catch a regression. When the runbot is slow however, more time might have passed, but not necessarily an animation frame, so the power buttons should still be invisible, making this test more reliable. runbot-242466 Forward-Port-Of: odoo/odoo#259854 Forward-Port-Of: odoo/odoo#259654
This change reverts a previous adjustment that affected how child contact names were shown. It helps ensure invoices and related documents display contact information in the expected way, reducing confusion for customers and internal teams.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260186 Forward-Port-Of: odoo/odoo#260065
Imported XML attachments are now kept linked in a safer way so they can still be opened when needed. This prevents access errors when users view bills created from email imports, especially in Mexican e-invoicing flows.
Original PR description
When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 Forward-Port-Of: odoo/odoo#260127 Forward-Port-Of: odoo/odoo#259095
This update corrects the appearance of contract-related buttons on the employee form. It keeps the "New Contract" label from wrapping on narrow screens and makes the contract template button match the surrounding interface more closely.
Original PR description
- Add `text-nowrap` to the "New Contract" button to prevent text from splitting at narrow viewport widths - Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488 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#256017
When a packed item is scanned with GS1 information, the system now correctly keeps the due date instead of defaulting to today. This ensures newly created lots carry the right expiration information, reducing manual corrections and avoiding mistakes in shipping and inventory records.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490The button used to manage contract templates on the employee form now matches the surrounding interface better. This fixes inconsistent spacing and border styling so the page looks cleaner and more polished for users.
Original PR description
Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488 Forward-Port-Of: odoo/enterprise#112113
This update adjusts an internal compatibility check so it recognizes the newer milestone for lxml 6.1. It helps keep accessibility-related HTML handling aligned with the updated library behavior and prevents the patch from being treated as outdated too early.
Original PR description
Whitelisting of ARIA attributes is now part of the milestone for LXML 6.1. This commit updates monkey patch's obsolescence detection accordingly. Forward-Port-Of: odoo/odoo#258910
This change prevents dropdown text from spilling out of bottom sheet panels or overlapping the selected checkmark. It also keeps long device names in voice and video settings from causing horizontal scrolling on small screens, improving the experience on mobile devices.
Original PR description
**Purpose of this PR:** Before this commit, in the bottom sheet, dropdown labels could overflow their active container or overlap with the checkmark icon when selected. In voice/video settings, long…
**Purpose of this PR:**
Before this commit, in the bottom sheet, dropdown labels could overflow their active container or overlap with the checkmark icon when selected. In voice/video settings, long selected device names could cause horizontal
scrolling on small screens.
This commit:
- Allows dropdown labels in bottom sheets to wrap on small screens.
- Reserves space for the checkmark icon in all bottom sheet dropdowns if any item is selected, ensuring consistent alignment.
- Constrains the selected device label within the available space voice/video settings to prevent layout overflow.
<table>
<tr>
<td><b>Before</b></td>
<td><b>After</b></td>
</tr>
<tr>
<td><img src="https://github.com/user-attachments/assets/8f347abc-fe26-427a-95ec-97ace3a0c5a2" width="300"/></td>
<td><img src="https://github.com/user-attachments/assets/6d6104b5-46c3-404b-be09-1cfa55209a96" width="300"/></td>
</tr>
</table>
task-[6095602](https://www.odoo.com/odoo/project/1519/tasks/6095602)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects inventory valuation so that quantities and values are computed properly when a specific end date is selected, regardless of the user's time zone. It prevents stock reports from showing missing or zero stock for items received on the selected day.
Original PR description
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to…
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to UTC+1 - Create a storable product with: - quantity: 10 (created today) - unit cost: 5 - valuation method: AVCO - Go to Accounting > Review > Inventory > Inventory Valuation - Select today's date - Click on "Ending Stock" -> The total value and quantity in stock are 0 instead of respectively 50 and 10. **Cause** When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation: - 12/04 00:00 (user timezone) -> 11/04 23:00 UTC - Converted to 23:59 UTC -> 12/04 00:59 in user timezone As a consequence, most of the quantities created on 12/04 are excluded from the valuation. This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153 This inconsistency leads to incorrect quantities and valuation results. opw-5491743 Forward-Port-Of: odoo/odoo#253438 Forward-Port-Of: odoo/odoo#246163
The call menu now includes the Picture-in-Picture action, making it easier to keep a call visible while switching to another conversation or chatter. It also corrects the visual styling of Fullscreen and Picture-in-Picture in the menu so they display at normal opacity.
Original PR description
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call. Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster. This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature. Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown. Before / After <img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" /> Forward-Port-Of: odoo/odoo#260416 Forward-Port-Of: odoo/odoo#259866
This change keeps message text readable when users click into a communication box in Helpdesk and related areas. It ensures the text color stays correct even after the field gains focus, which prevents white text from appearing on a white background in dark-themed websites.
Original PR description
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to reproduce - Install the Helpdesk app - Go to Website > Help - Submit a ticket (the ticket's information is not important) - Click the ticket link shown when the ticket is submitted - Start writing a message in the Communication History. # The problem As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable. Note : the same problem is present for product reviews in the eCommerce application. These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103 # Cause The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131 In our case, it sets `color` to #FFF (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101 But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149 The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6 Because `.o-discuss-text-body` is overriden by `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied. # Proposed solution Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused opw-6063961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258142
The grouped list pager now uses the actual total number of records when that total is already known, instead of falling back to the configured display limit. This makes record counts more accurate and avoids confusing users when browsing grouped lists with many records.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705
Forward-Port-Of: odoo/odoo#259858
Forward-Port-Of: odoo/odoo#259562This update prevents an error that could occur when the Purchase app is installed after Accounting on older database versions. It makes the purchase invoice view more resilient so users can continue installing and using modules without the setup failing.
Original PR description
c5ac4867fb708c56aa74e38508347660f1875dd3 added back the computed fields `invoice_vendor_bill_id` and `purchase_vendor_bill_id` on `account.move` in stable. The issue is that the view on purchase expects the view on account to have `invoice_vendor_bill_id` in it. But if a user already had `account` installed before the commit, then install `purchase` after, the purchase view will raise an exception as it expects `invoice_vendor_bill_id` in the view of account. The fix here is to not reference `invoice_vendor_bill_id` in the purchase view and compute its visibility with a non-stored computed field.
This change fixes an error that could happen when opening account report information. It ensures the report uses the correct way to update internal report data, so users can view reports without interruption.
Original PR description
Currently, an error occurs when retrieving account report information. ``` File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy…
Currently, an error occurs when retrieving account report information.
```
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
child_line.update
^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.
This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].
[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420
[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377
[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565
sentry-7403925422Discuss now correctly displays complex emoji combinations as a single symbol instead of splitting them into parts. This improves message readability and prevents emoji from appearing incorrectly in chat conversations.
Original PR description
Prior to this commit, emoji sequences were rendered incorrectly in Discuss. The existing regex failed to match multi-codepoint sequences, splitting complex emojis (like ❤️🔥) into separate individual emojis (❤️ and 🔥). Steps to reproduce: 1. Post a message in Discuss containing "🤷♂️" 2. Notice the message displays "🤷♂" instead This commit refines `EMOJI_REGEX` to match complete emoji sequences. [Task-6128638](https://www.odoo.com/odoo/project/1519/tasks/6128638)
This update corrects a typo and improves the dashboard’s styling for a cleaner user experience. It does not change how the feature works, but it helps make the interface look more polished and consistent.
Original PR description
task-6132220
This update makes AI chat messages easier to read by reducing oversized headings and cleaning up table borders in the chat layout. It also fixes a formatting issue that could cause stray asterisks to appear in AI responses, making the content display more consistently for users.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286
Resupply pickings for subcontracted products now correctly display the source purchase order, even when the replenishment route uses the alternate stock-based flow. This makes it easier to trace where the resupply came from and reduces confusion for users managing subcontracting operations.
Original PR description
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route,…
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route, rules supply method to: Take from stock, if unavailable, trigger another rule (mtso) - Create a subcontracted bom For a product P with a component COMP - Create and confirm a PO for 1 unit of P with your subcontractor - Use the Resupply smart button to access the resupply picking #### > The resupply picking does not refer to the source PO ### Cause of the issue: The link is currently computed based on `move_dest_ids` which are only set for mto moves. However, moves created from mtso rules are `make_to_stock`. ### Fix: Since 19.0 2713876dbc70d3984e584a9037a2206dcda4e84a, we can rely on references to rebuild the link between the resupply picking and the source PO even in mtso. Note that this will also add the source PO link to each other picking of the reference. opw-6079680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256689
This update improves how the editor handles content inside inline code. It prevents formatting tools from appearing when text is fully inside code, and makes pasted content inside code insert as plain text so the result stays consistent. When a selection includes both code and normal text, formatting is now applied only to the normal text, reducing unexpected changes while editing.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258781 Forward-Port-Of: odoo/odoo#250911
This fix ensures product prices are converted from each product’s own currency to the Point of Sale currency, instead of assuming they were always in the company currency. As a result, prices shown and charged in multi-currency setups will be more accurate and consistent at checkout and on receipts.
Original PR description
Before this commit, in a multi-currency environment, the company currency was used to convert the prices, while it was a wrong assumption that the product prices were in the company currency. The products have a currency_id field, and the price should be converted from that currency to the PoS config currency. opw-6065969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257324
Downloading receipts for kiosk self-order POS orders could fail with an error in some cases. This fix prevents that error so receipts can be opened and downloaded normally.
Original PR description
Currently an error occurs when the user tries to `Download Receipt` of self-orders as the following steps: - Install the pos_self_order module - Create a new POS shop with `Self Ordering` as `Kiosk` - Add Online `Payment Methods` on the above POS shop - Make an order from kiosk mode - Go to Point of Sale > Orders > Orders - Open the recent order which was created from the kiosk. - Click `Download Receipt` > Error Error: `QWebError:Error while rendering the template: AttributeError: 'bool' obje...` This issue occurs because, while rendering pos_order_receipt_header`, the `preset` value is `False`. Attempting to call `.get()` on a falsy value leads to an error. This commit fixes the issue by accessing `preset` only when it is available, preventing errors during rendering. sentry-7402711985
This update corrects an automated performance test so it matches the current demo data setup. It helps keep test results reliable and prevents false failures during validation.
Original PR description
Query counts were updated for demo data. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260297
This change filters out characters that are not accepted by the Swiss QR-bill standard before generating QR codes. It helps prevent bank rejections caused by unsupported Unicode characters in payment references or addresses.
Original PR description
**Description of the issue/feature this PR addresses:** QR code is rejected by the bank, when it contains an invalid character `U+202F`. **Current behavior before PR:** Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part. **Desired behavior after PR is merged:** Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out. > spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258680 Forward-Port-Of: odoo/odoo#254980
This update fixes an issue where clicking certain cells in the Trial Balance report could fail for Undistributed Profits/Losses. As a result, users can open the related details normally without encountering an error.
Original PR description
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year…
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year `Accounting Date` (eg: 31-12-2025) and include one `Journal Items` for `Undistributed Profits/Losses` - Open `Trail Balance` report and click on any cell for `Undistributed Profits/Losses` Traceback: `KeyError: 'report_line_id'` Before this [commit], we were returning fields with `null/None` values. After the commit, fields containing `null/None` [value] are removed, and only fields with valid values are returned. As a result, when the `dispatch_report_action` function is called, the `report_line_id` is missing in `params`. [commit]: https://github.com/odoo/enterprise/pull/102808/changes/b92dc397bef029472a40223f51b611cdf5b631dc [value]: https://github.com/odoo/enterprise/blob/626b8157bcea2e3843cd9d5d0c0036e302b8e5ce/account_reports/utils/report_data_objects.py#L42-L43 sentry-7372351871 opw-6119913
This update prevents the system from creating accounting entries when a physical inventory adjustment results in no actual quantity change. It reduces clutter in the books by avoiding zero-value journal items that do not reflect any real stock movement.
Original PR description
**Issue**: Applying a physical inventory adjustment with a 0 quantity difference creates an account move with 0 debit/credit, resulting in accounting noise. **Steps to reproduce**: - Configure a product with perpetual valuation - Go to Inventory > Configuration > Warehouse Management > Locations - Remove the internal filter and open the "Inventory adjustment" location - Set a Loss Account - Go to physical inventory - Create and apply for this product with counted quantity of 0 - Go to Journal Items -> An item is created **Cause**: While checking whether an `account.move` should be created: https://github.com/odoo/odoo/blob/9dfd673465e4a3326a6caa64c8d61fe7319cbc44/addons/stock_account/models/stock_move.py#L613-L620 The quantity of the `stock.move` is not taken into account. opw-5957406 Forward-Port-Of: odoo/odoo#254331
This update makes salary and mobility budget calculations behave more consistently. Changes made in the backend or to employer cost now only affect the wage itself, instead of unexpectedly altering other benefits; the full adjustment logic remains available in the salary configurator.
Original PR description
For consistency purposes, we only trigger the inverse on the mobility budget computation if we are in the context of the salary configurator. Changing the wage in the back end or changing the employer cost should only touch the wage and not other benefits Forward-Port-Of: odoo/enterprise#111828
When a product belongs to categories used on multiple websites, the site now chooses a category that is accessible on the current website. This prevents customers from clicking a breadcrumb link and landing on a 404 page when browsing a different website.
Original PR description
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two…
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2. 2. Create a product and assign both categories to it. 3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly 4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error** Cause: ====== In `_prepare_product_values`, when no category is passed in the URL, the fallback was: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802 This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2. The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404. Solution: ========= Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one. opw-6070191 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258336
This change fixes an issue that could prevent certain sales-related email templates from being saved correctly in the editor. It makes the template content stay in a valid structure during editing, so users no longer run into unexpected save errors.
Original PR description
**Steps to reproduce:** - Install sale / website_sale - In debug mode, go to Settings app - Go to Technical > Email > Email Templates - Try to edit and save "Sales: Order Confirmation" or "Ecommerce:…
**Steps to reproduce:**
- Install sale / website_sale
- In debug mode, go to Settings app
- Go to Technical > Email > Email Templates
- Try to edit and save "Sales: Order Confirmation" or "Ecommerce: Cart Recovery"
- QWebError is raised: 'IndentationError: unexpected indent'
**Issue:**
Before a `mail.template` is rendered in the html editor it must be valid html (even if they contains qweb elements) to avoid the browser silently moving elements around to match its specifications (and breaking template logic). This is also what happens with `DOMParser.parseFromString` function.
e.g. the browser moves html elements out of the parent `<table>` if they are not the children of a `<tr>` `<td>`.
```xml
<table>
<t t-foreach=...>
<tr>
<td>1</td>
</tr>
</t>
</table>
```
Becomes:
```xml
<t t-foreach=...>
</t>
<table>
<tbody>
<tr>
<td>1</td>
</tr>
</tbody>
</table>
```
**Fix:**
The template is still working if not edited, but we need to ensure the template `body_html` is valid html to avoid the hierarchy modification.
related: https://github.com/odoo/odoo/commit/dbd8b879fd95f3e913e1c777cb8619c4e0673b03
similar issue: https://github.com/odoo/odoo/pull/259548
opw-6055026This update fixes an accounting issue where invoices for kits could miss the cost of goods sold entry if one or more kit components were removed from the delivery. It now records the cost based on the components that were actually delivered, which keeps invoice accounting accurate and more reflective of the real shipment.
Original PR description
Steps to reproduce: - Create a kit with 3 or more components - Create a sales order with the kit and confirm it - Remove at least one of the kit's components from the delivery and validate it - Create the invoice from the sales order and confirm the invoice - Check the journal entries included in the invoice form Current behavior: - There is no COGS entry Expected behavior: - There should be a COGS entry Context: In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount. opw-6082565 Forward-Port-Of: odoo/odoo#259875 Forward-Port-Of: odoo/odoo#258982
When users select all documents across multiple pages and open the Share action, the system now correctly applies permission changes to every selected document, not just the ones visible on the current page. This prevents incomplete sharing updates in large document lists.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload more than 80+ files (max page size is 80) - Use the checkbox to select all files on the page - Click the 'Select All' button in the control panel to select allfiles - Use Share action button - Pop-up only takes the current page into account - Rights modifications will not be applied on remaining records **Issue:** `onShare()` only takes current records into account even if the full selection was applied. **Fix:** Fetch all document ids (if needed) before opening the dialog. opw-5957777 Forward-Port-Of: odoo/enterprise#110299
The annual tax report now handles comparison values more safely, even when the report contains text entries. This prevents a crash when users compare the report with one previous period, so the comparison view opens normally.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#113330 Forward-Port-Of: odoo/enterprise#112619
This update fixes a small wording error in website and mass mailing snippets, changing “am” to “pm” where needed. It helps ensure displayed opening hours and related content are accurate and less confusing for visitors.
Original PR description
am to pm Forward-Port-Of: odoo/odoo#260577
This change prevents an error that could appear when users add task dependencies from the mobile Project view. It ensures the correct part of the screen is updated, so the action works reliably on mobile devices.
Original PR description
Steps to reproduce: - Install Project - Create a project and a task and enable task dependencies - In mobile view, go to the "Blocked by" tab and click "Add" Issue: A traceback occurs in the mobile view. Cause: In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element. Fix: Update the XPath to correctly replace the element containing parent_id. task-6009997 Forward-Port-Of: odoo/odoo#252804