the `write` method from `AccountMove` class and its children
expect `journal_id` in `vals` to be an `int` and not an `account.journal`.

linked PR : https://github.com/odoo/enterprise/pull/26515



opw-2794392

closes odoo/odoo#89854

Related: odoo/enterprise#26515
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

First thing is that when you send an invoice to PA in test/production,
it should be considered as sent after the xml is generated as we do not
have the functionality to send sign invoices yet.

We added a test for posting the invoice when the invoice partner has a
l10n_it_pa_index (and it is of length 6).

Alos, when the proxy user is a 'demo' user, creates a
traceback. The solution is to only add the demo response to those that
would have been sent to the iap server otherwise.

We also avoid doing a call to the IAP server if there are no invoices to be
sent (e.g. because they all go to the PA)

opw-2807213

closes odoo/odoo#91020

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

[IMP] account_invoice: prevent erasing of a tax line entry if there is a tax related to it in the invoice

This is actually checking if for each tax of each line of invoice in the move, there exist a tax entry.
This will prevent the users from accidentally or dully erasing tax lines which includes 0% taxes.
If the users delete the line containing tax, it will be added again the same way as the counterpart line
for an invoice line is being added.

Also, fixes the following:
Recalculating all invoices if a single invoice in a batch has a line with `recompute_tax_line` set should not be allowed.
Deleting a tax account entry of a posted move should not be allowed.

task ID:2834679

closes odoo/odoo#91140

Pr: #90834
X-original-commit: ac3cf2ed
Signed-off-by: William André (wan) <wan@odoo.com>

The current problem is that the codice fiscale field is validated using
a regex that matches an alphanumeric code of 16 digits (that causes no
problems) and both a simple numeric code (of 11 digits) and an
alphanumeric code (of 13 digits, starting with the country code 'IT')
for businesses. The problem is that the systems that make use of the
codice fiscale code tend to utilise the former (i.e. the 11 digit code,
without the 'IT' prefix).

The filename for the EDI comprises a country code, the codice fiscale of
the company and a progressive number. When the codice fiscale is
completed as being eg. 'IT00465840031', the country code + codice
fiscale will be 'ITIT00465840031', which will be rejected by the edi
system (a single country code is expected).

This commit removes the 'IT' in the xml by utilising a function on the
template _l10n_it_normalize_codice_fiscale from the res.partner model.

related ticket-id: 2845341

closes odoo/odoo#90900

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

When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one.

closes odoo/odoo#88303

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

The file extension detection previously used to determine whether a
filename required an extension was not very smart and in fact only
checked for a dot in the filename.
`mimetypes.guess_type` is now used on the filename to better determine
whether the filename still needs a file extension or not.

This commit is a follow-up to: https://github.com/odoo/odoo/pull/90614


Which aimed to fix the same issue.

TaskId-2826061

closes odoo/odoo#91192

X-original-commit: 1a75900b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

When moving some products between two warehouses thanks to an internal
transfer, the forecasted inventory becomes incorrect

To reproduce the issue:
1. In Settings, enable "Multi-Warehouses"
2. Let WH01 be the existing warehouse. Create a second one WH02
3. Create a storable product P
4. Update the quantity of P:
    - 3 in WH01/Stock
5. Create a planned and internal transfer T:
    - Source: WH01/Stock
    - Destination: WH02/Stock
        - Ignore the warning
    - Operations:
        - 1 x P
6. Mark T as todo
7. Open the Forecasted Inventory:
    - Filters:
        - Forecasted Stock
        - Product: P
    - Group By: Warehouse

Error: The report is incorrect, it says there are 3 P in WH01 and 0 in
WH02 (should be 2 and 1). It becomes worst if T is done (the quantities
in the past become incorrect)

We should be able to move a product between two warehouses thanks to an
internal transfer (so the warning of the step 5 should be removed).
Moreover, the `report.stock.quantity` should consider that use case.

When processing a stock move, the SQL view translates it as an in-move
or out-move for a specific warehouse. For instance, if the SM comes from
a warehouse and goes to a location without any warehouse (e.g., customer
location), the SM is considered as an out-move. But here is the issue:
in case of an inter-warehouse SM, both source and destination have a
defined warehouse.

