This fixes an issue where saving an inventory receipt could fail after users entered lot numbers in detailed operations. The change prevents receipts from getting out of sync, so users can save and validate tracked products without missing-lot errors.

Steps
---
* install stock
* create product P, and Q tracked by lot
* create a receipt for 1 P and 1 Q > *Mark as Todo*
* go to the detailed ops for the P move (list icon on the right of the lines)
* set the lot name to 001 > *Save*
* repeat for the Q move, set the lot name to 002
* Try to save the picking 
  * => **clicking the cloud save icon does nothing**
* Try to Validate 
  * => Traceback: missing lot for the Q move

Cause
---
We try to save the picking when it is dirty when opening the move lines This will create new datapoints corresponding to the backend data, and but the datapoints linked to the inputs are still the old ones so we become out of sync

opw-4107258

Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo

Steps to reproduce:
- Switch the user language to arabic
- Go to CRM
- Insert the CRM lead pivot in spreadsheet => the values are in #ERROR

The reason is that `toFormat` returns the date with arabic numbers,
which can't be parsed by the spreadsheet engine.

Similartly, we have to tell `.fromFormat` to parse the string
using latn numbering system.


Task: 4102957


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176039

**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they

**Current behavior:**
In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated.

**Expected behavior:**
The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they are being created with respect to.

**Steps to reproduce:**
1. Create a component_product such that: - is storable - category has automated valuation and avg cost method - has the `dropship subcontractor on order` route - has some vendor

2. Create a final_product such that: - is storable - category has automated valuation and avg cost method - invoice policy is on quantity delivered - has a subcontract bom that consumes some quantity of component_product - has a subcontractor vendor

3. Create a sale order for >1 of the final_product, set the route on order line to dropship, confirm the SO and the PO which is generated

4. In the dropship transfer, set the quantity to half the demand and validate -> generate the backorder

5. On the SO, create an invoice for the completed quantity and confirm it

6. Complete the rest of the order in the backordered dropship transfer and create and confirm another invoice on the SO

7. Go to the SVL tree view and observe that the latest SVL is ~2x (before the compensatory SVL difference is applied)

**Cause of the issue:**
When the SVL is created, its value is calculated by taking the difference of subcontract SVL(s) values and dropship SVL(s) values. The subcontract SVLs come from the `move_orig_ids` of the current SVL's move.

When the sequence is broken up by backorders, these moves are still used in the calculation for the value of future SVLs. This results in the inaccuracy.

**Fix:**
Only use SVLs from the move in the current move's
`move_orig_ids` which has the maximum `backorder_sequence`.

opw-4078510

Forward-Port-Of: odoo/odoo#176958
Forward-Port-Of: odoo/odoo#176163

[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894

[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website.

The test was always failing, but we didn't catch it before as we were not testing said module.
 



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176007
Forward-Port-Of: odoo/odoo#175894

before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215

before this commit:
When the user removes the end date and then selects a new date, that date is
update the start date.

after this commit:
When the user removes the end date and then selects a new date, that date should
update the end date.

Task-3899581

Forward-Port-Of: odoo/odoo#171215

Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209

Steps to reproduce:
- Download french accouning localization module
- Switch company to 'FR Company'
- Invoicing > Customers > Invoice > New
- Fill in a product
- Confirm > Gear > Print > Invoice

It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture).

opw-4089199

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176209

Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavi

Description of the issue/feature this PR addresses:

Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict.

In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method.

This fix simply makes all the upstream context pass through.

Current behavior before PR:

Calls to methods that have `_compute_translated_display_name` somewhere in the call stack will not see the context that they have been originally given.

Desired behavior after PR is merged:

All methods will see the context that they have been given at the call



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#170682
Forward-Port-Of: odoo/odoo#170050

Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p

Description of the issue/feature this PR addresses:
This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation.

Current behavior before PR:
Unable to inherit properly to change the selection of the seller, and have the correct price

Desired behavior after PR is merged:
Can change the parameter of _select_seller before price computation


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176943
Forward-Port-Of: odoo/odoo#170021

When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - G

When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted.
One form where all fields can be deleted is the extra info step in eCommerce.

This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form.

Steps to reproduce:
- Install eCommerce.
- In Settings/Website, enable the extra info step.
- Go in shop, add a product to the cart and proceed until you reach the extra info step.
- Edit the extra info page.
- Remove all form fields.
- Add a field to the form.

=> An error dialog was displayed.

opw-4102127

Forward-Port-Of: odoo/odoo#176559

`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023

`Other income` and `Other income previous years` are obviously income accounts and not expense accounts.

Forward-Port-Of: odoo/odoo#176629
Forward-Port-Of: odoo/odoo#175023

Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data. Here is traceback: ``` File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data need_refresh = request.env.user.sudo()._syn

Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data.

Here is traceback:
```
  File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data
    need_refresh = request.env.user.sudo()._sync_google_calendar(GoogleCal)
  File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 73, in _sync_google_calendar
    synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
  File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 197, in _sync_google2odoo
    odoo_record.with_context(context)._write_from_google(gevent, vals)
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in _write_from_google
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in <genexpr>
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
KeyError: 'start'
```

opw-4100958

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176634

**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes

**Issue:**
When several invoices are selected and sent via "Send & print"
action, it happens that some invoices are sent several times.
It seems to be caused by a serialization failure on an invoice
in "_compute_debit_credit" when a concurrent write operation is
executed on an invoice being sent.
This serialization failure cause a retry on the batch being sent,
resulting on the invoice to be re-sent.

**Cause:**
"Send & print" action triggers "_compute_debit_credit" method that
writes on debit and credit fields.
The values are generally the same, so no write is really performed.
However, for some values (e.g. 14.79), there is a floating point
issue (i.e. 14.790000000000001) and the "get_records_different_from"
method considers the record as different and triggeres an actual
write.

**Solution:**
In "get_records_different_from" method, for monetary fields, apply
the same rounding to the current value than the one applied when the
value is converted to cache.

opw-3773287




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#176218

[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987

[FIX] website_sale_slides: scale down big num price

Before this commit price had h2 class always. With this commit
if price is longer than 10 digits we'll use smaller heading. 

[Reproduce]
- Install website_sale_slides
- Have a course:
	- "Enroll Policy": "On Payment"
	- It's related product's price has more than 10 digits
	- You not enrolled in it yet
- Open course page -> UX BUG: price overflows

opw-4075034

Forward-Port-Of: odoo/odoo#176754
Forward-Port-Of: odoo/odoo#175987

@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538

@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977

Thanks



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#120538