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>

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>