Steps to reproduce :

  - Install Sales
  - Modify the report, use the theme "Clean" and the font "Open Sans"
  - Modify the company phone to: +41 26 322 01 02
  - Print a quotation

Issue :

  Company phone is on 2 lines

Cause :

  CSS issue with wkhtmltopdf.

Solution :

  Replace CSS display value `inline-block` by `inline`.

ref commit: https://github.com/odoo/odoo/commit/5b022f433a44e627541d30ae21d7a867f4a3a6ff


opw-2567836

closes odoo/odoo#75515

Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

As a followup of commit odoo/odoo@06081d2e8d86ec695f68c155b882d6a15a3fce9f ,
the CSS rule `flex: 1 1 0` should also be applied to `.o_Discuss_thread`
to avoid the same kind of issue.

Steps to reproduce:
* Open Discuss
* Select History => BUG the `.o_Discuss_mobileNavbar` is not visible

closes odoo/odoo#77615

Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>

Miscellaneous entries created by POS are handled like invoices by the tax report engine. They hence differ from regular miscellaneous entries, as they don't require inverting their tag signs under any circumstances.

Before this fix, manually editing and entry from POS in such a way that the tax lines were recomputed did not take that into account, and the signs were inverted on every line, causing a sign inversion in the tax report.

OPW 2653923

[FIX] point_of_sale: also consider pos.sessions when guessing if an account.move comes from pos to compute tax_audit

In every other place doing that, both models are checked. See here, for example https://github.com/odoo/enterprise/blob/13.0/pos_account_reports/models/account_generic_tax_report.py#L14

 .

closes odoo/odoo#77510

Forward-port-of: #77363
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Not a smart line.

closes odoo/odoo#77623

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Steps to reproduce the bug:
- Create a BOM kit for “product K”  with:
    - 2 * “product A”
    - 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”

Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)

Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change

opw-2645719

closes odoo/odoo#77580

X-original-commit: 2fd87885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

The exists method (of BaseModel) doesn't work with model
without SQL table but with a table query (see
f2ceef0e)
This method is call when we try to read a forbidden
record (`forbidden = missing.exists()` in `_read`)

- Fix it by using a Query object (which able the case).
- Also use a partition method instead of duplicate it in the method.
- Fix the CRM Lead Report which can return a Falsy id

task-2633558

closes odoo/odoo#77473

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Steps to reproduce the bug:
- Install product_expiry and inventory
- Go to inventory settings and enable “Expiration date”
- Create a product with tracking by lots and an expiration date
- Set on the product category: Force Removal Strategy = FEFO
- Create a PO for the product > Receive product and set expiration date to “30/10” for LOT1
- Create another PO for LOT 2 with an expiration date set to “29/10”
- Create a sales order for this product > Go to delivery

Problem:
Lot1 will be chosen on the delivery linked to the SO while lot2 must be selected
because it has an expiration date before the lot 1

The lot is chosen based on the date defined in the removal_date field,
so this field should always be calculated when an expiration date is defined

Solution:
Set the fields ("use_date", "removal_date", "alert_date") when an expiration date is defined

opw-2613711

closes odoo/odoo#77261

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

When there is an issue updating digest state (concurrent access, or some other
error that may happen), digest emails may be sent in loop. Indeed they are
currently sent in the same transaction that the one that updates digest state.
This means that emails may be sent even if digest udpate fails.

As we do not think timing is so important, we now use the email queue to send
digest emails. That way email creation is rollbacked and they are not sent
if digest update fails for some reason.

Task-2641394

closes odoo/odoo#76591

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Description of the issue/feature this PR addresses:

Variant Product kits where not shown in delivery slips reports.

Current behavior before PR:

Variant Product kits where not shown in delivery slips reports.
Product where linked via their description to the variant name but then compared to the product template name.

Desired behavior after PR is merged:

Variant Product kits are now shown in delivery slips reports.
Solution : Compare to product name if it exist and compare to template name.

opw-2603829

closes odoo/odoo#77486

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Given that we have a viewport of 320px and, to simplify the explanation,
we discard the height of the <header> (aka. the top navbar).

Since the refactoring of Discuss [1], a global rule was added to the
'.o_action_manager' to allow the flex to shrink the discussion's list
in Discuss on Mobile.

But this rule change the box sizing of '.o_action_manager' as now it
takes the minimum size (e.g. before 3000px became now 320px +/- the
height of the viewport).
Therefore a limit for the sticky-scroll behaviour of control panel is
set at the end of the height of the element.
Then when the viewport goes outside this limit the sticky doesn't work
anymore until the viewport returns before this limit.
(e.g. <= 320px ok, > 320px ko).

