In case of a picking type where stock move lines are not shown, clicking
on 'Put in Pack' without 'Done' quantitites set shows a confusing error
message.

closes odoo/odoo#40920

Related: odoo/enterprise#6901
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

- Activate product packing
- Create a PO for a stockable product, validate
- In the barcode interface, go to the created picking
- Set the product quantity
- Click on 'Put in Pack'

An error is raised: 'All the products currently reserved in the picking
are already in a pack...'

In the regular interface, the procedure is to create the move lines
manually, therefore setting a quantity done. However, this is not
possible in the barcode, and `move_line_nosuggest_ids` is always empty.

We introduce a special use case to bypass this in the case of the
barcode view.

opw-2127637

opw 2144639

closes odoo/odoo#40874

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

fixes #38014

closes odoo/odoo#40838

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

The current 'Newly Hired' filter is incorrect in several ways:
- the compute method doesn't assign the value correctly
- the search method mixes `hr.applicant` IDs with `hr.employee` IDs

Moreover, it relies on the fact that the job position is closed. Some
positions might always be opened, so the result is inaccurate.

We make the simpler assumption that the newly hired people are employees
created less than 90 days ago.

opw-2125861

closes odoo/odoo#40889

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

When clicking on stat button "Meetings" on a partner, just highlight the
partner meetings as is done for similar stat button instead of having
a domain that hides other event (so when creating meeting, we can take
into account other existing meetings).

A similar change with same reasoning has been done for "Meetings" stat
button of hr.applicant records.

opw-2131494
closes #40812

closes odoo/odoo#40891

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

closes odoo/odoo#40898

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

Before this commit, the export of translations was incorrect for code
and model translations:

For code translations, the field 'name' was used for the matching
while the _() method explicitly use None in the _get_source call to
only use the field 'src' for the search.

For model translations, the field 'res_id' was not used when searching
for a translation.
For instance, if a ir.model.fields did not have translated label,
exporting the translations was using the translations of the first
field having the same source.
While this could be convient during the import (to be discussed),
doing so in an export of translation is clearly an unexpected
side-effect.

closes odoo/odoo#40879

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

Those cases are already checked in models._check_company() but not considered
when defining the default domain on `check_company=True` fields.

* Consider res_users relational field
	Companies allowed for user = user.company_ids
* Consider company-dependent fields
	Companies allowed = self.env.company

closes odoo/odoo#40724

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

closes odoo/odoo#40754

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

A second edition is being written but not published yet

closes odoo/odoo#40405

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

Backport of CLA from master (af98694e) to 13.0 for odoo/odoo#40405

- Create a vendor bill for partner A with reference 'AAAAA'
- Create another vendor bill for partner A with the same reference:
=> Constraint is triggered.
- Create another vendor bill without partner with the same reference.
- Edit the vendor bill and set a partner:
=> Constraint not triggered.

closes odoo/odoo#40849

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

closes odoo/odoo#40864

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

im_livechat main controller was referring to website.visitor but this module is
not depending on website. The usage of website visitor's name should have been
done in website_livechat module.

This commit fix this issue.

Task ID: 2116715
PR #40732

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

The slide.slide "_compute_slides_statistics" method is missing the 'slide_ids.sequence' trigger.
It should be specified for cases when one of the slide_ids changes category (determined by the
sequence).

This can cause some CacheMiss and seem related to nondeterministic errors on the runbot.

PR #40705
Task#2123711
Runbot build error ID 247

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

before this commit:
when creating a product from frontend and editing the product and
delete image, it doesn't get any url thus generating the traceback.

after this commit: if url is not defined then return None from
ir.qweb.field.image field converter

task-2063293

closes odoo/odoo#40626

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

This commit applies the following ACLs rules:

C : nobody can create visitor (except of course the automated flow)
R : everyone that should access to this model
U : website_designer can update (even if only few fields are editable),
    mainly useful for language (+ system obviously)
    + livechat users as they are the guys who directly speaks with the visitors
D : system + website_designer can delete, mainly useful to clean if necessary

Remove the no_create from all visitor views as nobody can create.

This fixes the 'can create' that should not be done by any users (even admin)
except the system.

Task ID: 2092502
PR #40439

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

Before this commit, the computation of kpi for last week, last 30 days and
previous period comparison was wrong due to cache. Indeed as first value
was in cache, other values were taken directly from cache itself instead
of recomputing each value based on start_date and end_date of the computation
timeframe.

As digest fields are computed fields used a bit off-side, let us manually
invalidate the cache before computing a kpi so that it correctly computes
the timeframe values.

Task ID 1883428

closes odoo/odoo#40834

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

Steps to reproduce the bug:
- Let's consider a fiscal position FP with automatic detection for customer in your country
- Let's consider two taxes T1 and T2 where T1 is mapped by T2 in FP
- Let's consider a product P with T1 as customer taxe
- Let's consider a customer C in your country with no fiscal position
- Create a repair order for C
- Add P as an add line

Bug:

T1 was set as customer taxe for P instead of T2.
When manually creating an invoice for C with P, FP is automatically
detected and T2 is set.

With this fix, the automatic detection of FP is applied on repair order.

opw:2120595

closes odoo/odoo#40511

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

- Group the SO list view by Analytic Account
- Go to a SO
- Click on the stat button 'Timesheets'

Traceback because the field `analytic_account_id` is not on Timesheets.

opw-2124539

closes odoo/odoo#40518

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

Accounting > Configuration > Journal > Create
Under Journal Entry Tab Fill name, type "Bank", short code
Under Advanced Settings tab set Post at "bank reconciliation"
Save

Go to Accounting > Customer Invoices > Create
Add Customer, and SO line with label and price, remove Tax Line.
Post and Register payment on the created journal.

