How to fix mail.template attachments by re-attaching them to some
template:

```sql
with template_attach as
 (select *
    from email_template_attachment_rel
   where attachment_id in (
          select id
            from ir_attachment
           where res_id = 0 and not public and res_model='mail.template')
 )
update ir_attachment a set res_id = ta.email_template_id
                      from template_attach ta
                     where a.id = ta.attachment_id;
```

The origin parameter must be an absolute link (starting with a /)
To be consistent and always have a leading slash (and avoid relative
links if the developer forgot to add a leading slash)

The request being of type http, the returned Content-Type was
text/html while the select2 request exepected json in the dataType

Using an explicit list of sign up parameters will avoid
polluting the context with unrelated values, and make
debugging easier.

task-2376327

Partially backport the changes from 49429f98 to file_open to be
able to use it in the assetsbundle

Only admin users should be able to load demo data, if needed.

This is only possible from the settings dashboard, and thus,
the method could be decorated.

See: c002e2eb

Steps to reproduce the issue:

  - Install eCommerce and Inventory module
  - Go to Settings
  - Ensure `Product Prices` is set to 'Tax included'
  - Ensure `Variant Grid Entry` is activated
  - Create a new Product as storable
  - Set `Sales Price` to $1.0
  - Set `Customer Taxes` to 10.00 %
  - Under `Variants` tab, set 'Sales Variant Selection' to 'Order Grid Entry'
  - Under `Variants` tab add an Attribute with 2 values
  - Set "Price Extra" to $2.0 to one of the variants
  - Go to the Shop and select the product

Issue:

  The extra price badge does not include the taxes
  ($2.0 instead of $2.2), however the final price does.

Cause:

  The price_extra field from ptav (used in the badge) does not include
  the taxes.
  However, when calculating the final price, we do first the sum of all
  prices (including the extra prices) and then apply the taxes.

Solution:

  In the template, for each 'variants', we call `_get_combination_info`
  to get the variant.price_extra with taxes included/excluded
  depending the `Product Prices` setting.

opw-2669871

closes odoo/odoo#80460

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

The goal is to ensure that 2 conditions are met for a fiscal position to
be applied (within the EU):

- The customer must have a valid VAT number from another EU Member State
- The goods must leave the country of origin

closes odoo/odoo#75033

Task: 2596204
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

The filter 'Difference different than zero' is not correct

Steps to reproduce:
1. Install the Inventory app
2. Go to Inventory -> Operations -> Inventory Adjustments
3. Create a new Inventory Adjustments and start it
4. Change the number of Drawer counted so that the absolute difference is <= 0,498
5. Apply the filter 'Difference different than zero'
6. The line disappears although the difference is not null

Solution:
Specify the argument name 'precision_rounding' for the function 'float_is_zero()'

OPW-2699771

closes odoo/odoo#81681

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#81629

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#81265

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Current behavior :
When using cash rouding method "HALF-UP" if the difference between the rounded price and the original price was exactly the half of the cash rounding, the order would appear as unpaid.

Steps to reproduce :
- Create a rounding method of 0.5 (half-up)
- Sell a product for 11.25
- The order appears unpaid in the PoS orders list view

opw-2593687

closes odoo/odoo#81642

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

Consider this example:

- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated

==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.

This is wrong, as we'd expect to see:

- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line

The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.

OPW 2716083

closes odoo/odoo#81725

Signed-off-by: Laurent Smet <las@odoo.com>

No notifications should be received whilst in Kiosk Mode.

closes odoo/odoo#81453

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

Current behavior:
When a user doesn't have any HR access right he cannot access his own profile

Steps to reproduce:
-Go to the demo user settings
-Remove all the right in the HR section
-Log into demo account
-Try to access My Profile

opw-2712593

closes odoo/odoo#81566

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Expected behaviour

The order date on the Purchase Order report (printable pdf) should be the
confirmation date if available and the order deadline else.

Observed Behaviour

The order date on the PO pdf is the order deadline of the RFQ, no matter
if the oder has been confirmed or not.

Reproducibility

This issue can be reproduced following these steps:
1. Create a new RFQ
2. Set an order deadline different from the current day
3. Confirm the RFQ
4. Download the printable PDF (as pdf) and check the Order date

Related ticket
- opw-2696794