The fix is to change the flex basis of the '.o_Discuss_notificationList'
to be 0 which avoids to alter the global '.o_action_manager' and scopes
rules to Discuss' specific classes.

DOM before this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager'                                ▲  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                     ELEMENT HEIGHT │  │
│                                       = 'VIEWPORT' │  │
│                                              320px │  │
│ ┌────────────────────────────────────────────────┐ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │        Control Panel                           │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ └────────────────────────────────────────────────┘ ▼  │
│ - - - - - - - - LIMIT OF STICKY ELEMENT - - - - - - - │ <- 320px
│                                                    ▲  │
│                                                    │  │
│                                        OVERFLOW    │  │
│                                        VISIBLE     │  │
│                                                    │  │
│                                                    ▼  │
└───────────────────────────────────────────────────────┘

DOM after this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager'                                ▲  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                                    │  │
│                                     ELEMENT HEIGHT │  │ <- 320px
│                                     >=  'VIEWPORT' │  │
│                                             3000px │  │
│ ┌────────────────────────────────────────────────┐ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │        Control Panel                           │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ │                                                │ │  │
│ └────────────────────────────────────────────────┘ ▼  │
└───────────────────────────────────────────────────────┘

Steps to reproduce:
* Open Odoo on Mobile
* Go to a Kanban view with list height at least twice the screen height
* Scroll to the end of the page (the control panel is hidden)
* Scroll a bit upper => BUG the control panel is not visible until we
scroll in the 'box' of the '.o_action_manager'

Note this behaviour is maybe related to an issue from CSS3 [2]
from MDN [3]

Ref:
[1] odoo/odoo@3fea5b2136627c1d7e83b2a5e111952fe3eb10a1
[2] Issue 865 on https://github.com/w3c/csswg-drafts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/position



closes odoo/odoo#77513

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Issue: With margin enabled and avco for stock valuation, after
confirming a SO with a product variant which is a bom kit,
when we try to change the variant, there is a traceback

Steps to reproduce :
1) Install Stock, Accounting, MRP, Sale,
2) Enable Margins in settings

3) Configure a Product Category with costing method AVCO
4) Configure a Product with 2 variants and that product category
5) [Important: KIT] Create 2 BoM, one for each variant and set those
BoM to KIT
6) Create a SO for that product and one variant
7) Confirm the SO, cancel it, and set to quotation
8) Edit the SO and change the variant, save
-> Traceback

Side-Note:
 This issue is due to the fact that we iterate over the stock_moves to
 find the quantity of the BoM, but that stock_move correspond to
 confirming at step 7, when we change the variant at step 8, the stock
 move has not changed, so still contains the previous bom_line_id with
 the quantity, but this doesn't reflect with the new state of the SO
 which is for a different variant.

 For me since the stock move is canceled, it should be taken into
 consideration when computing the average price but I might be wrong,
 it's up to the reviewer to decide if it makes sense

opw-2639093

closes odoo/odoo#76723

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

If `_name_search` is called with `limit=None` it could take time in the loop
because `_name_search` for `product.product` has `limit=100`, i.e. it could be
100 iterations to scan 10 K products. To solve this problem, call `_name_search`
with `limit=None` to get all product variants at once.

As an example, the problem is reproduced on using menu `Manufacturing > Products
> Bills of Materials`, which makes following search query:

```
["|", ["code", "ilike", "XXX"], ["product_tmpl_id", "ilike", "XXX"]]
```

for which ORM calls `_name_search`:

https://github.com/odoo/odoo/blame/9b23864027bc24032993833f213395cb45fe86bb/odoo/osv/expression.py#L863



In a customer database, this speeds up the query from 70 seconds to 3,5 seconds.

---

opw-2631012

closes odoo/odoo#75820

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

- Storable product with MTO and manufacture route;
- On your warehouse set 3 steps manufacture
- Create a SO for this product > Confirm

The smart button linking the Manufacturing order does not appear on
the MO.

opw-2634309

closes odoo/odoo#76485

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>

Steps to reproduce the bug:
- Create a product and enable serial number option
- Create one “on hand qty” with SN e.g: “001”
- Create a SO for SN product
- Confirm SO and check the delivery order
- In the Operations tab > Enable Serial Number field
- “001” SN is already reserved in Detailed Operations and the qty done is 0 but the Serial Number field in “stock.move” is empty
- Edit and add “001” in the SN field
- save

