A "thematic break"[1] is composed of 3 or more characters (-, _,
or *). The current separator using only 2 characters between the main
body of the PR and the footer / addendum makes it more difficult to
interpret the message.

Update to 3 so e.g. the mergebot can strip the footer.

[1]: https://spec.commonmark.org/0.30/#thematic-breaks



closes odoo/odoo#101100

X-original-commit: c7bf932c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Reproduction:
1. Install eCommerce and accounting
2. Go to Accounting->Configuration->Taxes, add one sale tax 15%, and one
0%. Both taxes are included in the price.
3. Go to Configuration-> Fiscal Position, create a new one “test” which
applies the tax mapping from 15% sale tax to the 0%. Check “Detect
Automatically”, set country group as Europe
4. Go to Website->Orders->Customers, set the country of the portal user,
Joel Willis, as Luxembourg. In Sales&Purchase->Fiscal Information set
the fiscal position as “test”
5. Go to Website->Products->Product Variants, create a new one
“test_tax_prod” with price 110, and sale tax 15%, can be sold, can be
purchased and consumable.
6. Go to Website->Configuration->Attribute, create a new product
attribute “test” with Display Type as Ratio, Variant Creation Mode as
Never. Create a value “a” in its attribute values
7. Go to Website->Products->Products, find test_tax_prod, go to its
variant tab, set attribute as “test” with value “a”, publish this
product
8. Open an incognito tab, login as “portal” pwd: portal, search the
product “test_tax_prod”, set the price list as “public price list”, the
price is 95.65 on the page. Add it to the cart, the price is 110

Reason: When we update the order_line, we should update the price based
on the fiscal position for the no_variant products too. However, based
on the current workflow, the price is computed in method
_website_product_id_change before an order line is created. Thus for
no_variant products, the price is not updated.

Fix:  This issue is fixed in saas-15.3 by rewriting the workflow and
calculating the price through an on_change function here: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605

In v13, we don’t have this on_change method to compute the new price, so
a similar price update can be created in the cart update for
website_sale. This fix solution was created here: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
However, new price computation issues can happen when combining two
pricelists, here: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391

Thus the fix is eventually done in _website_product_id_change. Added a
new parameter to force checking the orderlines based on the domain. The
orderline is created but only can be searched based on the domain. This
ensures the price is computed correctly for pricelists and for tax.

Added fiscal position test for no variant product

opw-2856956

Fix by re-writing in saas-15.3: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605
First related fix: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
Second fix to patch for the first fix: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391



closes odoo/odoo#101087

X-original-commit: d8a730f5
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>

complementary to https://github.com/odoo/odoo/commit/523cfc447bada2617d0e2cce61806aa188bc59b8



closes odoo/odoo#101061

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

To reproduce:
Video: https://drive.google.com/file/d/1bAh7KA_5UhhIrr-qF5A5gOVWhk3_9clj/view


 1. Have multi-language website
 2. Event with one ticket
 3. Reload page and click the "Register" button
 -> in some cases there is a traceback
 `/event/great-reno-ballon-race-2/registration/new: Function declared as capable of handling request of type 'json' but called with a request of type 'http'`

 Reason of the issue:
 As the button "Register" in the form is defined with `type="submit"` it will send the form as plain HTTP if clicked.
 This behavior is modified in the JavaScript to prevent this default behavior.
 However, if the button is clicked before the JS load, the HTTP behavior is used which does create the above traceback (as the `registration/new` route accept only `json` type).

 Solution proposed:
 Prevent the button default behavior and make it deactivated and let the JS activate it when it is ready

 Note on stability:
 As JS code and XML view is modified, this fix was thought so that the JS won't have an impact if the view isn't updated.
 There is theoretically no way that the XML view would be updated without the JS being updated (except manual modification in the view or rollback on the version revision after performing a module update on odoo.sh). If it was the case then the button will be deactivated until the user change the number of ticket.

 OPW-2946706

closes odoo/odoo#100490

X-original-commit: 34db5005
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Steps to reproduce the bug:
- Create a storable product “B1”:
    - Costing Method: average
    - With BOM:
        - BOM Type: Kit
        - Components:
            - 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
    - Click on “Compute Price from BOM”
    - Cost = 3 * $2 = $6

- Create a storable product A1:
    - Costing Method: average
    - BOM
        - BOM Type: Kit
        - Components:
            - 2 units of B1