closes odoo/odoo#81294

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

How to replicate:
- Create a user and assign the current company to its
related contact.
- Go to Recruitment -> create a job with the user
created before as Responsible.

Result:
- The user doesn't display in the sidepanel.

Expected:
- The panel should display the user and the other
users that are responsible of at least one job.

Additionally, if the user's contact has no company
assigned, it will display in the panel whether or not
the user is set as responsible in at least one job.

I overwrote the 'search_panel_select_range' to
display only the users that respect the rules listed
above.
I also changed the original search_panel_select_range
and now I don't set parent_field if the parent_field
model is different than the current model

opw-2654573

closes odoo/odoo#80333

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Before this commit, it was possible to drag and drop a popup inside an
oe_structure which was itself inside an other oe_structure (e.g. snippet
parallax). It didn't make sense and moreover created bugs.

After this commit, it is no longer possible to drag and drop the popup
snippet or the newsletter popup snippet in a substructure.

task-2491976

closes odoo/odoo#80836

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

When a kit is exploded to `stock.move` the quantity is rounded half-up
for every move. But during the invoice. The quantity to invoice on
kit is rounded up so it could result in differences between the
inventory valuation and the cost of the product

closes odoo/odoo#81355

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

Fix for task 2620026.

_get_bom_component_qty function is only referred to once in the whole odoo app,
which is on addons/sale_mrp/models/account_move.py#22.

The result returned from this function is used as a multiplier to quantity
to convert into the expected UoM. However, the quantity being referred to on
_stock_account_get_anglo_saxon_price_unit (qty_invoiced, qty_to_invoice), are
already converted into the SO Line's product's default UoM. In this function,
it however tries to convert 1 from SO Line's UoM to BoM's UOM.

With this, if Product UoM=x, SO Line UoM=y, BOM UoM=x, in the function _stock_account_get_anglo_saxon_price_unit,
the quantities will be multiplied by the same factor twice, resulting to the incorrect computation of price_unit to follow.

Part-of: odoo/odoo#81355

- Set up a POP account
- On the POP account, receive emails addressed to various recipients,
  e.g. `my_alias_1` and `my_alias_2`. Receive more than 50 emails to
  `my_alias_2`.
- In Odoo, create a mail alias for `my_alias_1`
- Run the fetchmail cron

The cron runs endlessly until it is killed. In the logs, inconsistent
messages are shown:

```
...
Fetched 3507 email(s) on pop server xxx; -16493 succeeded, 20000 failed.
Fetched 3507 email(s) on pop server xxx; -16543 succeeded, 20050 failed.
...
```

First the message count is incorrect in the log. We fetched at most 50
emails, not the total number of emails. Then, the endless loop is due
to the fact that
- we do not delete failed messages (= messages addressed to
  `my_alias_2`)
- we always fetch messages from `num=1`

If the first 50 messages fail, we fetch them endlessly until the cron is
killed.

To avoid this, we compare the number of failed messages with the number
of messages retrieved. If all messages retrieved have failed, we stop
the loop.

After the fix, consistent messages are show in the logs and the process
stops after the first complete failure:

```
start checking for new emails on pop server xxx
Fetched 50 email(s) on pop server xxx; 0 succeeded, 50 failed.
```

Note that it doesn't solve the core of the issue; we just fail faster. A
proper way would probably be to use an offset so we don't always start
at `num=1`. On the other hand, it is just a matter of time before the
cron times out: if the mailbox is full of messages which canot be
treated, we will just spend more and more time trying to find the ones
which can be treated.

closes odoo/odoo#81115

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Goal:
The aim of this commit is to make the cogs generation multi-company
safe.

Context:

Considering the situation in which company A has set a product P with
a real time valuation and company B didn't set the real time valuation
or has set it to manual;
Considering the user has selected both company in the switcher;
The user post an invoice for the product P.

Before this commit:
There isn't any cogs created for the invoice which is wrong.

After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.

closes odoo/odoo#81348

Task: #2713607
Signed-off-by: Laurent Smet <las@odoo.com>

Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.

closes odoo/odoo#81393

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

It should be allowed to pay amount that are not rounded if the value is less than the rounding value.
Ex:
Rounding value: 0.05
Amount to pay: 0.04
The amount to pay should remain 0.04 and not be rounded to 0.05.