Problem:
- The SN is deleted and the quantity done in the `”stock.move.line”` is not updated

Solution:
Update the quantity done in the `“stock.move.line”` linked to the selected SN

opw-2623101

closes odoo/odoo#77521

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

When adding an odd width images on website, a thin black line is
drawn on its right side. The problem comes from the getSourceCanvas
of the cropperjs library. A translation is applied followed by an other
translation in the opposite direction. However the second translation
was not the exact reverse of the first due to a rounding problem.

The fix proposed here comes from: https://github.com/fengyuanchen/cropperjs/pull/300/commits/a6481c052cfc93ef14dd95a3bd00142215dda36e



task-2652904

closes odoo/odoo#77039

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

When invoicing via POS delivery address is missing on the invoice.
This value is needed in some localizations (i.e. l10n_co) to correctly
validate the invoice

opw-2653661

closes odoo/odoo#77393

Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

How to reproduce the problem:
- Install the Employees app
- Create a new user and create an employee form for this user
- Log in with this user, then log out
- On the user's Employees form, the employee still appears as connected

Cause of the problem : as soon as a user logs in,
the system saves the date of his last connection. That value was wrongly
used in the process of computing the user's status.

Now, if the user is offline, he is shown as "Not Available" or "Away"
(grey or orange).

opw-2623386

closes odoo/odoo#77488

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Add _auto_init for stock_picking.sale_id
to speedup the module installation.

Since its related field, group_id.sale_id is also
created in sale_stock, creating the sale_id column is
enough.

opw-2638554

closes odoo/odoo#77437

X-original-commit: 6fb05387
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Since [1], a footer effect option has been introduced which allows to
have the content hovering the footer to then reveal it when reaching the
bottom of the page (instead of having the footer to scroll like the rest
of the content).

To achieve that, the body color was forced on the snippet container (the
`<main/>`) so that the transparent snippet still appear with a
background color for the time they go over the footer.
That background color should however not have been forced in non-full
layouts as another is already forced in that case. In those non-full
layout, the "full" body background (= background of color combination 1)
is applied on the snippet container but the "body" color is another
color which is customizable by the user too.

[1]: https://github.com/odoo/odoo/commit/5879e40445f0176d545b4a50f7f7ec33b2e171c8



Related to task-2590182

closes odoo/odoo#77490

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The empty string, the forward slash `/` and NULL are all to be
considered as without a sequence set on `account.move`.

While this is just true, it was detected because of non deterministic
bugs at the end of the month because the tax closing move was
explicitly set to an empty string on version 14.3 and higher.
See: https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4


Most of the tests posting an entry in the MISC journal could then
randomly fail on the last day of the month.

closes odoo/odoo#77481

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

The chrome.start() call also involves iot device loading
which is dependent on Gui to show error when there is any.
In this fix, we call configureGui when the Chrome instance is
available and before calling start.

closes odoo/odoo#75007

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

ISSUE ADDRESSED
- Open Project > Tasks > Gantt view
- Click on the button "Create"  of any cell to open a form dialog
- Fill the form and click on SAVE&NEW button
- Fill again the form and click on SAVE&CLOSE button
- Both tasks are created, but only the first has been planned, because the second one has lost a part of the context (plan dates...)

BEFORE
Opening a form view dialog without passing a _createContext method (see commit c14b17c4 where it was introduced) was still passing an empty object additionalContext argument when save&new was hit.
This was leading to not take into account the full context (see BasicModel._getContext).

AFTER
If no _createContext method is passed to a form view dialog, then no empty object additionalContext is passed to evaluate the context, resulting in the full context being used.

cherry-pick of: https://github.com/odoo/odoo/pull/75795/commits/73d1321268224e25ba4ac9927c95a83e5cd3c400



opw-2655195

closes odoo/odoo#77447

X-original-commit: f52469a8
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

Before this commit the only way to modify the domain is to completely override portal_my_invoices.
Since this function is so big this is not clean/easy to do.
By creating a separate function we can simply override it and we can reuse the function on two places.

closes odoo/odoo#77272

Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>

