Steps to reproduce the bug:

- Enable Multi-Currencies and Multi-Companies
- Create a vendor bill
- Remove the default journal
- Set an other currencies

Bug:

A traceback was raised

opw:2350490

closes odoo/odoo#59469

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

closes odoo/odoo#59292

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

- Create companies A & B
- Switch to company B
- Open a POS session in company B, but do not close it
- Switch to company A
- Set a Lock Date for Non-Advisers

The error message 'Please close all the point of sale sessions...' is
raised.

The message shouldn't be raised since the session is not in the company
we are setting a lock date.

We filter the session based on the company.

opw-2351930

closes odoo/odoo#59505

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The method _get_document_type_sequence is returning the match sequences for the given journal
and invoice. In case there are several sequences, we should only take the first one when
computing l10n_latam_sequence_id field.

closes odoo/odoo#59490

Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>

Following [1]. The mentioned commit selectors were to be simplified and
actually did not solve the problem in mobile affixed menu. Also,
targeting "o_affix_enabled" to target the non-affix menu was wrong since
when there is no affix menu, no header has the "o_affix_enabled" class
as its names indicates it. So the mentioned commit fixed half of the
problem and only when the website used the affix menu feature... Let's
hope this new commit fixes everything.

[1]: https://github.com/odoo/odoo/commit/21959599d1c25321865afabe7f70191efdda154e



closes odoo/odoo#59468

X-original-commit: dac65690
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit there would be crash on Removing `Unit` field from Sale order lines list view due to missing `product_uom`, Which is necessary for `QtyAtDateWidget` widget.

Now we hide the Widget if `product_uom` is not selected.

Closes #59042
Fixes #58928

closes odoo/odoo#59447

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

On a fresh Linux Mint installation, the libraries used by Pillow and
psycopg2 are not installed. This update the list of dependencies so
users don't have to dig through Pillow/psycopg2 documentations in
order to find and install the missing dependencies.

closes odoo/odoo#59429

Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>

Activate Delivery Packages option in the settings, and check "Move
Entire Packages".
Create a product, and update the quantity on hand (e.g. product X with 5
quantity in package Y in location shelf 1)
Then,create an internal transfer (e.g. package Y from shelf 1 to shelf
2), check a first time the 'done' box and save.
Finally, edit, uncheck and check again the 'done' box in the same
operation and save.

You will see (tracking message in the chatter) that the initial quantity
is wrongly updated (doubled apparently).
After saving, the 'done' box will be unchecked and the transfer cannot
be validated with the following error message :
"You cannot move the same package content more than once in the same
transfer or split the same package into two location."

This occur because on uncheck and recheck done checkbox the quantity is
added again to the related move.

opw-2350335

closes odoo/odoo#59248

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Current behavior before PR:

It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself.  This is undesirable as when we create a
manufacturing order for this product we will have an error.

It is a regression bug that was introduced in commit
575353e2 between v12 and v13.

Behavior after PR is merged:

When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself.  Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.

opw-2347941

closes odoo/odoo#59181

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The Duration Per Unit should be averaged, not summed.

opw-2353041

closes odoo/odoo#59431

X-original-commit: 54b40f1e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

When lines are loaded in the reconciliation widget, get_bank_statement_data
and get_bank_statement_line_data both return the same object containing e.g.
{st_line: [], reconciliation_proposition: [], lines: []}.
Then, the value of 'lines' should be passed to _formatLine. However
in loadData, which is called after reconciling an entry, and if an additional
line should be loaded in the reconciliation widget, the value passed was
incorrect. Before saas-12.3, res['lines'] was passed to _formatLine. We
do the same change to ensure the correct value is passed to _formatLine.

opw 2299574

closes odoo/odoo#59428

X-original-commit: 924413c3666dbc4b69d57a67ec9c673e86a0bb6e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit, "Today's meeting" section of activities systray may have
recurrent events for other days. This happens only if today is the first day
of recurrent events.

Technical reason for this error: filtering by start_date and
stop_date doesn't work. You can see in method get_recurrent_ids that it checks only fields
start, stop, final_date/

opw-2345550

closes odoo/odoo#59354

X-original-commit: 1201732a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Issue

	- Install "Point of sale"
	- Create a new one.
	- Activate the "Is a Bar/Restaurant" feature and save
	- Activate the "Bill Printing" feature then save
	- Start a new session
	- Add a product A
	- Click on "Bill" then "Print"
	- Then click on "Ok" to go back to order
	- Add a product B

	Error is raised ("Cannot read property 'add_product' of null").

Cause

	Trying to add a product to an order who is destroyed
	if the bill has been printed.

Solution

	If the bill is printed (and not the receipt), set '_printed' of
	the current order to 'false', therefore it will add the product
	to the current order.