This fix allows the user to pay for values under the rounding value without applying the rounding.

closes odoo/odoo#81302

Signed-off-by: Masereel Pierre <pim@odoo.com>

Expected behaviour

When having multiple promotions with, for example, a promotion of X% for the
first order and a promotion of Y% (Y<X), we should apply the first promotion
on the first order and then don't get this promotion into account to choose
the best promotion for a future order, so that we have:
1. A promotion of X% on the first order
2. A promotion of Y% on every other order

Observed behaviour

When trying to apply promotion on other order, nothing seems to happen, as
Odoo take the already-used X% promotion into account, being the most
interesting promotion, select it as the best promotion to apply and then
apply it to finally get a result of a 0% discount as the promotion has
already been used.

Problem Root Cause

As it can be seen in the commit, the error comes from the fact we filtered
the available promotion with a non-strict inequality.

Validation

A test has been added in test_program_numbers.py to validate our fix

Related issue

- opw-2674681

closes odoo/odoo#80192

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

Bug
===
Since 85053a8b we limited the access
of the registration to the event users. But now we want to limit the
access to the internal users.

So only the portal users and the public users will be concerned by this
restriction.

Task-2666823

closes odoo/odoo#78235

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

After paying the expense report, the lines are reconciled right away but
with this old code I can't inherit the custom reconciliation lines. So I
provide a hook method to be able to inherit and customize the lines that
want to be reconciled.

closes odoo/odoo#81267

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

The aim of this commit is to make the cogs generation multi-company
safe.

Before this commit:
When posting an invoice from company B with both company A and B
selected and A being selected as "main", the cost from company A could
be selected instead of cost from company A to create the anglosaxon
lines.

After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.

closes odoo/odoo#79674

Task: #2686104
Signed-off-by: Laurent Smet <las@odoo.com>

If you create an individual contact that has a company contact as the
parent, it will inherit certain fields from that parent, which are
defined by `_address_fields` in `res.partner`.

`base_address_city` allows enforcing picking a city from a pre-defined
list, which gets stored in `city_id` instead of the standard free-text
`city` field on `res.partner`. If you change `city_id`, an `onchange`
will update `city`.

`city_id` was not being inherited from the parent, which means the
contact ends up in an inconsistent state: `city` will be set, but
`city_id` will not.

In the Colombian accounting localization, which uses the enforced city
feature, a municipality code which is part of the record behind
`city_id` is mandatory in certain electronic invoice XML fields that get
sent to Carvajal. This value will incorrectly be 0 if `city_id` is not
set on the contact due to the above issue, causing the invoice to be
rejected.

This fix lets a contact inherit the `city_id` from its parent if
`base_address_city` is installed.

opw-2638687

closes odoo/odoo#81230

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

closes odoo/odoo#81194

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

This fixes inconsistencies when dealing with fields that are computed
and inversed by the same methods.

Consider two fields F1, F2 with the same compute and inverse methods.
Consider a record where we wrote on a dependency of the common compute
method.  At this point, both fields F1 and F2 are marked to be computed.

Now let us write on F1 only.  Here is what happens:
 - the write discards the computation of F1, but not F2
 - the inverse method of F1 is called:
    - the method accesses F2
       -> this calls the compute method, which assigns both F1 and F2
    - the method accesses F1
       -> the value of F1 has been replaced by the computation above

The issue comes from a combination of factors:
 - the value of F2 must be determined by the computation;
 - the computation assigns both F1 and F2;
 - the computation is done while inversing F1 (and F2).

The solution is to force the computation before actually writing on the
fields and calling their inverse methods.  Note that this is necessary
only when part of the fields computed by a common method are updated.
When all fields computed by a common method are updated, the computation
will automatically be cancelled.

closes odoo/odoo#81105

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

How to reproduce:
1: create two employees (A B)  and two departments (C D)
2: Assign A as manager of C and B as manager of D
3: Assign C as A's department and A as A's manager
4: Change A's department to D -> A is deleted

This is due to `parent_id` being both a computed field and the source
field for a One2many. By changing the `department_id` the `parent_id`
also changed which results in it being report in the `onchange` method.
For some reason however the command sent by the orm is not `UNLINK` but
`DELETE` which results in the `active_id` being deleted.

TaskId-2711428

closes odoo/odoo#81122

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