Thursday, December 21, 2023
24 changes · 17.0
Resolved issues and error corrections
This fix prevents website pages from crashing when visitors hover over animated images that were edited and then viewed through another domain. It improves reliability for multi-domain websites and avoids broken user experiences caused by image loading restrictions.
Original PR description
The image mouseover animation can crash through legit UI flows: - Visit your website on domain 1 (you will need to access the same website from another domain later): 1. On local: use…
The image mouseover animation can crash through legit UI flows:
- Visit your website on domain 1 (you will need to access the same
website from another domain later):
1. On local: use http://localhost:8069/ and http://127.0.0.1:8069/
2. On runbot: use master-all and master in URL
3. On odoo.com: use xyz.odoo.com and xyz.com
- Drag & drop "Text - Image" snippet
- Double click on the image to replace it
- Upload any image
- Click on the image and set its "Animation" option to "On Hover"
- Save
- Outside edit mode, mouseover the image to see the animation
- Behind the scene, the img src is changed from /web/image/xyz to a
hardcoded base64 value to show the animation
- Now enter edit mode, the system will actually reset the src to the
original src (to replace the b64) but it will replace it by an
absolute link and not the initial relative link
- Edit the text below the image, BUT DON'T MOUSEOVER THE IMAGE
(otherwise the absolute url would be turned into b64)
- Save, again DON'T MOUSEOVER THE IMAGE
- Now go on your second domain to access the same page
Bug: Mouseover the image, a `Uncaught Promise > Failed to fetch` error
will be raised because of a CORS error.
Indeed, on http://localhost:8069/, simply doing this in your debug tool:
```js
fetch('http://127.0.0.1:8069/website/static/src/img/snippets_demo/s_image_text.jpg')
```
will throw the same error.
Note: we can't just modify the CSP rule(s) to allow that domain because
we have no way to know which domains are safe and really domains from
the same database:
- When you are on xx.odoo.com, there is no way to know that xx.com is
also your domain for the same website. At best it will be set in the
website domain but it's not always the case (often not the case in
mono website)
- When you are on xx.com, we have no way to know that xx.odoo.com is
also your domain for the same website. At best it will be set in the
ICP `web.base_url` but until that ICP is actually frozen, it will
change every time the admin logs in the database.This fixes an inventory issue where validating a backorder could fail silently when one product line had no received quantity. Backorders now keep the correct remaining quantities, helping warehouse teams continue processing purchases without manual workarounds.
Original PR description
Steps to reproduce the bug:
- Create two storable product “P1” & “P2”
- Create a purchase order:
- Add 10 quantity of “P1” & “P2”
- Confirm the PO
- Go to the delivery:
- Set the quantity of “P1” at 2 and “P2” at 0
- validate the delivery and create a backorder
- Go to the backorder:
- The quantity set for “P1” is 8 and for “P2” is 0
- Try to validate and create a backorder
Problem:
Nothing happens because the quantity of "P2" is 0, and the "picked" field is set to True. However, the quantity should be 10, and the "picked" field should be set to False when the backorder is created: https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L1822-L1828
opw-3629848The sale order portal page now shows order totals correctly again. This restores a previously fixed display behavior, helping customers view accurate order information in the portal.
Original PR description
The portal view of the sale order total is broken. This issue was fixed in this commit 619e5e0dadaa27d9eb5f13289c90a4a205e73a04 but it was removed in this commit df8535fbd40e1e5c09dbe616a3332c76c23525c8 The changes that were removed have been re-added. task-3646364
A course page could fail to load for visitors because of an incorrect date handling function. This update corrects the date processing so the affected eLearning content opens normally without a client-side error.
Original PR description
HOW TO REPRODUCE ================ - Don't need to login - From Odoo front-end, go to Courses > Trees, Wood and Gardens > Main Trees Categories - You get the following client error: Uncaught Promise > datetimeObj.getTime is not a function HOW TO SOLVE: ============ Unlike standard JS equivalent, luxon datetime objects don't have a getTime() function. Replace it by valueOf() function. Also, replace calls to `DateTime.fromJSDate().formatting_fn()` by luxon equivalent functions. task-3632077 see bb09cf76e32b20864dc45eacf912d2c6f26768ef --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now try another discount or loyalty code after entering an invalid one. This prevents shoppers from getting stuck during checkout and helps reduce lost sales caused by a blocked code field.
Original PR description
If incorrect code was applied, possibility of putting another code was blocked. task-3601317
This fixes an error that could block users from opening Kiosk Mode in the Attendance app when multiple companies are active. After the change, users are redirected to Kiosk Mode as expected, reducing disruption to attendance check-in workflows.
Original PR description
Description of the issue/feature this PR addresses: Singleton error due to multi-company. Current behavior before PR: When clicking on the "Kiosk Mode" menu in the **Attendance** app, it gives (500: Internal Server Error) due to multi-company and prevents redirection to the "Kiosk Mode". Desired behavior after PR is merged: It'll successfully redirect it to the "Kiosk Mode". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening article pages in eLearning courses no longer triggers an error for users. This keeps course content accessible and avoids interruptions when visitors or learners navigate to article-based lessons.
Original PR description
Currently, there is a traceback error when opening an article of a course.
Steps to reproduce:
-------------------
* Install ´eLearning´ with demo data
* Skip website building
* Go to ´Website´
* Select page ´Courses´
* Select a course that has articles (ex: Furniture Technical Specifications)
* Select an article (ex: Foreword)
Why this fix:
-------------
datetimeObj.getTime() is not a function.
new Date(datetimeObj).getTime() and datetimeObj.ts are equivalent fixes.
Note:
-----
After changing `DateTime.fromJSDate(datetimeObj)` to `datetimeObj`, `const { DateTime } = luxon;` had to be removed as it was now assigned but never used.
opw-3622688The appointment booking form now stops users from confirming an appointment until required details are completed. This prevents an error page during booking and gives customers a clearer path to finish scheduling.
Original PR description
When a user wants to take an appointment and confirms appointment without filling there details the user would face error. Steps to produce: - Create an appointment from Appointments. - Share that…
When a user wants to take an appointment and confirms appointment without filling there details the user would face error.
Steps to produce:
- Create an appointment from Appointments.
- Share that appointment by clicking on Share button of the created appointment and copy the link.
- Paste the copied link in some other browser or incognito tab.
- Select a date & time slot.
- After doing it you will see `Add more details about you` form.
- Leave the whole form blank and click on the `Confirm Appointment`.
Error:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5830, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.partner()
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1873, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/appointment/controllers/appointment.py", line 624, in appointment_form_submit
'phone': customer._phone_format(number=phone, country=self._get_customer_country()) or phone,
File "addons/phone_validation/models/models.py", line 53, in _phone_format
self.ensure_one()
File "odoo/models.py", line 5833, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
After applying this commit user would not be able to confirm appointment
until they fill valid and required details.
sentry-4659228058This fix resolves an issue where kitchen printers were not printing order changes in the Point of Sale system. The problem occurred because the system was saving changes to the order before sending them to the printer, which meant there was nothing new to print. Now changes are printed first, then saved, ensuring kitchen staff receive the necessary order updates.
Original PR description
Current behavior: When trying to print the changes of an order, nothing was printed. This was happening because we were first saving the changes before sending them to the printer. Because of this when we tried to retrieve the changes to print them, they were already saved and we were not retrieving anything. Steps to reproduce: - Setup a printer to print order changes - Create a new order in PoS restaurant - Add a product to the order - Click on the "Order" button - Nothing is printed opw-3625397
This fix expands access to spreadsheet history viewing beyond administrators to all regular users. Previously, only admin users could open and review the history of spreadsheet changes. This change improves usability by enabling all team members to track spreadsheet modifications and understand the evolution of their data.
Original PR description
Currently, only Admins can open a spreadsheet history Task: 3639902
This update significantly improves the performance of subscription pricing searches in Odoo. A search operation that previously took over 7 seconds now completes in less than 100 milliseconds—roughly 70 times faster. This means users will experience quicker load times when working with subscription pricing data.
Original PR description
Before this commit,
In [2]: %time _ = env['sale.subscription.pricing'].read_group([('product_template_id', '!=', False)], ['product_variant_ids:array_agg'], ['product_template_id', 'plan_id', 'pricelist_id'], lazy=False)
CPU times: user 6.01 s, sys: 136 ms, total: 6.14 s
Wall time: 7.11 s
After this commit:
In [12]: %timeit = self.read_group(['|', ('product_template_id', 'in', self.product_template_id.ids), ('product_variant_ids', 'in', self.product_variant_ids.ids)], ['product_variant_ids:arrayagg'], ['product
...: template_id', 'plan_id', 'pricelist_id'], lazy=False)
49.4 ms ± 127 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)This update fixes and upgrades expression handling in Turkish localization accounting reports for Odoo 16.3. The changes include updates to translation files and configuration across multiple accounting modules to ensure proper report generation and localization support for Turkish users.
A bug was preventing placeholder changes from being saved when editing sign templates. Users would make changes to placeholders in their sign templates, but these changes would not be persisted. This fix ensures that all placeholder modifications are now properly saved to the template.
Original PR description
After the sign conversion to OWL, changing the placeholder of a sign item while editing a template, would not save the placeholder changes to the sign template. This commit fixes this issue. task-3576993 Forward-Port-Of: odoo/enterprise#53088 Forward-Port-Of: odoo/enterprise#49928
This fix resolves an issue where pressing Tab in a list view inside a dialog would not navigate to the next line as expected. The problem was caused by conflicting keyboard event handlers. The solution removes a technical optimization that was preventing proper Tab key navigation, allowing users to seamlessly navigate through list items in dialogs using the Tab key.
Original PR description
Description: =========== Before this commit, when a line in edit mode in a list view is the last tabable element in a dialog, pressing "tab" does not cause a switch to the next line in edit mode. It…
Description: =========== Before this commit, when a line in edit mode in a list view is the last tabable element in a dialog, pressing "tab" does not cause a switch to the next line in edit mode. It is therefore not possible to navigate in this dialog using "tab". Problem: ======= Currently, the ListRenderer listens to keydown events using few t-on-keydown.synthetic in order to know whether to switch the next line to edition. For information, the effect of a synthetic is to create a single listener on "document" instead of creating a listener for each element. There is a conflict with the ui service which listens to all the "tab" keydowns in order to check whether or not we are on the last tabable element of the current activeElement. If we are, we stop the event and focus on the first tabable element. This feature avoids the need to navigate outside dialogs by pressing tab. In our situation, this has the effect of stopping the keydown event before the synthetic can receive it, as the service ui listener is placed on the dialog and the synthetic listener on the document. Solution: ======== Remove the use of synthetic in the ListRenderer. No significant loss of performance was observed. Issue in Enterprise: =================== Because of our fix in community, the DocumentListRenderer no longer receives the "enter" keydown event first. We therefore need to overwrite "onCellKeydown" to ignore the "enter" event in this situation. Forward-Port-Of: odoo/enterprise#53109 Forward-Port-Of: odoo/enterprise#52920
This fix resolves an issue where the upsell quotations button would disappear from sale orders after changing a quotation status. Previously, the button was only visible when sale orders were in draft state. Now the button remains visible regardless of the sale order state, allowing users to continue managing upsell quotations throughout the sales process.
Original PR description
**Version:** - saas-16.2 **Step to reproduce:** - upsell a sale order - click on the upsell quotations stat button and change the state=sent quotation - the upsell quotations button will disappear from the confirmed sale order form view **Issue:** The upsell quotations stat button in the subscription module's sale order form view is only visible when the sale order is in the draft state. **Solution:** The upsell quotations stat button will remain visible even when the sale order is in the sent state. task-3593973 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#53096
A field in the Luxembourg tax report's Appendix A that allows users to enter a custom operational expense name was incorrectly configured as a number field instead of a text field. This fix corrects the field type so users can properly enter expense descriptions as text rather than numbers.
Original PR description
Line 42 in Appendix A is supposed to allow entering a custom name of an operational expense and its value, both of which are manual values to be entered by the user. The name field is supposed to be a string but currently it's a float as the report doesn't specify that it should be a string.
This fix resolves a bug where users couldn't update an embedded view's title after clearing it. Previously, the system would only save title changes if a title already existed, preventing users from setting a new title after removing the old one. The fix now allows title updates to be saved regardless of the previous state.
Original PR description
This commit fixes a bug where an embedded view's title would no longer be saved after being set to an empty value. Meaning that after removing the title it is no longer possible to set as anything else than its default value. This was caused by a condition stating that we could only update the display_name inside the behavior props if its value already existed, which is incorrect when a user removes it. Now we change this value no matter what happens. task-3637710 Forward-Port-Of: odoo/enterprise#52690
Fixed an issue where the WhatsApp button was always displayed in the message area, even when no approved templates were available, which caused error messages. Now the button only appears when templates exist for that model, though administrators can always see it to create new templates. When users click to configure templates, they're taken directly to the template setup filtered for their current model.
Original PR description
**Before this PR:** `WhatsApp` is always displayed even if there are no approved templates for the model which returns a `ValidationError`. Which is just noise. **After this PR:** - Do not display the button if no approved templates for the model - Button should be always visible to admin users as they can create templates. - After clicking on `Configure Templates` button in the warning popup the `Whatsapp Templates` should be opened with a filter for the current model. task-[3497496](https://www.odoo.com/web#id=3497496&cids=2&model=project.task&view_type=form)
This update fixes a sorting issue in the WhatsApp messaging sidebar within Odoo's Discuss application. The fix ensures that conversations are properly organized and displayed in the correct order, improving the user experience when managing multiple WhatsApp conversations.
Original PR description
fixes runbot-47784 community: https://github.com/odoo/odoo/pull/146805
Fixed a bug in the EC Sales Report reminder banner that was displaying at the wrong times. The banner was incorrectly showing when no relevant sales occurred and hiding when sales were actually made. This fix inverts the logic so the reminder appears only when it should, helping users remember to submit their EC Sales Reports when necessary.
Original PR description
Problem --------- Since saas-16.4, the banner reminding a user to submit EC Sales Report was showing when not relevant sales had occured. Furthermore, it would hide when some of those sales were made. Objective --------- Have the opposite behavior. Solution --------- Invert the condition that would show or not the banner by remove the 'not'. task-3645189 Forward-Port-Of: odoo/enterprise#53203
This update resolves a critical issue where the data_merge module's tests were crashing due to an unnecessary dependency on the accounting module. The fix removes the problematic inheritance relationship and reconstructs the required test data independently, allowing the module to function properly without requiring additional modules to be installed.
Original PR description
Steps to reproduce: - init a db with [base,web,auth_totp,base_import,base_setup,bus,web_cohort,web_gantt,web_grid,web_tour,iap,mail,web_editor,web_enterprise,web_map,auth_signup,auth_totp_mail,base_install_request,data_recycle,google_gmail,iap_extract,iap_mail,mail_bot,phone_validation,privacy_lookup,web_mobile,web_unsplash,data_cleaning,mail_enterprise,partner_autocomplete,sms,snailmail,data_merge,mail_mobile] - run tests from `data_merge` module Issue: - crash Cause: We inherit a class from `account` module which is not installed Solution: Instead of facing the burden of creating a bridge module, we eliminate the troublesome inheritance and reconstruct the necessary records for the test. runbot-45753 Forward-Port-Of: odoo/enterprise#53141 Forward-Port-Of: odoo/enterprise#52945
This update corrects how overtime hours are calculated when employees work across multiple companies in the HR Attendance module. The fix ensures accurate overtime reporting regardless of company configuration, improving payroll accuracy and compliance with labor regulations.
Original PR description
This commit apply the same changes done in commit 9352c74 for the same reason to hr_attendance_gantt. The fix was introduced in 16.0 but this fix is only valid starting from 17.0
A bug in the appointment booking form was preventing checkbox questions from being validated correctly. The system was trying to validate checkboxes as a single object instead of treating them as a group, which caused validation to fail. This fix ensures that checkbox questions work properly when customers fill out appointment forms.
Original PR description
Introduced in 98544fcf51e7f7e6dd395b8a1221801a683b7c9c, We replaced underscore functions with native JS. When changing 'any' to 'some', we apply the some method to checkboxes, but it is an Object, not an array. -> spread checkboxes to array. Task-3648070 Forward-Port-Of: odoo/enterprise#53118
A bug in the Knowledge module's properties panel has been fixed that was causing the application to crash when debug mode was enabled. The issue was related to an incorrect data type for a button display setting, which has now been corrected to ensure the panel functions properly.
Original PR description
Purpose: -------- When debug mode is activated, opening the properties panel crashes because the "showAddButton" prop is not a boolean as required. This prop is now a boolean. Task-3649459