Therefore, we need to:
- Duplicate the inter-warehouses SM (so we have one in and one out)
- Fake the values (no destination warehouse for the out move, no source
warehouse for the in move)

Also, before duplicating all SM, we filter out some useless SM:
- Draft and cancelled ones
- SM done more than 3 months ago (because the report only works for [-3
months; +3 months])

Considering some tests:
(SM are confirmed. Each test has been repeated 5 times to get an
average)
|                                       |          |
|:-------------------------------------:|:--------:|
| 5000 SM, 0% inter-wh, without the fix |  ~715 ms |
| 5000 SM, 0% inter-wh, with the fix    |  ~710 ms |
|                 Impact                |   0.99x  |
|                                       |          |
| 6666 SM, 0% inter-wh, without the fix |  ~911 ms |
| 5000 SM, 33% inter-wh, with the fix   |  ~999 ms |
|                 Impact                |   1.10x  |
|                                       |          |
| 7500 SM, 0% inter-wh, without the fix | ~1004 ms |
| 5000 SM, 50% inter-wh, with the fix   | ~1097 ms |
|                 Impact                |   1.09x  |

The impact is not that significant

OPW-2752017
task-2822157

closes odoo/odoo#91056

X-original-commit: b6833702
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

The field `duration` was still declared but has actually been removed
from the SQL view with d2238de5.

Avoid an error when trying to read this field.

Error spotted by odoo/upgrade#3511

closes odoo/odoo#91186

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

If applied, this commit will fix the following bug by adding some
restrictions on the creation of analytic default
and the uses of tags in account.move

Steps to reproduce:
1- install account.accountant, account_analytic_default
2- Accounting --> Configuration --> Analytic Tags, analytic accounting
3-  Create an Analytic Tag, with no Analytic Distribution.
4-  Accounting --> Configuration --> Analytic Default Rules.
Create an Analytic Default Rule, using the Analytic Tag above
and select a Partner
5- Create a Vendor Bill on that partner. The Analytic Tag is added to
the invoice, as expected
6- However when selecting Accounting --> Reporting --> Analytic Report,
the report is empty and does not contain the Analytic Tag. Adding the
 Analytic Tag to the filter has no effect.
Bug/Issue:
An analytic tag is meant to be an additional dimension of analysis.
Dimension which is only worth/valid when an analytic account is
specified.

An analytic default rule should never be applied without
- either an analytic account
- or analytic tag used for distribution
Fixes:
1- changing the error condition on creating analytic default
2- changing the error message accordingly to better explain the issue
3- raise an error when the user creates an account.move with analytic
tags without (analytic tags + analytic account) or (analytic tags with
analytic distrubtion)

Please refer to the ticket for the whole discussion on this

OPW-2766749

closes odoo/odoo#90866

X-original-commit: d80dfd30
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

The current implementation is rather non-standard and largely an
ad-hoc pre-RFC implementation, with a number of incompatibilities with
the standard & actual real-world identity providers (IDP).

Tested with the following IDP:

- google oauth v1
- google oauth v3
- auth0
- okta

Add support to bearer Authorization
===================================

Sending the access token via "Authorization: Bearer $TOK" is strongly
recommended by the RFC, and required for all IDP to support. The query
parameter method is a legacy compatibility method and should be
avoided.

Query parameter access tokens are supported by Google (both v1 and
v3), and auth0, but not okta. All three support bearer tokens. However
making this the default is complicated by compatibility issues with
current behavior.

Use standard `sub`ject for identity
===================================

The specification defines `sub` as the userinfo key providing the user
identifier at the IDP.

- auth0, okta, and google v3 use `sub`
- google v1 uses `id`
- google v1's `tokeninfo` (possibly v3 as well, not tested) uses
  `user_id`
- odoo replicates the google v1 tokeninfo behavior, using `user_id`

All the code is now standardised on `sub`, with `_auth_oauth_validate`
performing unification under that key.

Support non-json error bodies and WWW-Authenticate
==================================================

Per-spec, there is no requirement for error (userinfo) responses to
return any body, and all error information can be returned via
`WWW-Authenticate`.

