When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.

Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account

=> If as an admin you check the company of the created user, it is
company A instead of company B.

[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9



task-3277317

closes odoo/odoo#121558

X-original-commit: eda9ad14
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Bug:
Currently, trying to import a fatturapa XML that has a document discount
doesn't do anything.

Setup:
- install l10n_it_edi and account_accountant
- have a fatturapa XML that has a document discount

Steps to reproduce:
- switch to the Italian company ()
- make sure that the VAT number on the document matches the one on the
  company
- attempt to upload the XML bill

You should be met with an empty vendor bill page.

Cause:
The issue comes from here: https://github.com/odoo/odoo/blob/43c9820b1d3020d89b1b7ca016754e29d1fc6b58/addons/l10n_it_edi/models/account_edi_format.py#LL725C21-L729C83


in 16.0, `invoice_form` is not an instance of `Form`, but a record.

opw-3193634

closes odoo/odoo#121010

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

As it holds full HTML documents, mail.mail often encounters issues with
the html editor.

We piggy-back off the intoduction of the switching
behavior between code-view and readonly-view behavior introduced in
a5c0085ce91570c6c961e3293dfe50f4faba6043

The 'sandboxed preview' mode can now be enabled with an option
and will ensure all content can only be viewed in a sandboxed iframe
or in the code editor.

This re-introduces editing, which was mistakenly fully disabled in the
usability fix that introduced body_content here:
5055b374

Some tests are added to ensure the key points of this commit remain
the same. Tests are re-ordered alphabetically to match the order
of execution, making debugging easier.

task-3255777

closes odoo/odoo#118423

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

It can be useful to search the body_content field
to find specific text while not including HTML tags
and attributes in the search.

task-3255777

Part-of: odoo/odoo#118423

In 2389f77c
containsComplexHTML was added to allow editing of html content
that would otherwise break when inserted as-is in a DOM

For this we added a rule to always display the code view toggle button.
This should not be the case when the field is marked as readonly.

Switching to the code view in readonly mode will cause a traceback.

task-3255777

Part-of: odoo/odoo#118423

The previous code with `parentsUntil` would not return any result
in an empty paragraph because the only valid element would be the
anchorNode itself but `parentsUntil` would only return parents and
never the base node itself. It makes sense, but is not suitable for
the case at hand.

Before this commit:
CTRL+A does nothing from inside an empty paragraph.

After this commit:
CTRL+A correctly triggers a select all from inside an empty paragraph.

Task-3150956

closes odoo/odoo#121711

X-original-commit: 4bcba1d7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: dhba-odoo <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>

Before this commit:

In mass_mailing entering a hax color for text triggers traceback.

After this commit:

Now, the traceback will not be triggered and color will be applied to the text

Task-3271517

closes odoo/odoo#120507

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

Fix the cash rounding displayed on accounting documents such as customer invoices, credit notes, vendor bills and vendor refunds. The amount that was computed was incorrect in most case. The only case that was working was the customer invoice when using the company currency. The PR address the issue of cash rounding for all account move type and when using foreign currencies as well.

Steps to Reproduce
 - Activate Cash Roundings.
 - Create a half-up cash rounding with a precision of 1.
 - Create a new bill with a pre-tax amount of 378 and a tax rate of 15%
 - Apply the cash rounding to the bill and save.
 - Review the "Total Rounded" value.

Expected Results:
The 'Total Rounded' value should be 435.00

Actual Results:
The displayed 'Total Rounded' value is 434.40

opw-3235723
opw-3236011
opw-3277942
opw-3271713

task-3257577

closes odoo/odoo#119545

Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Nshimiyimana Serge Séna <sesn@odoo.com>

[IMP] stock: unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

Example:
Now there is this behaviour
Inventory quantity 4
Reserved quantity 3
Available quantity 1
If i do a stock move of 2 pieces, it will unreserve ALL the stock move of the product.

With this PR it will unreserve only the pieces that are required minus the available quantity not reserved , in this case 2 (new stock move) - 1 (available quantity) = 1

closes odoo/odoo#121692

X-original-commit: 999c2045
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

This commit adds a new function to the module.

Currently, there is no way for managers or administrators to customize the list of customers per PoS UI.

This function can be used as a hook and can be inherited to add a domain to filter partners while loading a PoS session.

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

closes odoo/odoo#121731

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

closes odoo/odoo#121344

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The generation of the assets may make this step fail randomly.
The pregenerate is not enough because this is generating assets for
website2.

This issue will be partially solved in master with this PR [1] by not
generating an asset if a close one is found in the database.

For now just increase the timeout for this test.

[1]: https://github.com/odoo/odoo/pull/121376



closes odoo/odoo#121638

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

Before this commit this tour was often failing. It seems to be because
there were some requests still being executed / received after the test
was marked as successful and browser getting killed.

According to the logs, even when the tour is actually not failing, there
is still some unexpected requests going on.

With this commit, saving and waiting the edit mode to be exited will
prevent all those requests issues, as it seems like the requests done
after exiting edit mode are all awaited before marking the test as
successfull.

== Before the fix success case ==
- Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)'
- GET /website/static/src/img/snippets_options/header_template_default.svg HTTP/1.1" 200 - 0 0.000 0.003
- [Same GET for 10 other header templates]
- test successful
- Session expired
- POST /website/theme_customize_data_get HTTP/1.1" 200 - 3 0.001 0.003
- [2 lines above x10]
- Deleting cookies and clearing local storage
- Navigating to: "about:blank"
- Navigation result: {'frameId': 'A538603CC37A4E9EBA99B8624C1CD34E', 'loaderId': '9187051DD3D9477FA4EDEB1A544D584E'}
- Waiting for frame 'A538603CC37A4E9EBA99B8624C1CD34E' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.139669352166976, started 139669352166976)>]

