Current behavior: --- When logged as a mass mailing user, in a mailing, using the editor, when applying a shape to an image, the image disappears. Steps to reproduce: --- 1. Make sure Marc Demo has the role User 2. Log in as Marc Demo 3. Create a new mailing 4. Select a template 5. Insert a picture 6. Select the picture 7. Change its shape to round 8. (preview works fine) 9. Save the mailing 10. Picture disappears Cause of the issue: --- When applying a shape to an image,

Current behavior:
---
When logged as a mass mailing user, in a mailing, using the editor, 
when applying a shape to an image, the image disappears.

Steps to reproduce:
---
1. Make sure Marc Demo has the role User
2. Log in as Marc Demo
3. Create a new mailing
4. Select a template
5. Insert a picture
6. Select the picture
7. Change its shape to round
8. (preview works fine)
9. Save the mailing
10. Picture disappears

Cause of the issue:
---
When applying a shape to an image, the resulting file is of mimetype 'image/svg+xml', 
when sending it to the server, the attachment is going to go through _check_contents https://github.com/odoo/odoo/blob/d752abb24d9b25bb6d10e411961447c8c8e28bba/odoo/addons/base/models/ir_attachment.py#L364 and if the mimetype is "xml_like", it will check for views write rights, 
without what the mimetype will be forced to text/plain. 

But in web_editor, when computing the image src
https://github.com/odoo/odoo/blob/b6392e2c7dbc8e1ece326e28a9698801142714b7/addons/web_editor/models/ir_attachment.py#L34 if the mimetype is not a supported image type, src will be False.

Fix:
---
Override of _writeShape to use canvas to convert the image from svg to png.

opw-3672798

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

Forward-Port-Of: odoo/odoo#164703
Forward-Port-Of: odoo/odoo#159497

PURPOSE Fix various issues related to automatic source creation and naming involving auto increment to avoid uniqueness constraint issues. Notably * avoid always incrementing (e.g. same name should not increment); * do not fail to start counters at 0 when possible; * improve write / batch bad support; * correctly check uniqueness in utm.source.mixin currently done on wrong model; * fill holes in counter sequence instead of continuing above higher found counter;

PURPOSE

Fix various issues related to automatic source creation and naming involving
auto increment to avoid uniqueness constraint issues.

Notably
  * avoid always incrementing (e.g. same name should not increment);
  * do not fail to start counters at 0 when possible;
  * improve write / batch bad support;
  * correctly check uniqueness in utm.source.mixin currently done on wrong
    model;
  * fill holes in counter sequence instead of continuing above higher found
    counter;

See sub commits for more details.

LINKS

