Monday, August 25, 2025
54 changes
18 changes
Resolved issues and error corrections
This fix prevents translated field values from being accidentally overwritten when working with temporary records in different languages. It helps businesses using multiple languages avoid unexpected data loss or blank product names during record creation and editing.
Original PR description
Steps to reproduce the issue:
1. Install a second language (eg, ar_001) and `product`
2. Start odoo shell
3. Run the following:
`(env := env(context=dict(env.context,lang='ar_001')))['product.template'].new({'name':'test'}).with_context(lang='en_US').name`
Current behavior before PR:
The `get` method of the cache will not find a value for the `en_US` language and set the value stored in the env language to a default (`None` in this case) after raising `CacheMiss`
Desired behavior after PR is merged:
We can read and write translatable fields in different languages on transient records without data loss.
opw-4943458
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#223997
Forward-Port-Of: odoo/odoo#222474This fix ensures invoices created from sales orders with global discounts show accurate unit prices and subtotals on down payment lines. It prevents duplicate price adjustments when invoice and company currencies match, improving invoice accuracy for customers and accounting teams.
Original PR description
Steps to reproduce 1. Create a sale order with a product line for 14,990.00 and a 0% tax. Make sure the product's product category has a Downpayment Account set on it. 2. Create a global discount for 990.00. 3. Create an invoice. Notice how the invoice lines' price_unit are respectively 2909.29 and -70.71, and differ from the lines' subtotals. Analysis Propagating the manual tax amounts in `_reduce_base_lines_with_grouping_function` causes a delta amount to be present in `_apply_base_lines_manual_amounts_to_reach` whereas there shouldn't be. Solution Drop manual tax amounts in `_reduce_base_lines_with_grouping_function`. We also take the opportunity to fix the `delta_currency == currency` condition which caused the price_unit to be adjusted twice if the invoice currency is the same as the company currency. opw-5001935 Forward-Port-Of: odoo/odoo#223876
The online store product feed for Google Merchant Center now checks for product images in a lighter way. This prevents memory failures when exporting very large product catalogs, helping merchants keep their product listings available and up to date.
Original PR description
**Traceback:** ```python File "/home/odoo/src/odoo/saas-18.3/addons/website_sale/controllers/gmc.py", line 63, in gmc_data_source 'items': products._prepare_gmc_items(), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^…
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-18.3/addons/website_sale/controllers/gmc.py", line 63, in gmc_data_source
'items': products._prepare_gmc_items(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/website_sale/models/product_product.py", line 251, in _prepare_gmc_items
**product._prepare_gmc_image_links(base_url),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/website_sale/models/product_product.py", line 281, in _prepare_gmc_image_links
'image_link': urljoin(base_url, self._get_image_1920_url()) if self.image_1920 else '',
^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1495, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_binary.py", line 137, in compute_value
super().compute_value(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1661, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.3/addons/mail/models/mail_thread.py", line 468, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 4627, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 73, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/product/models/product_product.py", line 164, in _compute_image_1920
record.image_1920 = record.image_variant_1920 or record.product_tmpl_id.image_1920
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1458, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 3452, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 3490, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 3607, in _fetch_query
field.read(fetched)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_binary.py", line 149, in read
att.res_id: att.datas
^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1495, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_binary.py", line 137, in compute_value
super().compute_value(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1661, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 4627, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 73, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/addons/base/models/ir_attachment.py", line 229, in _compute_datas
attach.datas = base64.b64encode(attach.raw or b'')
^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1495, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_binary.py", line 137, in compute_value
super().compute_value(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1661, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 4627, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 73, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/addons/base/models/ir_attachment.py", line 235, in _compute_raw
attach.raw = attach._file_read(attach.store_fname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/odoo/addons/base/models/ir_attachment.py", line 118, in _file_read
return f.read()
^^^^^^^^
MemoryError
```
Issue:
-------
Loading product data in Google Merchant Center was causing memory error when handling a large number of products (14k+ in this case). The problem occurred because `self.image_1920` was used to check if a product had an image. This field is computed and non-stored, so accessing it for many records loads the full high-resolution image into memory, leading to excessive memory usage.
Solution:
------------
Use `image_128` instead of `image_1920` for image existence checks, significantly reducing memory usage and preventing the error.
upg-3063427
opw-4981983
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222584The online shop now loads smaller product images when processing large product lists. This prevents out-of-memory errors and helps keep shopping pages stable for customers and staff.
Original PR description
This commit fixes an "out of memory" error caused by loading the `image_1920` field into memory for a large `product.product` recordset. To resolve this, the code has been changed to use `image_128` to limit the memory impact. See also: - https://github.com/odoo/odoo/pull/222584 opw-4981983 Forward-Port-Of: odoo/odoo#223949
This fix prevents product image imports from failing when images are provided as URLs and a file type detection library is installed. Businesses can reliably test and import records with image fields without encountering an unexpected upload error.
Original PR description
Currently on SaaS it is not possible to import field image_1920 from file as the operation fails Steps to reproduce: - Have python-magic library installed - Products > Import records - Upload a file containing an URL as image_1920 - Test upload Upload fill fail with error `Could not retrieve URL: <img-url> [image_1920: L1]: argument 2: TypeError: wrong type` Investigation: It occurs because the python-magic library does not work with bytearray opw-5004768
Portal users sharing Microsoft Office documents will now have files saved with the correct file type information. This prevents spreadsheets or similar documents from being treated as zip files, so users can open and interact with them as expected in Odoo.
Original PR description
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3.…
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3. User can't interact with the file to open the file in the Odoo spreadsheet because the mimetype is zip. <img width="387" height="192" alt="image" src="https://github.com/user-attachments/assets/be31f05f-e4e3-44d9-b12a-66f96feba950" /> <img width="274" height="67" alt="image" src="https://github.com/user-attachments/assets/93064e5c-c028-41ce-8e79-1b9c9447c018" /> With `fix_filename_extension()`, the following two commits fixed the issue of Odoo's `guess_mimetype` function incorrectly guessing extensions such as `.xlsx` as `.zip` extension. https://github.com/odoo/odoo/commit/8842b6b43e7c3d1cc67d7d399bb210e4009e23b2 https://github.com/odoo/odoo/commit/34d9375e2efb604f8e7036cb710f44b01f9ccaee However, the `_from_request_file()` still uses the incorrectly guessed mimetype to create an attachment, leading to inconsistent extension from the filename (.xlsx) vs attachment record's mimetype (.zip). This commit fixes the issue by using the mimetype from the filename's extension. This is safe if the following assumption is correct: At the point where the `from_request_file()` attempts to create the attachment record, the `filename` contains correct extension name, presumably fixed by the `fix_filename_extension()`. Commit message to be changed after with Julien's confirmation; opw-4753670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222643 Forward-Port-Of: odoo/odoo#222368
This fixes an issue where event time slots could be created on the next day when the user's timezone differed significantly from the event timezone. It ensures calendar slots are displayed on the intended date, reducing scheduling confusion for event organizers.
Original PR description
Purpose ======= Fix the creation of slots at the wrong date. Specification ============= User timezone: Europe/Brussels Event timezone: America/Los Angeles When creating a slot on the calendar on the 10th of April from 8PM to 11PM, the slot is created from 8PM to 11PM but on the 11th of April. In scenario where the conversion from the local tz to the event tz changes the date, the slot is created at the wrong date. => After conversion, the DateTime 'zone' param needs to be set back to the local tz (without changing the converted times) to make sure the calendar renders records correctly as it always expects datetimes expressed in the 'local' tz. related PR: https://github.com/odoo/odoo/pull/205945 Task-4743999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217476
This fix prevents errors in workflows that handle very large selections, such as paying or reconciling more than 1,000 accounting records at once. It improves reliability for bulk operations by avoiding a crash caused by temporary record references during data loading.
Original PR description
Currently, an error occurs in any wizard or flow that fetches a many2many field with more than 1000 records. For example, attempting to reconcile more than 1000 journal items at once or making…
Currently, an error occurs in any wizard or flow that fetches a many2many field with more than 1000 records. For example, attempting to reconcile more than 1000 journal items at once or making payment of more than thousands invoices. **Steps to reproduce:** 1. Install Accounting(without demo data). 2. Create a new product (e.g., "p1"). 3. Import a [file](https://docs.google.com/spreadsheets/d/1QslJXsDB70jzJwW64AQ4Br6pVcqGCDLP/edit?usp=sharing&ouid=113889705772170635141&rtpof=true&sd=true) to a customer invoice and confirm it to post the entries. 4. Select all (1010 records) invoices and click on the "Pay" button. Tip: Posting the invoice may take some time. Alternatively, the issue can be reproduced by adjusting the PREFETCH_MAX limit. **Error:** `KeyError - <NewId origin=4250>` **Cause:** Previously, the method used `get_until_miss`, which was handled by stopping on missing keys. However, after [this](odoo/odoo@670897c#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aL66) commit, the error handling was removed, leading to the error. - [1] Here, the `move_line_ids` field is a many2many field. When fetching is involved at [2]: - If the number of records is less than PREFETCH_MAX(1000), both the real id and its corresponding origin ids are available in the `field_cache`. - When the number of records exceeds, only the real id will be fetched; new/origin ids are not. This leads to an error. **Fix:** This commit only performs fetching for real IDs and skips for new/origin IDs to avoid KeyError. [1] - https://github.com/odoo/odoo/blob/b424877f9d9f9dd03b766ba57ef7c1dd822fc1d9/odoo/orm/environments.py#L781-L791 [2] - https://github.com/odoo/odoo/blob/b424877f9d9f9dd03b766ba57ef7c1dd822fc1d9/odoo/orm/fields_relational.py#L63-L71 sentry-6789677009
Fully flexible employees can now request time off in hours as well as full days. This helps related apps like Timesheets and Planning accurately record paid holidays and unavailable time slots.
Original PR description
In this PR, we allow fully flexible employees to take time off in hours or days, to allow other apps such as timesheet to encode their paid holidays or planning to use unavailable intervals Forward-Port-Of: odoo/odoo#217938
This fix reduces memory consumption when generating the French POS inalterability check report, especially for companies with large volumes of orders. By avoiding unnecessary data loading, the report is less likely to fail and should run more reliably on large datasets.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#223535 Forward-Port-Of: odoo/odoo#222416
Fixed an issue in the HTML editor where removing text color formatting could freeze the editor in certain selections, especially when color was applied to larger content blocks. The toolbar also avoids opening for non-editable content, making editing more reliable and preventing disruptive hangs for users.
Original PR description
**Current behavior before PR:** - When color was applied to a block-level element, attempting to remove it caused the `removeFormat` method to enter an infinite loop. - Removing formatting on a contenteditable false element infinite loop when removing format. **Desired behavior after PR is merged:** - Now, the color is correctly removed from the selected text, even when it is applied to a block-level element. - Now, the toolbar no longer opens when the selected element is contenteditable false task: 4575459 Forward-Port-Of: odoo/odoo#223939 Forward-Port-Of: odoo/odoo#198319
Refunds made through Viva payment terminals now keep their connection to the original payment even if the Point of Sale page is refreshed mid-process. This prevents staff from having to ask customers to present a card again for refunds that should be completed automatically.
Original PR description
Steps to reproduce: 1. Configure a PoS with a Viva payment terminal 2. Complete an order using the Viva payment method 3. Start to refund the order, and get to the Payment screen 4. At this point, refresh the page 5. Now continue with the refund, using the Viva payment method **Expected behaviour**: The refund is referenced to the original payment, meaning it can be automatically completed without a card. **Actual behaviour**: The refund reference is lost after refreshing, so an unreferenced refund is performed, requiring a card to be presented. The fix is to store the refund reference in the `uiState`, not just on the plain JS object. This way it is saved to the indexedDB. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223908
Opening a Project could fail if a saved embedded action still pointed to Timesheets after that app was uninstalled. The change safely hides unavailable embedded actions instead of crashing, helping users keep working after module changes.
Original PR description
The system failed to evaluate the embedded action, which refers to the Uninstalled module.
**Steps to produce:-**
- Install `Project` and `Timesheets`.
- Go to Project and open any project.
- Click on the `embedded action` icon and select Timesheets.
- `Save` the view from the `embedded action's icon`.
- Now, `Uninstall Timesheets`.
- Now, go to that Project and try to open it.
**Error:-**
`KeyError: 'allow_timesheets'
ValueError: Invalid field in filter of project.project:
[('allow_timesheets', '=', True)]`
**Solution:-**
- Added a safe check using `hasattr` to verify if the `python_method` defined on the embedded action actually exists on the specified model.
- Ensured that if the method is missing or invalid, the embedded action is marked as not visible instead of causing a crash.
**sentry-6738596751**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#218564This fixes an issue where automatic subscription invoicing could stop looking too early if some subscriptions in the first batch were not ready to invoice. The scheduler now applies its limit after checking invoice eligibility, helping ensure ready subscriptions are found and future invoice runs are triggered correctly.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884 Forward-Port-Of: odoo/enterprise#92690 Forward-Port-Of: odoo/enterprise#89787
Knowledge now saves an article's pending edits before reloading it after another article is moved nearby. This prevents users from accidentally losing work while organizing content in the sidebar.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Appointment users can now create resource-based appointments directly from calendar events without hitting an access error. This fixes a permissions issue that blocked bookings when an appointment type had a single resource, improving reliability for day-to-day scheduling.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373
The Indian Payroll EPF report export has been corrected so users can download the XLSX file without encountering an error. This ensures payroll teams can generate required provident fund reports reliably after payslips are paid.
Original PR description
Steps to Reproduce: - Install Indian Payroll Localization - enable the Provident Fund of the employee in Payroll tab of employee form view - Create a payslip of the employee and mark as paid - Try to export XLSX file of EPF report from the reporting menu Issue: - A traceback error occurs when click on 'Export XLSX File' report. Reason: - The domain used to search payslips uses an incorrect date format. Solution: - Use the correct date format for the search. task-5002518
This change prevents Accounting from crashing when users reconcile more than 1,000 journal items at once. It improves reliability for high-volume accounting workflows by ensuring large reconciliations can complete without a key error.
Original PR description
Currently, an error occurs when attempting to reconcile more than 1000 journal items at once. **Steps to reproduce:** 1. Install the **Accounting** app. 2. Create a new product (e.g., "p1"). 3.…
Currently, an error occurs when attempting to reconcile more than 1000 journal items at once. **Steps to reproduce:** 1. Install the **Accounting** app. 2. Create a new product (e.g., "p1"). 3. Import a [file](https://docs.google.com/spreadsheets/d/1QslJXsDB70jzJwW64AQ4Br6pVcqGCDLP/edit?usp=sharing&ouid=113889705772170635141&rtpof=true&sd=true) to a customer invoice and confirm it to post the entries. 4. Open Journal Items and filter by `Account = 12100 Account Receivable`. 5. Click on the _Reconcile_ button. **Tip:** Posting the invoice may take some time. Alternatively, the issue can be reproduced by adjusting the PREFETCH_MAX limit. **Error:** `KeyError - <NewId origin=4250>` **Cause:** Previously, the method used `get_until_miss`, which was handled by stopping on missing keys. However, after [this](https://github.com/odoo/odoo/commit/670897c6dc8e744f0622cb96c78fdab0a6249fb6#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aL66) commit, the error handling was removed, leading to the error. - [1] Here, the `move_line_ids` field is a **many2many** field. When fetching is involved at [2]: - If the number of records is **less** than `PREFETCH_MAX`, both the **real ids** and its corresponding **origin ids** are available in the `field_cache`. - When the number of records **exceeds**, **only the real ids** are prefetched and cached; origin ids are not. This leads to an error. **Fix:** This commit ensures that real ids are used when accessing the field cache, preventing a key error when the number of records exceeds the prefetch limit. [1] - https://github.com/odoo/odoo/blob/b424877f9d9f9dd03b766ba57ef7c1dd822fc1d9/odoo/orm/environments.py#L781-L791 [2] - https://github.com/odoo/odoo/blob/b424877f9d9f9dd03b766ba57ef7c1dd822fc1d9/odoo/orm/fields_relational.py#L63-L71 sentry-6789677009
15 changes
Resolved issues and error corrections
Saudi electronic invoicing no longer blocks invoices when the invoice company differs from the journal company in standard branch setups. This helps businesses using branches generate the correct QR code and process invoices without unnecessary restrictions.
Original PR description
This commit removes the previously enforced restriction in https://github.com/odoo/odoo/commit/d6175d0552c18006913e969eac7006666164609c that required the company specified on an invoice to match the company specified on the associated journal and makes sure that the company used to create the QR is the appropriate company whether in a branch or in a main company task-5005477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223976 Forward-Port-Of: odoo/odoo#222935
10 changes
Resolved issues and error corrections
The product search in Kenya localization now works correctly when users filter by KRA item code. This prevents search errors and helps sales users find products more reliably.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526
11 changes
Resolved issues and error corrections
When an individual customer is linked to a company, their assigned pricelist now stays synchronized with the company's pricelist. This prevents quotations from switching to the wrong pricelist when users change the customer between a company and its related contact.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create an individual partner; 2. assign them a pricelist A; 3. create a new company partner for them; 4. create a new pricelist A & sort it on top; 5. open a…
The online store now uses smaller product image versions when processing large product lists. This helps prevent out-of-memory errors and improves reliability for shops with many products.
Original PR description
This commit fixes an "out of memory" error caused by loading the `image_1920` field into memory for a large `product.product` recordset. To resolve this, the code has been changed to use `image_128` to limit the memory impact. See also: - https://github.com/odoo/odoo/pull/222584 opw-4981983
Repeated global discounts now ignore tax amounts copied from the original sale order lines, preventing discounts from being calculated too high on already discounted orders. This keeps discount and tax totals accurate when users apply global discounts more than once.
Original PR description
When creating a global discount more than once, the values on the second time onward would be incorrect due to the manual tax amounts being propogated from the sale order lines. This would cause the discount amount to increase when discounting an already discounted sale order. This happened because manual tax amounts that were from the lines that the discount lines were created from were being propogated and used to attempt to find the correct tax amounts up to the target_amount_currency, but this is incorrect. Removing the manual tax amounts when the special type of the line is global_discount resolves this issue and allows multiple global discounts to be used. opw-4985380
Fully flexible employees can now request time off in hours as well as full days. This helps related apps such as Timesheets and Planning accurately record paid holidays and unavailable working periods.
Original PR description
In this PR, we allow fully flexible employees to take time off in hours or days, to allow other apps such as timesheet to encode their paid holidays or planning to use unavailable intervals Forward-Port-Of: odoo/odoo#217938
Accounting now handles manually adjusted tax amounts more accurately when preparing electronic invoices. It also improves how global discounts and returned items are spread across invoice lines, helping country-specific formats such as Mexico's CFDI report amounts correctly.
Original PR description
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts…
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. This commit also adds a new helper '_dispatch_global_discount_lines' that can be used to split the global discount lines across the others base lines. That way in EDI like Mexico, the global discount can be reported line by line as a discount per line and no longer a big discount applied on a single line. There is also another helper '_dispatch_return_of_marchandise_lines' that allows to dispatch negative lines using the quantity. For example, if you buy 3 times the same product but one is returned because broken, you will end up with a sell of 2 products instead of 3 but having a discount of 33.33%. This makes the difference when generating the mexican CFDI. task-id: 4926200 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where starting a new order with a default preset that requires a customer name did not show the name entry popup. Staff will now be prompted as expected, helping restaurants capture the needed customer details for takeout or similar orders.
Original PR description
Steps to reproduce: - go to the setting of your pos.config - set the default preset as takeout (or any other that require the name) - open your pos - click on new order - the slot selection opens (only if set so it's ok) - but then no dialog to enter the name of the client Issue: The handleSelectNamePreset method in the POS Restaurant module attempts to access the selected preset through the order, but the preset has not yet been set on the order at that point. Fix: Make sure the preset is set on the order before calling handleSelectNamePreset. Task-5030520 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
The Point of Sale now handles new orders that do not yet have a preset assigned, avoiding a crash during customer selection or initial order loading. This keeps cashier workflows running smoothly when address-based presets are configured.
Original PR description
STEPS TO REPRODUCE: ---------------- - Open Point of sale - Create preset in the backend with Identification = Address (make it Default). - Open Register - Try to new order and select a customer. ISSUE: ------------------ - Crash occurs if the order has no preset set yet (e.g., during customer selection or initial load). CAUSE: ------------------- - Accessing the preset’s fiscal position and pricelist even when no preset is set. FIX: --------------------------- - Used optional chaining (?.) to safely access preset fields. TASK-5005015
Event calendar slots now keep the intended calendar date when the user and event are in different time zones. This prevents sessions from being created a day late in cases where timezone conversion crosses midnight, improving scheduling accuracy for event organizers.
Original PR description
Purpose ======= Fix the creation of slots at the wrong date. Specification ============= User timezone: Europe/Brussels Event timezone: America/Los Angeles When creating a slot on the calendar on the 10th of April from 8PM to 11PM, the slot is created from 8PM to 11PM but on the 11th of April. In scenario where the conversion from the local tz to the event tz changes the date, the slot is created at the wrong date. => After conversion, the DateTime 'zone' param needs to be set back to the local tz (without changing the converted times) to make sure the calendar renders records correctly as it always expects datetimes expressed in the 'local' tz. related PR: https://github.com/odoo/odoo/pull/205945 Task-4743999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The French point of sale compliance check now avoids loading extra order data that it does not need. This reduces memory usage substantially for businesses with large numbers of POS orders, helping the report run more reliably.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#223535 Forward-Port-Of: odoo/odoo#222416
Opening a project could fail after a related app, such as Timesheets, was uninstalled because a saved embedded action still referred to fields from that app. The change safely hides unavailable embedded actions instead of crashing, allowing users to keep working normally.
Original PR description
The system failed to evaluate the embedded action, which refers to the Uninstalled module.
**Steps to produce:-**
- Install `Project` and `Timesheets`.
- Go to Project and open any project.
- Click on the `embedded action` icon and select Timesheets.
- `Save` the view from the `embedded action's icon`.
- Now, `Uninstall Timesheets`.
- Now, go to that Project and try to open it.
**Error:-**
`KeyError: 'allow_timesheets'
ValueError: Invalid field in filter of project.project:
[('allow_timesheets', '=', True)]`
**Solution:-**
- Added a safe check using `hasattr` to verify if the `python_method` defined on the embedded action actually exists on the specified model.
- Ensured that if the method is missing or invalid, the embedded action is marked as not visible instead of causing a crash.
**sentry-6738596751**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#218564Fixes an issue where removing text color or formatting in the HTML editor could cause the editor to get stuck. This makes editing content more reliable, especially when formatting is applied to larger text blocks or non-editable elements are selected.
Original PR description
**Current behavior before PR:** - When color was applied to a block-level element, attempting to remove it caused the `removeFormat` method to enter an infinite loop. - Removing formatting on a contenteditable false element infinite loop when removing format. **Desired behavior after PR is merged:** - Now, the color is correctly removed from the selected text, even when it is applied to a block-level element. - Now, the toolbar no longer opens when the selected element is contenteditable false task: 4575459 Forward-Port-Of: odoo/odoo#223786 Forward-Port-Of: odoo/odoo#198319
Restaurant table appointments are now correctly loaded in the Point of Sale when restaurant mode is enabled. This ensures staff can see upcoming table bookings on the floor plan, reducing missed reservations and improving service coordination.
Original PR description
Issue: The calendar envents that have a restaurant table ressource are not loaded in the pos if the config is in restaurant mode. Fix: If the config is a restaurant the calendar_event pos domain will return a domain containing the appointment_ressources linked to the config restaurant tables. This commit also fixes the test that checks for the appointment-label on the floor plan. Task-id: 4970986
Knowledge articles now save any pending edits before the page refreshes after moving another article nearby. This prevents users from accidentally losing their work and makes article editing more reliable.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Fixed an issue where automatic subscription invoicing could stop too early when a limited batch included subscriptions that were not ready to invoice. The scheduler now applies the limit after checking invoice eligibility, helping ensure ready subscriptions are invoiced on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884 Forward-Port-Of: odoo/enterprise#92690 Forward-Port-Of: odoo/enterprise#89787
Users with standard Appointment access can now create resource-based appointments from calendar events without hitting an access error. This restores the expected booking flow when an appointment type has a single resource, reducing disruption for staff managing appointments.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373
Receipt validation now correctly triggers lot or serial number label printing after a quality check is passed. This prevents missing labels when receiving tracked products and improves completion of mixed receipts with and without quality checks.
Original PR description
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The…
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action ## Cause: The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close' ## Note: The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option ## Steps to reproduce: - Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts - Create a Product tracked by Unique Serial Number - Add a Quality Check for the Receipts operation - Create a New Receipt for the product - Mark as Done and Add the Serial Number - Validate the receipt and Pass the check - Before the fix, no document was downloaded opw-4790427 Forward-Port-Of: odoo/enterprise#92850 Forward-Port-Of: odoo/enterprise#90134
Users with appointment access can now create resource-based appointments directly from calendar events without hitting an access error. This keeps the booking flow working as expected when an appointment type has a single resource assigned.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373
Manufacturing orders now follow the configured backorder preference when the first work order is completed with a smaller quantity. This prevents unwanted production and work order backorders, helping teams keep manufacturing records aligned with their operational settings.
Original PR description
When marking as done the first workorder with less quantitites, backorders (mo+wo) were always created, with no respect of the 'Create Backorder' setting defined on the Manufacturing picking type. Now this setting is taken into account. task: 4440866
Expiration dates shown in the Barcode app are now displayed using the user's local timezone. This prevents products received with a midnight expiration time from appearing as expiring one day earlier, reducing confusion during warehouse receipt validation.
Original PR description
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the…
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the Purchase app - Create a new Request For Quotation - Select a product that: - is a good tracked by lot - has the `Expiration Date` field enabled (Inventory tab > Traceability) - Confirm the RFQ - Click the `Receipt` smart button - Click the `hamburger button` and enter an expiration date at midnight. - Go to the Barcode application > Operation > Receipts - Open the corresponding RFQ - Click Edit and increase the quantity to 1, then Validate - Observe that the date is displayed as one day earlier **Cause**: The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day. **Solution**: To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date. opw-4865513 Forward-Port-Of: odoo/enterprise#92109 Forward-Port-Of: odoo/enterprise#88526
Reconciliation between a customer invoice and a vendor bill now keeps the correct partner on each accounting line. This prevents paid invoices and bills from being reflected under the wrong customer or vendor in reports such as the Partner Ledger.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#92909 Forward-Port-Of: odoo/enterprise#89972
Users editing a Knowledge article will no longer lose unsaved work when another article is moved beneath it. The system now saves pending changes before reloading the article, reducing frustration and preventing accidental data loss.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Manufacturing users can now search for employees to assign without triggering errors caused by records from companies they cannot access. The employee picker is limited to employees in companies available to the current user, making work order assignment more reliable in multi-company setups.
Original PR description
Task ID: 5005753 Prev behavior: when searching for employees to assign (employee_assigned_ids) from the manufacturing page and using "Search More", it was raising an error bc it was fetching data even from employees part of companies he's not part of New behavior: added domain over employee_assigned_ids such that the accessed users are only the ones being part of a company the current user can access Forward-Port-Of: odoo/enterprise#92079
Payroll users can now edit validated work entries as long as those entries have not yet been included in a payslip. This helps teams correct payroll preparation mistakes earlier without weakening the protection around entries already used for payslip calculations.
Original PR description
Originally, the validated work entries cannot be modified, either they have been included in payslips or not. This logic has been adjusted to allow for modifying the work entries marked as "validated" if they are not linked to a payslip. Task #4921300 Forward-Port-Of: odoo/enterprise#89552
The Indian Payroll yearly salary report now prints correctly when salary structure names are stored in multiple languages. This prevents an error that blocked payroll teams from generating the report after payslips were paid.
Original PR description
Steps to Reproduce:
- Install Indian Payroll Localization
- create a payslip of any employee and mark as paid
- try to print yearly salary report from reporting menu
Issue:
- A traceback error occurs when printing the yearly salary report.
Reason:
- the sturcture name is translatable field, which gives the value in a dict with the key as languages like {'en_US': 'India: Regular Pay'}.
- The error occurs because the code attempts to use this dictionary with setdefault, which expects a string.
Solution:
- Get the structure name corresponding to the appropriate language from the dictionary before passing it to setdefault.
task-5002518
Forward-Port-Of: odoo/enterprise#91901Versions
--------
- 18.0+
Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.
Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.
Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.
Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.
In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.
As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668
Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
- This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
- `property_product_pricelist` shouldn't get synced by itself
- `specific_property_product_pricelist` is already included by the base method
opw-4988736Resetting a refused or cancelled Extra Hours time off request now correctly recreates the related overtime entry. This keeps employees' extra hours balances accurate when time off requests are changed and reset.
Original PR description
When refusing or cancelling a time off request of type Extra Hours, the linked hr.attendance.overtime record was hard deleted. As a result, if the leave was later reset, the extra hours were not deducted again. This fix ensures that a new hr.attendance.overtime record is recreated when resetting the leave, restoring the correct impact on the employee's extra hours balance. Related task: 4966880. 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
Fixes an issue where deleting a bank account from a customer could trigger an error and interrupt the workflow. The change prevents invalid empty duplicate-bank-account data from being processed, making customer bank account management more reliable.
Original PR description
Currently an error occurs when we try to remove bank accounts from a partner. **Steps to reproduce:** - Install `accountant` (with demo), Go to customers and create a new one with random name. -…
Currently an error occurs when we try to remove bank accounts from a partner.
**Steps to reproduce:**
- Install `accountant` (with demo), Go to customers and create a new one with random name.
- Under accounting tab add a new bank account with an acc number, bank and save.
- Now remove the bank account record.
**Error:**
`AttributeError: 'NoneType' object has no attribute 'origin'`
**Cause:**
- The error occurs because of the SQL query [1] returning None values in the `id2duplicates` dict, somewhat like `{1: [None]}`, this caused the browse [2] to assign `None` to the `duplicate_bank_partner_ids`.
- While recording snapshots for diff checking in onchange system the none value will be stored like`None: {display_name:{}}` and when the line [3] tries to access `id_.origin` where `id_` is None and causes the error.
**Solution:**
- Added a condition which makes sure null values are not accounted. (The Join is added to makes sure that the correct `partner_id` is fetched.)
[1]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L71-L85
[2]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L88
[3]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/web/models/models.py#L1173
sentry-6748249363
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prRestricted website editors can edit permitted website content without triggering an access rights pop-up when saving. The change prevents editor-only metadata from being added to page elements that restricted users are not allowed to modify directly, improving the editing experience while preserving permissions.
Original PR description
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival"…
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival" - user is able to edits is footer contents,make a change - try to save. Observation: A pop-up for access right appears Cause: after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , we allow website to be editable for restricted user if, user can modify other models, which are editable from website,like event. And, if website is editable, we brand the ir.ui.views nodes, https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94 but restricted user do not have access to ir.ui.view model, causing access issue Note: if a node is branded, that means it is editable Fix: Brand ir.ui.view nodes only if user has full access to website editor opw-4659114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221202
Duplicating a warehouse now also duplicates its Point of Sale operation type, matching the behavior of other warehouse operation types. This prevents missing PoS logistics settings on copied warehouses and reduces manual correction after duplication.
Original PR description
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types…
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types will be duplicated. ## Reproduction Steps 1. Make sure PoS and inventory are well installed. 2. Go to inventory. 3. Click on configuration, then warehouse. 4. Select a warehouse, click on action, then duplicate. 5. Click on configuration, then on Operation Types. ### Expected behavior We should be able to see 2 instances of PoS operation type: one for the original company, and one for the copy. ### Unexpected behavior There's only one instance of PoS operation type, which is related to the original company. ## Origin of the issue PoS operation type is a model inherited from stock.warehouse, and no copy method was defined. Therefore, upon duplication, the copy method of the original stock.warehouse was called, leading to issues with the field created in the inherited version. __ opw-4991271 Forward-Port-Of: odoo/odoo#222694
Fixes Turkish e-invoice and e-archive XML data so Nilvera no longer rejects invoices when no tax office is set. Also corrects the displayed country label from the misspelled “Turkyie” to “Türkiye,” reducing validation failures and confusion for users.
Original PR description
### Description of the issue/feature this PR addresses: Nilvera rejects E-Archive invoices if extra fields are present under `PartyTaxScheme` when no tax office is set. In addition, the…
### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.
### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.
### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:
```xml
<cac:PartyTaxScheme>
<cac:TaxScheme>
<cbc:Name>TAX OFFICE NAME</cbc:Name>
</cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.
task-5017223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prInvoices created after portal subscription payments now trigger the required electronic document signing process. This restores compliance for localizations such as Mexico, where government-signed invoices are required after payment.
Original PR description
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses…
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses Stripe but it can be reproduced with any - Make sure the online payment setting is active - Go to subscription module - Do a new order - In other info, add the online payment checkmark - Confirm the order - Generate the payment link or go into the preview - Make the payment ## Issue: The invoice is generated, but is not signed by the government (no edi is generated), as it used to. ## Cause: The flow works in 17.0 but for the wrong reason. Before this [commit](https://github.com/odoo/enterprise/pull/70562), two mails were sent. And during the chain of triggers of the second email, edi document was generated with `orders._send_success_mail(tx.invoice_ids, tx)`. https://github.com/odoo/enterprise/pull/70562/files#diff-8778c8dce7ca1c24de19f26f11ac0c5410c6c2a4d121c3815682a2323cbb09c2L177 After the removal of the method, it should still work since we still have `payment.transaction._send_invoice` which calls `_generate_and_send_invoices` and should trigger the sub calls necessary for generating the edi stuff. But in `_create_or_link_to_invoice`, we check that the transaction has no invoice_ids linked (make sense with the name of the method). However, at this stage, we already created the invoice in https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/controllers/portal.py#L419-L424 And unfortunately, it will be effectively possible to "let the post process of transaction create" the invoices only in Master (the code is not ready yet). For now it would be too risky for a stable version to make such change. ## Solution: We ensure EDI documents are generated whenever a `subscription_action` is set. To achieve this, modify the `_post_subscription_action` hook to call `_subscription_post_success_payment` for any `subscription_action`, including `assign_token`. From `_subscription_post_success_payment`, we can call `_generate_and_send_invoices` on any invoice that has an EDI associated with it, which sends & signs the required EDI documents. opw-4648189
Fixed an issue where disabled Urban Piper delivery providers were automatically re-enabled when a cashier returned from the backend to continue selling. Provider availability is now kept consistently in the backend, preventing unwanted online status changes and avoiding unnecessary update requests.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969
Fixes an issue where adjusting a checkout time in the weekly Attendance view could be lost when saving. The system now keeps the user’s selected checkout time instead of replacing it with the current time, helping prevent incorrect attendance records.
Original PR description
Steps to Produce: - Go to the Attendance interface and select week. - Drag on one column to adjust checkout. - Save the change. Issue: - Dragging on one cell deletes the checkout value from the context. - As a result, the system sets the checkout time to the current time instead of the dragged value. - This leads to incorrect attendance records. Fix: - Ensure the checkout value remains in the context when dragging the cell. - Preserve the modified checkout time so it reflects the user's intended change instead of defaulting to the current time. Task-4958060
Knowledge now saves any unsaved article edits before reloading the page after another article is moved nearby. This prevents users from accidentally losing work while organizing articles in the sidebar.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494
Fixes an error that occurred when refunding Mexican Point of Sale orders containing a global discount line. This helps businesses process refunds normally without interruption when discounts were applied.
Original PR description
**Steps to reproduce:** ``` - Install PoS mexican localization - Activate PoS setting Global Discounts - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ``` **Cause:** Bad fw-port In the original commit `json.lines` is an array and accessing index "2" of the array was not a problem (https://github.com/odoo/enterprise/pull/84331/files#diff-63a117ed6751a8aae4fcb11d867177f5d0feb78cc1e2f3461f425babc10b5016R15) From 18.0 we are accessing the record `currentOrder` itself and `currentOrder.lines` is an PosOrderline object which doesn't have a property named "2". **Fix:** Remove index access `[2]` opw-4899501