ValueError 'unknown colour specifier' occurs when we access
export_icon_to_png(). This error occurs when we change the colour of an
icon in the mailing template, because the value of alpha (opacity) in 'rgba'
is in the range of 0 to 1, but PIL Image support colour opacity range 0 to 255.

This commit converts the opacity value range (0 to 1) to a range (0 to 255)
compatible with the PIL image library when the colour specifier is 'rgba'.

sentry - 3933353285

closes odoo/odoo#121516

X-original-commit: a5418770
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The note "Quotation viewed by customer" posted when a public/portal user
access an order came with the order's partner name instead of the actual
user's partner name

This made confused for internal users to see something in internal note
like **Colleen Diaz** with a message **Quotation viewed by customer
Nicole Ford**

This commit makes sure to use the right partner name except the
quotation is viewed anonymously (with access token)

closes odoo/odoo#121528

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

The issue occurred when a loyalty program's rule was set to be
based on money spent, and the reward was a free product with a
sale price of zero. This caused a zero division error in the code,
resulting in the remaining points becoming NaN after the reward
was obtained in the point of sale.

opw-3253366

closes odoo/odoo#118579

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.

This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.

Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.

Steps to reproduce:

 - Install Purchases app
 - Install Inventory app
 - Create a purchase order with purchase lines and quantity > 0
 - Confirm the purchase order
 - Click on receive products
 - Click on validate
 - Uninstall Inventory app
 - Check that the purchase order lines have the received field set to zero and
   it is not editable

opw-3006951

closes odoo/odoo#121011

X-original-commit: a5de7371303538874b69e028905df22ab8df3f47
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>

For performance reason, we avoided computing goals for the set of users
that didn't log in recently (See ec0c0f29).
However, users can stay logged in for a while without having a new "log
in event" (password asked), such that active internal users can keep
old values in their challenges when reports are sent, which is not good.

Until an improvement can be implemented in master, we drop this time
constraint for active internal users.

A test is added, checking the behavior of the method called by the cron.

Task-3226408

closes odoo/odoo#121483

X-original-commit: 6c77dd82
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.

Steps to reproduce the bug:

- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.

This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.

opw-3233684

closes odoo/odoo#121442

X-original-commit: 4e996e67
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

Create an expense paid by company for $100
Create the expense report > Submit to manager > Approve > Post journal entries
Go to Expenses > Expense reports, expense sheet payment status is 'paid'
Add a bank statement line for the expense and set amount to -$100
Match the bank statement with the expense payment

Issue:
Go to Expenses > Expense reports, expense sheet payment status is 'In
payment'

This occurs because in account_accountant the invoice in payment state
is 'in payment' but in expense the flow is already over

opw-3177025

closes odoo/odoo#120673

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

On install, `hr_work_entry_contract` only associates work entries to
contacts which are open or closed.

However during its execution (?) `hr_work_entry_contract` generates
entries associated with `Mitchell Admin Contract`, which is a draft
contract. As a result, when uninstalling then reinstalling
`hr_work_entry_contract` it is not able to re-associate the entries to
the contract, and thus can't reinstate the `required=True` on
`HrWorkEntry.contract_id` either, which is a "reinstallation failure"
on the CI.

A simple solution is to create the contract closed, though it would
also be a good idea to not be able to create work entries associated
with a draft contract either, maybe?

closes odoo/odoo#119808

Related: odoo/enterprise#40361
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Since the "dirty flag" refactoring of
384fda2c
`IrModelFields._prepare_update` did not cope well with fields missing
from the python-side models, which can during uninstallation for
custom fields (possibly because the script loads the registry
incorrectly, not entirely clear).

Because of a custom field created by worksheet linking to it, the
removal of the `project.task` table would fail, making the
reinstallation of project fail to restore several constraints.

This case was actually handled correctly just a few lines above when
trying to resolve field dependencies, both record and field would be
checked for their presence before actually trying to use them.

Getting the model from the registry / environment has not been noticed
to break uninstallations, but might as well do that too so everything
lines up, and just in case.

Part-of: odoo/odoo#119808