== Before the fix error case ==
- Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)'
- GET /website/static/src/img/snippets_options/header_template_sidebar.svg HTTP/1.1" 200 - 0 0.000 0.004
- [Same GET for 10 other header templates]
- test successful
- GET /web/static/img/smile.svg HTTP/1.1" 200 - 0 0.000 0.001
- GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.001
- Failed to fetch
- Asking for screenshot
- Trying to set result to failed (TypeError: Failed to fetch) but found the future settled (<Future at 0x7f8fa1a25120 state=finished returned bool>)
- Deleting cookies and clearing local storage
- Screenshot in: /data/build/tests/36222061-master-all_no_autotag/screenshots/sc_20230513_220042_739175_TestUi.png
- Navigating to: "about:blank"
- Navigation result: {'frameId': 'E1A779132E972A440E5FE892BBBC9FEC', 'loaderId': '822ACED443DB0C84F57DD4A1FF451D5B'}
- Waiting for frame 'E1A779132E972A440E5FE892BBBC9FEC' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.140254747010624, started 140254747010624)>]

== After the fix case ==
- Tour snippet_editor_panel_options on step: 'iframe body:not(.editor_enable)'
- GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.003
- POST /website/theme_customize_data_get HTTP/1.1" 200 - 8 0.002 0.035
- [Many other POST/GET requests]
- test successful
- Deleting cookies and clearing local storage
- Navigating to: "about:blank"
- Navigation result: {'frameId': '4B87BC8A50A3FEBD7D508394DD5BDB19', 'loaderId': '7CCB3B6434B52B456A1AA470C3CFA1BF'}
- Waiting for frame '4B87BC8A50A3FEBD7D508394DD5BDB19' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.139744500471360, started 139744500471360)>]

runbot-15312

closes odoo/odoo#121635

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

