invoice line

Steps:
- Create 2 service products with "Invoicing based on timesheet" & " Create a task in sales order's project"
- Create a SO with both products > confirm
- Add hours to both tasks
- Create invoice > remove one invoice line > Save

Issue:
- The removed invoice line is still appearing in the Timesheet stat button

Cause:
- account_analytic_line.timesheet_invoice_id is set to the invoice when the invoice is created
- It is not reset to False when the line is removed from the invoice

Fix:
- Reset it to False when the move the line is removed from invoice

opw-2668814

closes odoo/odoo#81145

Signed-off-by: Laurent Stukkens (ltu) <ltu@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#81808

X-original-commit: d60c3ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

closes odoo/odoo#81772

X-original-commit: 9b39cd51
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#81776

X-original-commit: d90b03e2
Signed-off-by: Martin Trigaux (mat) <mat@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#81588

Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@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#81588

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

X-original-commit: 24d32f3d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

When clicking on save, the saved HTML should be what the user currently
sees. Before this commit, there might be cases where clicking on save
actually triggers a DOM update which occurs too late for the change to
be considered for the save. In 15.0, this manifests for example with
the blog cover saving*: if the color is being changed with the
colorpicker and that the user does not close the colorpicker before
saving, the color change is not considered because the previewMode=false
update of the colorpicker is not received. With this commit, we ensure
that DOM updates which occur because of the click on the save button
are considered before saving.

* That bug is however due to two other issues which are being fixed with
  the PR at [1].

[1]: https://github.com/odoo/odoo/pull/79028



closes odoo/odoo#81732

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

Before this commit, the ripple effect did not work when a button was not
in the same location/size when clicked compared to its position/size
when the page was loaded. (e.g. after scrolling the page)

task-2686370

closes odoo/odoo#80611

Signed-off-by: Quentin Smetz (qsm) <qsm@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#81477

X-original-commit: 9b665ba8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@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#81653

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

No notifications should be received whilst in Kiosk Mode.

closes odoo/odoo#81454

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

This is internal data that does not need to be shown to the user

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

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

Fix of 57665a02 which was problematic in point_of_sale

task-2388659

task-2376327

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

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

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

Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.

Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.

Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.

opw-2657048

closes odoo/odoo#80534

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

Those were not accounted for, leading to fstrings passing through
unflagged.

Also update the SQL checker to be stricter but smarter:

The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.

This flags a few more cases, all of which seem acceptable upon review.

However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).

In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.

It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.

NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.

closes odoo/odoo#81639

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Current behavior:
When creating a PO with a product and a note you had a traceback when sending reminder and clicking on "No, Update dates"

Steps to reproduce:
1. Create a PO with one line and one note
2. Confirm it
3. Click on action>Send Reminder
4. Go to the mail and click "No" => Error

opw-2709323

closes odoo/odoo#81466

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

On sale.order.line, the onchange on product_packaging ensures that a warning
is raised when changing the package if the qty on the line is not a multiple
of the package qty.
With this commit, a same warning is raised when changing the qty if the qty
on the line is not a multiple of the package qty.

closes odoo/odoo#78405

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

This label was defined with 'for="match_text_location_label"', even though it actually isn't met for just that field, but for the three boolean fields allowing to choose where to match on the statement line. As a consequence, in debug, it displayed the helper of that field, which was confusing for the user.

closes odoo/odoo#81481

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

When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.

This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.

As an example, consider the following case:

1) setup an invoice-matcing reconciliation model as such:
	- Partner Is Set and Matches = False
	- Match Invoice/bill with = Reference

2) Create an invoice with payment reference 123, for 100€

3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.

4) Try to reconcile the statement line

=> not match is found

OPW 2701729

Part-of: odoo/odoo#81481

closes odoo/odoo#77762

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

Before this commit, when the redirection of a form was an anchor and
that anchor link came from the anchor option, the scroll animation was
not triggered.

task-2172312

closes odoo/odoo#81596

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

We did not add the description of the invoice line on the print-out
of the invoice. (probably because description is not translatable
and the name of the product is)

If a product is set, the name of the product becomes the description (label)
on the invoice line,  but of course this depends on the language.

So, we only add the description if it does not correspond
to either the English (/standard language) or Arabic product description.
(People can always add both languages in the same field)

Of course, if the product is not set, it will also just show the description (label).

Also put the : of the payment reference in Arabic on the other side.

closes odoo/odoo#81464

Signed-off-by: Florian Gilbert <flg@odoo.com>

We had a constraint(raise) that said that the delivery date needed
to be after the invoice date, but this is putting too many
constraints.

However, we put a help message to say that they should put the
date of the last delivery.  Also, the delivery date should not be
changed once confirmed like the other information in the invoice.

Part-of: odoo/odoo#81464

Have an MX database set up
Activate multicurrency (MXN and USD)
Have several rate for USD
- yesterday 0.047939098170
- today 0.048486729180
Make an invoice, dated yesterday for USD 116, tax 16% (cash basis)
Create a received payment dated today, for USD 116
Reconcile invoice and payment

Jounal items will be created for the invoice, for the exchange
difference and for the cash basis entries, but there are redundant
entries addressing the tax.
This occur because when reconciling the payment with the invoice the
system create the cash basis moves and reconcile them. During this inner
reconciliation exchange difference move are created (1) just for the tax
line.
Then the outer reconciliation flow continue and compute the exchange
difference moves, considering all cash basis items created before. A new
couple of journal items will be created to account for the difference in
tax, but this is redundant since it was already covered before (1)

opw-2685570

closes odoo/odoo#79764

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

When you reload the pos (F5), this.payment_terminal is undefined.
And you can update the amount even if the payment is done.

closes odoo/odoo#72218

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

closes odoo/odoo#80938

Signed-off-by: Tiffany Chang <tic@odoo.com>

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

X-original-commit: 72cd8d07
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

When editing a countdown with a redirect action, sometimes the
countdown block will be hidden when toggling the "Hide countdown at the
end" option.

The problem is caused by the button that allows previewing
and editing the end message of the countdown, this button does not
apply in the case of a redirect action though. However, the button can
still be activated by selecting a different end action first and
switching to the redirect action afterwards, in which case it will
incorrectly hide the countdown.

task-2638366

closes odoo/odoo#76343

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