Both auth0 and okta return empty bodies on error, though only okta
returns a useful www-authenticate, or relevant 40x statuses (auth0
seems to always return 400, okta has been observed to return both 400
and 401 depending on client error).

Error handling in `_auth_oauth_rpc` has been updated to only parse the
body as json on success (200), and fallback on a generic error payload
if `WWW-Authenticate` doesn't contain relevant information.

Nonce
=====

Okta requires a nonce to be provided.

Misc
====

A few improvements which are in no way required but should make things
simpler / clearer:

- update the default scope to match the standard for the implicit
  flow's values (intersected with our requirements)
- update the default google configuration to use the v3 endpoints and
  drop the tokeninfo request, remove the explicit scopes
- update the label of `validation_endpoint` to match the official
  terminology, same with `auth_endpoint`
- add a label to `body` in order to explain what it's for (as that's
  really confusing when the form just says `body` until you hover the
  field)

Expected future updates
=======================

These issues were left out and may lead to degraded security, but were
considered too large changes fora stable compatibility-oriented
update:

* store and validate the nonce
* request and properly validate the id token, as well as validate the
  access token (implicit guide sections 2.2.1, 2.2.2)
* implement "basic" flow[^basic], and / or "hybrid" flow, the implicit
  flow[^implicit] is intended for purely client-side applications
  (SPAs), the "authorization code" flow is intended as the primary
  flow for normal web applications involving a server component,
  the main advantage of the hybrid flow is that the id token *can*
  contain the claims selected by `scope`, avoiding the need for the
  userinfo request[^idtoken]
* remove support for query parameter requests
* remove support for Google's v1 oauth and subject identifiers other
  than `sub`, facebook has not been tested but looks to support that
  key as well in the OpenGraph API[^fb], this will require migrating
  existing google providers to v3 implicitly (but would allow
  simplifying their configuration)

References: RFC 6749, RFC 6750, Implicit Client Implementer's Guide
1.0 draft 23[^implicit]

Closes #88618, closes #64348, fixes #63963, closes #63970,
closes #69568

[^implicit]: https://openid.net/specs/openid-connect-implicit-1_0.html
[^basic]: https://openid.net/specs/openid-connect-basic-1_0.html also
          known as "authorization code" flow
[^fb]: https://www.facebook.com/.well-known/openid-configuration


[^idtoken]: during testing, only auth0 returned the additional claims
            as part of the id token, but this may be a configuration
            issue

closes odoo/odoo#91191

X-original-commit: 56fe16bd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Currently, "Editor and Designer" can't edit the views which originate
from a theme (which are copies from the theme `theme.ir.ui.view`
records).

This error is caused by [1], which is preventing the `arch_updated`
field to be set to `True`, as this field is supposed to be set to `True`
only on manual user change, not during module update.

Indeed, restricted users don't have access to the themes records, making
the overide raising an error.

But there were actually no reason for this code to be executed outside
module operation.

Steps to reproduce:
- Create any view in a theme module.
  For example: create a custom footer view.
- As a "Editor and Designer" user, edit this view through the website
  builder.
- An access right error is raised.

[1]: https://github.com/odoo/odoo/commit/1eb7c577ecb31c2f0876b6dd76769e2b47802cb0



closes odoo/odoo#88990

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

We can use ._search() to make sure that permissions and ir.rules are applied. By making use of psql subqueries, we remove the need of costly python filtering afterwards, thus increasing performance.

Created test_meeting_count() to check that that the computing of meeting_count is done correctly.

closes odoo/odoo#88460

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

Functions like `_get_price_total_and_subtotal` should be able to handle false-y values like 0 or empty recordset,
currently invoking them with these values (e.g. discount=0) leads to use record values instead of given values.

closes odoo/odoo#91030

X-original-commit: 045aaf31
Signed-off-by: William André (wan) <wan@odoo.com>

How to reproduce the bug ?

- install hr_payroll and web_studio
- in Settings > Technical > Automated Actions, create a new action
linked to the Payslip model
- Go to the Payslip app and generate a payslip by choosing an employee
that has work entries

