This fix improves the readability of Gantt progress bars when warnings are shown. Hours and line names now display clearly without overlapping, making schedule information easier to review.

Currently, when a warning is displayed on the progress bar, the hours overlap with the name of the line. This PR will fix it by adding the class 'bg-view' to the span.

task-3888502

Commit 1: [FIX] website: use em unit for vertical padding of highlighted text The padding was defined in pixels, thus adding a small padding on highlighted titles (wanted design) but an apparently big one on highlighted paragraphs (unwanted design). Using em unit makes more sense: this commit chooses the values so that the padding of highlighted h2 titles in the default Odoo theme is unchanged. You will thus get a slightly bigger one for highlighted h1

Commit 1:

    [FIX] website: use em unit for vertical padding of highlighted text
    
    The padding was defined in pixels, thus adding a small padding on
    highlighted titles (wanted design) but an apparently big one on
    highlighted paragraphs (unwanted design). Using em unit makes more
    sense: this commit chooses the values so that the padding of highlighted
    h2 titles in the default Odoo theme is unchanged. You will thus get a
    slightly bigger one for highlighted h1 titles and a slightly smaller one
    for highlighted smaller titles.
    This would lead to no padding for highlighted paragraphs though. While
    this might be what is wanted (most document editing software do not add
    any padding) it was decided to keep a minimal value as a compromise.
    
    Related to opw-3877772

Commit 2:

    [FIX] website: remove highlighted text horizontal padding
    
    Not adding any horizontal padding is important as it ensures that
    several features work (the first one is the very problematic one
    reported in the customer ticket):
    
    - Coloring a word inside a highlighted sentence -> in this case, the DOM
      is a succession of 3 <font> elements, the word one with both the
      background-color and the color.
    
    - Highlighting part of a word -> you don't want the word to be split
    
    - Even in the good cases, you might just not want the padding, to align
      the highlighted element with the general layout.
    
    => The user can still add surrounding spaces if needed anyway which is
       actually both technically and functionally intuitive.
    
opw-3877772