Go to Accounting > <Created Journal> > Create
Add reference, label, partner as in soline, amount as in so line.
Save and Reconcile.

There will be no entry to reconcile with. This is because the domain
used by the reconciliation widget does not take into account the
possibility to have a draft move_id, so the line which can be reconciled
because the line is automatically posted on reconciliation is filtered

Rearranging the domain to take into account this possibility

closes odoo/odoo#40786

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

When you create a pos order, it is possible that the request timeout or
the client loose the connection with the server, that will lead to not
have the server_id of the order sent to the server. So when the client
will try to synchronize the order again, it'll not send the server_id to
the server, and the server will create a new order which is a duplicate
of the one created when the client lost the connection.

To avoid this duplication, we are using the pos_reference to find if
there is an existing order like in 12.0 to avoid duplication.

closes odoo/odoo#40600

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

After the rainbowMan issue was fixed here: e5bc2e7, steps were consumed
on 'click' events. This caused an issue with the drag and drop event
(which breaks tour, because it is expecting a click event). If the user
dragged an element, thetip was not getting consumed as no click event
was triggered.

closes odoo/odoo#40810

X-original-commit: 3f458fe06e6a629edc72428eab749068c2eba1ba
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>

Archived users are inactive, so we shouldn't be able to ping them.

Task-2046885

closes odoo/odoo#40809

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

In the pivot view of report.pos.order that is a view mainly over
pos.order, the "Count" measure is a little rubish giving more or less
the number of different products in the grouped order lines.

With this changeset, we have the field "Order" as measure that allow us
to know the number of orders a grouping is corresponding to.

opw-2127275
closes #40723

closes odoo/odoo#40797

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

Following f6ae9f0a and dee9042e
Started as a forward port, exporting all terms in the end

closes odoo/odoo#40794

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

A customer reported an issue when he tried to add a link on the
blog covers of his blog. The link is displayed as text and it's added
to all the covers.

![links on all covers](i.imgur.com/fuFu6op.jpg)

According to SBU, the user should not do this.

This commit prevents the user from editing a blog cover.

OPW-2119924

closes odoo/odoo#40783

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

Steps to reproduce the bug:

- Let's consider Today = 21/11/2019 and Employee E
- Create a new hr.leave.type LT and set a validity from 01/01/2020 to 31/12/2020
- Set mode = Free Allocation Request and Validation = No Validation
- Try to create leave allocations for LT

Bug:

It was impossible to create a leave allocation for LT because Today < 01/01/2020
So it was impossible to allocate future leave.
We had to wait the 01/01/2020 to make the allocation of LT leaves

opw:2126300

closes odoo/odoo#40629

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

- Create a product tracked by lot
- Create a delivery picking

You are allowed to create a new lot for the product although the picking
type doesn't allow it.

This is because of the missing context key `active_picking_id` on which
`_check_create` relies:

https://github.com/odoo/odoo/blob/e5ee5e5b65f85d66c8d59594ead9eece172c4282/addons/stock/models/stock_production_lot.py#L50



opw-2128497

closes odoo/odoo#40793

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

It was discussed previously from:
 - https://github.com/odoo/odoo/commit/b79d05fff0cacb4d99ebc1b60f44d8dab757b806



I quote Olivier Dony commit message:

"""
Having it in INFO should be sufficient for its purpose, and will avoid
impacting all CI builds done on a system that does not have the lib
installed.

For the record, this is not a hard requirement because the lib was not
available in Debian stable packages at the time of release. It is only
enabled on demand for those who want the feature and can install it
manually.

Fixes #22426
Closes #22459
"""

closes odoo/odoo#40781

X-original-commit: 0394f5e9
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

steps to reproduce:
-change decimal accuracy for "Product Price"
-create a price list with fixed price
-the fixed price field does not takes the decimal accuracy into account

this was working in V11 and V12
fixed_price was a float field like other price fields

previous behavior:
fixed_price is a monetary field
when setting up a fixed price for a pricelist, it takes into account
the precision from the current currency

current behavior:
fixed_price is a float field
when setting up a fixed price for a pricelist, it takes into account
the proper decimal accuracy setting ("Product Price")

opw-2121964

closes odoo/odoo#40777

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

Added Chart of Accounts, taxes and other related data

closes odoo/odoo#40776

Task: 42243
Courtesy: www.vitraining.com
Signed-off-by: Josse Colpaert <jco@openerp.com>

closes odoo/odoo#40512

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

This is a performance fix.  It avoids the cost of XML/HTML translations
for fields that may not be necessary when prefetching fields on records.
This patch marks such fields as non-prefetchable by default.

The code that changes the attribute `translate` on HTML fields (from
`translate=True` to `translate=html_translate`) has been adapted to
allow the setup of textual fields to mark the field as non-prefetchable.

Jairo Llopis made a comparative benchmark: evaluating `name_get` on
`event.event` records.  The method needs the field `name` and without
the patch, the prefetching mechanism reads the translated HTML field
`description` as well.  This patch speeds up the benchmark from 5800ms
to 800ms (see https://github.com/odoo/odoo/pull/37967#issuecomment-538364011

).

closes odoo/odoo#40706

X-original-commit: 4d501480
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Pedro Baeza <pedro.baeza@tecnativa.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>

The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.

`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.

Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).

While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.

This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.

closes odoo/odoo#40213

Related: odoo/enterprise#6688
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

closes odoo/odoo#40589

X-original-commit: d8bc17d5
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

We are initializing over the limit to make sure we will compute it at least once.
If the target goal is set to 0, we are facing a division by zero error when
displaying the gamification goal just after initialization.

closes odoo/odoo#40729

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