Tuesday, May 21, 2024
24 changes · 17.0
Resolved issues and error corrections
This update fixes a test in the tax cloud integration for online sales to ensure customers properly select a shipping carrier for physical products before completing their purchase. This prevents checkout errors and improves the reliability of the payment process for orders containing storable or consumable items.
Original PR description
Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/odoo/pull/161476 Forward-Port-Of: odoo/enterprise#60550
This fix resolves an issue where recorded timesheet hours were not being reflected in the project planning view. The system now properly tracks when timesheets are added to a project, ensuring that the displayed hours in planning slots are always up-to-date with actual work recorded.
Original PR description
Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute, one of its dependencies must change. `project_id.analytic_account_id.line_ids` is different from `project_id.timesheet_ids`. As a result, the method which computes `effective_hours` is not triggered. Solution: --------- Add `project_id.timesheet_ids` in dependencies. opw-3891624
This fix resolves a bug where the timer in the timesheet grid could display negative values when users quickly stopped and restarted it. The issue occurred due to a timing conflict where the timer would be added to a component that was already being destroyed. The fix ensures the timer is only added to active components, preventing the negative value display.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestroy` is called; 5. timer isn't canceled because it hasn't started yet; 6. `onWillStart` continues; 7. a timer is added for a destroyed component. Solution -------- Use Owl's `status` function to ensure the component hasn't been destroyed before adding a timer. opw-3815398
Fixed an issue where filter options (like currency settings and draft entry inclusion) were not being properly applied when navigating to the General Ledger report from the Bank Reconciliation warning message. This ensures users see consistent filtered data regardless of how they access the General Ledger report.
Original PR description
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Ledger - Go back - Create, confirm & reconcile an invoice - Reset invoice to draft - In "Accounting", go to "Dashboard" - Click on the 3 vertical dots to the right of the "Bank" card - Click on "Reconciliation Report" - In "Options: Posted Entries Only", select "Include Draft Entries" - Click on "General Ledger" in the first yellow warning - Draft entries won't be included task-3928454
This fix resolves an issue where restaurant table bookings were incorrectly appearing on multiple tables when moved. Previously, when an appointment was transferred to a different table through the appointments app, the booking would still show on the original table. Now, bookings correctly display only on the current assigned table, ensuring accurate table availability in the POS system.
Original PR description
Steps: - Schedule an appointment for one table at a specific time. - Open the POS and verify the appointment. - In a separate tab, open the appointments application and transfer the appointment to a different table. - Return to the POS tab and confirm that the appointment is displayed on both tables. Issue: Both tables display scheduled appointments. Cause: Booking is not removed from the previous table. FIX: When updating an appointment to a new table, the booking is only visible on current booking table. task-3893909 Forward-Port-Of: odoo/enterprise#62020
A recent design update inadvertently removed the background color from kanban view headers within Knowledge. This fix restores the proper visual styling so that kanban group headers display with their intended background color, improving the visual consistency and usability of the Knowledge module.
Original PR description
This commit fixes an issue that was brought by the redesign of Odoo, Milk. This redesign modified a scss variable for kanban views inside of form views which removed the background of the kanban view's headers. Now a new css rule has been added to the kanban embedded view so that the background comes back to its original value inside of Knowledge. task-3930157 Forward-Port-Of: odoo/enterprise#62528
Fixed a bug in the Partner Ledger report where the "Open" and "Journal Items" buttons were not properly linked to specific partners when using the Prefix Groups Threshold feature. Previously, clicking these buttons on grouped lines would either create a new partner or cause an error. Now the buttons are correctly disabled or hidden for group summary lines.
Original PR description
# Issue:
In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback.
# Reproduce:
- Go in debug mode
- Accounting > Configuration > Accounting Report > Partner Ledger > Options
- Set Prefix Groups Threshold to 2
- Go in Accounting > Reports > Partner Ledger
- Try to open a journal items on a "Grouping Line"
# Task:
opw-3916555
Forward-Port-Of: odoo/enterprise#62360Fixed an issue where public users clicking embedded links in published knowledge articles would see no action. Now when a public user clicks an embedded link, they are redirected to log in, and after authentication, they are taken to the requested view if they have permission to access it. This improves the user experience by enabling seamless access to linked content.
Original PR description
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-Of: odoo/enterprise#57346
Fixed a broken link in the Luxembourg Balance Sheet (abridged) report that prevented users from navigating to the Profit & Loss (abridged) report. The issue was caused by incorrect data formatting in the link's configuration, which has now been corrected to allow seamless navigation between these financial reports.
Original PR description
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It should have the value 'report_id' but has 'model' and 'id' instead. This raises an error in execute_action when trying to read 'report_id' on this action. ### Solution: Remove 'model' in the context and rename 'id' to 'report_id'. opw-3912348 Forward-Port-Of: odoo/enterprise#62715
This fix ensures customers must select a shipping carrier for physical products (storable and consumable items) before they can proceed to payment. Previously, customers could attempt checkout without choosing a delivery method, which could cause issues. This improves the checkout experience by catching this requirement earlier in the process.
Original PR description
Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/enterprise/pull/60550 Forward-Port-Of: odoo/odoo#161476
This update fixes a visual alignment issue with the custom color button in the color picker tool used in the Notes application. When users select text and open the color picker to access gradient options, the custom color button now displays correctly aligned, improving the user interface appearance and usability.
Original PR description
Issue: ====== Buttons of type of custom color in colorpicker are misaligned. Steps to reproduce the issue: ============================= - Go to notes and write some text - Select some text and open colorpicker - Got to gradient and click on Custom button Before: ======  After: ====  task-3562148 Forward-Port-Of: odoo/odoo#157234
This update removes a duplicate field definition in the project task views configuration file. The duplicate "context" field was causing configuration conflicts and has been cleaned up to ensure the system operates smoothly without redundant settings.
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
Users were unable to edit badge snippets in Website edit mode because the overlay handles were blocking interactions with the snippet content. This fix adjusts the handle positioning so users can now properly edit snippet text and properties without obstruction.
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Badge" snippet into the footer. - Bug: it is not possible to edit the text of the badge or change its icon. The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles. Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this bug. Their height was changed with this commit [1]. [1]: https://github.com/odoo/odoo/commit/70f723a9f78c406746f5409f6a89cbe93ad21580 task-3927962
Fixed an issue where event time and duration information was not visible when opening a calendar event popover. The fix ensures that time details are now displayed consistently across all calendar views, including mobile view, making it easier for users to see complete event information at a glance.
Original PR description
## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDateTimeAndDuration` function of the calendar popover. opw-3829004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160907
This fix resolves a system crash that occurred when calculating the sum of sales amounts where some values were empty or null. The issue affected the sales module and prevented users from viewing customer information properly. The fix ensures the system can handle missing sales data gracefully without crashing.
Original PR description
After merge commit b5d02cc72543b36c7e5e620a3a579f15c88baed6, this error occurs: ```python RPC_ERROR Odoo Server Error Traceback (most recent call last): File "/home/odoo/src/odoo/odoo/http.py", line…
After merge commit b5d02cc72543b36c7e5e620a3a579f15c88baed6, this error occurs:
```python
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 1770, 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 1797, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 2001, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 725, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/src/odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/addons/web/models/models.py", line 86, in web_read
values_list: List[Dict] = self.read(fields_to_read, load=None)
File "/home/odoo/src/odoo/odoo/models.py", line 3540, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/odoo/models.py", line 3751, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/odoo/models.py", line 6603, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/addons/sale_timesheet/models/sale_order.py", line 52, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/addons/sale/models/sale_order.py", line 1703, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/odoo/models.py", line 4875, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/addons/sale/models/sale_order.py", line 655, in _compute_partner_credit_warning
order.partner_credit_warning = self.env['account.move']._build_credit_warning_message(
File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 1515, in _build_credit_warning_message
credit_to_invoice = partner_id.credit_to_invoice - exclude_amount
File "/home/odoo/src/odoo/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/odoo/models.py", line 4875, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/addons/sale/models/res_partner.py", line 85, in _compute_credit_to_invoice
amount_to_invoice_sum = sum(max(float(amount), 0) for amount in amount_to_invoice_agg)
File "/home/odoo/src/odoo/addons/sale/models/res_partner.py", line 85, in <genexpr>
amount_to_invoice_sum = sum(max(float(amount), 0) for amount in amount_to_invoice_agg)
TypeError: float() argument must be a string or a real number, not 'NoneType'
```
Desired behavior after PR is merged:
No longer try to sum `None` values
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA test in the website forum module was failing on newer systems (Ubuntu Noble, Debian Bookworm) due to changes in how Werkzeug 3.0.1 orders routing information. The fix improves the test to be more specific about which forum routes it checks, making it work reliably regardless of the order in which routes are returned.
Original PR description
This test was not working on Debian Bookworm and Ubuntu Noble. This is probably because they use `werkzeug 3.0.1`, which seems to be ordering the routing map differently. Results in the test with…
This test was not working on Debian Bookworm and Ubuntu Noble. This is probably because they use `werkzeug 3.0.1`, which seems to be ordering the routing map differently.
Results in the test with current requirements.txt:
```
[
{'loc': '/forum/testforum-18'},
{'loc': '/forum/testforum-18/renameit-37', 'lastmod': FakeDate(2023, 5, 31)}
]
```
Results in the test with werkzeug 3.0.1 and some tweaks to be close to Noble:
```
[
{'loc': '/forum/testforum-17/renameit-35', 'lastmod': FakeDate(2023, 5, 31)},
{'loc': '/forum/testforum-17'}
]
```
You see that the forum post route is added in a different order. The code then simply crash when doing `list(locs)[1]['lastmod']`
Step to reproduce:
- Install/run python3.12
- Tweak a bit the requirements.txt
- Comment the 2 `greenlet` lines
- replace the 2 lxml lines by
```
lxml==4.6.5; python_version < '3.12' # min version = 4.5.0 (Focal - with security backports)
lxml==5.2.1; python_version >= '3.12' # (Noble - removed html clean)
lxml-html-clean; python_version >= '3.12' # (Noble - removed from lxml, unpinned for futur security patches)
```
- replace werkzeug line by `Werkzeug==3.0.1`
- Install a db with `website_forum`
- Run the `test_01_forum_sitemap` test
- It will crash:
```
Traceback (most recent call last):
File "/data/build/odoo/addons/website_forum/tests/test_sitemap.py", line 23, in test_01_forum_sitemap
self.assertEqual(list(locs)[1]['lastmod'].strftime("%Y-%m-%d"), datetime)
~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'lastmod'
```
runbot-65289This fix resolves an issue where adding components to a manufacturing order with multi-step warehouse routes caused inventory quantities to be updated multiple times, resulting in incorrect stock levels. The problem occurred because the system was processing inventory updates twice during the component confirmation process. This fix ensures inventory is updated only once, maintaining accurate stock counts.
Original PR description
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing…
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing order for a product P1 with a demand of 1 x P2 - Confirm the MO (a transfer for 1 x P2 should be created). - Add a line to the MO with a demand of 1 X P2 and save. #### > the related stock picking was updated twice leading to a demand of 3 Cause of the issue: Since pbm is enabled the components are required to be in pre-Production for the manufacturing to start with. As such, our MO is associated with two stock moves. One for the local transport of components: - move_inter_1: 1 x P2 from Stock to pre-Production - move_raw_1: 1 x P2 from pre-Production to Production Saving the additional component requirement on the mo will create and confirm a second raw move: - move_raw_2: 1 x P2 from pre-Production to Production During its "_action_confirm", the procurements of this move will create and confirm a second internal move: - move_inter_2: 1 x P2 from Stock to pre-Production During the "_action_confirm" of this internal move a merging process will start since the already existing move_inter_1 is a good candidate: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1369-L1370 https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L994-L998 The quantity of move_inter_1 will then be updated: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1035 Then, the merging process of move_raw_2 will start since the already existing move_raw_1 is found as a good candidate and the quantity of this move will be updated by a "write" call. However, procurements are also run in the call of the write method unless 'no_procurement' is specified in the context: https://github.com/odoo/odoo/blob/e8f8c9b4286f60733153220511fd0e2bf33370b3/addons/mrp/models/stock_move.py#L344-L348 Since this is not the case, this will create and confirm a new internal move: - move_inter_3: 1 x P2 from Stock to pre-Production This move will also be merged to move_inter_1 (this is the second update). ### Fix: Since procurements will always be run by the "_action_confirm" of the related stock moves, we can safely skip the procurements run by the write method during this flow. opw-3880686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163808
This fix resolves an issue where GIFs were appearing twice in the favorites category when only one was selected. The problem occurred because the system was loading the same GIF twice - once when displaying favorites and again when opening the category. This update ensures each favorite GIF appears only once as intended.
Original PR description
STEP TO REPRODUCE: -Add gif api key -Go to a channel and choose any gif to be favorite -Then go to favorites category and we will the gif has been duplicate although we only choose one REASON: because we use 'this.pushGif(gif);' 2 time first when loading favorites gif and second is open 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 ensures that shipping costs are recalculated correctly when you change the quantity of items in an order. Previously, the system would not update the package weight after a shipping method was applied, even if you modified the order quantities. Now, the weight is automatically recalculated each time you update the shipping cost, ensuring accurate shipping fees based on the current order contents.
Original PR description
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odoo/odoo/blob/17.0/addons/delivery/models/sale_order.py#L139 since we can edit the quantity of the order lines then there is not point of not calculating the estimated weight each time. **Desired behavior after PR is merged:** With removing this condition the weight will get updated each time we open the shipping cost wizard. opw-3908453 Forward-Port-Of: odoo/odoo#165838 Forward-Port-Of: odoo/odoo#164928
This update fixes a test in the CRM module to ensure it works correctly regardless of demo data. The test was being affected by demo leads that impacted probability calculations. By cleaning up test data before running, the test now produces reliable and consistent results without interference from sample data.
Original PR description
As all won / lost leads will have an impact on the PLS frequency table, demo data will have one on the probabilities of leads without team_id set, as their probability is based on all leads, regardless on their team. Therefore, make sure we unlink all leads that are not the ones created in the test. We rebuild the table below, which is needed to ensure we only consider test leads. Follow up of ecac497336826b66799f63c1daa0749535ce73f1 Task-3700966 Forward-Port-Of: odoo/odoo#165842 Forward-Port-Of: odoo/odoo#162414
This fix corrects an issue where PayuLatam payment redirects were going to incorrect websites when using databases with different domains. The system now properly uses the correct root URL when communicating with PayuLatam, ensuring customers are redirected to the right location after payment processing.
Original PR description
Before this commit, the root URL of the request was not sent to PayuLatam, leading to redirection to an incorrect website when databases with a different domain were set. To use the url_root, get_base_url must be called from the payment.acquirer instance. opw-3348291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165252 Forward-Port-Of: odoo/odoo#165092
This fix allows credit notes to be confirmed and submitted to ZATCA (Saudi Arabia's tax authority) even when they are not linked to an existing invoice, as long as they have a valid Customer Reference. Previously, credit notes could only be processed if they were created from existing invoices, which limited flexibility for users who needed to issue standalone credit notes.
Original PR description
Previously, only credit notes created from existing Invoices were allowed to be posted & sent to ZATCA. Now, as long as a credit/debit note has a Customer Reference (ref), the system will allow it to be confirmed and submitted Description of the issue/feature this PR addresses: Users are not allowed to confirm/submit Credit Notes if they are not linked to an existing Invoice Current behavior before PR: Upon confirmation/posting of a Credit Note, if it is not linked to an existing Invoice or does not have a Customer Reference, the system blocks the confirmation Desired behavior after PR is merged: As long as a credit note is linked to an existing Invoice or has a valid Custoemr Reference (ref) the system allows it to be confirmed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166102
This update fixes a test that was failing on Ubuntu 24.04 due to a bug in the Werkzeug library version shipped with that operating system. The test has been adapted to handle this specific issue without affecting normal system behavior. The underlying Werkzeug bug is already fixed in newer versions.
Original PR description
The brand new Ubuntu Noble 24.04 ships python3-werkzeug 3.0.1. This versions has a bug [0] which leads to this test failing as double slashes get fixed by werkzeug even though `merge_slashes` parameter is set to False by default in Odoo. This should not have a big impact on real life but the test should be kept to ensure that the actual behavior of a 404 is not broken outside of Ubuntu Noble. So, with this commit, if the impacted version of werkzeug is used the test will not fail with a fixed url and a redirect response. The issue that exists from 2.2.0 up to 3.0.1 is fixed upstream [1] in 3.0.2. A bug report was filled in Ubuntu [2] (Debian is not impacted) [0]: https://github.com/pallets/werkzeug/issues/2834 [1]: https://github.com/pallets/werkzeug/pull/2860 [2]: https://bugs.launchpad.net/ubuntu/+source/python-werkzeug/+bug/2066041 Forward-Port-Of: odoo/odoo#165998
This fix resolves a bug in the web editor where text selection would incorrectly jump back to the start of a paragraph after clicking on text in a new line created with Shift+Enter. The issue was caused by a previous change that didn't account for this specific scenario. The fix properly positions the cursor relative to its parent element, ensuring selections remain where users expect them to be.
Original PR description
commit that introduced the issue: [1] Steps to reproduce the issue: ============================= - Go to to-do - Add some text - Click shift+enter at the end of the first line - Add some text in the second line - Select a prefix of the second line - Click any character - The selection is back at the start of the paragraph Origin of the issue: ==================== This was done intentionally by the mentioned commit which didn't take into consideration this case. Solution: ========= We set the curosr at the element index relative to its parent. opw-3829462 [1]: https://github.com/odoo/odoo/commit/06658ff13abfbdaeb7c562b8fd33fc9cf4f56f95 Forward-Port-Of: odoo/odoo#164509