opw-2341115

closes odoo/odoo#59353

Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

* mail,calendar,note

Before this commit:

When accessing activities from the systray, any existing breadcrumb-item should
be clearer.

After this commit:

Clear breadcrumb-item when access activities from the systray.

Task-2342246

closes odoo/odoo#59364

X-original-commit: 6dd181c7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

"Print Return Label" button on a Transfer is showed when `is_return_picking` field is True.
But `is_return_picking` is True for any picking that is a return of another picking, making
the button visible for the return of a return, when it should not as it is an outgoing picking.

opw-2312425

closes odoo/odoo#59287

Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Behavior before the fix:

Uploading a grayscale image with transparency in the company logo field
of the document layout causes a crash:

```
  File "/data/build/odoo/addons/web/models/base_document_layout.py", line 89, in _compute_logo_colors
    wizard.logo_primary_color, wizard.logo_secondary_color = wizard_for_image._parse_logo_colors()
  File "/data/build/odoo/addons/web/models/base_document_layout.py", line 191, in _parse_logo_colors
    color[1][2] > white_threshold) and color[1][3] > 0:
Exception

...
IndexError: tuple index out of range
```

To reproduce, use the `logo_ci.png` image included in the unit test
data and load it in the document layout (under General Settings).

The system does not detect that the image does not have color
information and attempts to read the R,G,B values (but the image only
has 2 values per pixel: the grayscale value and the alpha)

Versions affected: 13, 14

Behavior after the fix:

The image is loaded correctly (arguably, there is not a lot of interest
in detecting the primary color of a grayscale image, but the script
still returns a (gray) value which is preferrable to a traceback)

opw-2352394

closes odoo/odoo#59275

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

- Prior to this commit, slide content of type document or presentation is
  having src as '/slides/embed' and that controller tries to set slide as
  viewed. Along with this, for few slide types (including document and
  presentation) and for logged in user, it will try to set slide as completed
  once slide rendering is done with help of method `_setCompleted`, without
  waiting for the iframe to be loaded. This means, the controller called from
  the src of iFrame and the above method both tries to update same 'slide_slide'
  table at the same time, resulting into concurrency error.

- This commit fixes the issue by marking the slide as completed (with help
  of method `_setCompleted`) only after the iFrame is loaded, avoiding the
  concurrent updation of 'slide.slide' table.

TaskID 2265863
Closes https://github.com/odoo/odoo/pull/52918



closes odoo/odoo#52918

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

- Go to Invoicing > Configuration > Taxes
- Create a Tax and enable "Included in Price" in Advanced Options tab
- Go to Sales and create a Quotation:
  * Add an Order Line with the created Tax
- Save & Confirm
- Edit the Quotation to set a delivery quantity, then save
- Go to Sales > Reporting > Sales:
  * Display row by "Order #"
  * In Measures, add "Untaxed Amount to Invoice"
- Check the values for the create SO
The amount for "Untaxed Amount to Invoice" is the amount with taxes included.

It is due to the fact that untaxed_amount_to_invoice field of sale.order.line is computed
from price_reduce field.
As price_reduce is computed from price_unit, if there is a tax that is included in the price,
price_reduce will also contain the tax in its value.

opw-2347571

closes odoo/odoo#59297

X-original-commit: 8c54ed42
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Before this commit, Label *Unit Cost* was displayed in the footer for *BoM Structure* report which is not displaying any cost Information.

With this commit we hide *Unit Cost* on  *BoM Structure* report.

closes odoo/odoo#59320

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Hide the add images button of the gallery snippet when not in edit
mode.

task-2312878

closes odoo/odoo#59323

X-original-commit: cd9c192f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Using box-shadow instead of border for o_move_handle button due to
incorrect border rendering when using css transform in Firefox.

task-2312878

closes odoo/odoo#58009

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Since 13.0, the website menu can contain text and buttons through
mega menus, which created inconsistencies on the way the "navbar font"
configuration works. Indeed, when setting the "button font", navbar
buttons were updated too... except if that "button font" was equal to
the "text font", in that case those buttons used the "navbar font", so
not logical at all.

This commit could solve the problem by only using the navbar font to
style bootstrap nav links, which is the common content of mega menu
snippets anyway but this would have a side-effect: text-in-navbar font
may change from navbar font to text font which is not acceptable in
stable versions. This will be changed for the very recent 14.0 though,
especially since headers can now have more static text in that version.

closes odoo/odoo#59291

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This feature description had stayed there since v8. Back at the day, we used to create one tax code per tax the module created. We removed this in v9, as similar result can be achieved by looking at the generic tax report.

closes odoo/odoo#59195

X-original-commit: 3a6aaa6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