- Go to the “A1” product form:
    - Click on “Compute Price from BOM”
    So: 1 unit of A1 → 2 units of B1 → 3 units of C1
    - Cost = (2 * 3 * $2) = $12

- Create a SO:
    - Add 1 unit of “A1”
    - save
    - cost(`purchase_price`) = $12
    - Confirm the SO
    - The cost is recomputed and becomes = $6

Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27

But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18



So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line

opw-2971248

closes odoo/odoo#100126

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The aim of this commit is to:
- allow OSS to use tax that aren't declare by TaxReportLine
- have the oss tax automatically populated with the correct tags for spanish
  tax report
- Add taxes specific to the spanish OSS : No sujeto y acogidas a la OSS (Servicios) and No sujeto y acogidas a la OSS (Bienes)
  using the official modulo 124 tag

closes odoo/odoo#99273

Community-pr: https://github.com/odoo/odoo/pull/99273


Task: 2930758
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Camille Casp Spiritus <casp@odoo.com>

Only compute the lot values info on stockable or consu (kits) products
on the invoice lines

closes odoo/odoo#100663

X-original-commit: affc9abb
Signed-off-by: Adrien Widart <awt@odoo.com>

Backport of https://github.com/odoo/odoo/commit/c88f76cab7a1292e6fff3bd77441a9845b8173c8

 because it could lead to a traceback in the case a GET wasn't supposed to receive this kind of format as request answer.

closes odoo/odoo#100674

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

When creating a MO with some WO from a mobile, the quality checks are
not created

To reproduce the issue:
(Need quality_control)
1. Create two storable products P_compo, P_finished
2. Create a BoM:
    - Product: P_finished
    - Components: 1 x P_compo
    - Operations: create a new operation OP
3. Add a step to OP:
    - Type: Pass - Fail
4. Switch into mobile mode
5. Create a MO for 1 x P_finished
6. Confirm it
7. Open the WO

Error: the tablet view skipped the pass-fail step, the user can already
mark the MO as done and close it

When confirming the MO, it leads to the quality checks creation. To do
so, we iterate on the `quality_point_ids` of the WO to generate these
quality checks:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L406
But, the WO has not any quality point, which is incorrect: it should
have the one related to the step created on the operation P. This field
is a computed one and is based on the quality points defined on the
operation linked to the WO:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L70-L73


But again, there is an issue: the WO has not any defined operation
(which is incorrect, it should be linked to OP). And this is because of
the WO creation from the kanban view: the field `operation_id` is
missing so it is not defined during the WO creation.

OPW-2984037

closes odoo/odoo#100672

Signed-off-by: Adrien Widart <awt@odoo.com>

When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
   'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
   one with values:
   - Product: Table Top
   - Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
   the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
   finish time) even though its expected duration is 2 hours

Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)

Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning

opw-2893622

closes odoo/odoo#100540

X-original-commit: 90f83914
Related: odoo/enterprise#31547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

What is done in start should be undone in the destroy.

closes odoo/odoo#100420

X-original-commit: 6f5fc1a2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

To check if the state 'Reversed' should be set on an invoice. We checked that the full reconciliation moves
only contain the invoice, the reverse move and the potential exchange move. However, it's possible to have
also some CABA moves for the invoice and credit note when the tax used have a CABA transition account which
is reconcilable (eg. tax "IVA(16%) VENTAS"). So if this append the status 'Paid' will be set instead.

Now, we take into account those CABA moves and the status will be set to 'Reversed' accordingly.

opw-2976667

closes odoo/odoo#100380

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Before this fix negative aml unit prices were systematically set to positive in the edi xml generating inconsistencies.

closes odoo/odoo#100598

Task: opw-2963947
Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps to reproduce:

  - Switch to debug mode
  - Go to calendar
  - Create an allday event in the future named test
  - Add an attendee with an email address
  - Save
  - Go to Settings > Technical > Email > Emails

  Two emails have been sent:
  * Invitation to test
  * test: Date updated

Cause of the issue:

  The method `_inverse_dates` is called when creating an event,
  triggering a write on the start field.
  This then causes an update email to be sent

Solution:

  Add a context key and don't send the update email if it is present

opw-2841276

closes odoo/odoo#100275

Signed-off-by: Arnaud Joset <arj@odoo.com>

Steps to reproduce the bug:
- Install [l10n_it_ddt]
- Create a storable product “P1”
- Create a SO for “P1” with qty 3
- Deliver 1 unit and create a backorder
- Generate the invoice for the delivered qty: 1
- Post the invoice
- smart button with the link to DDT n°1 appears
- Deliver the remaining 2 units
- Create the second invoice
- Post the invoice

