Wednesday, November 15, 2023
29 changes · 17.0
Resolved issues and error corrections
This fixes an issue that could cause the Point of Sale order screen to crash when showing sales order lines. The change ensures the needed screen context is available so staff can view and manage related orders without interruption.
Original PR description
`Orderline.getDisplayData()` relies on the presence of the component's `env`. However, since 7dd76be303b6769767ef0736ba738fc0063a4a28, an `Orderline` instance can be created without `env`, which results to a traceback when rendering the order widget. This commit makes sure the `env` is present in the Orderline instance created from pos_sale module. Closes runbot error: 27820 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue on Safari where website pages could still scroll behind the mobile menu after it was opened. Visitors using mobile navigation get a cleaner, more stable browsing experience without unintended page movement.
Original PR description
Since [commit 1] replaced the mobile menu, a bug appeared on Safari where the `#wrapwrap` element would still be scrollable even with the menu open and even though the `body` has `overflow: hidden;`. This commit fixes it. [commit 1]: https://github.com/odoo/odoo/commit/bc13176de8d66bbdc1c536017b1f046c5fd31a86 task-3584299
This update fixes an intermittent failure in a mobile test flow by ensuring the next record is fully displayed before trying to edit it. It improves test reliability without changing any user-facing business behavior.
Original PR description
Since the commit afdcf9a5d5cd0d25b2ba61167d3ae6726a97d554, the mobile main flow tour fail sometimes. This is due to the fact that the tour try to edit the record before the new record is displayed. The solution is to wait for the new record to be displayed before trying to edit it. 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
This fix restores the missing desktop spacing between the message filters and the New Message action in the Messaging menu. It improves visual clarity and prevents the controls from appearing cramped after a previous mobile-focused update.
Original PR description
Follow-up of [1] PR above made several improvements to Messaging Menu, especially in mobile. By mistake, it removes the spacing between "All"|"Chats"|"Channels" and "New Message" in desktop. This commit re-adds this spacing with `div.flex-grow-1`. [1]: https://github.com/odoo/odoo/pull/140405 Before/After  
This fixes a visual issue where the file drop area background did not appear in embedded live chat. The change keeps the live chat upload experience consistent in both light and dark modes.
Original PR description
Before this PR, the dropzone background was not showing on the embed live chat. The dropzone is displayed as a `main component`. In the Odoo frontend, the main component container is displayed outside of the live chat shadow dom, where the `bg-view` class is not available. This commit replaces this class by the `bg-100` one that is almost the same and available in the frontend. task-3595537 Before/After - Light:  Before/After - Dark: 
Module imports now handle static file paths that contain spaces when creating attachments. This prevents import failures for modules that include files or folders with spaces in their names.
Original PR description
When we are importing a module and we need to create an attachment from a file in static. We get an error if the file path of the file contains a space. We get this error becuase it takes the path to generate an xml id and the name of an xml_id cannot contains spaces. 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
Repair order line items now default to a quantity of 1, avoiding accidental overstatement based on the main repair quantity. The repair screen also uses clearer forecasted availability wording and removes a redundant quantity-clearing button to reduce confusion.
Original PR description
This commit fixes the following issues: 1. Before this commit, when adding a new move in a repair order, its default quantity was equal to the repair order's product quantity. The move's quantity should be 1 by default; 2. The `forecast_availability` is renamed from "Reserved" to "Forecasted"; 3. Removes the "Clear Quantities" button since it does basically the same thing than the "Unreserve" button.
The manufacturing order overview now opens correctly even when some work orders have no expected duration set. This prevents a division-by-zero error, helping users review manufacturing details without interruption.
Original PR description
Opening the Overview of manufacturing orders containing work orders without expected duration gives a division by zero. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem that caused the Purchase tour test to fail when launched from debug mode. The change keeps the guided purchase workflow test compatible with recent internal code changes, helping ensure purchase-related features remain reliably tested.
Original PR description
Steps to reproduce ================== - Install purchase_tour - Enable debug mode - Click on the debug menu - Click on Start tour - Run the purchase_tour tour in test mode `TypeError: Cannot read properties of undefined (reading 'apply')` See https://github.com/odoo/odoo/pull/125716 opw-3595512
Fixed an issue where the fuel type wasn't displaying when employees selected a new car model in their contract. The system now correctly shows fuel type information whether a car is selected from existing inventory or as a new car model. This ensures accurate vehicle information is always visible in employee contracts.
Original PR description
https://github.com/odoo/enterprise/pull/34883 started showing the fuel type of the car_id in the form view of hr_contract. However, when selecting new cars, the car_id won't be set. Instead we'll set the new_car_model_id field and the fuel type won't be shown. This commit changes the fuel_type field in hr_contract to be a computed field that will either take the fuel_type from car_id or from new_car_model_id. task-3515936 Forward-Port-Of: odoo/enterprise#47717
A white gap that appeared on the right side of the room booking interface has been fixed. The issue was caused by a missing CSS class that controls how the layout adapts to larger screens. Adding this class ensures the interface displays properly without unwanted spacing.
Original PR description
Prior to this commit, there was a white gap on the right side in the frontend view. This was due to a missing class enabling the column size to be set correctly on large screens. To fix that, this commit introduces this missing class. task-3592631
This update reorganizes how the recruitment module handles credit purchasing functionality. The credit widget has been moved to the specialized recruitment extraction module where it's actually used, removing an unnecessary dependency. This improves the system's organization and makes the code cleaner without affecting how recruitment features work.
Original PR description
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes odoo/odoo#114747 Forward-Port-Of: odoo/enterprise#49576 Forward-Port-Of: odoo/enterprise#37959
This fix improves the user experience when working with embedded views in knowledge article templates. The toolbar that appears next to embedded content is now easier to click and visually appears properly connected to the content, rather than floating above it. This makes the interface more intuitive and responsive for users creating or editing knowledge articles.
Original PR description
This commit slightly adapts the template data to add a br element after the hr separator, which is necessary to be able to easily click on the embed view toolbar that appears right next to it. In addition, we modify the toolbar styling to make it appear "connected" to its embed view rather than floating a few pixels above it.
Code cleanup and technical improvements
This update reorganizes and simplifies styling across several HR-related apps, making the interface code easier to maintain. Business users should see little to no functional change, but the cleanup helps reduce future maintenance effort and supports more consistent screens.
Original PR description
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
Miscellaneous changes
Since commit [1] which converted wysiwyg to owl, a wrong props definition made the website builder translate mode impossible to enter when in debug mode (because it's when props validation are done). [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997 opw-3570241 Forward-Port-Of: odoo/odoo#142228
Original PR description
Since commit [1] which converted wysiwyg to owl, a wrong props definition made the website builder translate mode impossible to enter when in debug mode (because it's when props validation are done). [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997 opw-3570241 Forward-Port-Of: odoo/odoo#142228
### Before this PR: If you are using mrp_subcontracting , there is an issue caused by the "product_id" set on mrp.bom also when variants are not enabled. Steps to reproduce:(install also subcontracting module with variants disabled) - Create a mrp.bom - Assign a component inside the mrp.bom - Click on the product (odoo goes to product.product form) - Click on Boms - Create a bom - Assign a subcontractor to the bom - Go to the product form - Create the product.supplierinfo on "Purch
Original PR description
### Before this PR: If you are using mrp_subcontracting , there is an issue caused by the "product_id" set on mrp.bom also when variants are not enabled. Steps to reproduce:(install also…
### Before this PR: If you are using mrp_subcontracting , there is an issue caused by the "product_id" set on mrp.bom also when variants are not enabled. Steps to reproduce:(install also subcontracting module with variants disabled) - Create a mrp.bom - Assign a component inside the mrp.bom - Click on the product (odoo goes to product.product form) - Click on Boms - Create a bom - Assign a subcontractor to the bom - Go to the product form - Create the product.supplierinfo on "Purchase" tab - The flag on subcontractor is not marked because on the mrp.bom has been set the variant, but the field is invisible because the variants are disabled so now you can t set ti False the product_id unless you enable the variants. The only way to make it work is create the mrp bom from Products => Products => Boms => Create but if you want to create bom coming from "product.product" form , the bom will be linked specific to the variant ### After this PR: The product_id on bom will be set only if the variants are enabled otherwise the variant is False on bom (in case of you are not managing variants, is it useless to set product_id on bom if you come from product.product form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134794
Scenario: - add doc_count field in project.project view - create new project Issue: error and can't create new project > File "addons/project/models/project.py", > line 190, in _compute_attached_docs_count > psycopg2.errors.SyntaxError: syntax error at or near ")" > LINE 6: AND res_id IN () Fix: only do the query if there is non-NewID IDs opw-3584925 Forward-Port-Of: odoo/odoo#141998 Forward-Port-Of: odoo/odoo#141706
Original PR description
Scenario: - add doc_count field in project.project view - create new project Issue: error and can't create new project > File "addons/project/models/project.py", > line 190, in _compute_attached_docs_count > psycopg2.errors.SyntaxError: syntax error at or near ")" > LINE 6: AND res_id IN () Fix: only do the query if there is non-NewID IDs opw-3584925 Forward-Port-Of: odoo/odoo#141998 Forward-Port-Of: odoo/odoo#141706
For a compute store field with new records (e.g. during an 'onchange'), the compute method can be called multiple times on the same records without changing the dependencies. Moreover, it can lead to have N² / 2 complexity for a trivial compute on N records. With partial (where we don't always change the value) compute method: ```python @api.depends('reward') def _compute_has_been_rewarded(self): for rec in self: if rec.reward: rec.has_been_rewarded = 'Yes' `
Original PR description
For a compute store field with new records (e.g. during an 'onchange'), the compute method can be called multiple times on the same records without changing the dependencies. Moreover, it can lead to…
For a compute store field with new records (e.g. during an 'onchange'),
the compute method can be called multiple times on the same records
without changing the dependencies. Moreover, it can lead to have N² / 2
complexity for a trivial compute on N records.
With partial (where we don't always change the value) compute method:
```python
@api.depends('reward')
def _compute_has_been_rewarded(self):
for rec in self:
if rec.reward:
rec.has_been_rewarded = 'Yes'
```
If every `reward` of `self` (N records) is `False`, when the ORM needs
to recompute `has_been_rewarded` of `self`: the compute will be batched,
but only the first record in the batch will be set (to `False`) each
time (due to the current fallback - "fallback to null value if compute
gives nothing"). This means that we will call the compute method N
times, and the compute itself will loop on an average of N/2 records
(the prefetch set decreasing at each step).
Fix this quadratic behavior by setting the cache to `False` for every
record not set during the compute method (instead of just the current
record).
Forward-Port-Of: odoo/odoo#142080
Forward-Port-Of: odoo/odoo#114210Odoo periodically updates the user online status. This is done every minute and is throttled in order to ensure it won't be triggered more than it should. Since [1], the underscore `throttle` function has been replaced by the `throttleForAnimation` function. This is not equivalent: the function won't be triggered if there is no animation which result in an outdated user status. This issue was highlighted by the live chat: the button does not show up when there is no available operato
Original PR description
Odoo periodically updates the user online status. This is done every minute and is throttled in order to ensure it won't be triggered more than it should. Since [1], the underscore `throttle`…
Odoo periodically updates the user online status. This is done every minute and is throttled in order to ensure it won't be triggered more than it should. Since [1], the underscore `throttle` function has been replaced by the `throttleForAnimation` function. This is not equivalent: the function won't be triggered if there is no animation which result in an outdated user status. This issue was highlighted by the live chat: the button does not show up when there is no available operator. Steps to reproduce the issue: - Log in on Odoo with live chat installed - Go to a web page that uses the live chat widget - Wait more that one minute and refresh the page - The live chat button is not shown anymore: the only operator is considered as disconnected. This PR fixes that issue by re-introducing the underscore throttle function: it is robust and can be needed, not all throttles are linked to animations. [1]: https://github.com/odoo/odoo/pull/120437. opw-3578517 Forward-Port-Of: odoo/odoo#142122 Forward-Port-Of: odoo/odoo#142009
Description of the issue/feature this PR addresses: Before this commit in large database, the time to unlink some lot can take lot of time. @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#138318
Original PR description
Description of the issue/feature this PR addresses: Before this commit in large database, the time to unlink some lot can take lot of time. @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#138318
A traceback was being thrown when multiple recurrent events were being updated by a batch microsoft update due to a `self.ensure_one()` validation: ``` Traceback (most recent call last): File "/home/odoo/src/odoo/odoo/http.py", line 2003, in __call__ response = request._serve_db() File "/home/odoo/src/odoo/odoo/http.py", line 1589, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "/home/odoo/src/odoo/odoo/service/model.py", line 133, in retrying
Original PR description
A traceback was being thrown when multiple recurrent events were being updated by a batch microsoft update due to a `self.ensure_one()` validation: ``` Traceback (most recent call last): File…
A traceback was being thrown when multiple recurrent events were being updated by a batch microsoft update due to a `self.ensure_one()` validation:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2003, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/odoo/http.py", line 1589, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1616, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 1820, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 237, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/microsoft_calendar/controllers/main.py", line 55, in sync_data
need_refresh = request.env.user.sudo().with_context(sync_context)._sync_microsoft_calendar()
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/res_users.py", line 106, in _sync_microsoft_calendar
synced_events, synced_recurrences = self.env['calendar.event']._sync_microsoft2odoo(events) if events else (self.env['calendar.event'], self.env['calendar.recurrence'])
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/microsoft_sync.py", line 385, in _sync_microsoft2odoo
update_events = odoo_event._update_microsoft_recurrence(mevent, microsoft_events)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/microsoft_sync.py", line 319, in _update_microsoft_recurrence
odoo_event.with_context(dont_notify=True).write(dict(event_values, need_sync_m=False))
File "/home/odoo/src/odoo/addons/base_automation/models/base_automation.py", line 401, in write
return write.origin(self, vals, **kw)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/calendar.py", line 180, in write
self._recreate_event_different_organizer(values, sender_user)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/calendar.py", line 203, in _recreate_event_different_organizer
self.ensure_one()
File "/home/odoo/src/odoo/odoo/models.py", line 5161, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: calendar.event()
```
After this commit, this traceback is now fixed because the validation iterates over each event, avoiding the batch conflict with the `self.ensure_one()` function and skipping the validation of recurring events since these updates are exclusively on the Microsoft side, which does not allow changing the organizer.
Issue from: 3450045
Forward-Port-Of: odoo/odoo#141398Description of the issue/feature this PR addresses: Until now, only European tax numbers were taken into account. Now, Indian numbers are also considered valid and sent to IAP for link creation. This commit takes advantage of IAP changes, which now integrates the Indian GST tax number system. Current behavior before PR: Only European tax numbers were taken into account. Desired behavior after PR is merged: Now, Indian numbers are also considered valid and sent to IAP for link crea
Original PR description
Description of the issue/feature this PR addresses: Until now, only European tax numbers were taken into account. Now, Indian numbers are also considered valid and sent to IAP for link creation. This commit takes advantage of IAP changes, which now integrates the Indian GST tax number system. Current behavior before PR: Only European tax numbers were taken into account. Desired behavior after PR is merged: Now, Indian numbers are also considered valid and sent to IAP for link creation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr related to: https://github.com/odoo/iap-apps/pull/713 Forward-Port-Of: odoo/odoo#141872
Current behavior: When you link a printer to the sales detail report. The report will contains no order. This happens because we are trying to assign docids to the session_id. Fix: Docids represent the session_id only when the report is called from the PoS directly. So we want to use it only when it's the only data passed to `_get_report_values`. If session_id is not set in the data, but other values are (date_start/stop, config_id) we should use those value in priority. When called from t
Original PR description
Current behavior: When you link a printer to the sales detail report. The report will contains no order. This happens because we are trying to assign docids to the session_id. Fix: Docids represent…
Current behavior: When you link a printer to the sales detail report. The report will contains no order. This happens because we are trying to assign docids to the session_id. Fix: Docids represent the session_id only when the report is called from the PoS directly. So we want to use it only when it's the only data passed to `_get_report_values`. If session_id is not set in the data, but other values are (date_start/stop, config_id) we should use those value in priority. When called from the frontend directly, docids doesn't represent a session_id. Steps to reproduce: -Install pos_iot -Link a printer from the demo iot to the sales_detail report (go in settings > reporting > reports) -Do some orders on the PoS, and close it -Go in the backend, and print the sales detail report -You will see that the report is empty (You can put a breakpoint in get_sale_details method to see that it will be empty) opw-3247196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142024 Forward-Port-Of: odoo/odoo#140748
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. Which was causing a traceback when IAP was not installed. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes #114747 Forward-Port-Of: odoo/odoo#139771 Forward-Port-Of: odoo/odoo#114759
Original PR description
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. Which was causing a traceback when IAP was not installed. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes #114747 Forward-Port-Of: odoo/odoo#139771 Forward-Port-Of: odoo/odoo#114759
This commit addresses a traceback that occurs when trying to serialize a node that has no `oid` property because it was added to the DOM while the mutation observer was not active (eg, using `observerUnactive`). This is the case with technical nodes added for managing the selection around links ("link zws spans"). When serializing a node, we expect it and its descendants to have an `oid` property so we throw an error if such is not the case. But we now have a legitimate case where nodes have
Original PR description
This commit addresses a traceback that occurs when trying to serialize a node that has no `oid` property because it was added to the DOM while the mutation observer was not active (eg, using…
This commit addresses a traceback that occurs when trying to serialize a node that has no `oid` property because it was added to the DOM while the mutation observer was not active (eg, using `observerUnactive`). This is the case with technical nodes added for managing the selection around links ("link zws spans").
When serializing a node, we expect it and its descendants to have an `oid` property so we throw an error if such is not the case. But we now have a legitimate case where nodes have no `oid` property so this removes the error. If the `oid` was in fact really supposed to be defined (eg, the node we tried to serialize was the direct target of a mutation), an error will be thrown soon enough after when trying to access said property.
Note that other, more ad-hoc fixes specific to the link zws spans would have been possible (and might still be useful in the future), such as:
- skipping said link zws spans when serializing
- adding a fake `oid` property to the link zws spans
task-3593081
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#141991
Forward-Port-Of: odoo/odoo#141831Steps to reproduce: - Enable 3 step delivery (pick,pack,ship) in inventory settings - Create and confirm an SO with a consumable product - Put the first transfer (PICK) in pack (check show detailed operation will make it easier to see the bug) - Result package is correctly set and will be correctly set as source package for the following transfer (PACK) Bug: result package is not set on the following transfers Fix: propagate the package by default (if it's disposable) since consuma
Original PR description
Steps to reproduce: - Enable 3 step delivery (pick,pack,ship) in inventory settings - Create and confirm an SO with a consumable product - Put the first transfer (PICK) in pack (check show detailed operation will make it easier to see the bug) - Result package is correctly set and will be correctly set as source package for the following transfer (PACK) Bug: result package is not set on the following transfers Fix: propagate the package by default (if it's disposable) since consumable product do not have a stock.quant _check_move_lines_map_quant_package will fail and package_level will not be created and result will not be assigned opw-3513870 Forward-Port-Of: odoo/odoo#141800 Forward-Port-Of: odoo/odoo#141514
Description of the issue/feature this PR addresses: The time for events on the website events snippet does not match with the actual timings for the events for public users Current behavior before PR: The events snippet shows UTC time for events for public users without any timezone info.Check the event timings in first screenshot and second screenshot for event 'Conference for Architects', it shows the time as 9:00 am in first screenshot and 8:00 am in second screenshot for the same event wi
Original PR description
Description of the issue/feature this PR addresses: The time for events on the website events snippet does not match with the actual timings for the events for public users Current behavior before…
Description of the issue/feature this PR addresses: The time for events on the website events snippet does not match with the actual timings for the events for public users Current behavior before PR: The events snippet shows UTC time for events for public users without any timezone info.Check the event timings in first screenshot and second screenshot for event 'Conference for Architects', it shows the time as 9:00 am in first screenshot and 8:00 am in second screenshot for the same event without any timezone info   Desired behavior after PR is merged: The events snippet would show the event time in the selected timezone for the event along with timezone info.Check the event timings in third screenshot, this would be after the 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#141532 Forward-Port-Of: odoo/odoo#140913
Current behavior: When the screen is too small to show all the categories, the scrollbar will start at the end of the list, and the user will have to scroll up right to see the first category. Steps to reproduce: - Add some categories to the pos - Make the screen small enough to hide some categories - The scrollbar will appear, but at the end of the list Note: This happens because of the reverse-row css property. So we remove it and put the element in the right order. opw-3530768
Original PR description
Current behavior: When the screen is too small to show all the categories, the scrollbar will start at the end of the list, and the user will have to scroll up right to see the first category. Steps to reproduce: - Add some categories to the pos - Make the screen small enough to hide some categories - The scrollbar will appear, but at the end of the list Note: This happens because of the reverse-row css property. So we remove it and put the element in the right order. opw-3530768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141997 Forward-Port-Of: odoo/odoo#140977
Steps to reproduce: - Add a date field in a model with `tracking=True` - Log with a user with timezone set to UTC+2 - Create a record and set the date field to any date. - Update the date value to another date (Should have logged a message in the chatter with changes) - Log with a user with timezone set to `America/Los Angeles` - Check the chatter of the record created above Issue: New date value displayed in the chatter is wrong (set to one day before). Cause:
Original PR description
Steps to reproduce: - Add a date field in a model with `tracking=True` - Log with a user with timezone set to UTC+2 - Create a record and set the date field to any date. - Update the date value to another date (Should have logged a message in the chatter with changes) - Log with a user with timezone set to `America/Los Angeles` - Check the chatter of the record created above Issue: New date value displayed in the chatter is wrong (set to one day before). Cause: The value displayed in the chatter is the date value converted first as datetime (with Luxon library), then the system timezone is set on it and therefore might change the day. opw-3427502 Forward-Port-Of: odoo/odoo#141996 Forward-Port-Of: odoo/odoo#141227