- check the auto-validate field on the reconciliation model
- set the post at bank reconciliation option in the Bank account
- create a vendor bills with payment reference and register payment
- create a matching bank statement
- from the Accounting Overview, click on reconciliate

Bank statement and payment are not reconciled automatically.
This occur because when having 'post at' set to bank reconciliation the
payment move of the vendor bill is not posted.

opw-2336300

closes odoo/odoo#59157

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Issue occurs due to the way we compute the default value in base ir ui view.
The method _compute_defaults don't set extention mode under some condition
even if we provide an inherit_id view.

This commit double fix it, we use now self.env['ir.ui.view'] to create the
new view and so always compute the mode based on 'if inherit id or not'.
Second fixes is to explicitely set mode manually as 'extention'.

before commit:
when you drop snippet to blog sidebar and click save button.
The changes of user is not visible in sidebar because view created in mode
'normal' and not 'extention'

task-2311520
closes odoo/odoo#55908

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>

Before this this commit there would be `ZeroDivisionError` if product is archived.

Steps to Reproduce Issue:
   Create product with AVCO and Automated Valuation
   Create PO and Received all Quantities
   Archive Product
   Create Bill and Post

   There will be Traceback
   ```
File "/data/build/odoo/addons/purchase_stock/models/account_invoice.py", line 84, in _stock_account_prepare_anglo_saxon_in_lines_vals
    valuation_price_unit = valuation_price_unit_total / valuation_total_qty
ZeroDivisionError: division by zero
   ```

Now we consider Archived `stock_valuation_layer_ids` as well.

closes odoo/odoo#54610

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

The method _notify_get_groups is called to determine how a user should be
notified based on the groups he belongs to.
If a record is shared via portal but the model does not have a field named
`partner_id`, the method was failing.

With this patch, the presence of the field is checked first. No additional
access_token is computed if the field is not present.

Forward port of #59123

closes odoo/odoo#59269

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

closes odoo/odoo#59255

X-original-commit: 3f184a25
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

- Create a new Project with 'Portal user and all employees' as
  visibility;
- Add a portal user as customer;
- Create a new task in the Project, without assigning the task to
  anybody;
- Connect to the portal as the portal user;
- Send a message on the task.

Before this commit, an Error 403 forbidden was raised, this error occurs
because the task don't have an access token created, this token will be
created when an internal user send a message on the task.

Now, the access token is created if the project has a 'Portal user and
all employees' visibility, and the portal user can post a message on
the task.

opw-2345070

closes odoo/odoo#59220

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Following the last summer runbot update, the URLs have changed

closes odoo/odoo#59211

X-original-commit: 7eaec4b2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

- Create a ticket product.
- Add it to an event.
-  Uncheck it as ticket.
- Sell it on the website.

A traceback is raised here:
https://github.com/odoo/odoo/blob/88e32c5af9f47981bebea560de456a1404b4e382/addons/website_event_sale/models/sale_order.py#L88

It happens because a ticket is found, but `new_qty` is a `string` while
while `old_qty` is a `float`. It is coming from `add_qty` which is a
`string` while a `float` is expected.

We apply the same logic than:

https://github.com/odoo/odoo/blob/88e32c5af9f47981bebea560de456a1404b4e382/addons/website_sale/models/sale_order.py#L181-L190



opw-2347633

closes odoo/odoo#59177

X-original-commit: 859ffdbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Otherwise computing unstored fields forces to compute all other already
stored fields. When being in a high charge context this may have a big
impact on DB use.

Task ID-2351463

closes odoo/odoo#59222

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

- Go to the Contacts app
- Click on the Azure Interior company, or any other company with multiple associated people
- Set the country to Mexico
- Edit the VAT field and enter the following string: UAC070620MB3

Traceback will happen after hitting save.

It happens because `self` is a recordset in this case. Moreover, while
the VAT number starts with `UA`, the country is Mexico so the check is
incorrct.

opw-2348045

closes odoo/odoo#59200

X-original-commit: 5691cd94
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

- Create a tax:
  5%
  Included in price
- Set the company currency to USD
- Set the currency rounding of CHF to 0.05
- Set the rate for CHF to 0.654065014
- Create the following invoice in CHF:
  Set a payment term
  Prod 1, 1 unit,  5.0 CHF, tax 5%
  Prod 2, 1 unit, 10.0 CHF, tax 5%
  Prod 3, 1 unit, 50.0 CHF, tax 5%

It is not possible to save the invoice because of an unbalanced journal
entry.

Indeed, the Receivable line is $99.30 while it should be $99.29. This
happens because we round the `total_balance` with the rounding precision
of the invoice currency while it is in the company currency.

closes odoo/odoo#58798

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

- Create a tax:
  5%
  Included in price
