The demo data created by account did not call _onchange_price_subtotal
on the created account_lines, making the total debit
and credit not matching the state of the lines.

closes odoo/odoo#77771

Related: odoo/enterprise#23738
Signed-off-by: Olivier Colson <oco@odoo.com>

Improve the journal audit report by adding information about impacted
tax grid for each computed journal.

Task id #2658937

Part-of: odoo/odoo#77771

Purpose
=======

Loading a view trying to retrieve the hierarchy of a record using the field
parent_path could lead to an access error if records are mixed up.

Note:
Easily achievable for an end user. It could happen in a multi company
environment (you activate 2 companies at the same time) while configuring
the departments (using _parent_store=True), and you say that you have:

R&D (company=1):
     - R&D Belgium (company=1)
     - R&D India (company=2)
Then you go back to a single-company environment, you click on the form
view of an employee and crack, since there is a multi-company rule on the
departments, and that the search panel is loading the hierarchy for
display purpose.

Use sudo to avoid access rights issues, as the forbidden records will be
filtered automatically by the constructed domain like this:

```py
parent_ids = [
    int(label)
    for rec in left_model.sudo().browse(ids)
    for label in rec.parent_path.split('/')[:-1]
]
domain = [('id', 'in', parent_ids)]
```

This actually makes the search consistent with the case where
_parent_store=False.

closes odoo/odoo#85005

X-original-commit: a7e13b32e6c47a3fdcfad8a6c6337b89580ad70a
Signed-off-by: Raphael Collet <rco@odoo.com>

closes odoo/odoo#84996

X-original-commit: 9af5338df16579ee3d5554bb03fe6d9e9c77e025
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

See doc preguntas frecuentes 4.4:
https://sede.agenciatributaria.gob.es/Sede/impuestos-tasas/iva/iva-libros-registro-iva-traves-aeat/preguntas-frecuentes/4-libro-registro-facturas-recibidas.html?faqId=f8276c3d02bc9510VgnVCM100000dc381e0aRCRD

Add tax agency Bizkaia to the tests too as in v15, so we see that the tests
pass here as well.

opw-2746495

X-original-commit: c35f34eebf3f57a835aa9c3056cf76293c3ca8de
Part-of: odoo/odoo#84996

closes odoo/odoo#84993

X-original-commit: b026f17988dfaecac41f0a350cf8cfb52aa3827c
Signed-off-by: Raphael Collet <rco@odoo.com>

Step to reproduce:
- Schedule activity on a project update
- Access the activity

Current Behaviour:
- On Project.update, we try to compute the info related to the project_update's project
due to the project update view showing information about the project.
In case of notification, we can show multiple project and thus no project_id can be
provided.
- Traceback

Behaviour after the PR:
- If there is no set project_id when opening the project update kanban view
We do not show the RightPanel related to the project and do not compute

related PR in enterprise odoo/enterprise#24427

opw-2755473

closes odoo/odoo#84720
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

When the selection only contains empty lines, no text nodes are
selected. `applyInlineStyle` however counted on text nodes being
selected, resulting in a traceback.

task-2740204

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

Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.

Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
  select a theme.
- Redirect is with enable_editor but nothing happens.

The editor isn't started if not in the source's lang.

This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.

[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107



task-2687416

closes odoo/odoo#84539

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

This commit hides the '"column_nb" field on the survey form.
Indeed, that option is currently not taken into account in the survey design.
A second PR will follow to properly remove the field (which can't be done in
stable).

More details at #83645

Task-2730409

closes odoo/odoo#83894
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Without ce342f42

 the new test fails because copying an
attachment requires write access to mail.template

closes odoo/odoo#84623
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.

This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].

Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.

A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.

Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.

issue 2746483

[^1] well not entirely true, see 4th paragraph

X-original-commit: 394b234e52b72646ff01a9b6c2aac67e59562000
Part-of: odoo/odoo#84623

When install the module on a db with huge amount of account move,
prefetching data when accessing partner_id of first move iteration is
costly and should be avoided.

closes odoo/odoo#84968

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

Steps :
Install Project and Dashboard.
Project > My task > Favorites (search zone) > Add to Dashboard.
Notice you can drag task between stages.

Issue :
Dashboard > Notice you cannot.

Cause :
m2m groupby normally (in kanban_renderer.js) does not allow drag.
project_kanban overrides its _setState() method to allow it for parsonnal
stages, because they "become m2o" with a user.
Yet, in the dashboard, we pass through the default method, because the
wrong view is created.

Fix :
Take into account the js_class in the arch to create the view.

opw-2752072

closes odoo/odoo#84864
Signed-off-by: Géry Debongnie <ged@odoo.com>

In 2e3075693b06d71222b446bd8a805dacb639d0e4 we used a head request to
determine type of page before trying to get a title out of it.

But requests.head does not allow redirect by default:

https://docs.python-requests.org/en/v2.9.1/user/quickstart/#redirection-and-history



so if an URL was a redirect, we would not longer get the page title.

