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>

A user should be able to scrap some products thanks to an internal
transfer.

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a storable product P and update its quantity (> 1)
3. Create a planned and internal transfer T:
    - From: WH/Stock
    - To: Virtual Locations/YourCompany: Scrap
    - With: 1 x P
4. Mark T as done

Error: T is still in draft

The `_compute_state` of a picking should not ignore the scrapped moves.
However, if we include them, we need to think about this use case: a
picking with a cancelled normal move and a done scrapped move -> its
state should be cancelled (see use case and test from [1])

[1] 429b5896

OPW-2841190

closes odoo/odoo#90725

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

How to reproduce the bug ?

- install the CRM and sales modules
- remove the user from the all the sales security group
- go back to the dashboard and click on settings

What is the bug ?

The res.config.settings model of the CRM module has a field referencing
the crm.lead.scoring.frequency model. This model can only be accessed by
the members of the sale security groups. If an admin is not part of the
sales group, he will get an error when he wants to access the settings
while he will not see the sales or the crm settings tab.

opw-2755177

closes odoo/odoo#90483

X-original-commit: 95da07bd
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>

Intended to cleanup qweb xmls:
- remove blank (empty) nodes and/or nodes with whitespace text
- fix indentation
- remove indentation (needed for some xml signatures)

closes odoo/odoo#90500

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

Same steps as [1], but add a section or a note on the SO.

It will raise an error: "AssertionError: precision_rounding must be
positive, got 0.0"

[1] 1351f370

closes odoo/odoo#90675

X-original-commit: 27c18035
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

If we had a product as an option to multiple products and we want to stop selling it we'll set sale_ok to `False`. We won't be able to add it to the sale lines but it will keep showing up in the products options popup and we'll be able to add it to the order that way. It must be prevented to keep a coherent behavior.

Description of the issue/feature this PR addresses:

- Add a product as optional product A to several products (B, C, D).
- Set that product to `sale_ok` = False
- Create a sale order

Current behavior before PR:

- Product A can't be selected from the order lines (

 )
- Add either product B, C or D and the optional products popup shows up allowing us to add Product A to the sale lines.

Desired behavior after PR is merged:

When a product is discarded from sale, we should not be able to add it as an option. Removing it as option in the affected product is not a proper workflow, as the product could be simply temporarily out of sale due to multiple commercial reasons.

cc @Tecnativa TT36178

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#90674

Forward-port-of: odoo/odoo#90593
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When triggering an inter-warehouses reordering rule, the partner of the
receipt is incorrect. When triggering several inter-warehouses
reordering rules, it will remove the partner of both receipt and
delivery

To reproduce the issue:
(Let C be the current company)
1. In Settings, enable "Multi-Step Routes"
2. Let WH01 be the existing warehouse. Edit WH01:
    - Set a new address ADD01:
        - Type: Individual
        - Company: C
        - Address Type: Delivery Address
3. Create a new warehouse WH02:
    - Set a new address ADD02:
        - Type: Individual
        - Company: C
        - Address Type: Delivery Address
4. Edit WH02:
    - Resupply From: WH01
5. Create 2 products PA, PB:
    - Type: Storable
    - Routes:
        - WH02: Supply product from WH01
6. For product PA:
    - Update the quantity:
        - 10 in WH01/Stock
    - Add a reordering rule:
        - Location: WH02/Stock
        - Trigger: Manual
        - Min = Max = 1
7. Run the scheduler
    - It generates a delivery D and a receipt R
8. Open R
    - Error 01: the field "Receive From" is incorrect (ADD02 instead of
ADD01)
9. Repeat step 6 for PB and run the scheduler again
    - Error 02: R and D have no more partner

Error 01: see diff

Error 02: we have two SM (one for PA, one for PB) that have a different
origin (one per reordering rule). Therefore, we remove the origin of the
pickings. However, we also remove the partners while we shouldn't

OPW-2733989

closes odoo/odoo#90557

X-original-commit: c08ebc3a
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Current behavior :
When a workorder is marked as done, the returned view is inconsistent between
"control panel" and work orders' list view.
- "Control panel"  : we correctly land back to workorders from this workcenter
- List : we land back to an empty list view

Steps :
- Install Manufacturing
- Get or create a manufactured product
- For this product, plan some orders in a work center
*Control Panel view*
- Proccess to a workorder and mark it as done
-> Correctly redirected to a kanban view with remaining workorder linked to
this work center
*List view*
- Proccess to a workorder and mark it as done
-> Redirected to an empty list view

OPW-2767737

closes odoo/odoo#88780

Related: odoo/enterprise#26226
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

This could lead to a traceback in case the user's priviledge is not
sufficient to make the name_search

closes odoo/odoo#90592

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

Usecase to reproduce:
- Product A with Vendor supplier lead time=1day
- Product B with same Vendor supplier lead time=4days
- Launch the replenishment report for both products at the same time

Current Behavior:
The expected arrival is correct but the order date deadline is today - 3
days

Wanted Behavior:
Same but the order date dead line is today

It happens because it does the minimum of expected arrivals - max of
supplier delays. However the supplier delays are already correctly
apply on each procurement (correct expected arrival). To know the
correct order deadline we should instead take the minimum date planned
with the related supplier delay.

opw-2822588

closes odoo/odoo#90316

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