Navigate
Branch
Tuesday, August 20, 2024
49 changes
14 changes
Resolved issues and error corrections
This fixes an issue where saving an inventory receipt could fail after users entered lot numbers in detailed operations. The change prevents receipts from getting out of sync, so users can save and validate tracked products without missing-lot errors.
Original PR description
Steps --- * install stock * create product P, and Q tracked by lot * create a receipt for 1 P and 1 Q > *Mark as Todo* * go to the detailed ops for the P move (list icon on the right of the lines) * set the lot name to 001 > *Save* * repeat for the Q move, set the lot name to 002 * Try to save the picking * => **clicking the cloud save icon does nothing** * Try to Validate * => Traceback: missing lot for the Q move Cause --- We try to save the picking when it is dirty when opening the move lines This will create new datapoints corresponding to the backend data, and but the datapoints linked to the inputs are still the old ones so we become out of sync opw-4107258
Miscellaneous changes
Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176039
**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they
Original PR description
**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for…
**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they are being created with respect to. **Steps to reproduce:** 1. Create a component_product such that: - is storable - category has automated valuation and avg cost method - has the `dropship subcontractor on order` route - has some vendor 2. Create a final_product such that: - is storable - category has automated valuation and avg cost method - invoice policy is on quantity delivered - has a subcontract bom that consumes some quantity of component_product - has a subcontractor vendor 3. Create a sale order for >1 of the final_product, set the route on order line to dropship, confirm the SO and the PO which is generated 4. In the dropship transfer, set the quantity to half the demand and validate -> generate the backorder 5. On the SO, create an invoice for the completed quantity and confirm it 6. Complete the rest of the order in the backordered dropship transfer and create and confirm another invoice on the SO 7. Go to the SVL tree view and observe that the latest SVL is ~2x (before the compensatory SVL difference is applied) **Cause of the issue:** When the SVL is created, its value is calculated by taking the difference of subcontract SVL(s) values and dropship SVL(s) values. The subcontract SVLs come from the `move_orig_ids` of the current SVL's move. When the sequence is broken up by backorders, these moves are still used in the calculation for the value of future SVLs. This results in the inaccuracy. **Fix:** Only use SVLs from the move in the current move's `move_orig_ids` which has the maximum `backorder_sequence`. opw-4078510 Forward-Port-Of: odoo/odoo#176958 Forward-Port-Of: odoo/odoo#176163
[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894
Original PR description
[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894
before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215
Original PR description
before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215
Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209
Original PR description
Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavi
Original PR description
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavior before PR: Calls to methods that have `_compute_translated_display_name` somewhere in the call stack will not see the context that they have been originally given. Desired behavior after PR is merged: All methods will see the context that they have been given at the call --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170682 Forward-Port-Of: odoo/odoo#170050
Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176943 Forward-Port-Of: odoo/odoo#170021
When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - G
Original PR description
When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - Go in shop, add a product to the cart and proceed until you reach the extra info step. - Edit the extra info page. - Remove all form fields. - Add a field to the form. => An error dialog was displayed. opw-4102127 Forward-Port-Of: odoo/odoo#176559
`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023
Original PR description
`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data. Here is traceback: ``` File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data need_refresh = request.env.user.sudo()._syn
Original PR description
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking…
Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data.
Here is traceback:
```
File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data
need_refresh = request.env.user.sudo()._sync_google_calendar(GoogleCal)
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 73, in _sync_google_calendar
synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 197, in _sync_google2odoo
odoo_record.with_context(context)._write_from_google(gevent, vals)
File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in _write_from_google
if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in <genexpr>
if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
KeyError: 'start'
```
opw-4100958
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176634**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes
Original PR description
**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice…
**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes on debit and credit fields. The values are generally the same, so no write is really performed. However, for some values (e.g. 14.79), there is a floating point issue (i.e. 14.790000000000001) and the "get_records_different_from" method considers the record as different and triggeres an actual write. **Solution:** In "get_records_different_from" method, for monetary fields, apply the same rounding to the current value than the one applied when the value is converted to cache. opw-3773287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176218
[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987
Original PR description
[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987
@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538
Original PR description
@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538
24 changes
New functionality added to Odoo
A new Vietnam localization report provides detailed tax information from accounting entries. This helps businesses operating in Vietnam review tax data more clearly and support local reporting needs.
Original PR description
- Create custom tax report which display the tax details of moves task-3558782
Enhancements to existing features
Spreadsheet side panels have been refreshed with a cleaner, more modern Odoo-style design across charts, filters, comments, and pivot-related views. This improves visual consistency and makes these configuration panels easier and more pleasant for users to work with.
Original PR description
Go through all the side panels and update their style to be prettier and more modern (and more odoo like). Task: 4107500
Website URLs are updated to a clearer, more human-friendly format across appointment booking, helpdesk knowledge and forum pages, rentals, subscriptions, and Studio. This improves the experience for customers and staff by making links easier to read, share, and recognize.
Original PR description
\* = {generator, helpdesk_forum, helpdesk_knowledge, sale_renting, sale_stock_renting, sale_subscription, studio}
This commit improves the readability of URLs by modifying them to a new, more human-friendly format.
Task-3820230URLs across social media integrations and dashboard document flows have been updated to a clearer, more human-friendly format. This makes links easier for users to understand, share, and recognize while navigating related pages.
Original PR description
\* = [social_facebook, social_instagram, social_linkedin, social_twitter, spreadsheet_dasboard_documents] This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
URLs used in the Sign and quality control worksheet flows have been updated to a more readable format. This makes shared links and navigation easier to understand for users while preserving the existing signing and worksheet experience.
Original PR description
*= quality_control_worksheet This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Several sales-related areas now use more readable web addresses for customer and user flows. This makes links easier to understand, share, and recognize across Amazon sales, planning, rentals, and subscriptions.
Original PR description
*= {amazon, planning, renting, subscription}
This commit modifies existing URLs to the new format
so that the URL's become more human readable.
Task-3820230Timesheet pages now use clearer, more human-readable web addresses. This makes links easier for users to understand, share, and recognize while keeping the same timesheet functionality.
Original PR description
This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Accounting users can now use a dedicated credit card journal type that behaves like a bank journal while keeping setup simpler and avoiding irrelevant fields. Internal transfers during reconciliation are also made broadly available, helping teams handle money movements between accounts more smoothly.
Original PR description
Create a new credit card journal type that is similar to a bank journal, streamlining the configuration and avoiding useless fields. --- The Belgian localization added the possibility to perform internal transfer during the reconciliation; this option has been made general. odoo/odoo/pull/175315 task-3925608
This update improves internal documentation for product configuration in Sales Renting and Sales Subscription. It helps development tools better understand the code, making future maintenance smoother without changing what users see.
Original PR description
This cleanup will allow IDEs to recognise parameter types.
Indian payroll settings now let companies store their EPF employer ID and ESIC IP number. This supports more complete Provident Fund-related company records for payroll compliance and administration.
Original PR description
In this PR, EPF employer ID and ESIC IP number fields were added, which are used by the company for Provident Fund. Task - 4023367
Resolved issues and error corrections
Screen orientation changes for self-ordering IoT displays are now sent directly from the user interface instead of the server. This avoids connection issues where the backend could not reach the IoT box, helping display rotation changes apply reliably.
Original PR description
As we performed the screen orientation update request from the backend, IoT couldn't be reached. We now send the request from the JS. Community PR: [https://github.com/odoo/odoo/pull/177236](https://github.com/odoo/odoo/pull/177236)
The report editor now avoids a visual overlap between heading hints and displayed field expressions. This makes report editing clearer and reduces confusion when working with dynamic heading content.
Original PR description
Before this commit, when a h2 node has a t-out, there was a collision between the display of `.o-we-hint` and the display of the expression of the `t-out` in terms of styling. This commit solves this by giving priority to the expression.
This fixes an automated test so it waits for all four serial numbers to finish processing before checking results. The change helps prevent false build failures and improves confidence in the stock barcode workflow validation.
Original PR description
In the tour `test_serial_product_packaging`, we didn't wait for the four serial numbers to be fully processed before checking the app state, which can cause race condition (only 3 serial numbers processed when doing the asserts.) runbot build error: [75125](https://runbot.odoo.com/web#id=75125&view_type=form&model=runbot.build.error&menu_id=405&cids=1)
Self-order kiosk setup now connects to IoT devices correctly when the database uses a secure HTTPS connection. This prevents connection errors during kiosk installation and helps keep setup reliable for users.
Original PR description
We were fetching through http, leading to errors when fetching from a https db. Now using `rpc` instead of `fetch` to request dynamically.
Code cleanup and technical improvements
This update reorganizes the setup of internal enterprise messaging performance tests. It helps keep the test suite easier to maintain without changing how users experience the product.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/177239
Barcode scanning and related tools were moved into a shared core area to remove an incorrect internal dependency. This keeps shared features easier to maintain and reduces the risk of future issues across apps that rely on barcode or view behavior.
Original PR description
This commit fixes a dependency issue by moving the barcode logic (dialog, scanner...) from webclient/ to core/. Indeed, Many2OneField uses it, but ideally, the views/ folder should not have dependencies to the webclient/ folder. That dependency showed that the barcode logic wasn't defined at the right place. Part of task 3446824
Miscellaneous changes
The display for the Month 13 date filter was kind of ugly after the date filters refactoring. This makes it more useable and pretty to use. Forward-Port-Of: odoo/enterprise#66894
Original PR description
The display for the Month 13 date filter was kind of ugly after the date filters refactoring. This makes it more useable and pretty to use. Forward-Port-Of: odoo/enterprise#66894
Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that. Traceback group: 1415 ```py ('social.menu_social_post', 609, 'Social Marketing > Posts', 860): Traceback (most recent call last): File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 256, in crawl_menu self.mock_action(action_vals) File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 429, in mock_action mock_method(model, view, fiel
Original PR description
Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that. Traceback group: 1415 ```py ('social.menu_social_post', 609, 'Social Marketing > Posts',…
Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that.
Traceback group: 1415
```py
('social.menu_social_post', 609, 'Social Marketing > Posts', 860):
Traceback (most recent call last):
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 256, in crawl_menu
self.mock_action(action_vals)
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 429, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 458, in mock_view_form
[data] = record.read(fields_list)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3670, in read
return self._read_format(fnames=fields, load=load)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3902, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 6727, in __getitem__
return self._fields[key].__get__(self)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1263, in __get__
self.compute_value(recs)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1445, in compute_value
records._compute_field_value(self)
File /home/odoo/src/odoo/saas-17.4/addons/mail/models/mail_thread.py, line 428, in _compute_field_value
return super()._compute_field_value(field)
File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 5037, in _compute_field_value
fields.determine(field.compute, self)
File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 101, in determine
return needle(*args)
File /home/odoo/src/enterprise/saas-17.4/social_instagram/models/social_post_template.py, line 36, in _compute_instagram_preview
faulty_images, error_code = post._get_instagram_image_error()
ValueError: too many values to unpack (expected 2)
```
Forward-Port-Of: odoo/enterprise#68232A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly. This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked cap
Original PR description
A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly. This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked capacity and existing bookings. Indeed, the asked_capacity will not be counted when computing the total reserved percentage. In practice, this means that events crossing the treshold will be automatically 'accepted' instead of 'needsAction' The fix creates another variable to avoid the issue and adds a test. Task-4084727 Forward-Port-Of: odoo/enterprise#67626
Steps to reproduce: - Open Aged Receivable report - Press the Days Interval filter -> Traceback stating "TypeError: optionPath.split is not a function" The issue was introduced in the following commit, which reworked how filters are updated: https://github.com/odoo/enterprise/commit/10d61ca19ea850be7023043051c31f2b4bd3354c task-4122464 Forward-Port-Of: odoo/enterprise#68532
Original PR description
Steps to reproduce: - Open Aged Receivable report - Press the Days Interval filter -> Traceback stating "TypeError: optionPath.split is not a function" The issue was introduced in the following commit, which reworked how filters are updated: https://github.com/odoo/enterprise/commit/10d61ca19ea850be7023043051c31f2b4bd3354c task-4122464 Forward-Port-Of: odoo/enterprise#68532
### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units on hand) - Create a BOM for P with an operation op 1 and two component lines: - 1 x COMP 1 consumed in op 1 - 1 x COMP 2 consumed in op 1 - Create and confirm an MO for 5 units of P - Go to the shopfloor and click on register production. **> the qty is updated to 1 on COMP 2 but to 5/1 on
Original PR description
### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units on hand) -…
### Steps to reproduce:
- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
- 1 x COMP 1 consumed in op 1
- 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.
**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**
As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P
### Cause of the issue:
When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").
Community: https://github.com/odoo/odoo/pull/168205
opw-3887580
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#68189
Forward-Port-Of: odoo/enterprise#63912Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work. This commit fixes two issues: 1. Get back packaging data (product and quantity) when a GS1 barcode is scanned; 2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned. Forward-Port-Of: odoo/enterprise#68315 Forward-Port-Of: odoo/enterprise#67727
Original PR description
Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work. This commit fixes two issues: 1. Get back packaging data (product and quantity) when a GS1 barcode is scanned; 2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned. Forward-Port-Of: odoo/enterprise#68315 Forward-Port-Of: odoo/enterprise#67727
Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_sco
Original PR description
Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_score field will be received here. Due to this, the API request to sync a single template and multiple templates are modified, and all the basic fields like name, components, language, status, category, and ID are included along with the quality_score field so we receive all basic fields and quality_score field. Task-3908894 Forward-Port-Of: odoo/enterprise#67764 Forward-Port-Of: odoo/enterprise#61150
We replace some calls to runAllTimers by calls to advanceTime in order to not to have to remove components/services from mail (see https://github.com/odoo/enterprise/pull/68143 for more info). Forward-Port-Of: odoo/enterprise#68540
Original PR description
We replace some calls to runAllTimers by calls to advanceTime in order to not to have to remove components/services from mail (see https://github.com/odoo/enterprise/pull/68143 for more info). Forward-Port-Of: odoo/enterprise#68540
11 changes
Enhancements to existing features
This update adds a helpful alert that reminds users when they create credit notes after November 30th of the financial year. According to Indian tax law (CGST Act 2017), these late credit notes cannot be included in GST reports, so the alert helps ensure compliance by prompting users to exclude the tax from their GSTR filings.
Original PR description
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664
Resolved issues and error corrections
Fixed an issue where batch payment amounts weren't updating when individual payments within the batch were reconciled with bank statements. The system now properly recalculates the remaining balance of a batch whenever any of its payments are matched, ensuring users see accurate amounts in their bank reconciliation interface.
Original PR description
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updates on every reconciliation between a Bank Statement Line and a Payment. Adding it to the dependencies of `_compute_from_payment_ids` will make reconciliations trigger the method. opw-4062387 Forward-Port-Of: odoo/enterprise#67519
This update enables customers to generate return labels when using Sendcloud for deliveries, a feature that was previously disabled. A helpful warning message has been added to guide customers when selecting return products. This capability is required by major marketplace partners like Zalando and Otto.
Original PR description
Before this commit: Generating return label on delivery was disabled intentionally. After this commit: Option to select return label on delivery is enabled. A warning is added in `sendcloud_product_selection_widget` for customers befroe selecting return product. opw-4008265
This update fixes the visual styling of appointment descriptions in the Odoo Appointments module. The styling issue has been corrected to ensure appointment details display properly for users booking appointments.
Original PR description
Commit fixes appointment description styling task-3446959
Fixed a bug where cancellation notification emails were only sent when the appointment organizer cancelled, not when attendees cancelled. Now cancellation emails are properly sent to all relevant parties when an appointment is cancelled, ensuring better communication and reducing confusion about appointment status.
Original PR description
**Steps to reproduce** 1).Log as Mitchell, create an appointment, and set Joel as an attendee 2).Log as Joel, open the appointment page, and cancel -> Cancellation mail is not sent **Before this PR** A cancellation email is only sent when the person who books the appointment cancels the appointment. **Technical** https://github.com/odoo/enterprise/commit/46f1b8aaeaa94d3ac7b72784a8fa7120f8a3e8a5#diff-394903898ffdd9f9e1f053ecda2afd00cda86d6cc96159268fbe4fefc62f3a83R187 Before the above commit we were archiving the meeting if there are < 2 attendees in the event. So now we restore that condition with the current conditions **After this PR** Now, a Cancellation email will also be sent if an event contains less than 2 attendee after the cancellation. Task-3975493
This fix prevents duplicate partner records from being created when importing a French FEC file that contains partners already existing in the system. Previously, the system would create a new partner even if one with the same reference already existed, resulting in duplicate contacts. The fix ensures existing partners are properly recognized and reused during the import process.
Original PR description
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them opw-3932234
When customers try to purchase items that are no longer in stock, they now see which specific product is unavailable in the error message. Previously, the error didn't identify the product, making it confusing for customers with multiple items in their cart to know what to remove.
Original PR description
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to reproduce the issue:__ - add products to your cart - remove one or many products of the stock - try to validate your payment __linked to Odoo PR:__ https://github.com/odoo/odoo/pull/174615 opw-4016059 (upgrade issues) Forward-Port-Of: odoo/enterprise#67423
This fix prevents an error that occurred when validating shipments through Sendcloud's Mondial Relay delivery service if the delivery partner address was missing required parent information. The system now provides a clear error message to users instead of crashing, ensuring a smoother delivery workflow.
Original PR description
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - click on the delivery address - remove the partner's parent_id - add an email and phone number to the partner and save - go back to the picking page and click validate - a traceback will appear ## Solution: - in the `_prepare_parcel_common_data` method, raise a user error if the SO has `access_point_data` and the partner has no parent_id. OPW-4042529
This fix corrects an issue in the EU OSS tax reporting module where incorrect tax lines were being included in the closing entry. The problem occurred because a model wasn't properly updated to use the new tax report handler, causing the system to include foreign tax entries that should have been filtered out. This ensures that only the correct tax entries appear in your closing reports.
Original PR description
During aea506700d9a3253c02f46f587a3e360a89cce0b, we forgot to adapt the model that was inheriting `account.generic.tax.report.handler` to make it inherit the new `account.tax.report.handler` model. Because of that, we never passed into the `_get_vat_closing_entry_additional_domain` method, leading to wrong lines being included in the closing entry. Steps: - Install l10n_lu and l10n_eu_oss_reports - Create and confirm two invoices, one with tax 17% S and the other with tax 20.0% FR VAT - Go to LU Tax Report, select the same month as the invoices - Click on Closing Entry button -> There are lines from tax 20.0% FR VAT, they should not be there opw-4015752
When duplicating a pricelist, the system now properly copies time-based rules for rentals and subscriptions, not just regular price rules. This ensures that all pricing configurations are preserved when creating a copy of an existing pricelist.
Original PR description
Duplicating a pricelist would copy over the price rules, but not the time-based rules. Adding copy to this field allows that to work. opw-4088788 Forward-Port-Of: odoo/enterprise#68066
This update corrects the Spanish translation for "Colony code" in the Mexican EDI module from "Código postal" (postal code) to "Código de colonia" (colony code). This ensures accurate terminology for Mexican users when processing electronic invoices, improving clarity and compliance with local standards.
Original PR description
"Colony code" translation changed from: "Código postal" => "Código de colonia"