Monday, April 8, 2024
34 changes
7 changes
Resolved issues and error corrections
Runbot now recognizes a failed web test as a completed test run instead of waiting until it times out. This helps developers and teams get faster, clearer feedback when automated tests fail.
Original PR description
Before this commit, when a test failed, runbot would wait until a message does not contain "[HOOT]" and timout. Now, it will wait until a message does not contain "[HOOT]" or a message that contains "[HOOT] test failed (see above for details)". This means that the runbot will not time out anymore. 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
Odoo now checks template relationships while preparing website and app assets, helping spot configuration or naming mistakes that could otherwise silently disable interface customizations. Several affected templates were also corrected so their intended extensions apply reliably.
Original PR description
With https://github.com/odoo/odoo/pull/145602, template inheritance is now applied lazily browser side. When OWL needs a template, the template and all related templates (if any) are parsed and used to construct the final template used by OWL. So if some parent template in the chain is missing, it is only detected at that time. But for extensions (t-inherit-mode="extension"), the situation is different. If for some reason (e.g a typo) the parent of an extension is not found, the extension will simply never be used and will never cause a crash (if not tested in a test/tour). In this commit, we check if all parent templates are available in the bundles when they are prepared server side. That check will only log an error in the console. We also make sure that some template extensions are now applied by modifying some template t-inherit attributes (an exact match t-inherit = t-name is needed now).
Odoo now waits until the web client has the complete user context before loading actions. This prevents server actions from running with missing information such as the active company, reducing errors in multi-company or context-dependent workflows.
Original PR description
Since [1], when an action is loaded, if the action is a server action, the server will execute the action directly and return the resulting action. Before the commit [1], only a part of the context was need, now that the server execute the action, the complete user context is need. Before this commit, a performance improvement was to call the action load at the beginning of the action service. The issue with calling the action load in such an early step, is that all the user context is not complete yet (For instance, the allowed_company_id is not yet there, it's added later by the company service). Now, the call to the action load is made on the mount of the WebClient, in which moment it should have the complete user context. [1] : https://github.com/odoo/odoo/commit/f49e97e9ad41c1c5e7123bad9c429a9af2732b73
This update fixes an internal code issue found by newer quality checks, helping prevent potential errors in hardware receipt printer handling. It supports a smoother upgrade of development tools without changing day-to-day user workflows.
Original PR description
We are planning to upgrade the pylint version since ruff is now fully deployed. This will fix some of the issue that where not detected with the previous version This will be backported from 15.0 to 17.1 by moc with additional fixes.
This fixes a display issue where 15-minute calendar events could lose their intended styling after refreshing the page. Short meetings now keep the correct visual indicators, making the calendar easier to read and preventing confusing event displays.
Original PR description
For info FullCalendar V6 use Preact internally. Preact is similar to OWL/React/Vue as when some props change it apply the change on the element linked to the props. In our case for the events, when…
For info FullCalendar V6 use Preact internally. Preact is similar to OWL/React/Vue as when some props change it apply the change on the element linked to the props. In our case for the events, when an event has a duration of 15 minutes FullCalendar changes the `isShort` to `true` so Preact can add the `fc-timegrid-event-short` class to the event. In Odoo we add also other classes to these events for our needs (e.g.: `o_event_striked`). In FullCalendar V4 it was done in `eventRender` using `el.classList.add()`. During the migration to FullCalendar V6 [1] the `eventRender` was changed into `eventDidMount` (a Preact HOOK). In most cases, `eventDidMount` is fine but not for short event, as in FullCalendar V6 there is another HOOK especially for the classes `eventClassNames` [2]. Before this fix, the render flow of the event was: 1) pre-render event 2) add the event to the DOM 3) call `eventDidMount` (here we add our classes) 4) FullCalendar set `true` to `isShort` props 5) Preact sets the classes on the event to add `fc-timegrid-event-short` (here FullCalendar removes our classes added in `eventDidMount`) After the fix, the render flow is the same as before, but as we add the classes using the `eventClassNames` HOOK, FullCalendar knows all additional classes per event so when Preact (in steps 5) sets the classes its adds `fc-timegrid-event-short` and all other classes added by our code in `eventClassNames`. Steps to reproduce: * Open Calendar App * Make an event with a duration of 15 minutes * Refresh the page (F5) => Bug the style of new event (15 min) is wrong [1]: odoo/odoo@90f85a19deaea33cd747c969762ff20f1d59ef4c [2]: https://fullcalendar.io/docs/event-render-hooks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web test timeout has been increased to reduce random failures in automated checks. This helps keep development and release validation more stable while the team investigates why some tests occasionally take longer than expected.
Original PR description
This PR increases the duration after which a test is considered as failed. This has been done because undeterministic failures have been observed on the CI, and this fix gives us time to investigate exactly what causes these tests to take a long time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when saving a Point of Sale product category after removing its parent category. This helps users update POS category structures without being blocked by a system error.
Original PR description
Currently, an error is generated when the user removes the parent category from the POS product categories and tries to save it. Steps to produce and error: 1. Go to Point of Sale > Configuration >…
Currently, an error is generated when the user removes the parent category from the
POS product categories and tries to save it.
Steps to produce and error:
1. Go to Point of Sale > Configuration > Products > PoS Product Categories
2. Open any PoS product categories that contains Parent Category.
3. Now remove Parent Category and try to save it >>> error generate
Stack Trace:
```
IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, 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 1825, 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 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, 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/web/models/models.py", line 71, in web_save
self.write(vals)
File "addons/point_of_sale/models/pos_category.py", line 67, in write
vals["color"] = self.search_read([("id", "=", vals["parent_id"])])[0][
```
This is because at [1], we receive the `False` value in `vals["parent_id"]` as a result of
the search; it has no value, and a key error is generated because we try to access the first element but it is empty.
This commit will fix this issue by ensuring that the value of `parent_id` is in `vals` before searching.
[1]-https://github.com/odoo/odoo/blob/7479ffdc43c857bfd6439aefc024330dc22825b3/addons/point_of_sale/models/pos_category.py#L66-L69
sentry-515306954618 changes
Resolved issues and error corrections
This update fixes multiple issues with the timesheet leaderboard feature, including preventing the leaderboard from displaying for employees without billable rates, correcting theoretical working hours calculations, and improving the visual presentation with proper icons and styling. These fixes ensure the leaderboard accurately reflects employee billing information and displays correctly for all users.
Original PR description
This commit adds various changes to the codebase to fix issues with the leaderboard system, issues such as the leaderboard being displayed even though the current employee has no billable time rate, billing rate target not having the fa-building icon next to it, theorical working hours being incorrect, visual issues and many more. task-3570302
Fixed an issue where users couldn't access products from their company when viewing the product catalog in Field Service tasks without existing sales orders. The fix ensures the system correctly recognizes which company's products should be available, allowing seamless product browsing in multi-company environments.
Original PR description
Steps ----- 1. Have field services and sales installed 2. Create a new company 3. Create a new product belonging to the new company 4. Log in under new company 5. Field service > click the "Product" smart button in a task with no sales order ** Read access error when accessing a page with a product from new company ** Issue ----- In a multi-company environment, accessing the catalog of products in field service is only possible if there are no products belonging to a different company than the user's main company. Note: this issue only arises if there's no sales order linked to the task. If an order already exists (for example by creating a sales order item in the task form), its associated company will be used. Fix --- We use the tasks's company to have the correct allowed_company_ids in the context. **opw-3752311**
This update fixes a visual issue in the field service task report where a horizontal line was overlapping other content. The fix improves the report's appearance by adjusting the display layering, making the document cleaner and easier to read when signing off on completed tasks.
Original PR description
17.0 Steps to reproduce: - install field service - check worksheet option from setting in field service - complete worksheet of any task and click on sign report - click on sign button on portal Issue: - horizontal line is getting overlapped on Sing task report. Solution: - Add z-index property on horizontal line to have better ui. Task: 3770835
This fix resolves a crash that occurred when users clicked the cancel button in the signature request popup after scheduling a signature activity. The issue was caused by an incorrect parameter being passed when the popup closed. By updating how the parent view reloads after cancellation, the error is eliminated and the activity updates properly.
Original PR description
Version: ----------- saas-16.3 Steps to produce: ------------------------- 1. Open Sales or any other app. 2. Schedule an activity for Request Signature 3. Once the activity is scheduled, click on the Request Signature field 4. In the New signature Request pop-up click on cancel button ->Traceback occurs Issue: -------- A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button. Cause: --------- The error occurs because when the cancel button is clicked, the onUpdate component is triggered to load and update the ID. However, a special parameter is passed incorrectly, leading to an error. Fix: ----- The issue can be resolved by changing the props from onUpdate to reloadParentView, the component correctly reload the parent view upon cancelation, This prevents the traceback error by ensuring that the activity is updated appropriately. task-3768008 Forward-Port-Of: odoo/enterprise#58729
This update upgrades the Dutch tax report templates used for submitting reports to the Netherlands fiscal authorities to the newer nt18 version. The templates have been updated to comply with the latest requirements from Dutch tax authorities, and a warning message has been added to remind users to upgrade their module before submitting reports.
Original PR description
The templates are used to create a report that will be sent to the fiscal authorities of the Netherlands. They have updated to a newer version of the template. Forward-Port-Of: odoo/enterprise#59907
This fix restores the ability for customers using global rounding to export their financial data to DATEV format. A previous restriction was blocking this important export functionality due to occasional minor rounding differences. The change prioritizes user access to critical business processes over preventing rare 1-cent rounding discrepancies.
Original PR description
Issue: If a customer was using `round globally` and at some point wanted to export its date, he could not do it because of this rounding parameter. The reason of the fix in the first place is not strong enough (occasional 1 cent rounding issue) to justify blocking such an important flow original pr: https://github.com/odoo/enterprise/pull/34560 opw-3848827 Forward-Port-Of: odoo/enterprise#60026
This fix corrects the WhatsApp message sent count in event communications to accurately reflect all messages sent, including those to unconfirmed attendees. Previously, the system was undercounting messages because it excluded unconfirmed attendees from the total sent count, making it difficult to track actual communication activity.
Original PR description
Before this commit the Whatsapp Sent Count (located in the Communication tab of the event view) wasn't including messages sent to the attendees who weren't confirmed. ### [This commit changes] Event…
Before this commit the Whatsapp Sent Count (located in the Communication tab of the event view) wasn't including messages sent to the attendees who weren't confirmed. ### [This commit changes] Event mail scheduler will include seats_uncofirmed into calculation of the mail_count_done which is the count of emails sent. This is reflecting the actual number of messages sent. ### [Reproduce] - Install whatsapp_event - Create event E starting in time T (Events/Events) - Add an "Unconfirmed" attendee - Add an E-Mail in the Communication tab of the event E - Set Interval time > T, - Template: "Email Reminder" - Trigger "Before the event" - Run scheduled Action sending whatsapp (Scheduled Actions / Event: Mail Scheduler) - BUG: message sent, but not included in the sent count in the communication tab of the event E Related to the commit in the odoo community called: [FIX] event: Include unregistered attendee emails in total sent count # Related PRs in odoo Community This Pr is a part of fix/test bundle. For more details check out the here Community PR: https://github.com/odoo/odoo/pull/153795 opw-3693626 Forward-Port-Of: odoo/enterprise#58428
This fix resolves an issue where opening the "Add to dashboard" dialog would permanently delete all version history from a spreadsheet, even if the user cancelled the operation. Users can now safely access the dashboard feature without losing their spreadsheet edit history.
Original PR description
Steps to reproduce: - create a new spreadsheet - edit a few cells to create a few history revisions - click on menu File > Add to dashboard - close the dialog (you don't even need to actually create the dashboard) - open the history: File > See version history => all the history is gone Task: 3850102
This update fixes code issues that were not previously detected by the older pylint version. The changes prepare the system for an upcoming pylint upgrade as part of the transition to ruff for code analysis. This ensures the codebase remains clean and maintainable as development tools are modernized.
Original PR description
We are planning to upgrade the pylint version since ruff is now fully deployed. This will fix some of the issue that where not detected with the previous version Note: self.transaction_ids could raise, this is why we have no garantee that existing_transactions will be defined. But the try except does not look to manage this case, this is why it should be safe to move this line outside the try. This will be merged in 17.2 with 60233 to allow a faster forward-port and adaptation of the docker image
This update fixes how helpdesk ticket confirmation emails are grouped in customer inboxes. The system now uses the correct email field to ensure all related ticket responses appear together, improving the customer experience when managing support conversations.
Original PR description
Follow-up of 0fd53102589e2bdc4d4a257f367a37eca88604c8 The mail template 'Helpdesk: Ticket Received' should also use the `name` instead of the `display_name` for emails all emails to be properly grouped. opw-3748509
This fix resolves an issue where scanning a different product in the barcode app during picking would lose the connection to the original sales order. The barcode app now properly tracks which sales order a picking belongs to, ensuring all products scanned are correctly linked to the right order and backorders are created properly.
Original PR description
Steps to reproduce: - Confirm an SO with a storable product - in barcode app open the created picking - Scan a different product confirm the picking and create a backorder Bug: the new product is not added to the SO and the original picking isn't linked the SO anymore Fix: when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group do the same for the barcode app opw-3644773 Forward-Port-Of: odoo/enterprise#60133 Forward-Port-Of: odoo/enterprise#57408
Users were unable to select different email templates when creating follow-up reminders for customers. The template dropdown only showed the currently configured template, making it impossible to change or re-select templates. This fix ensures the system properly recognizes available templates by setting the correct default model type for template filtering.
Original PR description
## Issue:
- When trying to select any new email template on follow up reports, it will only display the current template (the one configured in the followup level that the customer is currently in), and if you delete it, it's impossible to select one again.
## Steps To Reproduce:
- accounting > Follow-up reports.
- On a report click on FOLLOW UP.
- Notice missing templates in Content Template.
## Solution:
- The template_id field's domain is defined as `domain="[('model', '=', render_model)]"`, which filters based on render_model. However, it was not functioning correctly because the computation for `render_model` was not being triggered.
- To resolve this issue, I set 'res.partner' as the default render_model in the `default_get`.
opw-3776312
Forward-Port-Of: odoo/enterprise#58400This update fixes how taxes are calculated on product prices in the online store to match the standard sales process. Previously, the website store used an older tax calculation method that didn't handle all tax scenarios correctly, particularly when taxes were included in prices. Now all tax calculations use a single, more reliable method that properly handles complex tax situations.
Original PR description
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unnecessary warning messages when users encounter missing pages (404 errors) in Odoo. The system now relies on color-coded status indicators in logs instead, which are easier to spot. This cleanup removes redundant code that was being skipped anyway due to how the error handling was structured.
Original PR description
The conditionnal `isinstance(exc, NotFound)` is shadowed by the conditionnal `isinstance(exc, HTTPException)` two lines above. Nobody ever complained that the warning for NotFound error was gone. Since werkzeug 1.0.0, the status code in the response log is colored, 404 is colored yellow which should catch the eye. The explicit warning line isn't really necessary. Forward-Port-Of: odoo/odoo#159665
This update resolves a problem where Afterpay payments processed through Stripe were failing due to incorrect shipping address information. The fix ensures that accurate shipping address details from orders or invoices are properly sent to Stripe, improving transaction success rates for customers using Afterpay as a payment method.
Original PR description
Resolves an issue with Afterpay via Stripe not receiving correct shipping address details, causing transaction failures. Now, ensures shipping address from the order or invoice is accurately sent to Stripe if we have it. backport of this PR: #157828 opw-3419984
This update fixes a display issue on mobile devices where product cards in the online shop would overflow when showing large prices alongside action buttons like "Add to Cart" or "Add to Wishlist". The fix allows the card content to wrap naturally to multiple lines, ensuring a better shopping experience on smaller screens.
Original PR description
In mobile, having a somewhat 'large price' (like a few thousands currency units) can cause the bottom of the card to overflow (esp. if buttons like 'add to card' or 'add to wishlist' are present). This commit modifies the card template so that content is normally spaced and can wrap to a new line if need be. opw-3706637
Users can now add spaces at the end of link labels without experiencing cursor flickering. This fix resolves a frustrating issue where the text editor would prevent users from typing spaces at the end of link text, improving the overall editing experience when creating and modifying links.
Original PR description
Current behavior before PR: The cursor kept on flickering when attempting to enter a space at the end of label text field of a link resulting in not being able to add space at all. Desired behavior after PR is merged: Now, it's possible to add spaces at the end of a link label. task-3820250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160661 Forward-Port-Of: odoo/odoo#160060
This fix corrects a rounding issue that occurred when creating downpayments on sales orders with multiple line items. Previously, the system would round the downpayment amount separately for each line, causing small rounding errors to accumulate and result in incorrect total amounts (e.g., 840.01 instead of 840.00). The fix now calculates the downpayment amount correctly by rounding once at the end rather than line-by-line.
Original PR description
Create a SO with the following lines: 1. Price Unit 10000, tax 20% 2. Price Unit 10000, tax 20% 3. Price Unit 10000, tax 20% 4. Price Unit 50, tax 20% Confirm, Create a downpayment of 840.0 Check the downpayment Issue: Amount will be 840.01 This occurs because we compute the downpayment values aggregating so line amounts line by line, each time multiplying for the downpayment percentage and rounding the result. Over multiple lines this mechanism may accumulate a rounding error. opw-3812925 Forward-Port-Of: odoo/odoo#160662 Forward-Port-Of: odoo/odoo#160521