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>

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>