opw-2457640

closes odoo/odoo#84803

X-original-commit: 63346cf4b77f760121f88762ab2911c37603b548
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

This commit uses the `is_html_empty` util method to detect empty HTML
fields in cleaner and more resilient fashion than what was done in
808cc53b

.

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

Current behavior :
In a multi-company environnement if you generate a payment link and access it from incognito page the company was always the logo of the first company.

Steps to reproduce :
- Get in a multicompany environnement
- Create a invoice in company B
- Generate the payment link in the action menu
- Access the link in incognito mode
- The company logo is always the logo from company A

opw-2756438

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

Before this commit when a text color was applied on a text within
which an already colored text already existed, the inner coloring was
lost during preview. All text was therefore set to the initial coloring
of the external selected text.

After this commit the "reset" of the text color preview is done by
undoing the draft "in progress" history step that contains the preview
changes, but that is not stored within the history itself.

Steps to reproduce:
- drop the Text snippet
- select a word in the middle of a sentence (e.g. "personality")
- set text color to red
- select several words containing the colored one (e.g. "story with
personality for potential")
- open text color palette
- hover over colors but do not click
- leave color palette
=> colored word is not colored anymore

Steps to reproduce a secondary problem also fixed by this commit:
- drop the Text snippet
- select text surrounding some bold (e.g. "have a personality. Consider")
- open text color palette
- quickly hover through several colors (i.e. move pointer downwards)
=> text selection range changed between some of the color previews

task-2742112 (was task-2666200)

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

the search method of contract_renewal_due_soon and
contract_renewal_overdue return a domain
id in res_ids where res_ids are id of contract
not vehicle

So it return random result

Solution
--------
Get the vehicle_id from the contract record set

closes odoo/odoo#84959

X-original-commit: b02227c582f9fa7c233d1a022739eda3058e9604
Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#84871

X-original-commit: 1a5afdef92589ca9ea31bfd30af755de7bb20985
Signed-off-by: Arnold Moyaux <arm@odoo.com>

When creating a MO _date_planned_finished_ is not added.
Consequently calculates wrongly the date planned to finish the MO.

X-original-commit: 2b2509e154af0e58a3f30f1d7fe40fb854b6b881
Part-of: odoo/odoo#84871

According to https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-OrderReference/


the cbc:ID in the Order Reference should be the PO number of the customer.

closes odoo/odoo#84179
Signed-off-by: Laurent Smet <las@odoo.com>

Step to reproduce:
- Switch language to arabic
- Go to Time off
- Click on 'New TIme Off'

Current behaviour:
- Traceback
Default date_from and date_to are given in arabic which cannot be parsed by the field

Behaviour after PR:
- Default date_from and date_to are given in english and then translated via the field

opw-2755258

closes odoo/odoo#84902
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Before this commit
The hotkey service was not taking into account that a new hotkey press
may have been triggered from an editable element.
This led to unwanted behavior, i.e. pressing ArrowLeft on an input
inside a sub Dropdown closed the sub Dropdown instead of navigating
through the text written in the input.

After this commit
The hotkey service now detects if the hotkey press was triggered from an
editable element (any input, textarea or other element with
[contenteditable=true] attribute) and does not dispatch this hotkey,
unless a candidate registered handler has explicitly asked to bypass the
editable protection. In that case, its callback will still get called.

task-2764821

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

Before this commit, the hotkey service will potentially
dispatch many time the same pressed hotkey.

After this commit, it will dispatch only to the newer
registrations or the first that match in the DOM.

task-2764821

Part-of: odoo/odoo#84778

ENCOUNTERED ISSUE:
Unable to close a dropdown with ESC when the focus has been given
to a select element inside the dropdown.

TO REPRODUCE:
i.e. in the searchpanel, go to "FilterMenu > Add Custom Filter" and
open the field select element.
Press ESC once: the field select element closes just fine.
Press ESC a 2nd time: we expect the dropdown to close but nothing occur.

REASON EXPLANATION:
Since 84715436 our Dropdown component uses the 'dropdown-menu'
bootstrap class.
But under some conditions bootstrap stops the keydown events propagation
when the event.target matches the query selector '.dropdown-menu'.

IMPLEMENTED FIX:
This commit refines this selector directly inside the bootstrap library.
This is admittedly a bad practice but:
- this modification is trivial and sensible
- the modified selector is only used locally
  in the bootstrap's 'dropdown.js' file
- the added test should prevent the lost of
  this customization in the future

task-2764821

Part-of: odoo/odoo#84778

* fix traceback when vat is not defined, return directly 0.
* remove api.model
* add ensure_one() to avoid misuse of the method

closes odoo/odoo#84948

X-original-commit: 5cd4df745462fcc12b9d92def9cf903ebd0df143
Related: odoo/enterprise#24562
Signed-off-by: Josse Colpaert <jco@odoo.com>

- A new flag is added to the Setting (l10n_it_edi_sdicoop_demo_mode)
  that is computed from the ir.config_parameter
  'account_edi_proxy_client.demo'.

  If the flag is 'demo', Odoo will not send invoices through the EDI,
  if the flag is 'test', Odoo will send invoices to an IAP test server
  instance that operates with a test SDICoop service
  if the flag is 'prod', Odoo will send invoices to production IAP,
  that routes them to the official SDICoop service.

- Some minor UI rework for the EDI parameters on res.company
  The EDI settings in the res_company form, under the
  'Electronic Invoicing' tab, must stay on the left

closes odoo/odoo#84904

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

Create a credit note for an amount between 0 and 1, confirm it.
In Accounting app, open Reporting -> Invoice Analysis
Switch to Pivot View
The credit note amount will be positive

This occur because in `insertThousandsSep` the number -0 is converted
to "0" (string), thus losing the sign before saving it

opw-2759964

closes odoo/odoo#84779
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

The function that converts inline images to urls returned the modified
html as a byte string. As a result, the Mail Debug tab showed a
hexadecimal string rather than rendered html. This makes sure the string
is encoded in unicode instead, so the format of the string coming out of
the function is the same as it was coming in.

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

Since [1] when fuzzy search was introduced, fuzzy search was also used
when the search term contained numbers.
This is a problem for companies where the shop search is used on
references: the fuzzy search does not match against the whole database
and therefore the exact match might not be found.

After this commit the exact search is used whenever the search term is
made of 80% of numbers or more - because it is very likely to be a
reference or an identifier.

[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986



opw-2715647

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

Before this commit:

When switching to mobile view and refreshing the channel in discuss than back
arrow button is not working

After this commit:

Back arrow button will close the channel

Task-2685187

closes odoo/odoo#81967
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Steps :
Install project and sale_project
Log in as portal > Tasks
Search bar > Dropdown > Search in All
Type anything and search

Issue :
Access Error : You cannot read sale_order_id.name, sale_order_id.invoice_ids.name,
sale_line_id.name, message_ids.body fields in task.

Cause :
We search in every field including those portal doesn't have access to.

Fix :
Add the domain of the rule of task to the search domain, so the search
only occurs on allowed fields.

opw-2762212

closes odoo/odoo#84787
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

There is an issue with the Italian carryover, line vp14b.
Use case:
 - Month 1, have a value of 25 in this line => will trigger a carryover to line vp7
 - Month 2, add more value to vp14b so that it goes above 25.82.
   This will set the bound as None, and thus this will not impact the carryover.
This is wrong, because then the next month we will see a value of 25 in vp7
while it should be 0.

closes odoo/odoo#84449

Related: odoo/enterprise#24270
Signed-off-by: Olivier Colson <oco@odoo.com>

Set the warehouse with manufacturing 3 steps
Create a BoM with a Components that use a Sub BoM
Set Both product MTO + Manufacture
Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.

It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO.

The idea between the fix is:
- We want to have the pick components picking merged.
- We want to have the store components split since they come from
different MO
So we create the different procurement groups during the _run_pull with
the picking type of store finished product. This way the pickings won't
be merged during _assign_picking

We will also propagate those groups to the newly created MO in order to
keep the picking type sequence and correct name.

FW PORT of
https://github.com/odoo/odoo/commit/bcfa03821b92bf52675db0e3b54d3cb19dfe3087



opw-2585525

closes odoo/odoo#84898

X-original-commit: 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Purpose
=======

The module website_crm_partner_assign has its own partner_longitude
and partner_latitude values that are resolved independently, when the
linked partner doesn't exist yet.

So when a lead is turned into an opportunity and a partner is created,
the address info is copied to the new partner, but not the geolocation.

In case these partners are supposed to be geolocalized (for example
on the FSM application), the geolocation will be recomputed despite
the fact that this information was already available at the convertion
time.

closes odoo/odoo#84878

Related: odoo/enterprise#24510
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======

This @depends could be 'dangerous' because it would trigger a
lot of calls to the GeoIP API.

It would be more reasonable to make it lazy instead.

So we just reset the geolocation to 0 when the address is modified
without providing the new values, and the user can manually trigger
the geolocation again when needed.

For FSM, it will be updated when needed as the computation is
triggered when the geolocation information is empty.

Part-of: odoo/odoo#84878

Prior to this commit the next call date for the first level would not
take the second level into account, as such it could be that the first
level would be completely skipped instead of being prorated properly.

TaskId-2768435

closes odoo/odoo#84862
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Sometimes when importing products that share the same internal reference code (default_code) the _import_fattura_pa function will throw an expected singleton error. This is because, in order to find the product for the line of the invoice, it will search for the product reference code (e.g. [CONS_0001]), which is not necessarily unique.

I've set the limit to one on the search to fix the immediate error for
now, but I will add more logic to better search for the relevant product
in a future commit.

closes odoo/odoo#84799

Task-id: 2764978
X-original-commit: aae609915cb1f76c32c518ff8959674853633f55
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>