Task-3874538 (odoo/odoo#162229) Do not create endless copies
Task-3837272 (odoo/odoo#159699) Incorrect UTM source enumeration

Forward-Port-Of: odoo/odoo#168439
Forward-Port-Of: odoo/odoo#164287

Current behavior before PR: - Cannot select projects with `company_id` = `False` when creating sale orders.  Desired behavior after PR is merged: - Allow to select projects with `company_id` = `False`.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port

Current behavior before PR:
- Cannot select projects with `company_id` = `False` when creating sale orders.
![image](https://github.com/odoo/odoo/assets/45560757/2981d705-4a8b-4b3a-b16f-87e5f3cd6282)

Desired behavior after PR is merged:
- Allow to select projects with `company_id` = `False`.
![image](https://github.com/odoo/odoo/assets/45560757/ebeaa02d-fc4c-4939-9fb5-848cdd2de18e)


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

Forward-Port-Of: odoo/odoo#167144

prior this PR, when a user selects an option from the HSN autocomplete widget using the keyboard, the selected value is not reflected in the input field. Technical Reason: The `onSelect()` method in the HSN autocomplete widget calls `this.props.record.update()`, followed by a call to `commitChanges()` in `input_field_hook.js` due to the `keydown` event. Consequently, the update method is called twice: first with the selected option value and then with the user's typed input value. This

prior this PR, when a user selects an option from the HSN autocomplete
widget using the keyboard, the selected value is not reflected in the input
field.

Technical Reason:
The `onSelect()` method in the HSN autocomplete widget calls `this.props.record.update()`,
followed by a call to `commitChanges()` in `input_field_hook.js` due to the `keydown` event.
Consequently, the update method is called twice: first with the selected option value and
then with the user's typed input value. This sequence results in the input field displaying
the typed value instead of the selected option.

With this PR, selecting an option from the HSN autocomplete widget using the
keyboard correctly updates the input field with the selected value.

task-3961406

Forward-Port-Of: odoo/odoo#167501

With the update of ace to 1.32.3, the lib is formatting her cells by getting them with hardcoded position in a array (here: 0, 1 and 2). On our side we are adding our o_info as first element, so the lib returns a traceback because her elements are shifted. After this commit, our info node is added after the lib nodes to not shift the all bunch. runbot issue 55085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168

With the update of ace to 1.32.3, the lib is formatting her cells by getting them with hardcoded position in a array (here: 0, 1 and 2). On our side we are adding our o_info as first element, so the lib returns a traceback because her elements are shifted.

After this commit, our info node is added after the lib nodes to not shift the all bunch.

runbot issue 55085



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

Forward-Port-Of: odoo/odoo#168264

**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field of the respective purchase order line. **Expected behavior:** These values will be synchronized. **Steps to reproduce:** 1. Make a purchase order with a following combination: A) `picking_type = receipt` `product cost_method != standard` B) `picking_type = dropship`

**Current behavior:**
Depending on the created picking type and product costing
method, unlocking a validated picking and changing the quantity
field of a move will not update the qty_received field of the
respective purchase order line.

**Expected behavior:**
These values will be synchronized.

**Steps to reproduce:**
1. Make a purchase order with a following combination:
    A) `picking_type = receipt`
       `product cost_method != standard`

    B) `picking_type = dropship`
       (product cost_method is arbitrary)

2. Confirm the order, validate the picking

3. Unlock the picking and change the quantity value of the stock
     move

4. Observe that the purchase order's qty_received value does not
     change

**Cause of the issue:**
In the case of the receipt picking type, when creating a stock
valuation layer for the related move with a 'standard' product
costing method we do not call `_get_price_unit()`. This method
will compute the qty_received value of a purchase order line.
After we unlock the picking and change the move quantity, this
field will not be recomputed (because it is stored). Thus, it is
not updated.

The dropship case is similar, except in the creation of a
dropship SVL, `_get_price_unit()` is called before checking the
product's cost method- so the bug always occurs.

**Fix:**
Make the purchase order line's qty_received field depend on it's
stock moves' quantities.

Reorder the conditional in the dropship SVL creation so it
matches that of the incoming SVL creation- this is for
improving consistency rather than a necessary modification for
the fix.

opw-3863510

Forward-Port-Of: odoo/odoo#166366

Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations. The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed. Impacted branches: `17.0` and `master` Steps to reproduce: 1. Go to the

Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations.

The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed.

Impacted branches:

`17.0` and `master`

Steps to reproduce:

 1. Go to the Technical menu -> Fields and select a monetary type field
 2. Try to update the Field Label or any field translation

Current behavior:

The editing is blocked by the required 'Currency field'.

Expected behavior:

Allow editing the form view or the related translations.

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

