This commit fixes ACLs for slide resources:
 * Access to resources should be blocked for non-members (except publishers
 for the course: responsible and managers)
 * Tests are included

Task-2818136
Part of Task-2663320

Part-of: odoo/odoo#88454

This commit fixes the following fronted bugs:
  * One link to "buy course" that was not updated to use the post_link class
  * The join course link for "payment" courses after completing the quiz once
    logged in.
  * The link to resources that became accessible for non-authorized users for
    "payment" courses

Task-2818136
Part of Task-2663320

Part-of: odoo/odoo#88454

Since PR #90855, we add extension if mimetypes doesn't match the type.
Since guess_type don't know some extension, we prefer considere all string
of less of 8 char as an extension before to fallback on the mimetypes lib.

With this commit, a filename filename.scss will be considered with an
extension .scss by our own helper instead of a fallback on .bin or .a as
returned by guess_extension of mimetype.

closes odoo/odoo#91713

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

Prior to this commit an user could try to add a product to cart that does not
exist anymore because it was deleted while the user /shop page wasn't refreshed.

This commit avoids this (rare) use case to happen.

TaskId-2835736

closes odoo/odoo#91648

X-original-commit: 79bf7e66
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Before this commit, When project user with sales admin right try to
create a sales order > select a service product(creating a task in a
project that current user doesn't have access to) generate an access
rights error while creating a task in private project.

So in this commit, fixes the issue by changing the group on project_ids as
it will be only used in stat button and it's only accessible to the project
manager.

task-2818646

closes odoo/odoo#88648

Related: odoo/enterprise#26160
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

There is 2 issues regarding the responsiveness of the cookiebar:

==== Problem n°1: ====
======================

By default, `.modal-dialog` receive a O.5rem margin.
```css
    .modal-dialog {
        margin: 0.5rem;
    }
```

But it only takes effect in small resolution, as starting from SM (576px,
see _breakpoints.scss), the margin is set to 0. `.modal-dialog` receive:
```css
    @media (min-width: 576px)
    .modal-dialog {
        margin: 0 auto;
    }
```

On top of that, the `.modal-dialog` has a `min-height` of 100%, which is
getting too big in XS, as there is a 0.5rem margin, which adds up on top
of the 100%
```css
    .s_popup[data-vcss='001'] .modal-dialog {
        height: auto;
        min-height: 100%;
    }
```
It results in a modal height bigger than the screen size, ultimately
creating a scrollbar for just a few pixels (2 * 0.5rem margin), making
the cookies bar partly hidden by the screen.

==== Problem n°2: ====
======================

The buttons from the cookies bar "discrete" template are simple `<a/>`
elements inside a `div.col`.
Those links have no bottom margin like a paragraph would have.
In LG screen, it is fine as the col containing those links is next to
the other col containing the paragraph which adds the margin bottom,
making elements not stuck to the bottom edge of the screen:

------------------------------
|  COL-LG    |     COL-LG    |
|   <p/>     |   <a/> <a/>   |
|                            | <-- bottom margin set on <p/>
------- screen edge ----------

But in lower resolution, as both col would be on top of each other, the
`<a/>` would be stuck to the bottom screen border.
--------------
|  COL-LG    |
|   <p/>     |
|            | <-- bottom margin set on <p/>
--------------
-----------------
|     COL-LG    |
|    <a/> <a/>  | <-- Against the screen bottom edge
-- screen edge --

======================

Steps to reproduce:
- Install Website
- Enable cookie bar in the Settings
- Go on the Website with a mobile screen width

opw-2784233

closes odoo/odoo#88905

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

Before this commit:

BasicModel.localdata is not getting updated after follower removed

After this commit:

BasicModel.localdata is getting updated after follower removed

Task-2810734

closes odoo/odoo#88902

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

This error is caused by [1], setting the line width to 90%
causes the content of the product title to overlap the product
image due to insufficient width.

Steps to reproduce:
- Add some products to cart.
- Hover the cart icon.

[1]: https://github.com/odoo/odoo/commit/6c883840dba1fd0eaada6d916f13e1d062e002c5



closes odoo/odoo#91613

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

This fix will try to write a new amount value on the tax when an
invoice is created from POS and you have texes with fixed amount
included in price that will raise a user error preventing the
creation of the order.

This reverts commit 2bfa5ae6.

OPW-2855694

closes odoo/odoo#91625

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

A default MAX(id) was added in the extraDomain when there are no messages
to create it. This validation already existed but was omitted in the
refactoring - https://github.com/odoo/odoo/pull/57061

Current behavior before PR:

If there are no messageIds, the method loadNewMessages returns id > null
and this domain returns 0 records

https://github.com/odoo/odoo/blob/7d992af9561c499ef1912453f3b697bad18e441f/addons/mail/static/src/models/thread_cache/thread_cache.js#L55



Desired behavior after PR is merged:

Create the extraDomain with a default MAX(id) when there are no messages
to create it and continue with the normal flow of loadMessages

closes odoo/odoo#91610

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

When we receive status changes of sent invoices, we send an
ack message to the proxy afterwards to indicate we received it
correctly.

However, as awaiting_outcome is the initial state for which no
message about the invoice state was received from the gov, we do
not need to ack it as it just says "we are still waiting for the
first msg from the gov"

In a scenario:

Normal flow:

- Odoo instance sends invoice to proxy, proxy to gov, which sends back transaction_id
- On the proxy, the state of the transaction_id is awaiting_outcome
- The gov sends a message back to the proxy that the invoice is approved (directly to the server), so the state becomes "approved"
- The odoo instance asks for the status, receives the "approved" message and then tells the proxy he received it
- The proxy deletes the "approved" message

What we want to avoid:

- Odoo instance sends the invoice
- Proxy: awaiting_outcome
- Odoo instance checks the status and the server returns "awaiting_outcome"
- The gov sends a new message
- The Odoo instance acks and says he received the msg (there is actually no message associated)
- The new message from the government gets deleted.

closes odoo/odoo#85551

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

Total invoiced is computed with `active_test=False` [1], however the
corresponding action didn't have that context. Since Odoo 14 `child_of` domain
filters out unaccessible records (including archived ones) [2].

Fix it by adding the context to the action.

STEPS:

1. Have a active contact that has an amount invoiced (invoices pointing to this contact name).
2. Click through on the amount invoiced button, and receive a list of relevant invoices.
3. Now go back to the contact, and archive the contact.
4. The smart button containing the amount invoiced stays the same.
5. Click through on the smart button again

BEFORE: no invoices
AFTER : listed invoices corresponds to the computed total value

[1]: https://github.com/odoo/odoo/blob/574ca75ab6fa583aabc0c1cfc65206e72864e546/addons/account/models/partner.py#L379
[2]: https://github.com/odoo/odoo/commit/3e1b960acf3f6a726338476ba9e62e5ef5c84ef9



opw-2853525

closes odoo/odoo#91558

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

Issue:

  When receiving a mail with a facturx XML file as attachment,
  the datas in the XML files are not parsed.

Cause:

  For security reason, if a mail attachment is a XML file, it will
  be saved as plain text and therefore not be parsed.

Solution:

  If attachment mimetype is `plain/text` and content starts with
  `<?xml`, consider attachment as XML for the parsing.

opw-2655445

closes odoo/odoo#91196

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

In Outlook, like any event, a recurrence is identified by an `id` which is
specific to the Outlook user calendar, and by an `iCalUId` which is the same
among all Outlook calendars.

Each event of an Outlook recurrence (called `occurrence`) uses a `seriesMasterId`
attribute to refer to the Outlook recurrence. Unfortunately, this `seriesMasterId`
attribute refer to the `id` which is specific to the user calendar and not to the
universal `iCalUId`. That means, when a user B is syncing his Odoo calendar and gets
a recurrence created by a user A, to be able to sync occurrences with Odoo event, we need
to first match the occurrence `seriesMasterId` attribute with the Odoo recurrence through
the universal ID of this recurrence.

closes odoo/odoo#82863

Related: odoo/enterprise#27429
Signed-off-by: Arnaud Joset <arj@odoo.com>

When a recurrence is converted from a daily type to a weekly type,
the full recurrence is recreated but the base event is kept as the
starting point of the new recurrence.

But, in this case, the base event may need to be shifted of some
days to match the new selected days in the weekly rule.

Part-of: odoo/odoo#82863

The `_get_occurrence_details()` method was not taking pagination into account.

Part-of: odoo/odoo#82863

when a single event becomes the base event of a recurrency, it
should be first removed from the Outlook calendar as it will be mapped
to another Outlook event ID then.

Part-of: odoo/odoo#82863

When creating a recurrence composed of 'all day' events, event
synchronisation/matching fails due to 2 different ways to manage
'all day' event start/stop time in Odoo and in Outlook.

In Outlook, a 'all day' event starts at 00:00 and ends at 00:00 the next day.
In Odoo, a 'all day' event starts at 8:00 and ends at 18:00.

This 2 ways of managing 'all day' event have to be taken into account to match
events during the synchronisation.

Part-of: odoo/odoo#82863

As `calendar` module has been modified, the query count used in hr_hollidays tests,
is not right anymore so it has been adjusted.

Part-of: odoo/odoo#82863

As several customers complained about lot of bugs in microsoft_calendar in 14.0,
It has been decided to backport bug fixes of the model layer from master to 14.0,
without the need of an upgrade script (no new field, ...).

In master, we use 2 ids (organizer event id + universal id) instead of only one,
to handle Odoo <-> Outlook sync correctly when several attendees sync their Outlook
calendar with their Odoo calendar. For that, we have added a new field.
To report this bug fix in 14.0, the existing field which stores the organizer event id,
is now a string storing both ids separated by a ':' as follow: 'organizer_event_id:universal_id'.

2 new compute fields have been added to be able to use these 2 ids more easily.

Part-of: odoo/odoo#82863

closes odoo/odoo#91379

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

This commit fixes the Signup link under the quiz validation.
widget.url is not defined in widget.
Now we use the redirectUrl from the widget as redirect after the signup.

It has been detected by a number of hit on /web/undefined

closes odoo/odoo#91374

X-original-commit: 3283aef1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>

I apparently missed this case in #88871: Google's legacy
flow (response_type=token) explicitly rejects a `nonce` parameter
being passed in the authentication request. The nonce parameter is
only accepted for an OIDC-conformant implicit flow request (aka
`response_type=token id_token`).

The specific endpoint doesn't seem to have any bearing on this, v1 and
v2 authentication endpoints result in the same behavior.

Drawback: Okta isn't supported anymore, as it requires the nonce, no
if, no but, even on "legacy" auth requests, possibly others. However
since these already weren't supported that's considered less of an
issue than possibly breaking compatibility with existing IDP.

Rejected alternative: adding `id_token` to the `response_type` to come
closer to OIDC-conformant request, however that was considered too
risky: Odoo clients could be using legacy IDP which also reject the
nonce parameter but don't have a magic "OIDC conformant" trigger.

closes odoo/odoo#91466

X-original-commit: 1fd738d9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>

The boolean_toggle should only be disabled when there is a readonly
modifier, not when the view is in readonly mode.

Cause of the issue

  The input was disabled but the `_onClick` was registered on the
  widget root node.

Solution

  - Listen for clicks on the input element
  - Override the render method to set the disabled prop according to the
    readonly modifier.

opw-2739468

closes odoo/odoo#91465

X-original-commit: 8021562b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

To reproduce
============

- Create a new Survey.
- Add questions under at least two sections.
- In Options, ensure that each section is displayed on its own page.
- Click "Share" and open the share link.
- Partially complete the survey and close the window before submitting.
- From the survey click "See Results". Then choose a response to a question from the partially completed answer.
- A traceback raised

Purpose
=======

On this condition :
https://github.com/odoo/odoo/blob/3602fdfc0ce8ed76a530c8c3cc1d49eecf9d250c/addons/survey/views/survey_templates.xml#L27



we check if we have to display the progression or not, in case of consulting results it doesn't make sense displaying it.
that's mean the check made in `t-if` was not enough in this case and a condition is missing.

Specification
=============

to solve the issue the condition `not survey_form_readonly` was added

opw-2821478

closes odoo/odoo#91442

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

Lines cannot be deleted if the order is confirmed. However, notes/sections lines
still might be changed. So, let delete such lines too.

STEPS:

1. Create SO, add product and add note
2. Confirm SO
3. Remove note

---

opw-2852676

closes odoo/odoo#91336

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

Before this commit, when searching something via the searchbar snippet
when it is in a mega menu, the dropdown that appears could not overflow
the mega menu dropdown and thus was mostly hidden.

opw-2779432

closes odoo/odoo#91378

X-original-commit: 3bc2ce2d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

If a default template is specified in a given database (it is the case by default
on runbot databases because of sale_quotation_builder), the webclient will
try to fetch its display_name (through a name_get rpc).

As this happens even if the default_sale_order_template_id field is hidden
in the view, administrators without sales rights were not able to open the settings,
because they didn't have read rights on sale.order.template model.

This commit makes sure that settings users are able to open the settings
independently of their level of rights for the Sales scope (salesman/sales manager).

Fixes #84597

closes odoo/odoo#91328

X-original-commit: 74857e31
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Timeoff is apply in the view to take effect on every view type
instead of only the calendar.

closes odoo/odoo#91095

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

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>