What is the bug ?

When you create an automated action, you will overwrite the origin write
function of the model. However, the origin write function will still be
called by the new write function.
In the new write function, the records will be filtered according to
their ids. This means that if a record has a NewId, it will not be
handled. This is the bug here since the payslip is under creation.

opw-2781751

closes odoo/odoo#88071

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

Before this commit, it was possible to click on the "Create page" button
before the JS was loaded, as that button is a simple link with a href.
But that link is supposed to be handled by the JS which transform the
GET href link to a fake form submit to send a POST request to the
`/website/add` controller.

If the user clicks before the JS had the chance to handle that click and
do the "transformation", the controller will reject the GET request and
a raw 405 error page will be shown.

Now, we wait for the JS to be fully loaded before allowing user to click
on this button.
The fix is made globally as it should be the case of every link related
to this behavior.

Note that the `/website/add` controller was changed from GET to POST
with commit [1]. It most likely forgot to adapt the button from the 404
page which was later done with [2] by using the `post_link` util class
introduced with [3] (for need of website_blog at the time).

[1]: https://github.com/odoo/odoo/commit/714f0aa07f25e8a88a778e8b21c79b48e9801231
[2]: https://github.com/odoo/odoo/commit/2c85c1cb6ee0f6000cd2db182d5b8cfd3d040876
[3]: https://github.com/odoo/odoo/commit/0f2cada32319b3910d6ace6d412cfa94a646c9c7



task-2847785

closes odoo/odoo#90869

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

# Issue:
With User1, create a MO with work orders, and start one Work Order.
With User2, go to the MO, and start the same Work Order
=> Nothing happen, we currently prevent the workorders to have more than 1 open Time Tracking.

OPW-2845080

closes odoo/odoo#91033

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

Prior to this commit:

- If the color attribute is set on a field on which the user might
  not have access to the model / record, a traceback is returned. However,
  in the case of a M2O, the name_get would be returned, so its is
  a pity that the color raise an access error.

After this commit:

- A search_read is made instead of a read, which returns nothing if
  the user does not have access to the model / record and does not raise
  a traceback.

closes odoo/odoo#90989

Signed-off-by: Géry Debongnie <ged@odoo.com>

The _get_unece_code method does not work in case where a specific uom
has multiple xml_ids.
Change it to handle such case and try to match every xml ids with a
unece code if possible.

closes odoo/odoo#90984

X-original-commit: f97fe80f
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>

With this commit, we allow mutliple payments with manual
check printing.

Steps to reproduce:

- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...

Setting the check_numbers before calling the super of
payment.action_post.

opw-2830586

closes odoo/odoo#90929

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

Current behavior:
In PoS restaurant cashier were not saved correctly in db if you
switched table before making the payment of the order.

Steps to reproduce:
- Install PoS
- Activate restaurant on one of your PoS
- Activate Authorized employee
- Start a PoS session, and select a cashier
- Create an order on a table
- Leave the table and comeback to it
- Make the payment for the order
- Go in the PoS orders, the cashier wasn't saved

opw-2794574

closes odoo/odoo#88825

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

An activity should be posted only when a SO is cancelled, this happens
after _action_cancel as action_cancel doesn't always cancel the order.

sale_purchase was forgotten in commit
7c8f15d4141d4ae130da59d58ee2eaff39e363c4

Backport of 7a146e6f

closes odoo/odoo#90959

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Steps to reproduce:

- Create invoice for a prudict at price X > 0
- Change the price to 0 before saving
- Then save it
-> Error : Cannot create unbalanced journal entry

This bug was introduced in 14.0 with this commit fe7d56dc32c71e04b54de9dbd756a48942a832f4
With this commit, we use an ugly condition to catch the
specific case of a tax with price included and amount type division
to avoid changing the price unit if the line balance is zero.

opw-2822635

closes odoo/odoo#90794

X-original-commit: bd621fd4
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>

Before this commit, some images were never appearing on Chrome,
especially when using the 90% zoom.

Steps to reproduce (on a 1920x1080 screen and using Chrome):
1. Edit the homepage
2. Add a "Cover" block and setup a 50% min-height on it
3. Add 2 "Columns" blocks below the "Cover" block
4. Set the width of the first "Columns" snippet's first image to the
   recommended size (690px)