Forward-Port-Of: odoo/odoo#168504

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022`

Before the present commit, the tests were surprisingly expecting the wrong result.

An attempt was made [1] to fix the upstream issue but was never merged.

In the meanwhile, Debian reverted the Babel issue 621 [2] in their package.

It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib.

So, this commit mitigate the issue by guessing the expected value even if the result is wrong.

[0]: https://github.com/python-babel/babel/pull/621
[1]: https://github.com/python-babel/babel/pull/887
[2]: https://sources.debian.org/patches/python-babel/2.10.3-1/



For reference (from @Xavier-Do )

Pip version and Jammy
```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2022'
```

It looks like the week year used is actually not localized, adding a cornercase on Sunday

Noble version

```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2023'
```

Forward-Port-Of: odoo/odoo#168132

We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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 Forward-Port-Of: odoo/odoo#144139

We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo.

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

Forward-Port-Of: odoo/odoo#144139

-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step, the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done -Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/b

-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step,
the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done

-Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/res_company.py#L336-L338

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

Forward-Port-Of: odoo/odoo#167941

Problem: Combo product can have a price that is not the expected one Steps to reproduce: - Install "Point of Sale" app - Go to POS settings and go to the Tax settings - In the tab "Advanced Options", check "Included in Price" - Create a product of type "Combo", set the price to $7.00 - Add 3 combo choices with products prices as $7.00, $2.50 and $1.50 with no extra price - In the shop, sell this combo - The total price is $6.99 rather than $7.00 Cause: The condition supposed to fi

Problem:
Combo product can have a price that is not the expected one

Steps to reproduce:
- Install "Point of Sale" app
- Go to POS settings and go to the Tax settings
- In the tab "Advanced Options", check "Included in Price"
- Create a product of type "Combo", set the price to $7.00
- Add 3 combo choices with products prices as $7.00, $2.50 and $1.50 with no extra price
- In the shop, sell this combo
- The total price is $6.99 rather than $7.00

Cause:
The condition supposed to fill the remaining price in the last orderline was always false

opw-3897431



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

Forward-Port-Of: odoo/odoo#167472

Currently administrators for the POS app don't see margins and costs when the setting is disabled. The setting should only affect simple POS users and admins should always see the margins and costs. Steps to reproduce: ------------------- * Connect as admin * Go to the current user settings and make sure he is a POS administrator * Go the **Point of Sale** App * Go to setting, make sure **Margins and Costs** is disabled * Open a shop session * Select the information icon on a product

Currently administrators for the POS app don't see margins and costs when the setting is disabled. The setting should only affect simple POS users and admins should always see the margins and costs.

Steps to reproduce:
-------------------
* Connect as admin
* Go to the current user settings and make sure he is a POS administrator
* Go the **Point of Sale** App
* Go to setting, make sure **Margins and Costs** is disabled
* Open a shop session
* Select the information icon on a product
> Margins and Costs are not shown

Why the fix:
------------
Data loaded is different since using the new relational model https://github.com/odoo/odoo/commit/28b7d698be8255f933ba5314e44e7059746fc234

opw-3897694

Forward-Port-Of: odoo/odoo#166294

Issue: ------ The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account. For example: - monday morning: duration = 0.4 - monday afternoon: duration = 0.4 allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81 Note: It's strange to round up to the sixteenth of an 8-hou

Issue:
------
The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account.

For example:
- monday morning: duration = 0.4
- monday afternoon: duration = 0.4

allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81

Note:
It's strange to round up to the sixteenth of an 8-hour day. It makes sense to have half-hour intervals, but it is does not work correctly with calendars that differ from the standard 8-hour calendar.

opw-3957459

Forward-Port-Of: odoo/odoo#168517

Currently, when buying products with variants the attribute values are not reflected on the backend order. Steps to reproduce: ------------------- * Go to the **Point of Sale** app * Open a shop session * Make an order for the product `Desk Organizer` * Select any option from the product configuration popup * Pay and Validate the order * Go in the backend * Navigate to **Orders** * Select the last order > Observation: Selected options for the product are not reflected Why the fix

Currently, when buying products with variants the attribute values are not reflected on the backend order.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** app
* Open a shop session
* Make an order for the product `Desk Organizer`
* Select any option from the product configuration popup
* Pay and Validate the order
* Go in the backend
* Navigate to **Orders**
* Select the last order
> Observation: Selected options for the product are not reflected

Why the fix:
------------
The function `set_full_product_name()` was changed with https://github.com/odoo/odoo/commit/672c853ab7d77ac1cebd2f4d16bd98fc454b2d55

It basically changed the behavior to set the `full_product_name` to `display_name` where it was previously computed with the attribute values.

The fix is based on the fix made for the `pos_retaurant` module. https://github.com/odoo/odoo/commit/3b6455eb979078354e3b1009a354ca7010e5fec9

This will re-introduce a feature removed from the first commit mentioned which is to show the attribute values in full name of the product. This has already been re-introduced in later versions

https://github.com/odoo/odoo/blob/8e00b5337a2ee30e667b0b2e6ff26b7df9fef2e3/addons/point_of_sale/static/src/app/store/models.js#L315-L320

This is in sass-17.2

opw-3950366

Forward-Port-Of: odoo/odoo#168697
Forward-Port-Of: odoo/odoo#168121

Steps: - Create a quotation template with 2+ products and optional products. - Create a new quotation using the template. - Add an optional product from the template. Issue: - Optional product is not added at the end of the quotation. Cause: - Optional product sequence defaults to 10 instead of continuing the sequence. Fix: - Adjust the sequence of added optional products in add_order_button to be the max sequence + 1. opw-3932966 I confirm I have signed the CLA and read the P

Steps:
- Create a quotation template with 2+ products and optional products.
- Create a new quotation using the template.
- Add an optional product from the template.

Issue:
- Optional product is not added at the end of the quotation.

Cause:
- Optional product sequence defaults to 10 instead of continuing the sequence.

Fix:
- Adjust the sequence of added optional products in add_order_button to be the max sequence + 1.

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

Forward-Port-Of: odoo/odoo#168311

Steps: - Install Ecom. - Buy a product without login and set different address for billing and shipping. Issue: - SO email sent to both billing and shipping emails it should only be sent to billing (main address). Cause: - In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails. Fix: - Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal

Steps:
- Install Ecom.
- Buy a product without login and set different address for billing and shipping.

Issue:
- SO email sent to both billing and shipping emails it should only be sent to billing (main address).

Cause:
- In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails.

Fix:
- Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal Sales flow.

opw-3714686

Forward-Port-Of: odoo/odoo#168259

## Description As an internal user one has access to many timesheets as if from the backend. If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of reco

## Description
As an internal user one has access to many timesheets as if from the backend.
If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of records, this leads to an Memory Error (OOM).

## Benchmark
On a database with over 4+M of timesheets matching the domain:
|        | Before    | After |
|--------|-----------|-------|
| Timing | N/A (OOM) | 0.7s  |

## Reference
task-3977971

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

Forward-Port-Of: odoo/odoo#168549

### Issue: When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal. The same thing happens with Vendor Bills when the firm setting is activated. ### Steps to reproduce: - In Set

### Issue:
When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal.

The same thing happens with Vendor Bills when the firm setting is activated.

### Steps to reproduce:
- In Settings > Accounting > 'Accounting Firms Mode' select "Customer Invoices and Vendor Bills"
- In Accounting > Customers > Invoices create a new Invoice
- Choose a name, for example 'INV234' and a journal
- Save the record
- Change the journal
- When saving a popup indicates it is impossible to change the journal when a sequence number is assigned

### Cause:
When not in firm mode the invoice can't be filled (displays as Draft) and will be generated from the previous invoice name (In fact the user can only modify the name of the first invoice created in the journal, not the next ones). With the firm mode activated, the user can always modify the name of the draft invoice, giving it a sequence number. Then when changing the journal, it is blocked because the user is not supposed to change the journal of an invoice with a sequence number greater than 1. The check: https://github.com/odoo/odoo/blame/16.0/addons/account/models/account_move.py#L2303

### Solution:
Modify the condition of the UserError so that it is not triggered when the 'Firm Mode' is active.

opw-3925402

Forward-Port-Of: odoo/odoo#168319

As the selection badge is not checking if a badge is selected to set the value, when clicking to a badge that is selected yet, is updating the value to itself, so the value does not change.  By checking if the badge is trying to assign the same value, we can set the badge to false.  cc @Te

As the selection badge is not checking if a badge is selected to set the value, when clicking to a badge that is selected yet, is updating the value to itself, so the value does not change.
![badge not working](https://github.com/odoo/odoo/assets/35952655/a9bad8fe-9e5d-42d0-90ac-30e175a999c4)

By checking if the badge is trying to assign the same value, we can set the badge to false.
![badge working](https://github.com/odoo/odoo/assets/35952655/1b55e7e2-bd25-4210-ac25-146c8decbc18)

cc @Tecnativa

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

Forward-Port-Of: odoo/odoo#167191
Forward-Port-Of: odoo/odoo#140544

Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode. This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode. task-3754159 Part of task-3575827 | Before | After | |--------|--------| |  | ![Capture d’éc

Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode.

This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode.

task-3754159
Part of task-3575827

| Before | After |
|--------|--------|
| ![image](https://github.com/odoo/odoo/assets/80679690/62476368-c3cd-4652-a8a4-19afc09631a1) | ![Capture d’écran 2024-02-21 à 11 40 56](https://github.com/odoo/odoo/assets/80679690/62b8cd53-4f4e-4f41-9b93-803b83e49d7d) |
| ![image](https://github.com/odoo/odoo/assets/80679690/274fb188-5779-4259-9681-ae7eb402b842) | ![Capture d’écran 2024-02-21 à 11 41 46](https://github.com/odoo/odoo/assets/80679690/35148fb7-1eea-49f1-b5b0-7aff46593a99) |
| ![Capture d’écran 2024-02-21 à 11 42 51](https://github.com/odoo/odoo/assets/80679690/536f6b4e-bff2-4ecb-963d-72c9acc78a59) |  ![Capture d’écran 2024-02-21 à 11 43 24](https://github.com/odoo/odoo/assets/80679690/3d2c3b20-b49b-4cb0-98e6-4c655778bd3d) |
| ![Capture d’écran 2024-02-22 à 08 39 12](https://github.com/odoo/odoo/assets/80679690/f91f0375-4768-4929-a89a-60152ead96a6) | ![Capture d’écran 2024-02-22 à 08 38 17](https://github.com/odoo/odoo/assets/80679690/daf670c1-86b6-4e2a-bfb6-dfceb4de6de5) |


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

Forward-Port-Of: odoo/odoo#154856

The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language. opw-3976888 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 Forward-Port-Of: odoo/odoo#168567 Forward-Port-Of: odoo/odoo#168482

The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language.

opw-3976888

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

Forward-Port-Of: odoo/odoo#168567
Forward-Port-Of: odoo/odoo#168482

When the user performs a mass produce, the generated serial numbers will only be created if they do not already exist in the database Forward-Port-Of: odoo/odoo#168141

When the user performs a mass produce, the generated serial
numbers will only be created if they do not already exist in
the database

Forward-Port-Of: odoo/odoo#168141

Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry. This fix adds the missing inverse command. OWP: 3966053 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168744

Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry.

This fix adds the missing inverse command.

OWP: 3966053





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

Forward-Port-Of: odoo/odoo#168744

Steps to reproduce: - Install eCommerce and `l10n_be` (to get a second company) - Enable online payment in the settings - Go to the payment provider and duplicate it for belgium company - Publish the payment provider - Make an invoice for a customer - Send or generate the link - Open the link in incognito - Pay the invoice Issues: When we create the `temp_move` we don't provide the `company_id` as such we will go in the compute which will fail. https://github.com/odoo/odoo/blob/f1

Steps to reproduce:
- Install eCommerce and `l10n_be` (to get a second company)
- Enable online payment in the settings
- Go to the payment provider and duplicate it for belgium company
- Publish the payment provider
- Make an invoice for a customer
- Send or generate the link
- Open the link in incognito
- Pay the invoice

Issues:
When we create the `temp_move` we don't provide the `company_id` as such we will go in the compute which will fail.

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_journal.py#L363

https://github.com/odoo/odoo/blob/17d85347f92d813704d3f8faef366166bbbaa730/addons/account/models/account_move.py#L693

In this line we call the `_accessible_branches` method on the belgium company as expected, in this method we use `self.env.companies` (default company) and we do an intersection with the current company (belgium).
This results in an empty recordset for the company.

Later in the stock we face this instruction which ends up in an empty recordset error as we have an ensure one at the beggining of `_get_violated_lock_dates`.

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_move.py#L4394

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/company.py#L370

Website solve it by copying the `public_user` and affecting it to the desired company.

https://github.com/odoo/odoo/blob/9079b7038754ca4fe547086d3fe8947a4bb6ddce/addons/website/models/res_company.py#L43-L57

A potential approach to solve this problem could be to allow `public_user` to access all of the companies (possibly problematic w.r.t. security).

The solution chosen for this PR is a local solution as it makes more sense for stable.

opw-3859791

Forward-Port-Of: odoo/odoo#162058

Helpdesk dashboards and reports now use clearer wording for time, SLA, and rating measures, making the figures easier for business users to interpret consistently. Kanban progress bars also show plain status labels like in progress, ready, and blocked instead of relying on color names.

-* = helpdesk_timesheet
After this merge:

- Display in progress/ready/blocked in the Kanban progress bar instead of grey/green/red.

- Unify the labels of the measures in all tickets, tickets analysis, and SLA analysis as per below:

    hours spent -> hours spent (timesheets)
    hours to assign -> working hours to assign
    hours to close -> working hours to close
    hours to respond -> average hours to respond
    hours until SLA deadline / working hours to reach SLA -> working hours
    until SLA deadline
    rating (/5) -> rating (1-5)

task-3827128

The Belgian payroll setup now stores the fiscal voluntarism rate on the employee record instead of each contract. This makes the rate easier to manage consistently when an employee has contract changes, reducing duplicate updates and improving payroll data reliability.

This will move the fiscal voluntarism rate from the contract to the employee.

Task: 3877405

Administrators can now set default follower subscription preferences from the activity wizard. These defaults apply to new followers and new records for the same model, helping teams keep future notifications consistent without changing existing records.

From the activity wizard: "Default subscription"
    1. "Edit default subscription" as action, after "Add follower";
    2. Should be available with admin rights for the model;
    3. This default subscription should apply to all new followers,
        not existing ones;
    4. This default subscription should apply to all records of the same
        model;
    5. Need a pop-up to confirm the action;
From the activity wizard:
    1. Toggle to apply the selection to all records of the same model;
    2. Should be applied to new records only, not existing ones;

task-3954970

The map view has been improved to handle grouping operations gracefully. Previously, when users attempted to group records by a property in the map view, the system would crash. Now, the grouping feature is disabled in the map view (similar to how it works in the gantt view), preventing errors and providing a better user experience.

Purpose
=======
Do not crash when grouping by a property, instead we want to disable the group by like it has been done for the gantt view.

Clean a test about the group by in the gantt view.

Task-3876726

Customers can now edit optional products on their active subscriptions (in progress, paused, or churned) when their recurring plan allows renewals or product additions. Previously, the optional products tab was hidden after subscription confirmation, preventing customers from making changes to optional items even though they could add them during renewal or upsell processes.

Before this commit, when recurring plan allow customer to renew or add product then  customer can create upsell or renew subscription from portal and they can add or remove product which are added as optional product in subscription and in upsell or renew quotation optional products from parent subscription are copied in new quotation. optional product tab is getting hidden from user when subscription is confirmed so user will not able to edit optional product value anymore.

after this commit, make optional product tab visible to user when subscription is 'in progress', 'paused' or 'churned' state and recurring plan allow customer to renew or add product so user will able to edit optional products for subscription.

task-3858850