In some cases, it is impossible to validate some landed costs ("Cost and
adjustments lines do not match.[...]")

To reproduce the issue:
(Enable debug mode)
1. Set the Decimal Accuracy of Product Price to 4
2. Create a Product Category PC:
    - Costing Method: FIFO
3. Create 4 storable products (category PC)
4. Create a service product (landed cost)
5. Create a PO with the 4 products:
    - 6 x $0.92
    - 6 x $0.92
    - 3 x $75.17
    - 6 x $20.54
6. Process the delivery D
7. Create a Landed Cost:
    - Delivery: D
    - Product: the service product
        - Split Method: By Quantity
        - Cost: $1000
8. Compute the landed costs + Validate

Error: a User Error is raised "Cost and adjustments lines do not match.
You should maybe recompute the landed costs.". The sum of the additional
landed cost equals $999.99 instead of $1000

From version 14, `additional_landed_cost` is a Monetary field and its
rounding property is no more based on "Product Price":
https://github.com/odoo/odoo/blob/800433bde03a36ead40a78bc6d53cbb95c24f97b/addons/stock_landed_costs/models/stock_landed_cost.py#L371-L372


Therefore, we should use the rounding of the associated currency to
round its value

OPW-2637701
OPW-2631718
OPW-2649348

closes odoo/odoo#77155

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

ISSUE:

The click on "THEME" tab in editor panel triggers the
'_onThemeTabClick' method which:

1- Starts the loader ('_execWithLoadingEffect' method).
2- Runs '_activateSnippet' which uses the same mutex as the
loader.

Execution order:

A1- '_execWithLoadingEffect' with promise: adds the loader in
the DOM immediately.
A2- '_activateSnippet' sets a second loader to be added after
a delay = 500.
A3- 'releaseLoader' removes the first loader.
A4- '_activateSnippet' ends : (before adding the second
loader: t(4) - t(2) < 500) and timeout is cleared.

In some cases we get t(4) - t(2) > 500 which adds a second
loader to the DOM, and the new flow will be:

B1- Same as A1.
B2- Same as A2.
B3- Second loader added to the DOM / replaces the first one
in 'loadingElements'.
B4- 'releaseLoader' removes the second loader (from the DOM
& 'this.loadingElements').
B5- Same as A4 but the first loader still in the DOM.

The goal of this commit is to fix this behaviour by preventing
more than one loader on the target element.

task-2656308

closes odoo/odoo#77226

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Issue:

  When trying to print a Suisse QR bill, if multiple images are presents
  in document and they have a url as src, some pictures will not be
  displayed.
  (Same issue may occur with simple QR code)

Cause:

  It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b


  Also, adding css class to body by js break wkhtmltopdf.

Solution:

  Replace link by base64 image value (use a function to retrieve base64
  image instead of image_url).
  Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
  to this report).

  Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
  (since generic) to account module.
  Move specific logic like `_get_qr_vals` and
  `_get_qr_code_generation_params` to specific module (ex: l10n_ch).

  extra: Alter some css for better rendering.

opw-2620082

closes odoo/odoo#76404

X-original-commit: 684f0c44
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Before this commit:
UTM campaigns are accessible to all internal users. But with sale module
installed, few of the fields are added into the `utm.campaign` model and
it's views. Those fields contain information related to quotations and
invoices. So if the internal user who does not have the basic sales rights
tries to access the campaing, an AccessError is raised.

With this commit:
We only show those fields in the views to the users having enough rights
("sales_team.group_sale_salesman") and thus allow other internal users
to access the UTM campaings without AccessError.

Task-2417993

closes odoo/odoo#77374

X-original-commit: 4b899e50
Related: odoo/enterprise#21244
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Steps:
- Set a supplier's 'Timezone' at a different timezone from user.
- Set 'Send Order By: Email' and set any 'Order Time'.

Result:
  E-mail will be sent at the set time, but in supplier's timezone. It is the desired behavior, but it is not intuitive for user.

Solution:
  Timezone displayed right below order time, so the relationship between both is more obvious.

opw-2541132

closes odoo/odoo#75429

Signed-off-by: Kevin Baptiste <kba@odoo.com>

If an invoice is posted, sended back to draft and the rate was change on res.currency, we preserve the value already existing on l10n_ar_currency_rate

closes odoo/odoo#77175

X-original-commit: 820df9ee
Signed-off-by: Josse Colpaert <jco@openerp.com>

BEFORE THIS COMMIT / How to reproduce :

Consider a multiple choice question with single answer.

A. 2 points
B. 1 point
C. -1 point