5. Save
6. As a public user, set the browser zoom to 90% and go to the page
   (you may need to reload the page again so images are in cache)

=> The first image of the second "Columns" block never appears.

opw-2731507

closes odoo/odoo#90905

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

Step to reproduce:
	Install purchase
	Create a purchase order
	Set a vendo and a product that has this vendor in its
	vendor list
	Set a product name in the line of the vendor in the product
	purchase section (you will need to add the field)
	Change the description of the product
	Change the quantity of the product

Expected behavior:
The description stay the custom input you just set

Current behavior:
The description is reset to its default value

Explanation:
When changing the quantity the vendor from the product vendors can change.
Then its vendor product name and code can change and thus the default
description in the purchase order. To solve that we need to differentiate
a custom description from a default one and only update the descritpion
when the quantity changes if the descritpion is a default one (and not a
sutom one)

opw-2827667

closes odoo/odoo#90764

X-original-commit: d5408b80
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>

revert of 135f3d7b373d07fb1f0a27145df3d3cd9fc28337
We don't want to consume a sequence in a compute.

closes odoo/odoo#90847

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

Before this commit:
calling `odoo-bin cloc -P <path_to_a_module>` when the manifest of a
module includes an empty string in the demo, demo_xml or cloc_exclude
entries, would result in a crash because an empty string is not an
acceptable pattern for Path.glob

to note: an empty string in those entries is technically wrong and will
cause issue during module install, but that shouldn't prevent the cloc
from giving correct results.

closes odoo/odoo#90583

X-original-commit: 93318b22
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>

Loading the demo data of Accounting app when only Japanese language is
installed will raise an error because there is a non-unique alias_name

Steps to reproduce:
1. - Run odoo with parameters `-d [db_name] --without-demo all
--load-language ja_JP -i l10n_jp,account_accountant` (you can also
install those apps using the UI but only Japanese should be installed
so it will be in Japanese)
   - Or create a trial database on odoo.com with Accounting installed,
using Japan as country and Japanese as language
2. Activate debug mode and go to Settings, scroll to the bottom and load
the demo data (`デモデータをロード`, last link in 'Developer Tools')
3. A validation error is thrown

Solution:
When building the alias name, if the name of the journal is not in
ascii, use the journal's code or type followed by the company's name. If
the company's name is not ascii, use the company id as suffix

Problem:
When a journal with non-ascii characters in its name is created, its
alias name fallbacks to the journal's code. In the demo data, two
journals have the same code. It will try to create the second journal
with the same alias name, violating the unicity check in
`_clean_and_check_unique`.

opw-2831638

closes odoo/odoo#90429

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

With this commit, we make sure that all lines are fully reconciled when
reversing a move.

Steps to reproduce:

- Create a Journal Entry, with eg a line with 300$ debit/credit and two others
lines to make the journal entry fully balanced
- Then reverse the move
-> Only one line is marked as fully reconciled, the other one is marked
as partially reconciled.

This is because each line was passed in the reconcile method with
all the counterpart lines, even those which didn't belong to it.
Therefore, all the firsts lines was marked as partially reconciled
until the last one, which passed with the only counterpart line
left.

With this commit, we group the lines and counterpart lines by account,
and reconcile them.

opw-2810392

closes odoo/odoo#89254

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

closes odoo/odoo#90419

X-original-commit: 901ca05e
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

on invoice, all round is default to half_up
but on efaktur export is half_down

ref #89793

X-original-commit: bd21e88a
Part-of: odoo/odoo#90419

What is the problem?
We assumed that an all-day event's end date is exclusive which means
that, for example, for a single all-day event on the 2022-03-20,
we have:
start = {'date': '2022-03-20'}
end = {'date': '2022-03-21'}

But it's acceptable for Google to have an all-day event where the start
and end dates are the same:
start = {'date': '2022-03-20'}
end = {'date': '2022-03-20'}

For checking the acceptability of this format, you can test it:
https://developers.google.com/calendar/api/v3/reference/events/insert



