Daily updates from Odoo
Tuesday, March 5, 2024
75 changes
38 changes
Resolved issues and error corrections
This update resolves an issue where website tours sometimes caused buttons to appear blank due to a conflict with content loading. The fix provides a fallback to an empty SVG, ensuring buttons always display correctly. This improves the user experience for website tour functionality.
Original PR description
In the test framework at [1], when a tour is finished, a request to stop loading content is sent to the browser. This clashes with [2] which sometimes is in the middle of a fetch request from the Snippets Menu. (Specifically when loading SVGs icons for buttons.) This commit fixes that by adding a fallback to an empty SVG when the fetch fails. This could lead to buttons appearing empty. [1]: https://github.com/odoo/odoo/blob/eca34179a1657d8fcbdf845349b5b051e5fc6043/odoo/tests/common.py#L1437 [2]: https://github.com/odoo/odoo/blob/eca34179a1657d8fcbdf845349b5b051e5fc6043/addons/web_editor/static/src/js/editor/snippets.options.js#L110 runbot-54422
The project tour now functions correctly on mobile devices. This update resolves a previous bug where the tour would get stuck, preventing users from fully experiencing the feature. The fix involved adding a mobile-specific step and adjusting a trigger to ensure compatibility.
Original PR description
The tour isn't working if you run it on mobile mode, it gets stuck at some points. To fix this issue, a mobile step was added, and one trigger was edited to work with mobile mode as well. task-3709501 Forward-Port-Of: odoo/odoo#155789 Forward-Port-Of: odoo/odoo#153444
This update fixes an issue where user preferences (like home menu app order) were not consistently saved during sessions. The change ensures that user settings, including app order, are correctly preserved after reordering, improving the user experience. This resolves a bug that caused lost preferences.
Original PR description
User settings is used to store user's preferences, in web we use it to store the home menus apps order and in mail for various settings like push to talk key, discuss sidebar preferences, etc. Before…
User settings is used to store user's preferences, in web we use it to store the home menus apps order and in mail for various settings like push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service overrided all the previous key that has not been changed because it kept only the changed keys returned by the backend. Leading to preferences being lost during the session when reordering the home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```
Forward-Port-Of: odoo/odoo#155902This update resolves a potential problem where a channel could be removed while a call was still loading, leading to errors. This fix ensures calls are handled correctly and prevents disruptions to user experience. It's a technical improvement focused on stability.
Original PR description
Before this commit, there could be race conditions in which a channel could be removed while the call was still loading, this commit prevents this issue. task-3660964 Forward-Port-Of: odoo/odoo#149034
This update resolves an issue related to how access keys are used within the loyalty program. The change ensures consistent behavior whether accessing loyalty data through retrieval or subscription methods, improving reliability and preventing potential errors. This update focuses on internal improvements within the loyalty module.
Original PR description
Addendum to https://github.com/odoo/odoo/commit/7ed0a773b6e0 Reference PR: https://github.com/odoo/odoo/pull/150418 Forward-Port-Of: odoo/odoo#155927
This update fixes an issue where discounts applied across multiple orders were leading to inaccurate report totals. The system now calculates the total amount for each product line and then sums those totals, ensuring accurate calculations regardless of how many times a product with a discount is ordered. This improves the reliability of sales reports.
Original PR description
Before this commit, if a product had a discount applied in two different orders, it could lead to incorrect calculations in the report For instance, if a product priced at 14.45 had a 30% discount…
Before this commit, if a product had a discount applied in two different orders, it could lead to incorrect calculations in the report For instance, if a product priced at 14.45 had a 30% discount applied, the discounted value would be 10.115, which rounds to 10.12. However, if there were two orders with the same discount, the report calculation would count the quantity of a product with the same discount and calculate the product total amount in one place. This would result in a discounted value of 10.115 * 2 = 20.23, while in the two different orders we had two 10.12 which sums to 20.24. With this commit, the calculation method has been changed. Now, the product amount total for each line is calculated first, and then the sum of these amounts is used to calculate the total for all of the orders. This change ensures accurate computation of the product total sum when discounts are applied across multiple orders. opw-3721376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156044 Forward-Port-Of: odoo/odoo#155899
This update resolves an error that occurred when creating new websites without a linked company. It also ensures existing Brazilian websites are updated consistently after module installation, standardizing their settings. This improves website creation reliability and data consistency.
Original PR description
This commit fixes an issue on websites creation. If a website is created with no company linked to it, an error is raised because website.company_id has no value. This is fixed by using a .get(). While at it a constistency issue is fixed too. When installing the module, already existing websites don't get their setting changed when the module is installed. A post init hook has been added to address this issue so all brazilian webites have the same behavior. Fixed issues originate from this commit: https://github.com/odoo/odoo/commit/45f28eed95b60119fb1770524e10b84eeee5e95f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that expired promotion programs are no longer applied in the Point of Sale system. The issue stemmed from a recent code change that didn't properly handle date formats, allowing outdated promotions to be used. This fix improves the accuracy of promotions and prevents potential revenue loss.
Original PR description
Before this commit, an expired promotion program could still be used. This issue arose due to a recent refactoring, which resulted in the 'date_to' and 'date_from' fields not being properly converted to date format. opw-3782490 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rare crash that occurred when Odoo generated initial assets (like CSS and JavaScript). The issue stemmed from a timing problem where multiple processes attempted to create the same directory simultaneously. This change ensures consistent directory creation, preventing the crash and improving stability.
Original PR description
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time…
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time (CSS, JS); one of the two times might crash.
Traceback :
```FileExistsError: [Errno 17] File exists: '/home/odoo/.local/share/Odoo/filestore/brawl-stars/7d'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/website/models/website.py", line 431, in configurator_apply
redirect_url = theme.button_choose_theme()
File "addons/website/models/ir_module_module.py", line 399, in button_choose_theme
self._theme_remove(website)
File "addons/website/models/ir_module_module.py", line 375, in _theme_remove
self.env['theme.utils'].with_context(website_id=website.id)._reset_default_config()
File "addons/website/models/theme_models.py", line 259, in _reset_default_config
self.env['web_editor.assets'].make_scss_customization(
File "addons/website/models/assets.py", line 38, in make_scss_customization
self.make_scss_customization('/website/static/src/scss/options/colors/user_theme_color_palette.scss', {
File "addons/website/models/assets.py", line 143, in make_scss_customization
self.save_asset(url, 'web.assets_frontend', updatedFileContent, 'scss')
File "addons/web_editor/models/assets.py", line 77, in save_asset
self.env["ir.attachment"].create(new_attach)
File "<decorator-gen-292>", line 2, in create
File "odoo/api.py", line 420, in _model_create_multi
return create(self, [arg])
File "addons/website/models/ir_attachment.py", line 23, in create
return super().create(vals_list)
File "<decorator-gen-61>", line 2, in create
File "odoo/api.py", line 421, in _model_create_multi
return create(self, arg)
File "odoo/addons/base/models/ir_attachment.py", line 636, in create
values.update(self._get_datas_related_values(
File "odoo/addons/base/models/ir_attachment.py", line 277, in _get_datas_related_values
values['store_fname'] = self._file_write(data, values['checksum'])
File "odoo/addons/base/models/ir_attachment.py", line 132, in _file_write
fname, full_path = self._get_path(bin_value, checksum)
File "odoo/addons/base/models/ir_attachment.py", line 112, in _get_path
os.makedirs(dirname)
File "os.py", line 225, in makedirs
mkdir(name, mode)
```
sentry-4417110945
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156232This update resolves an issue where the search bar within the website's fixed header was incorrectly positioned. The fix involves relocating the search element to ensure it appears below the header when the header is in its fixed state, improving the user experience in website edit mode.
Original PR description
Steps to reproduce:
- In website edit mode, have a header with a search icon
('default header').
- Add a few building blocks, enough so that you can scroll.
- Save the page.
- Scroll down until the header is back to fixed on top.
- Click on the search icon.
- Bug: the search bar appears in header (instead of below it, like at
the beginning).
This issue occurs because when the header is fixed and has a 'transform:
translate' property applied, the search modal, which is positioned
absolutely, takes the dimensions of the header instead of those of the
body.
To resolve this, we relocated the '#o_search_modal' element from the
'#header' to '#o_shared_blocks'.
task-3646513
Forward-Port-Of: odoo/odoo#155703This update fixes a usability issue where the image crop tool wouldn't work correctly when images were partially visible on the website editor. The change ensures the image is scrolled to a visible position before cropping, allowing users to accurately adjust image sizes and ensuring the crop widget functions as intended.
Original PR description
Steps to reproduce: - Go to a website page (in "edit" mode) > Add a "Text Image" block > Add other blocks before and after the snippet so you can scroll the page content. - Scroll in a way that makes only a part of the image visible. - Select the image and click on the "Crop" button > The crop widget is applied to the image in its current position (partially visible), which makes it impossible to crop it correctly. The goal of this commit is to prevent the issue described above by simply scrolling to a position that allows to correctly edit the image before applying the crop widget and also allowing the widget element to scroll when trying to crop an image that overflows the current viewport. task-3420186 Forward-Port-Of: odoo/odoo#155094 Forward-Port-Of: odoo/odoo#152440
This update resolves an issue where users received an error when reconciling payments after changing the outstanding receipts account in the bank journal. The fix ensures the system correctly handles updates to payment accounts, preventing reconciliation failures. This improves the reliability of payment processing.
Original PR description
When having reconciled a payment with an invoice after having changed the outstanding receipts account on the bank journal, we get an error when unreconciliing the payment and the move. Steps: - Create two new outstanding receipts accounts X and Y - Set X as outstandings receipts account on the Bank journal - Create a manual customer payment P for $100, confirm - On Bank journal, change the outstanding receipts account from X to Y - Create and confirm an invoice for $100 - Reconcile with payment P from the widget - Unreconcile or reset invoice to draft -> Error: "Journal Entry %s is not valid. In order to proceed, the journal items must include one and only one outstanding payments/receipts account." This is a fw port of https://github.com/odoo/odoo/pull/149285 which is not needed in 16, and needed here only where we reset move to draft/unreconcile opw-3659092 Forward-Port-Of: odoo/odoo#155558
This update resolves an issue where the calendar month view wasn't correctly showing the start hour of events. The fix ensures that the start hour is consistently displayed, improving the accuracy of event scheduling and visibility within the calendar. This was a minor bug fix identified and resolved by our development team.
Original PR description
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is display in calendar month view.
The test was failing because when clicking on scale selector, it used '.dropdown-toggle:contains("Week")' however it might happen that the current scale is not week.
This commit fixes this issue by changing the way we access the scale selector.
fixes runbot-59023
Forward-Port-Of: odoo/odoo#156121This update corrects a display issue where landed costs were incorrectly shown for product types like Event Tickets and Gift Cards. The fix involves changing how product types are defined within the system, ensuring landed costs are only visible for service-based products during purchase.
Original PR description
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a…
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a service type product under purchase. Issue : - Landed cost boolean is suppose to be visible for a service type product under purchase, But currently it is visible on other type of products specific to other models like event tickets, event booths etc. Cause: - In product Module there are two Selection fields like detailed_type and type. The detailed_type Selection field contain service, consumable, event booths, event tickets, storable product And the type selection field contains service, consumable, storable product - In xml views for that landed cost boolean the invisible attribute contains the condition like type != service, because of this the landed cost boolean is visible for the product type of event tickets, event booths and gift Cards. Solution: - if we use detailed_type instead of type selection field, then the landed cost boolean field will be invisible on other product types. task- 3725202 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156133 Forward-Port-Of: odoo/odoo#153371
This update fixes an issue where the shipping price wasn't correctly recalculated when a customer changed their shipping address during checkout. Now, the system automatically updates the shipping rate in the order badge after the address is modified, ensuring accurate delivery costs for customers. This improves the overall checkout experience and prevents potential order errors.
Original PR description
Steps to reproduce: 1) Configure a carrier with 3d party api(for ex. fedex) 2) Create 2 shipping addresses(better to choose addresses with different delivery rates) 3) Go to /shop and add product that needs to be delivered 4) Proceed to checkout choosing a shipping address and a carrier 5) See the calculated rate 6) Click on 'edit' near the addresses and change the address 7) Click 'confirm' and observe that a new rate on the badge is not applied to the order After this commit the rate is recalculated and updated when the shipment address is changed. opw-3737266 Forward-Port-Of: odoo/odoo#155943 Forward-Port-Of: odoo/odoo#155170
This update moves the 'Kode Transaksi' field from the accounting tab to the tax field within the customer contact view. This ensures the sales team can easily access and utilize this critical field for sales transactions, improving workflow efficiency. The change addresses a previous limitation where the field was hidden from the sales team.
Original PR description
Currently the field `Kode Transaksi` can be found inside the accounting tab. This fix will move it under the tax field. `Kode Transaksi` is a field that should be used in the sale flow and is…
Currently the field `Kode Transaksi` can be found inside the accounting tab. This fix will move it under the tax field. `Kode Transaksi` is a field that should be used in the sale flow and is currently unavailabe for sales team. Steps to reproduce: ------------------- * Install **l10n_id** * Create a company with indonesian localization * Switch to that company * Creat a contact * Toggle the checkbox next to `Tax ID` * Under the `Accounting` tab, you can find `Kode transaksi`. Sales team don't have access to the accounting tab, and thus not to `Kode transaksi` either. Why the fix: ------------ Technically what we want here is to have the field for `Kode Transaksi` after the `vat` field from this view https://github.com/odoo/odoo/blob/04593b265b765f7a6ee079f21bad6a1cf0e5d094/odoo/addons/base/views/res_partner_views.xml#L205-L210 Two possible solutions for this fix: * Fetch the path to `group/group` and put the field inside. * Fetch the path to the `vat` field and put the field after. This would also require to change the priority of the view starting from saas-16.3 because the `vat` field is being moved in this view: https://github.com/odoo/odoo/blob/8ccde3f101cdb6ca41fe29cc5b4252f13745774a/addons/base_vat/views/res_partner_views.xml#L14-L18 By changing the priority, it would allow for `Kode transaksi` to be place after the `vat_vies_container`. Else it would be inside, which does not make sense inthis case. opw-3731357 Forward-Port-Of: odoo/odoo#156005 Forward-Port-Of: odoo/odoo#155515
This update resolves an issue where survey text areas would overlap when resized, particularly when filling them with a lot of text. The fix ensures the text area maintains its intended height and prevents unexpected resizing behavior, improving the user experience for surveys.
Original PR description
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data…
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data vertically - Now, hold the icon to resize the text area block - It's overlapping with other questions. **Issue:** Fixed `height:1px` is applied to Parent div. **Technical Reason:** With this commit (https://github.com/odoo/odoo/commit/eaacaf122dff62adcdf885f0ffdcb4a506bded27) the height is applied to the parent div and textarea which is the same for the backend(title of the survey) and frontend. Now backend needs to apply this height to the parent and text area because it has to show all data in the text area but, in the frontend, if we change the height of the textarea then while pressing enter the textarea block increases, and this should not happen. **Solution:** So, applying the `h-auto` class to the parent div of textarea. Now, the questions did not overlap with each other. **Task**-3707415 Forward-Port-Of: odoo/odoo#152182
This update prevents the automatic generation of a Windows-specific configuration file containing a hashed admin password from being tracked in the Odoo Git repository. This change improves security by avoiding potential exposure of sensitive information and ensures a cleaner, more secure development process.
Original PR description
On Windows installations there is a odoo.conf file generated in the root directory containing a hashed admin password. This only happens in Windows installations where the config file location is not specified. The code responsible can be found here: https://github.com/odoo/odoo/blob/d2ccea9a292c02dc6f4cfdb960d22caa0fd98fd5/odoo/tools/config.py#L414 Forward-Port-Of: odoo/odoo#156099
This update resolves an issue where the status bar on mobile devices would overflow when viewing the expense module. The fix ensures the status bar remains within the screen boundaries, providing a consistent and usable experience for users on smaller mobile screens. This improves the overall usability of the expense tracking feature.
Original PR description
Steps to reproduce ================== - Install Expense (hr_expense) - Use a small viewport - Go to Expense => The status bar overflows  opw-3704233 Forward-Port-Of: odoo/odoo#156114 Forward-Port-Of: odoo/odoo#154032
This update resolves an issue where form fields were displaying numerical IDs instead of their intended labels. This change ensures users see the correct labels when selecting options within forms, improving usability and data entry accuracy. The fix was triggered by a user reporting the incorrect display of field IDs.
Original PR description
This commit resolves an issue (arose in [1]) where a select field was displaying IDs instead of labels. Steps to reproduce: - Navigate to edit mode - Drop a form block. - Select the form action type "create customer" (CRM app must be installed). - Add a field for "country". - Add another field and set its visibility to depend on the country value. Issue: Users are seeing IDs instead of country labels. [1]: https://github.com/odoo/odoo/commit/a54f11edb1f81c8dade2a4ef6080b666b94e918d task-3460326 Forward-Port-Of: odoo/odoo#155531
This update resolves a bug where PDF navigation buttons (next, previous, etc.) in e-learning materials were sometimes incorrectly enabled or disabled. The fix ensures these buttons function reliably, regardless of the content's structure or suggested slides, improving the user experience for e-learning courses.
Original PR description
Bug === When we show a PDF in e-learning, we have some navigation buttons (next, previous, last, first) with some conditions for them to be enabled or not (e.g. a documentation can have suggested slides, and so the next button is visible even if we are on the last page). Those conditions are broken (sometimes a button is disabled when it shouldn't and vice versa), this commit aims to fix that issue. Task-3751253 Forward-Port-Of: odoo/odoo#156252 Forward-Port-Of: odoo/odoo#154967
This update fixes an issue that prevented the generation of PDF BOM overviews when products were created with dynamic attribute variants. The change ensures that BOMs are correctly generated, even with this product configuration, allowing users to consistently print accurate BOM reports. This resolves a previous error that impacted the printing of product BOMs.
Original PR description
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: -…
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: - Inventory > Configuration > Products > Attributes Create an attribute with Variants Creation Mode set to "Dynamically". Create a new product with this single attribute and multiple values. Create a BOM for this product with BOM Type set to "Subcontracting". Print the BOM overview. Cause of the issue: - Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function `_get_bom_data` can not apply the method `_select_seller` properly in that case. Notes: - - There is no error if a variant was manually created for that product. - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise. Fix: - As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid. opw-3698050 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152275
This update ensures that taxes are calculated consistently regardless of their order on an invoice. Previously, the order in which taxes were applied could lead to different totals. This fix introduces a standardized sorting method to guarantee accurate tax calculations for all invoices.
Original PR description
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not…
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not manually adjusted, leading to each tax having an identical sequence value. As a result, their hierarchy within the `flatten_taxes_hierarchy` function is determined by their input order rather than a defined sequence, causing unpredictable tax calculations. https://github.com/odoo/odoo/blob/56666f8f7858fcbcce466d2240135b35509d2d96/addons/account/models/account_tax.py#L611-L632 A tax sequence should be explicitly defined, and in cases where sequences are identical, organization by tax ID should be enforced. **Steps to Reproduce**: 1. Navigate to the `Account` or `Invoice` app. 2. Go to `Configuration > Taxes`. 3. Create a new tax with the advanced option `Affect Base of Subsequent Taxes` and specify an amount. 4. Generate a new invoice and add a line item priced at 100. 5. Apply taxes in the `Taxes` column in the following order: 15% followed by the newly created tax, and note the total amount. 6. Repeat step 5, but reverse the order of the taxes. 7. Observe that the total amounts differ between the two sequences. **Proposed Solution**: To ensure that taxes are applied consistently regardless of input order, we will modify the `flatten_taxes_hierarchy` function to add sorting by id. If the sequences are identical, the sorting will depend only on the id, otherwise it will be based on the sequence. This setting ensures a predictable and logical process for applying taxes. opw-3691765 Forward-Port-Of: odoo/odoo#156031 Forward-Port-Of: odoo/odoo#154167
This update ensures that product variants are automatically adjusted when product template exclusions are created, modified, or removed. Previously, changes to exclusions didn't reflect on the associated variants. This fix maintains data consistency and accuracy for product offerings.
Original PR description
opw-3693065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156212 Forward-Port-Of: odoo/odoo#155103
This update fixes an issue where tests related to screencast recordings wouldn't run correctly if the necessary files were missing. It also reduces the amount of logging generated during test failures, making debugging easier. This ensures more reliable test results and faster identification of problems with screencast functionality.
Original PR description
Fix similar to 151558 Don't fail if the screencast dir doesn't exist (after clear) Also, reduce the log size. Forward-Port-Of: odoo/odoo#156202 Forward-Port-Of: odoo/odoo#156043
This update resolves a technical issue where accessing a non-existent file URL within the Odoo interface triggered an infinite redirection loop. The fix prevents the system from incorrectly attempting to serve attachments via a fallback mechanism, ensuring a stable and reliable user experience. This improves overall system stability.
Original PR description
Create an attachment with an URL to a static file that does not exists, e.g. '/web/static/idontexist.png'. Inside your browser try to access that file, open <localhost:8069/web/static/idontexist.png>. The browser fails with a "Too Many Redirections" error. When a path is not found, nor in the static files, nor in the controllers, `_serve_fallback` kicks in and attempt to find a resource outside of the router that matches the URL. In case it finds an attachment with a matching URL, it'll deliver it. In this specific case, it finds our attachment and return a redirection to it's URL, which is the same URL as the request hence it loops back. Don't deliver URL attachments via `_serve_fallback`, only deliver stored files. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154883
This update fixes an issue where the departure date wasn't correctly populated for employees with ongoing contracts. Now, if an employee has an open contract, the system automatically uses the end date of their most recent expired contract as the departure date. This ensures accurate record-keeping and reporting.
Original PR description
Purpose ======= Take the last expired contract end date if there is not open contract for the related employee. TaskID: 3610709 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156065
This update corrects a bug where email templates didn't always show all intended recipients (followers/partners) during the preview stage. The issue stemmed from a formatting error when processing partner IDs, leading to a partial list being displayed. This ensures accurate recipient lists are shown when creating and testing email templates.
Original PR description
Steps to reproduce:
---
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
---
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#149563This update fixes a technical issue preventing the number of open job positions displayed on the website from being translated. The change ensures that job listings are correctly localized for different languages, improving the user experience for international job seekers. This resolves a previous bug impacting translation accuracy.
Original PR description
When listing jobs on the website, we show the number of open positions. Currently the "open positions" were crafted in the QWeb template in such a way that the translation mechanism couldn't extract it and thus it could not be translated. In this commit we fix that, so that it can be translated again. opw-3761288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155974 Forward-Port-Of: odoo/odoo#155876
This update fixes an issue where payments weren't displayed on POS invoices. Previously, after invoicing a POS order, the payment details were missing from the invoice PDF. This change ensures that all payment information is accurately reflected when generating invoices from POS orders, improving invoice accuracy and reporting.
Original PR description
Current behavior: When invoicing a POS order, the payment were not appearing in the invoice. Steps to reproduce: - Create a POS order - Validate and invoice the order - Open the invoice PDF, the payment is not appearing opw-3748596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155771
This update fixes an issue where dates and datetimes were not being formatted correctly, leading to incorrect data storage and the display of 'Invalid Date'. The fix ensures that dates and datetimes are stored in the standard 'YYYY-mm-dd' format, improving data accuracy and reliability.
Original PR description
Bug === Since c5b87e130bd69996c9121227bb6d085035c362fa , the Date / Datetime are not formatted the way they suppose to be. So the value is not correct (it contains the timezone, etc). Because of that, the string "Invalid Date" is stored in database instead of "YYY-mm-dd". Task-3774178 Forward-Port-Of: odoo/odoo#155749
This update fixes an issue where barcode searches in Point of Sale were returning multiple product matches due to a fuzzy lookup. The change now directly matches the barcode, eliminating confusion and ensuring accurate product selection. This improves the user experience and reduces errors during sales transactions.
Original PR description
Before this commit, searching with a barcode could return multiple products due to the fuzzy lookup, as barcodes often have similar patterns. This could lead to confusion and incorrect product selection. To resolve this issue, this commit excludes the barcode from the fuzzy lookup and instead matches it directly. opw-3758356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error that prevented users from applying for jobs after removing the LinkedIn profile field. The change ensures the application form can be submitted if either the LinkedIn or resume field has a value, providing a smoother user experience. This resolves a technical issue impacting job applications.
Original PR description
### Steps to reproduce: - Install **website_hr_recruitment** module. - Go to **Recruitment** app. - Click on **Job Page** button on one of the position cards. - Click on **Apply Now!** button. -…
### Steps to reproduce:
- Install **website_hr_recruitment** module.
- Go to **Recruitment** app.
- Click on **Job Page** button on one of the position cards.
- Click on **Apply Now!** button.
- Click on **Edit** in the upper right corner.
- Remove the LinkedIn Profile, then save.
- Click on **I'm feeling lucky** button to apply the form.
- An error is raised indicating that `Cannot read properties of undefined (reading 'trim')`
### Investigation:
- the linkedin field is grabbed by `const $linkedin_profile = $('#recruitment4');`
- and then is used to check the condition `$linkedin_profile.val().trim() === ''`
- but since the field no longer exists, the `$linkedin_profile.val()` is undefined and hence the error is raised
### The Fix
- The functionality is to allow to apply the form if _**at least one**_ of the **linkedin** or **resume** fields is non-empty
- we a field as empty if it:
- doesn't exists
- exists but is value-empty
opw-3754506
Forward-Port-Of: odoo/odoo#155336A minor issue preventing the correct styling of the 'preview' button on the course page has been resolved. This ensures that the button consistently displays the appropriate styles for both enabled and disabled content previews, improving the user experience. This change was a simple fix to ensure proper button styling.
Original PR description
Bug ===== Click the `preview` button on the course page. It does not apply the proper styles to the button used for enabled or disabled content previews. Technical =========== With commit https://github.com/odoo/odoo/commit/2d386bc437194b78ea5d446d7b0fa4f5444406e2, the `badge-hide` class used for the `preview` button was replaced and some styles were altered. After this commit ================== The `preview` button is functioning properly. Task-3751285 Forward-Port-Of: odoo/odoo#155003
A bug causing an infinite loop in the Trial Balance report has been resolved. The fix prevents recursive loops within account groups, ensuring the report calculates correctly. This improves the stability and reliability of financial reporting.
Original PR description
# Issue: Infinite loop in Trial Balance. # Analyze: The infinite loop is due to account_reports.models.account_report.AccountReport.get_account_codes `while group:` loop if a recursion exist in group.parent_id there is an infinite loop. # Fix: Ensure the no recursion constrains on parent_id in account_reports. # Related tasks: opw-3665256 opw-3700368 Forward-Port-Of: odoo/odoo#156321 Forward-Port-Of: odoo/odoo#150171
This update resolves an issue where product documents with incomplete URLs were incorrectly redirecting to local pages, causing errors. The change adds a validation step to ensure URLs in product documents are properly formatted (e.g., including ‘https://’), preventing these redirects and ensuring accurate external links. This improves the user experience and data integrity.
Original PR description
Added a validation for URLs on product.document to resolve an issue where incomplete links on documents will redirect to a local URL instead of an external URL. Thus leading to a page that does not exist. e.g.: youtube.com instead of https://www.youtube.com This seemed like the proper course of action as there would be no reason to not validate as any URL within the database can still be formatted properly and work the same. Changed from targeting 15.0 ir.attachments to targeting product.document on this version as per @ryv-odoo Old PR: https://github.com/odoo/odoo/pull/155322 api.constrains does not seem to work upon creation on this model, so I opted to use the api.onchange. opw-3698591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155806
This update resolves a discrepancy in invoice tax calculations caused by rounding errors during tax processing. The fix ensures that tax totals align correctly between sales orders and invoices, preventing inaccurate financial reporting. This improves the reliability of our invoicing system.
Original PR description
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be:…
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be: |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.44| |Total | 169.89| From the Sales Order create the Invoice Issue: Invoice tax totals will be |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.45| |Total | 169.90| This occurs because when managing the rounding errors for global rounding the system 'force' a 1 cent difference on the negative line that do not need rounding Example: Line 1 - current diff: 0.0 - computed tax amount: 5.455 - tax amount + diff: 5.455, after rounding: 5.45 - stored diff for next line: -0.005 Line 2 - current diff: -0.005 - computed tax amount: 60.0 - tax amount + diff: 59.995, after rounding: 60.0 - stored diff for next line: -0.005 Line 3 - current diff: -0.005 - computed tax amount: -50.0 - tax amount + diff: -50.005, after rounding: -50.01 A solution is to not add the diff when the tax line is already rounded opw-3715229 Forward-Port-Of: odoo/odoo#156016 Forward-Port-Of: odoo/odoo#154861
This update fixes a bug in the daily sales report that previously failed to include differences for bank payments when closing a session. The change restores the original report behavior, ensuring all payment types (bank and cash) are accurately reflected in the report totals. This improves the reliability of sales data reporting.
Original PR description
Current behavior: When entering a difference at the closing of the session for a bank payment method, the daily sales report was not taking into account the difference for the bank payment method. Steps to reproduce: - Start PoS and make a sales with bank and a sales with cash - Close the session with a difference for both payment methods - Go to the daily sales report and check the difference for the bank payment method. The one for the cash is there but not the one for the bank. Note: This bring back the original behavior of the report that was removed here (https://github.com/odoo/odoo/pull/146341) and makes it coexist with the current one so that all cases are covered. opw-3737223 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154929
2 changes
Resolved issues and error corrections
The company bike benefit in Belgian salary packages now uses a grouped dropdown by default. This makes the option list clearer and helps employees or HR users choose the right bike-related benefit more easily.
Original PR description
With this commit, by default the display type of the company bike is "dropdown-group" instead of "dropdown" task : 3659590
Fixed an error that could appear when using the auto plan button with only the Planning app installed. The sales-specific logic now runs only when the Sales Planning feature is available, preventing disruptions for Planning users.
Original PR description
Part of this commit- https://github.com/odoo/enterprise/pull/51742/commits/6f66cc46ddb554725b6bc8ab68691597f5eba24e If only the planning is installed, then the sale_order_id will not be found, causing a traceback. I have moved this code to the sale_planning. task-3764488
35 changes
Resolved issues and error corrections
This fix corrects an issue where bank account verification for payroll batches was incorrectly checking all employees in the company instead of just those in the specific batch. When a batch had no employees with bank account numbers, the system would expand the search beyond the intended batch scope. This update ensures verification stays limited to the relevant batch employees only.
Original PR description
Context: ======= If none of the batch's employees have a bank number then the employee verification was no longer limited to the batch but to the entire company. With this commit this issue is solved task: 3679494
This fix prevents the salary configurator from repeatedly generating commission plans every time it's accessed. By adjusting how the system processes salary updates, it now avoids unnecessary duplicate operations that were slowing down the salary configuration process.
Original PR description
When the create_new_contract function is called from update_salary it should be called with no_write set to true to avoid generating the commission plan each time the salary configurator is touched and call update_salary
Ticket ratings were not showing correctly in the helpdesk ticket list view, even though they displayed properly in other views like kanban and form. This fix updates the list view to use the correct rating field so customers can see ticket ratings consistently across all views.
Original PR description
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is…
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is properly visible in other views (kanban, form). Cause: - In list view we used `rating_last_text` field and in other view we used `rating_avg` because of that list there are not data in that field. Fix: - Replace rating_last_text by rating_avg_text field to display proper ratings. Additional info: - There are actually two ratings created from a ticket one from demo data and other from thread send email and helpdesk ratings demo data created before ratings created from thread email and since that ratings does not contains any ratings in it gives `rating_last_text` value as false. We can create our rating demo data after thread's rating by moving ratings related demo data in different file in master. task-3589757 Forward-Port-Of: odoo/enterprise#57854 Forward-Port-Of: odoo/enterprise#52371
Fixed an issue in the Barcode App where scanning an expected destination location would not split a partially processed picking line. Now when warehouse staff scan a destination that matches the expected location, the system correctly splits the line, allowing them to easily allocate different quantities to different locations without manual workarounds.
Original PR description
In a picking, when a destination is scanned, if the scanned line is not complete, the line is splitted: the processed qty goes to the scanned destination and the remaining qty still goes to the…
In a picking, when a destination is scanned, if the scanned line is not complete, the line is splitted: the processed qty goes to the scanned destination and the remaining qty still goes to the previous expected destination. That said, if the scanned destination is the move line expected location, the line is not split, which can be annoying in some case. How to reproduce: - Active multi location; - Create a receipt for 4x product A and confirm it; - Open the receipt in the Barcode App; - Scan 2x product A and then scan WH-STOCK as the destination -> Nothing happens. If the picker wants to move 2 product A in WH/Stock and 2 product A in Shelf 1, they have no easy way to do it if they scan WH-Stock first. If they scan Shelf 1 first, then the product A line will be splitted and they will get: - 2/2 product A going to WH/Stock/Shelf 1; - 0/2 product A going to WH/Stock. But if they scan WH-Stock first, they will stay with only one line: - 2/4 product A going to WH/Stock. In such case, no other choice than create a new line through the "Add Line" button (form view) and so, the reservation won't be split between the two lines. OPW-3774095
This update removes the automatic installation of the Belgian tax deduction and fleet expense module. Since not all businesses use tax deductions and computed values, this module will now only be installed when explicitly needed, reducing unnecessary features for users who don't require this functionality.
Original PR description
Not everyone works with tax deductions and computed values, we thus remove the auto install for now task-3786729
This fix corrects how Odoo calculates the remaining balance on invoices when processing multiple partial payments in Mexico's electronic invoicing system (CFDI). Previously, when making a final payment to close an invoice, the system incorrectly showed a remaining balance instead of zero. This has been resolved by fixing the payment calculation logic.
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
Steps to reproduce:
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any]
- Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Register a partial payment from the invoice:
* Payment Way: Effectivo
* Amount: [any partial amount] (e.g. 50%)
* Payment Date: [yesterday]
- Create Payment
- Click on "Update Payments" button
- On "CFDI" tab, force CFDI on the payment
- Check the generated CFDI XML of the payment
- Attribute `ImpSaldoInsoluto` of `<pago20:DoctoRelacionado>` element contains the correct residual amount
- Register another payment from the invoice:
* Payment Way: Effectivo
* Amount: [the remaining amount]
* Payment Date: [today]
- Create Payment
- Click on "Update Payments" button
- On "CFDI" tab, force CFDI on the payment
- Check the generated CFDI XML of the payment
Issue:
In the generated CFDI XML of the closing payment, the attribute `ImpSaldoInsoluto` of `<pago20:DoctoRelacionado>` element contains a residual amount as if no payment had been done before.
Its value should be 0 as it is a closing payment.
Cause:
In the method computing the residual amount from the chain of payments, a reverse sort on the payment date is performed on the list of payments before the computation.
opw-3745151
Forward-Port-Of: odoo/enterprise#57792This update simplifies how delivery prices are retrieved from Starshipit by reverting to a more efficient method. The original issue that required workaround code has been resolved, allowing us to reduce unnecessary API calls and speed up the delivery pricing process.
Original PR description
The current code was made in response to an issue where the exact_price value would not always be in the response of /orders, which would cause issues and inconsistencies. As of now, this issue seems to not happen anymore and we can thus revert to the original way of handling that which uses less api calls and a faster flow.
A recent change inadvertently broke the bank reconciliation widget's ability to suggest payment matches for invoiced sales orders. When a sales order is already invoiced and paid, the system now incorrectly prioritizes the sales order rule over the payment rule, resulting in no suggestions being shown to users. This fix restores the proper matching behavior so users can see available payment options during bank reconciliation.
Original PR description
Since https://github.com/odoo/enterprise/commit/79461fce51f1f931b34aa66f8886a5faaf9c0908 The matching with SO changed. Suppose a SO already invoiced and reconciled with a payment. Before the commit above: - the SO rule was failing. - the AML rule was able to retrieve the related payment. After: - the SO rule found a match. - since there is no available aml to match on the invoice, nothing is suggested to the user on the bank reco widget. ticket_id: 3776876 Forward-Port-Of: odoo/enterprise#57958
Fixed an intermittent test failure in the image cropping feature where the browser would quit before the image fully loaded, causing unpredictable test results. The fix adds a small delay to ensure the image cropper widget is fully ready before proceeding with the test, making the testing process more reliable.
Original PR description
Before this commit the test `test_image_crop` sometimes failed. This was because the browser quit while the image of the image cropper was loading. This operation caused an error, that was caught by the browser and then by the test infrastructure but *after* the tour was marked as succesful. After this commit, we wait a little bit longer, that is, until the cropper widget (which is a JQuery extension) appears. runbot-error-59063 Forward-Port-Of: odoo/enterprise#58002
Fixed an issue where the grid view (such as timesheet) would not remember your previous selection when you opened a record and returned to the grid. Now when you navigate back to the grid view, your previously selected week or time period is properly restored, improving the user experience by eliminating the need to re-select your view settings.
Original PR description
Steps to reproduce ================== - Go to timesheet - Switch to the next week - Open a record by clicking on the magnifying glass icon - Go back to the grid view by clicking on the previous breadcrumb => The previously selected week is not restored Cause of the issue ================== We don't export the current state when leaving the view opw-3729307 Forward-Port-Of: odoo/enterprise#57990 Forward-Port-Of: odoo/enterprise#57510
This fix corrects an issue where the system was incorrectly suggesting accounts when creating vendor bills. Previously, if a partner name and invoice line label matched an account name, the system would suggest that account even if it was the wrong type (e.g., suggesting a payable account when a different type was needed). This update ensures accounts are only suggested when they match both the name and the correct account type, improving accuracy in bill processing.
Original PR description
Having a partner and a label that match an account in a bill line leads to the account to be predicted even if it is of the wrong account type. Steps: - Create a payable account X with name containing ABC - Open vendor bill, set partner ABC - On the invoice line set the label to ABC and unfocus the line -> The account that is predicted is account X opw-3717805 Forward-Port-Of: odoo/enterprise#57790
This update removes confusing language from the Belgian bank connection wizard that incorrectly suggested certain features were exclusive to Odoo. The change makes the setup process clearer for users by removing misleading text and ensures all translation files are properly included.
Original PR description
After some discussion, it was decided to remove the "(exclusive to Odoo)" part which may confuse the user Also add missing translation file
Fixed a bug where duplicating a warehouse in Inventory would not copy its associated operation types (picking types). Now when you duplicate a warehouse, all its operation types are properly created for the new warehouse, ensuring consistent warehouse configurations.
Original PR description
[FIX] stock: duplicating warehouse dependencies Before this commit when duplicating a warehouse, its operation types (picking.type) wouldn't get copied. This commit ensures that new picking.types are created for the duplicate warehouse. ### [Reproduce] - run odoo 17 with -i stock,mrp_subcontracting - in Inventory/Configuration/Warehouses Duplicate a Warehouse - Bug: in Inventory/Configuration/OperationTypes picking types aren't duplicated opw-3674614
This fix resolves permission problems that prevented Point of Sale users with basic access rights from performing essential tasks like creating invoices and using the "Ship Later" feature. The update adjusts access controls to ensure users with only Point of Sale permissions can properly use all core functionality without requiring additional system access.
Original PR description
Current behavior: When a user has only "User" right for point of sale and no other access some functionalities are not working properly. For example, the user cannot create an invoice from the PoS interface. And the user cannot use the "Ship Later" functionality. Steps to reproduce: - Change the right of a user to "User" for point of sale and no other access. - Log in as this user and try to create an invoice from the PoS - Try to use the "Ship Later" functionality Note: This commit modify the access right of the test pos_user so that it has the minimum access to be able to use the PoS interface properly. opw-3644739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the Surveys app where comment text fields were not appearing when selected as an answer option. When a survey question is configured to allow comments as an answer choice, users can now properly see and fill in the comment field after selecting it.
Original PR description
**Current behavior:** A survey question which has a comment field counted as an answer will not reveal its text box input field when it is selected as the current answer. **Expected behavior:** After clicking on the comment field answer, the text box will be revealed and enabled. **Steps to reproduce:** 1. In the surveys app, add a question to a survey of type `Multiple choice: only one answer` 2. In the question's options, enable the `Show Comments Field` and `Comment is an answer` options 3. Go to the question in the survey, click on the comment answer and observe there is no field to enter a comment **Cause of the issue:** The function which is responsible for adapting these page elements is not selecting the correct html elements, thus their attributes are not properly changed when needed. **Fix:** Change the function variables so that they are pointing to the correct location in the DOM. opw-3748291
Fixed a bug in the recruitment job application form that caused an error when the LinkedIn Profile field was removed. The form now correctly handles missing fields and allows applicants to submit their application as long as they provide either a resume or LinkedIn profile. This ensures a smoother application experience for job seekers.
Original PR description
### Steps to reproduce:
- Install **website_hr_recruitment** module.
- Go to **Recruitment** app.
- Click on **Job Page** button on one of the position cards.
- Click on **Apply Now!** button.
- Click on **Edit** in the upper right corner.
- Remove the LinkedIn Profile, then save.
- Click on **I'm feeling lucky** button to apply the form.
- An error is raised indicating that `Cannot read properties of undefined (reading 'trim')`
### Investigation:
- the linkedin field is grabbed by `const $linkedin_profile = $('#recruitment4');`
- and then is used to check the condition `$linkedin_profile.val().trim() === ''`
- but since the field no longer exists, the `$linkedin_profile.val()` is undefined and hence the error is raised
### The Fix
- The functionality is to allow to apply the form if _**at least one**_ of the **linkedin** or **resume** fields is non-empty
- we a field as empty if it:
- doesn't exists
- exists but is value-empty
opw-3754506This fix prevents the system from unnecessarily recalculating sales order totals when no actual changes are made to order lines. Previously, the system would trigger unwanted recalculations and display duplicate tracking records with identical values, which wasted processing resources. Now, the system only recalculates when there are genuine changes to order data.
Original PR description
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands…
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands will be sent to the server, potentially triggering unexpected recomputations. Steps to reproduce: * install sale_stock & sale_management * create a new storable product * create a new SO * create a new line with this product * Confirm the SO * Set or Update the SO delivery date (Other info tab) * Save -> In the chatter, you will notice an useless tracking value being printed for the SO Total, with identical values before and after update. Cause Since the server received an empty list of commands for the `order_line` field, this triggered a recomputation of the total amounts of the SO, even though there were no effective changes in the lines. Solution Do not send empty command lists for x2m fields. This will avoid unexpected recomputation and also improve performance since the fields were recomputed for 'nothing' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug in the Loyalty module where data was being accessed unsafely, which could cause errors when certain information is missing. The fix uses a safer method to retrieve data that gracefully handles missing values instead of crashing.
Original PR description
Addendum to https://github.com/odoo/odoo/commit/7ed0a773b6e0 Reference PR: https://github.com/odoo/odoo/pull/150418 Forward-Port-Of: odoo/odoo#155927
This update resolves an issue where newly added message types in the mail system could cause errors when fetching related data. The fix automatically synchronizes message type selections in the database on first access, ensuring smooth operation without disrupting existing functionality. Subsequent accesses are cached for optimal performance.
Original PR description
A new message type was added in stable. This is usually safe, however in cases where there are related fields on that same selection fetching them will raise an exception as the ORM has to fetch the translations for the selection in DB. We add a hack on mail.mail to update the selections in DB when fetching the message type the first time. Subsequent gets should be inexpensive as these are cached. task-3773301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156112 Forward-Port-Of: odoo/odoo#155766
This fix corrects an issue where bank payment method differences were not appearing in the daily sales report when closing a Point of Sale session. Previously, only cash payment differences were shown. Now both cash and bank payment differences are properly displayed in the report, ensuring accurate financial reconciliation.
Original PR description
Current behavior: When entering a difference at the closing of the session for a bank payment method, the daily sales report was not taking into account the difference for the bank payment method. Steps to reproduce: - Start PoS and make a sales with bank and a sales with cash - Close the session with a difference for both payment methods - Go to the daily sales report and check the difference for the bank payment method. The one for the cash is there but not the one for the bank. Note: This bring back the original behavior of the report that was removed here (https://github.com/odoo/odoo/pull/146341) and makes it coexist with the current one so that all cases are covered. opw-3737223 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154929
This fix prevents users from changing the unit of measure on component stock lines after quantities have been reserved during subcontracted product receipt. Previously, changing units (e.g., from grams to kilograms) after reservation would cause system errors and inventory discrepancies. The system now blocks these changes when quantities are reserved or the receipt is completed.
Original PR description
Before this commit: "Cannot unreserve more than you have in stock" Error It was possible to purchase a subcontracted product, and on the receipt of the product, change the unit of measure o on the stock move lines of the components when the quantities were already reserved. This caused unreserve issue given that, all of a sudden, instead of having 200g, we would have 200kg reserved and the change would not be reflected on the quant. After this commit: The view was modified to not allow changes of UoM if there are reserved quantities, or if the state is done. OPW-3742720 Forward-Port-Of: odoo/odoo#154450 Forward-Port-Of: odoo/odoo#154327
This update fixes navigation button behavior in embedded PDF viewers within e-learning courses. Previously, the next, previous, first, and last buttons were incorrectly enabled or disabled based on broken logic. The fix ensures buttons display correctly based on course structure, such as showing the next button even when viewing the last PDF page if suggested slides are available.
Original PR description
Bug === When we show a PDF in e-learning, we have some navigation buttons (next, previous, last, first) with some conditions for them to be enabled or not (e.g. a documentation can have suggested slides, and so the next button is visible even if we are on the last page). Those conditions are broken (sometimes a button is disabled when it shouldn't and vice versa), this commit aims to fix that issue. Task-3751253 Forward-Port-Of: odoo/odoo#156252 Forward-Port-Of: odoo/odoo#154967
This fix resolves an error that occurred when printing Bill of Materials (BOM) documents for subcontracting products created with dynamic attributes. The system now properly handles products that don't have manually created variants, allowing users to successfully generate BOM overview PDFs without encountering crashes.
Original PR description
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: -…
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: - Inventory > Configuration > Products > Attributes Create an attribute with Variants Creation Mode set to "Dynamically". Create a new product with this single attribute and multiple values. Create a BOM for this product with BOM Type set to "Subcontracting". Print the BOM overview. Cause of the issue: - Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function `_get_bom_data` can not apply the method `_select_seller` properly in that case. Notes: - - There is no error if a variant was manually created for that product. - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise. Fix: - As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid. opw-3698050 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152275
This fix ensures that taxes are applied consistently on invoices regardless of the order they are entered. Previously, when multiple taxes had the same priority level, the calculation results would vary depending on which tax was listed first. Now taxes are sorted by a defined sequence, with a consistent fallback to tax ID when priorities are equal, guaranteeing predictable and reliable tax calculations.
Original PR description
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not…
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not manually adjusted, leading to each tax having an identical sequence value. As a result, their hierarchy within the `flatten_taxes_hierarchy` function is determined by their input order rather than a defined sequence, causing unpredictable tax calculations. https://github.com/odoo/odoo/blob/56666f8f7858fcbcce466d2240135b35509d2d96/addons/account/models/account_tax.py#L611-L632 A tax sequence should be explicitly defined, and in cases where sequences are identical, organization by tax ID should be enforced. **Steps to Reproduce**: 1. Navigate to the `Account` or `Invoice` app. 2. Go to `Configuration > Taxes`. 3. Create a new tax with the advanced option `Affect Base of Subsequent Taxes` and specify an amount. 4. Generate a new invoice and add a line item priced at 100. 5. Apply taxes in the `Taxes` column in the following order: 15% followed by the newly created tax, and note the total amount. 6. Repeat step 5, but reverse the order of the taxes. 7. Observe that the total amounts differ between the two sequences. **Proposed Solution**: To ensure that taxes are applied consistently regardless of input order, we will modify the `flatten_taxes_hierarchy` function to add sorting by id. If the sequences are identical, the sorting will depend only on the id, otherwise it will be based on the sequence. This setting ensures a predictable and logical process for applying taxes. opw-3691765 Forward-Port-Of: odoo/odoo#156031 Forward-Port-Of: odoo/odoo#154167
This fix improves how the system calculates an employee's departure date when handling contract records. Previously, the system may not have correctly identified the departure date when an employee had open contracts. The fix now ensures the system uses the last expired contract end date as the departure date when there are no open contracts for the employee, providing more accurate employee departure records.
Original PR description
Purpose ======= Take the last expired contract end date if there is not open contract for the related employee. TaskID: 3610709 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156065
This fix resolves an issue where accessing a non-existent static file URL would cause the browser to get stuck in an infinite redirect loop. The system was incorrectly redirecting URL-based attachments through the fallback handler, creating a circular redirect. Now only stored files are served through the fallback mechanism, preventing this redirect loop.
Original PR description
Create an attachment with an URL to a static file that does not exists, e.g. '/web/static/idontexist.png'. Inside your browser try to access that file, open <localhost:8069/web/static/idontexist.png>. The browser fails with a "Too Many Redirections" error. When a path is not found, nor in the static files, nor in the controllers, `_serve_fallback` kicks in and attempt to find a resource outside of the router that matches the URL. In case it finds an attachment with a matching URL, it'll deliver it. In this specific case, it finds our attachment and return a redirection to it's URL, which is the same URL as the request hence it loops back. Don't deliver URL attachments via `_serve_fallback`, only deliver stored files. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154883
This update fixes the electronic address system (EAS) code used for Swedish organizations in electronic invoicing. The deprecated code has been replaced with the current valid code to ensure Swedish invoices are properly formatted and recognized by the Peppol network. This change ensures compliance with the latest international e-invoicing standards.
Original PR description
remove deprecated EAS code for Sweden. The code is no longer part of the valid list of codes. See https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/ and https://docs.peppol.eu/edelivery/codelists/ Also, in the endpoint the Swedish organization number must be used, which is taken from the VAT by removing the country code and the last two digits. You can check it out here: https://organisationsnummer.dev/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156289 Forward-Port-Of: odoo/odoo#153440
This fix resolves an issue where repair orders for products with no stock were incorrectly creating duplicate picking records, causing gaps in the repair sequence numbering. The problem occurred because draft stock movements were not being properly recognized by the assignment logic.
Original PR description
For repaired products with no stock, a new picking is wrongly created, leading to a gap in the repair sequence. This because the move is created in 'draft' and the function does not take it into account. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156083
This fix prevents users from submitting multiple reviews for the same course, even when accessing the course from multiple browser tabs. Previously, users could bypass the single-review-per-course policy by having multiple tabs open. Now the system properly enforces that each user can only submit one review per course, improving data integrity and preventing duplicate reviews.
Original PR description
Once a user posts a review, they are able to edit this single review and not create any new ones. However if the user had multiple tabs open of the same course, then they can still access the "Add a review" functionality. This fix enforces the single review per user per course policy. Task-3721958 Forward-Port-Of: odoo/odoo#156198 Forward-Port-Of: odoo/odoo#153679
The preview button on course pages was not displaying with the correct visual styles for enabled or disabled content. This fix restores the proper button appearance so users can clearly see whether content previews are available or restricted.
Original PR description
Bug ===== Click the `preview` button on the course page. It does not apply the proper styles to the button used for enabled or disabled content previews. Technical =========== With commit https://github.com/odoo/odoo/commit/2d386bc437194b78ea5d446d7b0fa4f5444406e2, the `badge-hide` class used for the `preview` button was replaced and some styles were altered. After this commit ================== The `preview` button is functioning properly. Task-3751285 Forward-Port-Of: odoo/odoo#155003
This fix resolves an infinite loop issue that occurred in the Trial Balance report when account groups had circular parent relationships. The system now includes proper validation to prevent recursive parent-child relationships in account groups, ensuring the Trial Balance report runs smoothly without freezing.
Original PR description
# Issue: Infinite loop in Trial Balance. # Analyze: The infinite loop is due to account_reports.models.account_report.AccountReport.get_account_codes `while group:` loop if a recursion exist in group.parent_id there is an infinite loop. # Fix: Ensure the no recursion constrains on parent_id in account_reports. # Related tasks: opw-3665256 opw-3700368 Forward-Port-Of: odoo/odoo#156321 Forward-Port-Of: odoo/odoo#150171
This fix resolves crashes that occurred when viewing tasks or records after upgrading to version 17.0, particularly when certain fields were removed during the upgrade process. The system now handles tracking information more carefully to prevent errors when displaying change history in emails and activity logs.
This fix addresses floating-point rounding errors that were occurring in electronic invoice price calculations. The system was using an ineffective rounding method that still produced incorrect decimal values (like 83.60000000000001 instead of 83.60). By switching to Python's built-in rounding method, invoice amounts are now calculated correctly, ensuring accurate electronic invoices for customers.
Original PR description
In [1], we added a rounding of the amounts in the `<PriceAmount>` tags to avoid floating point rounding errors. However, it seems the `float_round` function does not guarantee to avoid these errors. Take the example of `price_subtotal` = 250.80 and `quantity` = 3. We will compute the PriceAmount as 250.80 / 3 which yields 83.60000000000001. Even when using `float_round(amount, 10)`, it still results in the same amount with the rounding error. For that reason we use the built-in `round` method of Python instead. [1] 58d57bbbaaab32ba0183890a9182e6de09b32ac5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155949 Forward-Port-Of: odoo/odoo#155570
This update prevents the messaging system from sending unnecessary notifications when there are no channel members to update. Previously, this could cause errors by creating invalid channel member records. The fix improves system stability and reduces unnecessary notification traffic.
Original PR description
When there is no channel members to be updated the seen status, we should not send a notification to the channel members, otherwise, it will lead into creating a channel member with id undefined. test case added to check that the notification is not sent when there is no channel members to be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how the system detects duplicate accounts when loading chart templates. Previously, the system could miss duplicate accounts because it compared account codes before standardizing their format. Now it compares the properly formatted codes, preventing the creation of unwanted duplicate accounts in your chart of accounts.
Original PR description
**Description of the issue/feature this PR addresses:** Function `_pre_reload_data` checks for the existance of accounts with the same code to avoid creating a duplicate. It does so however comparing with the code before normalizing it with the length from the template, failing to find possible duplicates with a normalized code. **Current behavior before PR:** If accounts with non-normalized codes _(eg 172)_ are being loaded, there's a risk that an account with a matching normalized code _(eg 172000)_ already exists in the database. If the corresponding xmlid is not pointing at it, another account with the same code will be created triggering the ValidationError. **Desired behavior after PR is merged:** The comparison with existing accounts is made with the normalized code avoiding this conflicts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156119 Forward-Port-Of: odoo/odoo#155256