Issue discovered in the uninstall (and reinstall) of sale_project: a
dump has ~100 tasks, when reinstalling `sale_line_id` has to be
initialised, this is done by marking `sale_line_id` on all extant
tasks as to-recompute, which triggers their computation on the next
`flush`.

Because it's a recursive field, `Field.recompute` ensures only one
record at a time gets recomputed (as there could be cross-dependencies
in the recorset which protection would prevent from resolving).

As the field computation runs, it accesses itself, which triggers a
cache miss, which triggers a `_fetch_field` (to get the currently
stored value), this calls `_read`, which flushes the field we're
trying to read.

The problem here is that for efficiency the cache miss will look for
all records in the cache without a value for the
field (`_in_cache_without`) and try to `fetch` on them as well. This
means rather than not doing anything in flush, we're going to
`Field.recompute` on all records except the one selected the first
time around, which repeats the cycle until there is no more additional
record found in `_in_cache_without`, which could trigger the next
round of `recompute`, and the entire thing unwinds, and we probably
perform a ton of unnecessary additional `compute_value`.

Except that doesn't even happen, because the process from one compute
to the next takes 12~13 stack frames, which given the default
recursion limit of 1000 gives a hard limit of 76 fields before hitting
a RecursionError. As this is less than 100, a recursion error [is what
we get](https://runbot.odoo.com/runbot/build/31726625).

In 15.2, this was fixed by only expanding the fetch on non-recursive
fields, pessimizing recursive
fields (5c2511115b14299516fce4aa3737a62faaf5b653). Test-wise this only
impacted mail performances and in a relatively minor manner.

In 16.0, the mail tests actually match already (so that part was
skipped by the cherrypicking) however this impacts the knowledge perf
tests much more significantly e.g. `test_article_creation_multi_roots`
gets +9 queries when creating 10 top-level articles, which is a bit
much.

So use an alternative which is ugly as hell but which I didn't
consider for 15.2 (may want to backport it one day if the current fix
is an issue): catch the recursion error and use the existing
fallback (of fetching just the requested record's field without
expanding the recordset).

This likely makes for a pretty inefficient situation in the original
case as we're certainly going to hit the recursion limit repeatedly,
but that still fixes the issue, and it avoids deoptimising cases which
fall short of the recursion limit (resolving under 60 records or
so).

Plus despite creating giant stacks we might actually get good
efficiency as we're going to hit recursion limits repeatedly but
that's pure python, once we fall below the limit we can resolve
everything at once with a single SQL query (or something along those
lines).

Part-of: odoo/odoo#119808

Uninstallation does not cope well with `setup_models` being performed
unconditionally as those will dramatically alter registry states, and
resurrect computes which the uninstallation has disabled: rather than
try to update registry models in-place (which is rather fraught) the
uninstallation deletes the columns, tables, and `ir.*` reflection
records and only after all of that is done does it reset the registry.

This means while it does fix up the registry caches (`field_depends`
and `field_triggers`) as it goes, resetting those may cause the
recomputation of fields whose columns have been deleted, possibly
based on dependencies whose columns have also been deleted.

As such these kinds of manipulations should either be performed in
`@ondelete` methods which don't get executed during uninstallation, or
they should be gated behind an uninstallation check.

In crm the latter is necessary, as `ondelete` runs before `unlink`
actually executes, and the registry reset would run too early (and
unnecessarily).

In base, only the latter is possible as we're not in `unlink` itself,
instead `IrModelFields._prepare_update` is called *during*
uninstallation and its trailing `setup_models` causes the issue.

X-original-commit: 1dc316ad
Part-of: odoo/odoo#119808

When modules get uninstalled, first the uninstall process will drop
all the fields (removing all the columns) then it drops all the
models (removing the tables).

When uninstalling mail, this means the various (res_)model(_id) fields
don't exist anymore by the time we're deleting models, so the queries
blow up.

Skip this step if we're unlinking the mail models, it means the tables
have already been dropped, so there's nothing to delete anymore. This
should not use `ondelete` because we *do* want to delete records from
those tables when deleting modules which depend on mail, and thus have
mail stuff associated with their own models which we're deleting.

X-original-commit: ec83293c
Part-of: odoo/odoo#119808

Confusion between uninstall hooks can apparently trigger errors during
uninstallation as two hooks can confuse one another?

In this here case, the issue triggered during the uninstall hook of
`account_accountant`, which apparently combines with the uninstall
hook of `industry_fsm_sale` to trigger an invalid in-memory state for
`project_project`. An implicit flush during the hook then blows up
with a check constraint error.

Flushing at the end of the `industry_fsm_sale` hook or at the start of
the `account_accountant` hook fixes the issue, so might as well flush
after each hook to ensure whatever they did using models is pushed to
the database and in good shape (hopefully).

X-original-commit: 63e83183
Part-of: odoo/odoo#119808

Before this commit, links scrolling to an anchor with a special
character did not work and displayed a traceback. The issue was that to
check that the anchor is valid, we don't need to check that the anchor
is a valid url as we have been doing since these commits [1], [2]. But
we only need to check if the jQuery selector is valid to correctly
target the element to which the page must scroll.

Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing
'oké%' wich is not valid jQuery selector. It has to be encoded to
'#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does.

We also changed the way to display a new anchor to the user in this
commit. Before, we showed the anchor unencoded in a notification and now
we show it encoded. That way, if the user copies the anchor from the
notification, it's the real anchor.

Also, this commit detect if the success URL of the redirect of a from is
the current page to perform a scroll to the anchor instead of a
redirect. To make this comparison, we needed to add the url code of the
language of the current page to the session info.

Also, before this commit, the page froze when we clicked on the "submit"
button of a form that redirected to an anchor that did not exist.

[1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420
[2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c



task-2172312

closes odoo/odoo#121388

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

This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.

closes odoo/odoo#121364

Sentry: - 4075426049
X-original-commit: ac2a3966cb035f112bf6aebb1244dc8d67831d1a
Signed-off-by: Rémy Voet <ryv@odoo.com>

Problem: The error "There is no chart of accounts installed for this company..." appears for POS shop configurations
if they don't have a chart template configured for the company. It doesn't take into account if the company has its
own set of accounts so it will always show the error unless the chart template is set.

Solution: Include an additional condition to check if the company has accounting entries which is used to check
if the company has used its own set of chart of accounts for accounting.

Purpose: The error will only appear if the company has no chart template set or no accounting entries.

opw-3291399

closes odoo/odoo#121309

X-original-commit: b5106da3
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>

When the user configures PayPal/Alipay and in his PayPal/Alipay account he set
the IPN address to the webhook_url he receives a notification from PayPal/Alipay
with data. Then origin of that notification is checked and when PayPal/Alipay
sends 'invalid'/'false' as a response the error occurs.

To fix this issue the log is updated into a warning.

sentry-4116633764

closes odoo/odoo#121235

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

The taxes update migration method didn't handle properly the creation
of taxes with `children_tax_ids`. Such taxes caused an infinite loop
when entering the `_generate_tax` method.
To fix this we have batched the creation of taxes.

We also fixed the comparison method that checks whether an existing tax
is close enough to the template we are evaluating to handle properly
taxes with an `amount_type='group'`. If we are evaluation such a tax
we ignore the usual checks on repartition lines.

closes odoo/odoo#121225

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>

Swiss taxes retrieved by module update (and the update of taxes it triggers)
need to be active, even if the template data was set to inactive.

Part-of: odoo/odoo#121225

When we were updating taxes from templates in a multilang localization,
newly created taxes were not translated in languages of the localization.
We also need l10n_lu migration script to be run in `end` instead of `post`
to have translations loaded.

Related: #108667
Part-of: odoo/odoo#121225

The tax with xmlid vat_0_import was missing its repartition
lines which caused validation errors.
This PR adds empty repartition lines to fix this problem.

Part-of: odoo/odoo#121225

If a tax is an aggregation of its sub-taxes it makes sense to have no
repartition line. This PR relaxes the validation in that case.

Part-of: odoo/odoo#121225

Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes

Task: 3162286
Part-of: odoo/odoo#121225

There is no notification telling which field are invalid when we try to
save a form in a dialog

Steps to reproduce:
1. Install Survey
2. Go to Survey and open any survey
3. Add a question in the survey and try to save it (without entering a
   title)
4. There is no notification. Although the invalid field is highlighted
   in red, it could be tricky to see it if the field is in a tab

Solution:
Create a method in Record that sends the notification and call it when
the record is not valid in X2ManyFieldDialog

opw-3196166

closes odoo/odoo#121205

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This issue only occurs on Firefox because ´has´ is not supported
and the following rule is not applied:
https://github.com/odoo/odoo/commit/2cd0106e63785dd34553c2b4747d72b93b9a7afd



Anyway, there is an existing css rule that is applied if the field
class is correclty added.

Steps to reproduce:
- Open Sale
- Add some content in the sale order line

opw-3201461
opw-3285854
opw-3266130
opw-3244581

closes odoo/odoo#121182

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

Steps to reproduce:

  - Log in as admin
  - Install `eLearning` module
  - Create a course and add a youtube video as a lesson
  - Publish the course
  - Go to the website and click on the course
  - Enable `Editor` mode (top left corner)
  - Click on lesson to open it in fullscreen
  - Click `Back to course` button

Issue:

  Video is playing in the background.
  Same issue occure with video snippet in the website editor (by default
  video is mute but still playing in the background).

Cause:

  When editor mode is enabled, there is a fallback iframe that clone the
  content of the current page that we leave into it.

  Since the youtube video has `autoplay=1` in the URL, it will
  automatically start in the fallback iframe.

Solution:

  For regular website pages, remove the `autoplay` param from all
  media video iframes urls (targeting all `div.iframe` that have a class
  `media_iframe_video`).

  For eLearning, override the `WebsitePreview._cleanIframeFallback`
  method to remove the `autoplay` param from youtube videos URLs.

opw-3226002

closes odoo/odoo#121157

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

Before this commit, when a cookie bar was displayed on a page and
elements of that page were animated (on scroll and on appearance), those
animations did not work while the cookie bar was present. This commit
fixes that and enables animations even if a cookie bar is displayed. The
problem was that we were looking to see if a modal (cookie bar, popup)
was displayed and if it was, all animations were based on the scroll
height of that modal. However, this should only be done for elements
that are in the modal. The other elements should always base their
animation on the scroll height of the page.

task-3151000

closes odoo/odoo#120294

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

closes odoo/odoo#119637

X-original-commit: efbaf72c
Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps:
- Install timesheet.
- Start timer.
- Make sure there is enough record to show search more on
task or project field.
- Click on search more button.
- Click on Create button on search more button.

Issue:
- Traceback.

Cause:
- Can not find owl form view in legacy form registry because
recent removal of old legacy code.

Fix:
- Add a widget to open owl form view in search create dialog
instead of legacy form view.

task-3051478

closes odoo/odoo#115062

Related: odoo/enterprise#40581
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Before this commit task action from kanban click and from
stat button does not have same behavior like kanban click
does show archive task for archive project and does not
display New button while other on does not.

This commit make both action consistance to have same
behavior in both actions.

task-3224627

closes odoo/odoo#114749

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

    Steps to reproduce:
    1- Create a BOM for a product, define an Operation on the product
    2- Link a Google Slides document to the Operation as the Operation Worksheet.
    3- Define an instruction on the Operation
    4- Set Step Document to Specific Page of Operation Worksheet and define a page.

    Issue: The step will not load the document.

    Cause: tablet.js passes the wrong value to let know the viewer is a google slide url. Also when the good
    value is passed the viewer always show the first page. That's because the SlideViewer has the page set in the
    setup() method so it never change despite we change the step in the same document.

    opw-3165142

closes odoo/odoo#113727

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

Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.

Bonus point: tests no longer need to be imported in the `__init__.py`
file.

closes odoo/odoo#121304

X-original-commit: 08adb3e6
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>

Before this commit
==================
when SO is confirmed and Delivery is created then add the shipping method
in SO, in this case, the shipping carrier is not set in the existing undelivered
delivery of that SO.

After this commit
=================
So in this commit, we set the shipping carrier for undelivered delivery.

taskId - 2946360

closes odoo/odoo#121300

X-original-commit: 51523c0dbf6ce9dd1a1ff35e03fa6a51267da14b
Signed-off-by: Tiffany Chang <tic@odoo.com>

__Current behavior before PR:__
When someone joins a call in the discuss public view and receives a message in the chatter, the part of the screen supposed to display the video streams of the participants goes black.

This happens because it is trying to open a chat window in the bottom right as it is done usually. However since we are in the public view it removes it instantly together with the participants cards.

__Description of the fix:__
If we are in the discuss public view, it is useless to make chat windows. This will prevent opening of chat windows.

__Steps to reproduce the issue:__
1. Open the discuss app and start a meeting.
2. Copy the Invitation Link
3. Open a new private window to join the call with a guest user.
4. Then go back to the non-guest user page and send a message in the chatter.
5. Notice that the participants cards vanished on the private window page.

opw-3229747

closes odoo/odoo#121195

X-original-commit: 49d56c5449e1bd9457fb935e98134cafc75931dc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

before this commit, on clicking on Go To Website
smart button in forum is not redirecting to the
corresponding forum due to missing parenthesis
to the function.

after this commit, on clicking the Go To Website
smart button, user is redirected to the forum.

introduced in: https://github.com/odoo/odoo/commit/36c734ab37fdf1d6a245e0e29cfefe3cc46c6d92



closes odoo/odoo#121338

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

Before this commit, there were cases where toggling the grid mode did
not work correctly. These cases are:
- when a snippet has None columns (e.g. Cover) and that an inner snippet
containing a row (e.g. Form) was dropped into it,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner snippet containing a row was dropped in this outer
content,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner content (e.g. Alert) was dropped in this outer content.

The first two cases happen because the row that was taken into account
when toggling the grid mode was the first `.row` element found in
general, instead of only considering the container children. Therefore,
what happened in these problematic cases is that the row found was the
inner snippet one, which should not be the case and caused the toggle to
fail because it was trying to put the element inside itself.

The third case happens because the `div` elements were excluded when
placing the outer content in a column, instead of only excluding the row
element.

This commit fixes these issues by only considering the container
children when looking for the row element when toggling the grid mode,
and by filtering out only the row element instead of every `div` when
creating a column for the outer content.

task-3279191

closes odoo/odoo#119965

Signed-off-by: Dieleman Guillaume <gdi@odoo.com>

When importing data and checking the possible values of a field,
clicking on one of the records to open it throws an error

Steps to reproduce:
1. Install Projects
2. Go to Project > My Tasks and trigger the list view
3. Select any record and export it (check the import-compatible export
   option)
4. Open the exported file and modify the `project_id` to a non-existing
   project name
5. Click on Favorites > Import records
6. Upload the modified file and click on 'TEST'
7. In the `project_id` field, click on 'See possible values'
8. Click on any project, an error is thrown

Solution:
Prevent the form from being opened when the action is in target "new"

Problem:
Opening the record in a target new throws the error `switchView
called but the current controller isn't a view`

opw-3161777

closes odoo/odoo#119643

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/115eda75 [REL] 16.0.10
https://github.com/odoo/o-spreadsheet/commit/80667964 [FIX] evaluation: compute format from empty cell
https://github.com/odoo/o-spreadsheet/commit/dbeb370a [FIX] ChartFigure: chart/image menu options in readonly mode Task: 3284659
https://github.com/odoo/o-spreadsheet/commit/3b3e49f6 [FIX] SelectionInput: Fix cross symbol
https://github.com/odoo/o-spreadsheet/commit/1fb31b93 [FIX] SelectionInputPlugin: prevent multiple range in 'singleRange' input Task: 3237798
https://github.com/odoo/o-spreadsheet/commit/644c6761

 [FIX] collaborative: ignore bad snapshot revision

closes odoo/odoo#121270

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

- Add missing account tag on repartition line taxes to fix the report 104 amounts for per tax

closes odoo/odoo#121095

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