It caused an issue because we decreased one day from the end date to
convert it to the odoo values, so the stop became smaller than the
start:
start = '2022-03-20 00:00:00'
stop = '2022-03-19 00:00:00'

It's not possible to reproduce the issue by the Google calendar UI.
However, you can insert an event with this format by using the APIs
and get that event to reproduce the problem.

The solution is to use start if the stop becomes smaller than it.

opw-2753872

closes odoo/odoo#87646

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

This commit aims to fix an issue when downloading attachments and using
'name' as the field for the file's name.
When 'name' contains a dot, the file is considered to already have a
file extension, and thus the right extension is not added to the name.
After this commit, using 'name' as a filename field will also consider
the name to be a 'default' for any other model than `ir.attachment`.

TaskId-2826061

closes odoo/odoo#90746

X-original-commit: ca854b66
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

in master datetime (the module) is unused, so keep datetime (the class).

line 9: import datetime
line 29: from datetime import datetime, date
line 1605: datetime.datetime.strptime(mtime.split('.')[0], server_format)

type object 'datetime.datetime' has no attribute 'datetime'

closes odoo/odoo#90612

X-original-commit: 8d37ac32
Signed-off-by: Julien Castiaux <juc@odoo.com>

In some languages and layout the currency symbol might be wrapped in a separate
line, which is not acceptable from accounting point of view. Fix it by replacing
space with a special symbol.

STEPS for v15:
* install MX localization;
* create a Spanish speaking customer
* generate a pdf:
1) Create quotation with products
2) Add IVA 16%tax
3) print a report

BEFORE: the currency symbol is incorrectly displayed on a separate line
AFTER:  currency symbol is always with the amount

---

https://github.com/odoo/odoo/pull/89722


opw-2829138

closes odoo/odoo#90591

X-original-commit: a9d38db2
Related: odoo/enterprise#26978
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

Apply next sequence check number with multiple payments

Steps to reproduce:

- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...

Remove the action_post method as it was not necessary anymore
because we compute the check_number in the compute_check_number method.
The check number should be computed only if the payment is posted,
that's why we filter on payment state.

opw-2830586

closes odoo/odoo#90193

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

This provides the possibility to import/export simplified invoices.
Currently, the import of simplified invoices would not work and the export of invoice without customer address would be blocked.
Simplified invoice will be able to be imported and exported if the customer address is incomplete, it's a domestic invoice and the total amount is below 400€

freeze_time was removed as it was unnecesarry and posting invoice would not be done directly as the invoicing date is in the future wrt the frozen time.

closes odoo/odoo#90052

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

It may happen than the routing map is cleared while rendering a qweb
view. For example, if an asset bundle is regenerated, the previous one
is unlinked, which causes a cache clearing.

Previously-generated EndPoint objects aren't found any more in the new
routing map, so `request.endpoint` cannot be used any more after a cache
clearing.

This commit adds hash and comparison magic methods on http.EndPoint so
that EndPoint objects created by a previous routing map generation can
still be used after a cache clearing.

Two tests were added: one to test the comparison and hash methods, and
the other to test them in a real-case rendering.

Commit 80a04f7e fixed this bug too, but introduced another issue
which caused many OPW, so it was quickly reverted by deb23450 along
with its performance improvement 33167b39. This commit replaces
80a04f7e with another way to fix the issue.
A third test has been added in order to avoid reintroducing this other
issue.

By the way, this commit also removes the EndPoint.arguments attribute,
as commit 17f19926 removed all usages of this attribute in Odoo 9.0,
but left this initialization here.

OPW-2834546
OPW-2834549
OPW-2834625

closes odoo/odoo#90745

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

closes odoo/odoo#90740

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

Steps :
Go to a Project's settings.
In your 'Following' preferences, uncheck 'Task Rating'.
Create a new Task in this Project and see your preferences.

Issue :
Task Rating is checked.

Cause :
The default value of project's task rating notification is True.
The value of its task's is supposed to be inheritted from there.
Yet, this inherittance only happen when default is False.

Fix :
Set default to False.

opw-282497

closes odoo/odoo#90719

X-original-commit: e4f861ce
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>