When unit prices have more than 2 digits, it is currently not reflected
in the UBL formats. Consequently, the line amounts are not equal to the
unit price * quantity (assume there is no discount, charges or
allowance) and it raises validation errors: "Invoice line net amount
MUST equal (Invoiced quantity * (Item net price/item price base
quantity) + Sum of invoice line charge amount - sum of invoice line
allowance amount".

To fix this, we no longer round the unit prices.

NB: the decimal accuracy should be set in the settings (otherwise, the
default is 2 digits for unit prices).

See https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding



opw-3290035
task-3302904

closes odoo/odoo#121559

X-original-commit: bd795593
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

Before this commit timesheet uom timer not displaying proper
aggregated value because it was not added in formatters registry.

This commit add timesheet uom timer widget in formatter registry to
display right value when timesheets are encoding in days and views
are displaying aggregated value(e.g. total in list view).

task-3251672

closes odoo/odoo#121125

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

Use case: Create an import file for a picking with stock.move.line directly in
it and add some reserved quantity on the stock.move.line.

The import of stock.move.line is not possible directly via a
stock.move.line menu but it still possible on a picking or
mrp.production import. However the create does not expect that
and never reserve the quants. So it result with quant <-> sml
inconcistencies in the data and the error can not reserve more
than you have in stock.

opw-3277938

closes odoo/odoo#120974

X-original-commit: 53af47d1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce the bug:
- Enable “subcontracting” in the mrp settings
- Create a storable product “P1”:
    - Add a vendor:
    - supplier: “Azure interior”
    - currency: euro
    - price: 20
    - Add a BoM:
        - Type: subcontracting
        - add any product as component
        - Save
- Check that the currency of the company is in dollars
- Click on Compute Price from BoM button in the product form

Problem:
The seller's price is not converted into dollars

opw-3321346

closes odoo/odoo#121320

X-original-commit: f60fac0afa9b87baa68328c5755a7fe84494cb10
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When sending an invoice to a recipient who is not the customer, they are
unable to view the invoice in the customer portal and are prompted to
log in.

1. Create and validate an invoice
2. Click on the Send & Print button, then add a recipient who is not the
   customer associated with the invoice.
3. Proceed to send the invoice.
4. Access the email that was sent to the added recipient (who is not the
   customer)
5. Using an incognito or private browsing window, open the link
   `View Invoice`

=> you should see that you are asked to log in, instead of being
directed to the customer portal.

opw-3114579

closes odoo/odoo#121572

X-original-commit: 3676692cb916bfcd417b7c06df6131e6bceb1659
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>

- Create a Deferred Revenue Model on a Current Liability account
- Create a Sale Order yourself (User 1), with Salesperson User 2
- Create the invoice from it
- Remove the salesperson from the invoice and add User 3 instead
- Change the account to the Revenue Model's one
- Post the invoice
- Post the deferred revenue created
=> User 2 is follower of the entries generated

The problem is that the context comes from the sales order, and
contains a `default_user_id` in the context.
The solution provided is to remove it from the context given, as
it serves no purpose (the invoices are already created).

opw-3141495

closes odoo/odoo#121560

X-original-commit: c3df8fc0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>

When archive a loyalty program which have somes rules and rewards and the unarchinving it will not have the rules and
rewards that it had before.

Steps to reproduce the error :
1- install sales
2- activate Discounts, Loyalty & Gift Card in sales settings
3- go to sales/products/Discount&loaylty
4- select one of the default programs and try to archive it and unarchive it after
5- you will not get the rules that it had before

The problem was in the toggle_active function of the loyalty program we try to unarchive already unarchived items because
we do ```program.rule_ids``` so it will get only active items.

opw-3299295

closes odoo/odoo#120902

Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

Current behavior:

Connections for outgoing email servers using Outlook/Office365 or
Gmail accounts will establish an OAuth2 authentication for the smtp server.
Through the `ir_mail_server` form view, one can fetch the necessary
tokens by logging in into their Microsoft/Gmail account.
Not specifying an username (`smtp_user`) on the `ir_mail_server` record
will not produce an error while fetching those tokens.
But when trying to test the connection or use that server to send an email,
even if the FROM header is correctly set (i.e. the account email address
authorized to sent emails), the smtp connection will fail. This is due
to the fact that when `smtp_user == False`, the respective method
`_generate_outlook_oauth2_string` or respectively `_generate_oauth2_string`
will not be called and send the necessary OAuth2 string when sending
an email through the smtp connection.
This will lead to a `5.7.57 Client not authenticated to send mail.` error.

After this change:

Add specific UserErrors that get called if `smpt_user == False` before
the actions in `open_google_gmail_uri` and `open_microsoft_outlook_uri`
get called. This forces the user to input a `smpt_user` (field Username)
before the login page for OAuth2 gets called to fetch the tokens.
Note: there is no check if the user inputs the right username, only
that the field is not empty. So it is still possible to input an
invalid username.

opw-3268246
Conflict resolved for 16.0 forward port

closes odoo/odoo#121541

X-original-commit: 0f6602c7
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: jorv-odoo <jorv@odoo.com>

Cast website_id so that if it contains more than 1 digit, we do not
browse() a tuple with each digit. For example, if we pass pagenew() the
website_id '123', this is the current behavior:
 - browse('1', '2', '3')
After this fix:
 - browse(123)

To reproduce the erroneous behavior:
 - Create at least 10 websites so that the id of this website is at
least in the double digits.
 - Create a new page within this website with a double digit id.
 - It will throw an expected singleton error.

Issue was introduced in this commit: https://github.com/odoo/odoo/commit/d6014c60acc4231a5e56d492d2a39deaf789cbe8



opw-3290571

closes odoo/odoo#121486

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

Since bd76e9d6, if the partner set on the SO is different than the invoicing partner set on the same SO, the generated payment link won't work, as the access_token is generated based on the `partner_id`, while verified based on the `partner_invoice_id` SO field.

This commit makes sure the `access_token` is correctly generated with the invoicing partner.

opw-3328772

closes odoo/odoo#121555

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

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>