Here, the user can only select one answer. He picks A. He only obtains 2/3 points.
This is because the maximum score was computed as the sum of all positive scores
for the question. It does not make sense, as the student can only pick one answer.
Therefore, the formula does not allow giving partial scores (here, answer B, close
to the correct answer) while maintaining correct score percentages.

AFTER THIS COMMIT:

The sum of positive scores is still used as maximum score for multiple choice
with multiple answers, as we want the student to pick all good answers for max score.

However, for multiple choice with single answer, we use the maximum positive score
(or 0, if none) among answers, as it the maximum score one can get while selecting
a single answer.

-> example above : I pick A, I obtain 2 points out of max(2, 1, (0)) = 2
-> I obtain max score for the question. 2/2.

ps: As the sum only uses striclty positive values, the negative points are still
operational and the flow is not changed.

TESTS:

A test test_partial_scores_simple_choice is added to make sure the simple_choice
is repaired and always gives 100% of points if the best answer is picked.

Task-2533836

closes odoo/odoo#76326

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

This commit adresses to two issues:

Since 0c83542a93dde8dcaead04fadb7db95cf627a8b4, the move line's `expiration_date`
set by the user is always overrided at the creation of the move which
means the user has to modify it after the move was created.

To fix that, the compute doesn't override the `expiration_date` if there
is already one set.
Therefore, the onchange on the product who was removed is re-added to
force to recompute the `expiration_date` if the move line's product is
changed and it has already an `expiration_date` set.

closes odoo/odoo#76847

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

How to reproduce:
  - Create a product tracked by lot;
  - Create two receipts for this product;
  - Use the same lot name in the two receipts;
  - Try to validate the two receipts in the same time
    => `ValidationError` will trigger in the `_check_unique_lot`
        constrain of the production lot.

task-2646107

Part-of: odoo/odoo#76847

Before this commit:
Let's consider the following two scenarios while answering time limited survey:

1) attendee's system clock is de-synchronized compared to the real time
2) Odoo server clock is de-synchronized compared to the real time

In any/both of the above cases, it will lead to a wrong timer display, and will
confuse the user and/or make him fail the test because he will think he still has
more time to submit when he does not.

With this commit:
To fix this, we simply get the offset of server UTC time and moment time, and apply
the offset while calculating the time remaining.

Task-2612972

closes odoo/odoo#75814

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit, when creating a new ribbon after selecting an
existing ribbon, the style of the selected ribbon was added to the new
ribbon in addition to the default style.

task-2501515

closes odoo/odoo#76025

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit, the text color preview of the ribbons in the
ribbon selector was wrong. But also, if we selected another ribbon
just after changing the text color of a ribbon. This color was applied
to the selected ribbon.

task-2501515

Part-of: odoo/odoo#76025

`tz` field is technical field related to `resource_id`, which is required field on that model.

However it is possible to try to write a void value, which leads to an issue as it is technically required.
With this commit we make the tz field required at write.

closes odoo/odoo#77339

X-original-commit: 7cda3632
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

How to reproduce the problem:
- Go to General Settings
- Check Custom Email Servers and create an Alias Domain
- Go to the Project app
- Create a new project and put an alias email for it
- In another (private) window), create a new portal user
- Send an email from that user's address to the created project's mail

A task is created, and the portal user is set as a follower.
BUT the portal user doesn't receive the task in his "Documents".

Cause of the problem : only the recipients of the mail are correctly
subscribed to the followers list, not the sender (which skips a step).

This commit adds the sender in the process of subscribing followers to a task.

opw-2619370

closes odoo/odoo#76836

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Steps to follow

  - Add an HTML field in the sales order line view
  - Create a sales order
  - Add a product
  - Add a table with multiple rows in the HTML widget
  - Add a new product
  -> The new product isn't selected

Cause of the issue

  The CSS selector used for finding the record to edit was taking all tr
  element into account

Solution

  Only select direct descendants of the tbody

opw-2632817

closes odoo/odoo#77355

X-original-commit: 05fedd20
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

Since https://github.com/odoo/odoo/pull/69124,the UBL template is wrong because of the order of the elements in `PaymentMeans` because it is a sequence
`PaymentDueDate` must be in second position (before `InstructionId`)

https://www.w3schools.com/xml/el_sequence.asp
https://docs.oasis-open.org/ubl/prd1-UBL-2.1/xsd/common/UBL-CommonAggregateComponents-2.1.xsd


see `<xsd: complexType name = "PaymentMeansType">`

OPW-2468492

closes odoo/odoo#77317

Signed-off-by: William André (wan) <wan@odoo.com>