Problem:
The link to DDT appears but with the 2 pickings, whereas in this case
only the 2nd picking is linked to the invoice.

Before using the `account.move.line` records, we sorted them by date
in order to always use the first created one to link it with the first
picking created, however if two `account.move.line` were created in
the same days, they will be ordered randomly, so we also have to
sort them by id if the date is the same.

opw-2968401

closes odoo/odoo#100294

Signed-off-by: Josse Colpaert <jco@odoo.com>

Manual action "click" was wrongly took off in
c650faaaf77fe99559a23a4d68fae56b498d8c89 and browser was sometimes
closed before the default click action ran. For clarity purpose, a step
is added to ensure the form is saved in place of the manual click.

closes odoo/odoo#100725

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.

This commit makes no analytic line is created for section/notes.

closes odoo/odoo#100615

X-original-commit: 3293ffa0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When the ACE editor was introduced in [1], it relied on the already
existing `_views_get` to obtain the list of views that could be edited.

When the `mode` of `ir.ui.view` was introduced in [2], no mechanism was
introduced in `_views_get` to avoid fetching primary views that have
nothing in common with the current view.

This commit adds a parameter to `_views_get` to request the
exclusion of unrelated primary views.
Since even before it appeared in [3], `_views_get` relies on the
following approach:
- consider the top-most parent of the `t-call`ed views
- consider the views that inherit it
I.e.: reach each node of each view hierarchy tree by starting from its
root.

Because this starts from the top-most parent, simply preventing the
call to each primary child view is wrong, because any child on the
parent path must be considered - be it primary or not.
We therefore introduced a `skipped` list that keeps track of those
"later to be processed" views - so that the filtering of primary
children does not remove them.

[1]: https://github.com/odoo/odoo/commit/7c45e5976e6caf3d7b9eb508f728062704232261
[2]: https://github.com/odoo/odoo/commit/434be479f97a32987d0817bf329183fc2bbe3bf5
[3]: https://github.com/odoo/odoo/commit/bff6e04e9536d7b80916987eb123de98b1b689b1



task-2898555

closes odoo/odoo#99838

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

Suppose a product P with an available quantity equal to 1. Suppose a
user writes on an existing SML for that product and sets the reserved
quantity to 2. When writing on such a field, `StockMoveLine.write` tries
to reserve the same quantity on the quants. If it fails (which would be
the case here because there is only one P available), the reserved
quantity of the SML is reset to 0 (and so does the reserved quantity of
the quant).
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L301-L313

However, there is an issue: the incorrect reserved quantity is still in
`vals`. As a result, later on in the method, this incorrect value is
written on the SML:
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L362


This creates an inconsistency: a SML affirms that 2 x P are reserved
while the reserved quantity of the quant is 0. Moreover, when marking
the SML as done, it will lead to a "unreserve more than..." issue.

OPW-2936689

closes odoo/odoo#100136

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

After commit [1], attribute `t-value` was replaced to `value` by mistake

Steps to reproduce:
- Go to a forum post
- Click on the author image, logged in as admin
- On the profile page, unpublish the user
- As public visitor go to the previous forum post
- See the avatar image url -> `href` is now `href="#"` with this PR.

[1]: https://github.com/odoo/odoo/commit/c8c8eb3d5652e9834d0ecd5aad907ee359edb657#diff-2a4205ad15bf7b1ef0d1361b1baec87ef8a6429de19f9e0e8afce4ca16be839d



closes odoo/odoo#100484

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

Before this commit: if an event's attendee didn't have a state, it couldn't
get synced with Google.

The solution is first to set a default value for it.

opw-2915661

closes odoo/odoo#97693

Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

Before this commit, when an event was set to recurrent, all the recurrence
values were falsy. They were not equal to the default values.

opw-2886253

closes odoo/odoo#97012

Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

Before this commit: syncing with google led to sending emails to
attendees of existing future events on Odoo.

Steps to reproduce the first issue:

- Install 'google_calendar' module
- Integrate with Google Calendar in setting
- Add an event to the Odoo calendar for future date
- Add one external attendee to the event
- Sync with Google

Invitation emails would be sent to the attendees of the events.
Solution

It's possible to not send emails to the attendees in api calls. So
the solution is to not send emails to the attendees for the syncing
time.
opw-2819046

