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>

The countdown snippet has an end action that can be configured to show a
message when the countdown reaches zero. A button in the editor toggles
a preview of this message. However, a bug currently makes the preview
disappear whenever the snippet's widget is restarted... which occurs by
simply hovering some other options.

To solve the problem, the preview visibility is now controlled by a
separate css class s_countdown_enable_preview overriding d-none. This
way, the preview visibility no longer interacts with the widget's logic
and is no longer affected by the widget restarting.

task-2638366

Part-of: odoo/odoo#76343

Currently Bank Suspense Account has "Current Liabilities" type, while it should be "Current Assets"

Task ID: 2702804

closes odoo/odoo#81071

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

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

2 bugs are fixed in this forwardport commit:
- The product.valuation on the line wasn't evaluated in a company safe
way.
- cogs method weren't company safe either

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.

- If company B's product isn't in real time valuation, cogs aren't even
created.

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

closes odoo/odoo#81256

Task: #2686104 and #2713607
X-original-commit: 3f777d43
Signed-off-by: Laurent Smet <las@odoo.com>

Since v14 (with commit[1]), we prevented users from creating 'link.tracker'
and 'link.tracker.click' records.

This is not ideal because creation of the link trackers should be allowed
whenever needed (for example to add it in a button somewhere, ...) unlike
'link.tracker.click', which is a technical model and so the records should
always be created by system.

This commit partially reverts commit[1] and allows users to create the
'link.tracker' records if user is having enough access rights.

commit[1] - https://github.com/odoo/odoo/commit/d43082233dda770a298e9ed321a792740d4deaa4



TaskId- 2712107

closes odoo/odoo#81279

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

When the system broadcasts an email response to document followers,
if the config parameters `mail.force.smtp.from` or
`mail.dynamic.smtp.from` are defined, it will rewrite the `From`
address to avoid spoofing the sender's domain.

For example, if the `mail.catchall.domain` is set to `example.com` and
an email response comes from:

   "John D" <john@doe.com>

it will rewrite it to:

   "John D (john@doe.com)" <notifications@example.com>

This will make sure the system never sends outgoing email for an external
domain, as it has no authority for doing so, and that could
break mail filtering/authentication rules (SPF, DMARC, etc.)

During this "encapsulation rewrite step", both the original Sender name
and their email are preserved, and put into the quoted "name" field of
the rewritten address. It seems sensible to preserve as much information
as possible about the original sender.

Unfortunately, the inclusion of the Sender email in the final name makes
it appear to some inbox providers as if the message is trying to
deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in
the UI when it happens. It will keep only the rewritten email, which is not
very useful in the case of a notification (even though it's more
technically correct, of course).

This patch removes the original email from the rewritten notification,
keeping only the name, considering that the email is not the most
important part, and it's better to have one of the two than none.

So after the patch, the rewritten address is now:

   "John D" <notifications@example.com>

When there is no name in the original address, we keep only the local
part of the email, to avoid the same display issue. The recipient will
have to identify the sender based on the context / past messages.

closes odoo/odoo#79979

Signed-off-by: Olivier Dony <odo@odoo.com>

- Create a TAX A and TAX B
- Create a fiscal position, and TAX A in scr and TAX B in dest, and add other tax map
- Use this fiscal position in POS
- A month latter unactive TAX B (because the law have change).
--> You have an issue during opening the pos

closes odoo/odoo#80739

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

Current behavior :
Quantity displayed on 'Detailed operations' block for a product lot isn't correctly displayed on the invoice sometimes.

Steps to reproduce : 
- Install Sales and Stock
- Enable 'Units of Measure' in Settings
- Enable debug mode then go to Users and enable 'Display Serial & Lot Number on Invoices' for current user (i.e. Mitchell Admin)
- Create a new product
  - Tracking set to 'By Lots'
  - UoM set to 'g'
- Create a quotation with the previously created product and set the quantity to 3.07
- Confirm the quotation, go to the Delivery and confirm it too
- Go back to the SO and create the invoice, then go to the invoice and confirm it
- Print the invoice

OPW-2704307

closes odoo/odoo#81313

Signed-off-by: Arnold Moyaux <arm@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#81239

X-original-commit: e4345c81
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Raf Geens <raf@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#81330

X-original-commit: 76ccaaf0
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#81308

X-original-commit: d2c58a9d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

When an event is created from an external calendar account such as
Google or Outlook, attendee info such as email and state may be given,
and should be taken into account.

For example, if the current user who is syncing his calendar is not
the organizer of the event, his attendee state should be set to
'needsAction' and not automatically set to 'accepted'.

opw-2489815

closes odoo/odoo#79313

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