- Set the currency rounding of the company to 0.05 (e.g. CHF)
- Create the following invoice
  Prod 1, 1 unit,  5.0 CHF, tax 5%
  Prod 2, 1 unit, 10.0 CHF, tax 5%
  Prod 3, 1 unit, 50.0 CHF, tax 5%

The total amount of the invoice is 64.95 CHF instead of 65.00 CHF, even
in a 'Round per line' configuration.

It happens because `compute_all` rounds the amounts following the number
of digits of the currency instead of using the `rounding` field.

Note that there is a discrepancy between the POS computation and the
Account computation: the POS already uses the `rounding` field instead
of the number of digits:

https://github.com/odoo/odoo/blob/80073c5430f0ab562dfc27572c108114161ebb25/addons/point_of_sale/static/src/js/models.js#L1855-L1991

opw-2341566

Currently the help of stock_inventory.date includes:
"If the inventory adjustment is validated, date at which the inventory
adjustment has been validated."

But for some reason this isn't the case. This commit makes it so we now
update the `date` when the inventory is validated. Since no one
previously complained about this, we only apply it to newly validated
inventories and leave existing ones as is. Note this change makes the
`accounting_date` help accurate (i.e generated account moves already
use the date when the inventory is validated when no accounting date
set, so before this fix the dates won't match).

Discovered during task: 2336455

closes odoo/odoo#59124

X-original-commit: 1da01214
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

This patch optimizes the performance of prefetching when iterating on
large recordsets.  The optimization is *transparent*, i.e., it requires
no code change for it to apply.

The worst-case scenario for prefetching is the following: the ORM has to
fetch a field for a given `record`, `record._prefetch_ids` (its prefetch
set) is *very* large (many thousands), and most records in the prefetch
set are already in cache.  This requires the ORM to iterate a lot on the
prefetch set in order to make a batch of records not having the field in
cache.

    records = model.browse(ids)     # large recordset
    for record in records:
        record.foo                  # fetch 'foo' every 1k records

When running such a loop on an empty cache, the overhead of prefetching
(determine a batch) grows as the loop progresses.  The time complexity
of this loop is actually O(N²)...

The overhead of prefetching is minimal when `record._prefetch_ids` is
about the size of a prefetching unit, i.e., 1k records.  This commit
modifies the iterator method such that every record returned by the
iterator has a prefetch set of maximum 1k records.

We measured the time taken by the loop above on an empty cache, before
and after this commit, on a simple model (res.partner.category) with
100k records.  The third measure is a reference one: a `_read` on all
prefetched fields (to fill in the cache) followed by the loop.

                            Total time      Time per 1k records
    Before this commit      3.690s          30ms - 45ms
    After this commit       1.176s          12ms
    Read then loop          1.161s          -

The measures are enlightening: the overhead of prefetching was more than
200% of the reference time, and the time to prefetch records grows as
the iteration goes on!  This commit reduces the overhead of prefetching
to less than 2% of the reference time, and make it scale gracefully with
data size.

closes odoo/odoo#59008

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

It's needed only on using skipTest in SavepointCase.setUpClass.

From docs https://docs.python.org/3/library/unittest.html#unittest-skipping

:

> Skipped classes will not have setUpClass() or tearDownClass() run.

This may lead to running out of available sql connections. It mostly happens in
odoo.sh, which has max connections set to 16, while default value is 64

Fixes #56636
opw-2345762

closes odoo/odoo#59112

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce the bug:
- Select an invoice in the list
- Click Action -> Export
- Select "I want to update data (import-compatible export)"
- Click the field "Tax Cash Basis Entry of"

Bug:
Traceback 

Cause:
Crashes because of a KeyError here: https://github.com/odoo/odoo/blob/2d860cdddf29b9fbd1a5401082c9f743028d2fb5/addons/web/controllers/main.py#L1743


The KeyError occurs because AccountPartialReconcile hasn't got a `name` field; `rec_name` is therefore `None`. Setting it to any field fixes the issue and `id` is the safest.

opw:2349511

closes odoo/odoo#59091

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

When manually updating the time on a daterange widget, the value sent to the
server is not converted to UTC and is sent as it appears on the input.

currently daterange widget send datetime value as it is, written in input field
if manually entered, so if user set 10:00:00 so while sending data it will be
send as it is 10:00:00 so when next time record reloaded after save, it will
display 15:30:00 if timezone UTC+5:30.

Instead, change the string date to moment object with current user timezone.
so that datetime send to server is UTC time and when next time it is loaded
it adds user timezone difference, so if timezone is UTC+5:30 and user enters
10:00:00 then while sending data to server it sends 04:30:00 and when displayed
again after reload it adds +5:30 timezone difference.

LINKS

PR https://github.com/odoo/odoo/pull/50132


Task 2240378

closes odoo/odoo#50132

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>