Part-of: odoo/odoo#97012

Steps to reproduce:
- create and send a quotation
- make a failed payment (through cutomer preview)
- create and send a second quotation to the same customer
- make a succesful payment this time
- redirect takes to the wrong quotation (failed one)

Bug:
polling the processed payments initially returns both transaction
but the following polls only returns the rejected payment
(introduced in [1] processed transactions are filtered out)
since there's only a single transaction, redirect takes to it

Fix:
if there's only a single succesful transaction (regardless of the rest)
it means the current payment was successfull so we redirect to it

opw-2954162

[1]:https://github.com/odoo/odoo/pull/31741/commits/7612659565ee24f1c878b81e6c86b5780fbd5a3d



closes odoo/odoo#100406

X-original-commit: 0420a0b6
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Current behaviour:
In the context of a multilevel contact hierarchy, if a contact is creating an SO, only that contact and it's commercial partner (usually the first company when going up in hierarchy from that contact) can see the SO.
The other contacts that are in that hierarchy could see the number of related SO on the smart button, but once clicking on it, no SO were shown.

Expected behaviour:
Every direct or indirect parent of a contact should be able to see the SO, as shown in the smart button count.

Steps to reproduce:
- Create 3 contacts with the following hierarchy: Company -> Contact 1 -> Contact 2 (Company is the root)
- Create an SO with Contact 2 as a customer
- On each of the contacts, click on the SO smart button, all of them have 1 SO shown on the button, but only Constact 1 has none shown once clicked. (Regardless if Contact 1 is an Individual or Company)

Fix:
Simplify domain search to only take into account the children's ids.
There is no need to make a distinction between a contact that is a company or not, since all commercial_partners are also partners by default.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- master

opw-2961030

closes odoo/odoo#100377

Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

Steps to reproduce:
1- install eComerce app and activate debug mode
2- go to Website > Configuration > Websites
3- on a website product page extra fields tab add an empty line and save
4- visit any product page on the website (500: internal server error)

Bug:
adding an empty field crashes the website server on the product page

Fix:
made the field required

opw-2945621

closes odoo/odoo#100318

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

`l10n_in_gstin_partner_id` should be hidden on the journal form for non-Indian companies. It's probably also a good idea to hide `l10n_in_tin`in the country state form whenever the state added is not in India.
vat field on `res.company` should be renamed to GSTIN only when the company country is India.

task-2765567

closes odoo/odoo#99124

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

HOW TO REPRODUCE

Go on a record (e.g. a lead), open the full composer and use the "File / Image"
button from the editor to insert an image. After sending the attachment is
displayed in chatter. However after a few days it disappears, being garbage
collected.

ISSUE

When adding an image inside a mail composer via the /image command or 'image'
button of the editor, the related attachment was never processed. This makes
sense as we do not want to attach it to the resulting message(s). However as
the attachment res_id and res_model were never updated from the compositor in
which they originated, they would become dangling attachments and be garbage
collected the next day (or the in the next pass of the GC) by
'_gc_lost_attachments'.

The attachment keeps 'mail.compose.message' as res_model and 0 as res_id.
It is therefore considered as a lost attachment and removed by the garbage
collect of attachments. As image are inlined in the content (using a link
towards /web/image) they are not part of 'attachment_ids' given to the
'message_post' method and therefore not linked to the document by
'_message_post_process_attachments' whose job is to correctly set the
model and res_id of attachments linked to the composer.

An event was not called on uploading files in a media dialog. This means the
parent of html field didn't know of the new attachments which resulted in
attachments being linked to no record at all and not being garbage collected
later. This fix makes that call.

The attachments newly uploaded in media dialog are uneditable to prevent users
from unlinking attachments that are still used in the body of the composer
(causing the same issue).

Task-2860761

closes odoo/odoo#95537

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

Currently the exception is not logged using the logger meaning that the
only indication of the failure is the "module not loaded" error message.

Catching the exception to log it the proper way will help identifying
the cause of the issue, mainly for uninstall tests.

closes odoo/odoo#100372

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Steps to reproduce:

  - Install `l10n_ar_website_sale` module

  - Go to shop (Argentinian website) and add a product to cart
  - Open cart and click on checkout
  - Click on Customize and disable `Show b2b fields` feature

Issue:

  Fields are no more displayed.