| Before | After |
| -------- | -------- |
| ![image](https://github.com/odoo/odoo/assets/10338094/96357e49-d3a2-40a3-98bd-a09a8f2c5311)  | ![image](https://github.com/odoo/odoo/assets/10338094/bcc536ee-8559-4502-99bf-b49e12bd08a1)  |
| Padding impossible to change + problems (the opw one is illustrated by the highlighted "what they want and give")  | Relative vertical padding + No horizontal one (you can add real spaces instead)                                                     |

Forward-Port-Of: odoo/odoo#164919

Before this commit: When you start a POS restaurant session in Chrome/Safari on iOS 15 or older devices. => It shows a blank screen and throws a `typeError` as `toSorted()` isn't supported. `toSorted()` is introduced in iOS 16. After this commit: Restaurant session screen works properly. As it's all about compatibility, This is a browser compatibility table for `toSorted()` vs. `slice()`, `sort()` (check below for reference) ![image](https://github.com/odoo/odoo/assets/163794447/82f7fd

Before this commit:
When you start a POS restaurant session in Chrome/Safari on iOS 15 or older devices.
=> It shows a blank screen and throws a `typeError` as `toSorted()` isn't supported. `toSorted()` is introduced in iOS 16.

After this commit:
Restaurant session screen works properly.

As it's all about compatibility, This is a browser compatibility table for `toSorted()` vs. `slice()`, `sort()` (check below for reference)
![image](https://github.com/odoo/odoo/assets/163794447/82f7fd68-05d9-43fd-a58d-304e0e6d2895)

Reference:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort

opw-3908355

Forward-Port-Of: odoo/odoo#165028

In an expense sheet, when an expense line is clicked on, its receipts are shown in the attachment viewer. This was broken in odoo/pull/142029 since it duplicates the attachments from the expense, leaving inconsistency between the attachment ID of the lines and the ones in the sheet. To fix this, the checksum is used instead to find which attachment in the sheet corresponds to the one in the line that was clicked on. task-3758922 Forward-Port-Of: odoo/odoo#155417

In an expense sheet, when an expense line is clicked on, its receipts are shown in the attachment viewer. This was broken in odoo/pull/142029 since it duplicates the attachments from the expense, leaving inconsistency between the attachment ID of the lines and the ones in the sheet. To fix this, the checksum is used instead to find which attachment in the sheet corresponds to the one in the line that was clicked on.

task-3758922

Forward-Port-Of: odoo/odoo#155417

To reproduce the problem: - Enable pricelist feature - Create a new Contact > no pricelist shown (all versions affected) - Save > still no pricelist shown (>= 17.0 versions affected) - Exit and go back to the Contact: the pricelist is set The _compute_product_pricelist() doesn't work properly for new record, then we create a new contact, pricelist is empty (until the save for version < 17.0, until save/exit/return on the record for version >= 17.0). In 17.0, we introduced web_save, whi

To reproduce the problem:
- Enable pricelist feature
- Create a new Contact > no pricelist shown (all versions affected)
- Save > still no pricelist shown (>= 17.0 versions affected)
- Exit and go back to the Contact: the pricelist is set

The _compute_product_pricelist() doesn't work properly for new record, then we create a new contact, pricelist is empty (until the save for version < 17.0, until save/exit/return on the record for version >= 17.0).

In 17.0, we introduced web_save, which makes create() and read() in the same request. This is why the version >= 17.0 is more problematic and more confusing for the user. Prior to 17.0, it was not great either, but was never considered a bug (some effort has been made in https://github.com/odoo/odoo/pull/153326/files). So this fix targets versions >= 17.0.

Fix the issue by taking care of new ids in the _get_partner_pricelist_multi() method. Also, add a Form test case for every possible case.

opw-3872299

Forward-Port-Of: odoo/odoo#163768

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. 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#162581

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified.

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#162581

Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts - Create an EU contact with "/" or "NA" as VAT (e.g. a Germnan contact with a full address) - Create an invoice: * Customer: [the created contact] * Product: [any] - Confirm the invoice - Process the electronic invoice - Check the generated electronic invoice Issue: In the XML, the "Nazione" field of customer is set to "/" (or "NA"), instead of th

Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts
- Create an EU contact with "/" or "NA" as VAT (e.g. a Germnan contact with a full address)
- Create an invoice:
  * Customer: [the created contact]
  * Product: [any]
- Confirm the invoice
- Process the electronic invoice
- Check the generated electronic invoice

Issue:
In the XML, the "Nazione" field of customer is set to "/" (or "NA"), instead of the code of the customer's country.

Cause:
The "Nazione" field is computed from the VAT of the customer with a fallback on customer's country.
It should be the opposite.

opw-3889051




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

Forward-Port-Of: odoo/odoo#164950

The field l10n_ae_vat_amount is not hide if the user is connected with a company in another country. For exemple, if you are connected with a BE company with the l10n_ae module installed, the field was visible. Now the field is only visible for the AE companies. task-3877935 Forward-Port-Of: odoo/odoo#163004

The field l10n_ae_vat_amount is not hide if the user is connected with a company in another country.

For exemple, if you are connected with a BE company with the l10n_ae module installed, the field was visible.

Now the field is only visible for the AE companies.

task-3877935

Forward-Port-Of: odoo/odoo#163004

Commit [1] added the support to also consider invisible dropped snippets when checking if the snippets in the right panel are droppable. In order for this status to be properly updated when showing and hiding invisible elements, the `reload_snippet_dropzones` event is now triggered in each call to `toggleTargetVisibility`. However, this function is called a lot of times when doing different operations (e.g. drag and dropping (in `buildSnippet` and `cleanForSave` functions), removing a snippet

Commit [1] added the support to also consider invisible dropped snippets when checking if the snippets in the right panel are droppable. In order for this status to be properly updated when showing and hiding invisible elements, the `reload_snippet_dropzones` event is now triggered in each call to `toggleTargetVisibility`.

However, this function is called a lot of times when doing different operations (e.g. drag and dropping (in `buildSnippet` and `cleanForSave` functions), removing a snippet, showing/hiding an invisible element), which means that `_disableUndroppableSnippets` is also called each time.

This slowed down the editor a lot:
- Drop a "Text-Image" snippet and click on it to activate it. 
=> It takes a bit long for the "Undo" arrow and the overlay to appear.
- Drag and drop one of the snippet columns.
=> It takes a while for it to be dropped and for the dropzones to disappear, while it should be instant.

It also made some tours having steps that drop snippets fail when launched in the browser console (e.g. `carousel_content_removal`). This happens because the "drop" step takes too long to complete, making the next one fail.

Also, this made the call to `_disableUndroppableSnippets` redundant in certain cases. For example, when removing a snippet: in `removeSnippet` there is a call to `toggleTargetVisibility` which will therefore call this function. At the end, it triggers the `snippet_removed` event which will call `_onSnippetRemoved` which also calls this function.

This commit therefore fixes these issues by removing the trigger from `toggleTargetVisibility` and by calling `_disableUndroppableSnippets` directly when showing/hiding invisible elements, so only when necessary.

[1]: https://github.com/odoo/odoo/commit/922b4ba13d679a237bcc43d7296ff402beacb022

task-3902277

Forward-Port-Of: odoo/odoo#164826
Forward-Port-Of: odoo/odoo#164159

[IMP] website: enable to use special characters in a form Before [1], the usage of some characters as field label inside a form led to a traceback. As explained in [1], the problem came from the selector given to the `querySelector()` method. To solve the problem, [1] encoded the problematic characters. The problem is that the backslash character was not taken into account and still led to a traceback if it was used as a field label. [2] solved the problem by adding this special character

[IMP] website: enable to use special characters in a form
Before [1], the usage of some characters as field label inside a form
led to a traceback. As explained in [1], the problem came from the
selector given to the `querySelector()` method. To solve the problem,
[1] encoded the problematic characters. The problem is that the
backslash character was not taken into account and still led to a
traceback if it was used as a field label. [2] solved the problem by
adding this special character in the list of the characters to encode.

The problem of encoding problematic terms manually is that others (still
unknown) can still be problematic and would have to be encoded in the
future. To solve the problem, it has been decided to escape the
problematic selectors with the `CSS.escape()` method, which is the right
method to promote when adding anything unknown inside a selector anyway.

[1]: https://github.com/odoo/odoo/commit/ccaf4f1e52f10308ef507059316732c02ad6e6e4
[2]: https://github.com/odoo/odoo/commit/03f230a77c0d38b46944d45b4991f48e45b275dd

task-3510450

-----------------------------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: decode special characters of website form
Steps to reproduce:
- Add a form on the website.
- Add a field and put `test"` as label.
- Save and send the form.

-> `test"` is displayed in the received mail.

Since [3] (and [4]), some characters are escaped when the user changes
the label of a field. The problem appeared since [5] where fields are
escaped on the server side upon form reception. Indeed, here is what
happens at form reception; the already escaped `test"` is stored as
`test"` in the database. Due to it, the mail displayed contains
`test"` while `test"` is wanted. To solve the problem, the
characters encoded at label change in the client side are decoded on the
server side before the form is processed. This is done at the server
side as we still encode client-side since it appears that if a form is
sent with an input that has a `"` character in its `name` attribute, it
is received as `%22` server side (see previous commit in-code comment
for details).

[3]: https://github.com/odoo/odoo/commit/ccaf4f1e52f10308ef507059316732c02ad6e6e4
[4]: https://github.com/odoo/odoo/commit/03f230a77c0d38b46944d45b4991f48e45b275dd
[5]: https://github.com/odoo/odoo/commit/db62d8c42b25b74210b4bae79200398acc4bb8de

task-3510450

Forward-Port-Of: odoo/odoo#164821
Forward-Port-Of: odoo/odoo#135797

[FIX] mrp_subcontracting: fix origin moves on backorder This commit reverts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and 7a78839ca6cf45ddec7adb59051da132e0ebceb4 The commits above try to split the origin moves during a split (backorder). However, if you create a subcontracting backorder by manipulating the stock.move.line qty_done, then it creates an issue were the production_id is not linked to the backorder. HOW TO REPRODUCE: - Create product FNS (storable) - Create subcont

[FIX] mrp_subcontracting: fix origin moves on backorder

This commit reverts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and 7a78839ca6cf45ddec7adb59051da132e0ebceb4

The commits above try to split the origin moves during a split (backorder).
However, if you create a subcontracting backorder by manipulating the stock.move.line qty_done, then it creates an issue were the production_id is not linked to the backorder.

HOW TO REPRODUCE:
- Create product FNS (storable)
- Create subcontracted BoM for FNS
- On Operation type 'Receipt', set Show Detailed Operations = True and Pre-fill Detailed Operations = True
- Create PO for 10 units of FNS -> Confirm
- Go to Receipt > Detailed operation > Set quantity = 1 > Validate (with backorder)
- Repeat step above on the created backorder

OR

- Create storable product FNS tracked by serial number
- Create subcontracting BoM, with strict consumption
- Create PO for 10 units of FNS -> Confirm
- Open detailed operation, add 2 lines with SN, confirm, Validate & create backorder
- Redo the same step with backorder receipt

---

https://github.com/odoo/odoo/assets/29302288/4c9de2b7-2a65-4e18-8a4b-c9faadf68d17

---

OPW-3838250
OPW-3812937

Forward-Port-Of: odoo/odoo#163667
Forward-Port-Of: odoo/odoo#161323

Usecase to reproduce: - Create a MO for 2 unit (1 component per finished product) - Produce 3 units - Mark as done - Unlock and change the quantity to 3 units Expected behavior: 3 components removed from stock Current behavior: 6 components removed from stock It happens because the set_quantity_done create a new stock.move.line with excessive quantity. Then the write of qty_producing in mrp.production will write this quantity on all the `stock.move.line`. It results by moving numb

Usecase to reproduce:
- Create a MO for 2 unit (1 component per finished product)
- Produce 3 units
- Mark as done
- Unlock and change the quantity to 3 units

Expected behavior:
3 components removed from stock

Current behavior:
6 components removed from stock

It happens because the set_quantity_done create a new stock.move.line with excessive quantity. Then the write of qty_producing in mrp.production will write this quantity on all the `stock.move.line`. It results by moving number of sml * the new quantity producing

Solution do the write of new quantity done on the `stock.move` level and let him manage the `stock.move.line`

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#161728
Forward-Port-Of: odoo/odoo#161650

- Allow anyone to preview the exhibitor description on events that have not started yet (not only registered people) - Fix/improve the handling of exhibitors missing a profile image or description (don't display broken images/"false") - touch up the layout of registration buttons to be more standard --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163105

- Allow anyone to preview the exhibitor description on events that have not started yet (not only registered people)
- Fix/improve the handling of exhibitors missing a profile image or description (don't display broken images/"false")
- touch up the layout of registration buttons to be more standard

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

Forward-Port-Of: odoo/odoo#163105

Before this commit, through the list view and form view, private events were being accessed by administrators who were not invited to those private events. These events should have their sensitive fields hidden. After this commit, we filter the sensitive fields from private events during read, thus uninvited administrators won't be able to read the private event's sensitive information anymore. task-3837646 Forward-Port-Of: odoo/odoo#164907 Forward-Port-Of: odoo/odoo#159913

Before this commit, through the list view and form view, private events were being accessed by administrators who were not invited to those private events. These events should have their sensitive fields hidden.

After this commit, we filter the sensitive fields from private events during read, thus uninvited administrators won't be able to read the private event's sensitive information anymore.

task-3837646

Forward-Port-Of: odoo/odoo#164907
Forward-Port-Of: odoo/odoo#159913

When emoji picker has no emojis, this means the loading of emojis failed. In that case, the screen should have its content centered. Task-3916943 Before/After <img width="303" alt="before" src="https://github.com/odoo/odoo/assets/6569390/5fb2709e-34c5-4027-ab68-cc47d97fc15b"> <img width="300" alt="after" src="https://github.com/odoo/odoo/assets/6569390/8065f4af-0200-4614-b492-63e3fa881b9d"> Forward-Port-Of: odoo/odoo#164896

When emoji picker has no emojis, this means the loading of emojis failed. In that case, the screen should have its content centered.

Task-3916943

Before/After
<img width="303" alt="before" src="https://github.com/odoo/odoo/assets/6569390/5fb2709e-34c5-4027-ab68-cc47d97fc15b"> <img width="300" alt="after" src="https://github.com/odoo/odoo/assets/6569390/8065f4af-0200-4614-b492-63e3fa881b9d">

Forward-Port-Of: odoo/odoo#164896

Problem: On the webshop product page of a product configured to display the available quantity, the quantity is displayed as a raw float, so it is sometimes shown with many digits. Note that, since the quantity is `float_round`ed python-side, often this doesn't appear. 1.4 is an quantity for which this does show. Exact steps to reproduce: * On a db with sales, webshop and inventory installed, create a product for sale * adjust the on-hand quantity to be 1.4 * set the product to displ

Problem:
On the webshop product page of a product configured to display the
available quantity, the quantity is displayed as a raw float, so it is
sometimes shown with many digits.
Note that, since the quantity is `float_round`ed python-side, often this
doesn't appear. 1.4 is an quantity for which this does show.

Exact steps to reproduce:
* On a db with sales, webshop and inventory installed, create a product
for sale
* adjust the on-hand quantity to be 1.4
* set the product to display remaining quantity on the e-shop (sales
  tab) if below x > 1.4
* go to the webshop page of the product, the remaining quantity is shown
as 1.4000...1

Desired:
The quantity is displayed as is for integers. ("usual" case)
The quantity is displayed with as many decimals as are significant,
based on the `uom_rounding`.

opw-3827850

Forward-Port-Of: odoo/odoo#164697
Forward-Port-Of: odoo/odoo#160356

Since commit[1], we have added an animation on the `DraggableHook`. However, we have used the same CSS `keyframes` name (`bounce`) as another one added[2] before by `hr_referral` module (enterprise). CSS `keyframes` can't be scoped [3] as they don't follow the cascade. So when `hr_referral` is installed the `keyframes` is override and produce some weird animation when the `DraggableHook` is used. Steps to reproduce: * Go to the HomeMenu (enterprise) on small screen * Click on a App => Bug

Since commit[1], we have  added an animation on the `DraggableHook`. However, we have used the same CSS `keyframes` name (`bounce`) as another one added[2] before by `hr_referral` module (enterprise). CSS `keyframes` can't be scoped [3] as they don't follow the cascade. So when `hr_referral` is installed the `keyframes` is override and produce some weird animation when the `DraggableHook` is used.

Steps to reproduce:
* Go to the HomeMenu (enterprise) on small screen
* Click on a App => Bug a weird animation appear before the "navigation" to the App

task-3918268

[1]: odoo/odoo@4c5cf0962f91d05085fea75e9c26ecdca9c0eb13
[2]: odoo/enterprise@08c19c4cbd1af70859cbdb49bb535927b1cbf76d
[3]: https://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes#resolving_duplicates


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

Forward-Port-Of: odoo/odoo#164914

Steps to reproduce the bug: - Create a storable product “P1”: - BoM: - Component: C1 - Workorders: OP1 and OP2 - Create a Manufacture order to produce one P1 - Confirm the MO - start the OP1 and mark it as done - start the Shop Floor from the "Work Orders" tab Problem: Operation 1 and 2 are visible, instead of only the OP2 opw-3904023 Forward-Port-Of: odoo/enterprise#62206

Steps to reproduce the bug:
- Create a storable product “P1”:
    - BoM:
        - Component: C1
        - Workorders: OP1 and OP2

- Create a Manufacture order to produce one P1
- Confirm the MO
- start the OP1 and mark it as done
- start the Shop Floor from the "Work Orders" tab

Problem:
Operation 1 and 2 are visible, instead of only the OP2

opw-3904023

Forward-Port-Of: odoo/enterprise#62206

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. Forward-Port-Of: odoo/enterprise#61137

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified.

Forward-Port-Of: odoo/enterprise#61137

When a user selects an account, but on connecting it appears there is no consent anymore, we want to show the error to the user. task-3813628 Related to https://github.com/odoo/odoofin/pull/264 Forward-Port-Of: odoo/enterprise#62046 Forward-Port-Of: odoo/enterprise#60283

When a user selects an account, but on connecting it appears there is no consent anymore, we want to show the error to the user.

task-3813628

Related to https://github.com/odoo/odoofin/pull/264

Forward-Port-Of: odoo/enterprise#62046
Forward-Port-Of: odoo/enterprise#60283

Steps to reproduce: Configure Sendcloud with a shipping product that provides customizable functionalities, and select `None` as the functionality filter. All of the shipping methods will be filtered out and we get an error message: `There's no shipping method matching all your selected filters for this picking/order.` The issue is that `'None'` is passed as a string in the list of functionalities but it is checked as `None` type. To fix the issue we check if the string exists in the fil

Steps to reproduce:
Configure Sendcloud with a shipping product that provides customizable functionalities, and select `None` as the functionality filter. All of the shipping methods will be filtered out and we get an error message:
`There's no shipping method matching all your selected filters for this picking/order.`

The issue is that `'None'` is passed as a string in the list of functionalities but it is checked as `None` type.

To fix the issue we check if the string exists in the filter.

opw-3878116

Forward-Port-Of: odoo/enterprise#61360