Cause:

  Since the b2b fields template (`address_b2b`) have customize_show set
  to `True`, it is possible for all countries to display/hide
  the b2b fields, but it should not.

  For Argentinian companies (for example), the b2b fields should always
  be displayed.

Solution:

  For frontend (Website shop): in address form, if website company
  country is Argentina, check if the address_b2b view is active and if
  not, enable it.
  For frontend and backend: on write of a view `address_b2b`, do not
  allow to disable it if have a website and website company
  country is Argentina.

opw-2941199

closes odoo/odoo#98084

Signed-off-by: Josse Colpaert <jco@odoo.com>

Following the steps that changed every quantity in a matrix, the next
step was triggered after at least one sale order line's quantity was
changed. Due to the number of lines created, one of the so lines was
sometimes not updated before the next step, which produces an error in
the final sale_count.

In order to check the total and ensure every line was updated, we set
the partner sooner in the tour, which in turn sets the pricelist used to
get the price of each line. Thus allowing a check on the subtotal.

Backport of commit-af1e67aa2c6c676479ee4ea73106bcabd20c621e

closes odoo/odoo#100301

X-original-commit: e0461e1d
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

When sending a mass mailing with a pdf attachment, the ir.attachment
is copied in the mail.composer for each email. Spending time and
resources in the indexing of the pdf. On copy that value is already in
the vals. This is especially true when attachment_indexation is
installed, processing the pdf documents can be costly with pdfminer.

It could also be done by overwriting the copu from ir_attachment but it
could happen a misuse of mass create of ir.attachment with the same file
has the same issue

closes odoo/odoo#99856

Signed-off-by: Raphael Collet <rco@odoo.com>

Steps to reproduce:
- Create a transfer and choose whatever operation
- Enable detailed operations option for the operation
- Check availability and set quantities
- Cancel the transfer then Go to Product Moves

Current behavior:
- todo filter is broken, it shows canceled moves

Desired behavior:
- Show only moves that are assigned or waiting

- Task id: #2981249

closes odoo/odoo#100292

X-original-commit: 49c8351f
Signed-off-by: Tiffany Chang <tic@odoo.com>

Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon.

closes odoo/odoo#100259

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

To Reporduce
=============
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date and set expiration days to a value
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”
- Click on the icon with 3 bars (last thing on line) to open Detailed Operations view
- add a line and set a `lot/serial Number`
- from the same view open the `lot/serial number` wizard and edit the expiration the date
- save/confirm

Problem
=======
The expiration date on Detailed Operations doesn't change

Solution
=========
to solve the issue a condition in compute method was corrected

opw-2937438

closes odoo/odoo#97898

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When a module extends model 'base', the database schemas of all models are
checked, including indexes.  And a log message appears for "unexpected index
mail_message_subtype_id_index on table mail_message_subtype".  The index indeed
exists, but not for the table mentioned in the message.  The ORM actually makes
a confusion between:
 - the index mail_message_subtype_id_index for subtype_id on table mail_message
 - the index mail_message_subtype_id_index for id on table mail_message_subtype

The fix consists in logging the message about the unexpected index only if the
index is on the expected table.

closes odoo/odoo#100217

Signed-off-by: Raphael Collet <rco@odoo.com>

The RappresentanteFiscale and CessionarioCommittente nodes must be in this order in the invoice xml. The RappresentanteFiscale node is only added if the company has a tax representative configured. In that case, before this fix, submitting an invoice to the SDI (Italian tax agency) would not go through and generate an error :
The invoice has been refused by the Exchange System
File non conforme al formato : Invalid content was found starting with element 'RappresentanteFiscale'. One of '{TerzoIntermediarioOSoggettoEmittente, SoggettoEmittente}' is expected.

How to reproduce :
- Install l10n_it_edi_sdicoop
- Configure a tax representative on the company
- Go to accounting settings > Electronic Document Invoicing and choose the test mode + check the “Allow odoo…” checkbox.
- Create a new invoice and confirm
- Click on “Send now”
- Click again on “Send now” until there is an update and the error is displayed.

closes odoo/odoo#100129

Task: opw-2952098
Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps to reproduce:
- enable multi currency in settings
- set different rates for multiple days
- create a vendor bill in a different currency
- create a second vendor bill
- fill the second bill using auto complete from the first one

Bug:
the correct currency rate isn't applied unless date is changed when
the source is a vendor bill not a purchase order

Fix:
update currency rate after adding a line with a different currency

opw-2890210

closes odoo/odoo#99934

X-original-commit: fd4a8d98
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>