- Install stock module
- Activate multi-company and variants
- Create a second company
- Create a product with 2 variants
- Create a picking with the product for both companies
- Add an attribute on the product with 2 values
- Save

An AccessError is raised on `stock.move`.

It arises because the field `product_qty` on `stock.move` must be
recomputed but is on a record in a different company.

The `try` / `except` clause doesn't protect against the recomputation.
Indeed, what happens is:
- try to unlink in batch => AccessError due to recomputation
- try to unlink individually => AccessError due to recomputation
- try to write individually => the field couldn't be recomputed before
(flagged as dirty), so try again to recompute => AccessError

We perform the operation as sudo, and take care of checking the access
rights beforehand.

opw-2009450

closes odoo/odoo#34369

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

There is no guaranty that both the request body and the response body
will contain JSON data. This fix corrects the logging by printing the
raw text in case of json decode error.

opw-2006561
opw-2024242

closes odoo/odoo#34221

Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

The tags set for TVA déductible (achat) 5,5% TTC were for "TVA collectée"

opw:2026360

closes odoo/odoo#34410

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

Complement of commit 7a24df48

opw-2009044

closes odoo/odoo#34374

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

1. Setup a few variants for a product;
2. Create a BoM for each of the variants with different
components/quantities, make sure to specify the product variant field;
3. Go to any of the variants and click Print BoM Structure.

Before this commit, it will print the BoM structure for all variants and
not only the one selected. Also, it will print in all the variants the
same BoM structure. If multiples BoM were selected to print, each
variant of the product was printed with each of the BoM structure
selected.

Now, if you select one BoM, only this is printed. If multiples BoM are
printed, each product, and product variant are correctly related to
their respective BoM structure.

opw-2007939

closes odoo/odoo#34353

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

Steps to reproduce the bug:

- Create a finished product P with a manufacturing BOM B
- Set two components on B C1 and C2
- Create a MO with P and process it(plan and produce it)
- Unlock the MO and set the consumed qty of C1 to 0
- Lock and click on Mark as Done
- Click on Cost Analysis

Bug:

C1 was displayed in the report with a qty = 1.0

opw:2010912

closes odoo/odoo#34351

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

The `timesheet_uom` widget is a proxy to another widget (configurable
server-side). We need to ensure the widget registry is filled before
using it to avoid a fallback to `float_factor` widget.

closes odoo/odoo#34350

Signed-off-by: Christophe Simonis <chs@odoo.com>

In case a many2one field (let us say 'foo') is used
simultaneously as a groupby and a measure in the pivot view,
the values returned by a read_group for that many2one are of
the form [id, label] and the aggregated values (always 1) are
missing in the read_group results (datapoints).
Thus typically, a datapoint is of the form

{'foo': [1, 'Bar'], '__count': 4, ...}

and does not contain information on the 'foo:count_distinct'
value (this is a read_group bug).

As a consequence, a special processing of the read_group
datapoints is done in the pivot model to handle that
situation and the value for 'foo:count_distinct' is infered
correctly to be 1.

In the pivot comparison mode, datapoints comming from the
period and the comparison period (data and comparisonData
sets) are identified if they have same values for the groupby
fields and the measure values become small objects containing
information on the the measure values for data and for
comparisonData and on the related variation.

Thus

{foo: [1, 'Bar'], __count: 4, ...}

from data and

{foo: [1, 'Bar'], __count: 3, ...}

from comparisonData should become a single datapoint

{
foo: [1, 'Bar'],
__count: {
data: 4,
comparisonData: 3,
variation: {
magnitude: +33 (%)
}
}
fooAggregate: {
data: 1,
comparisonData: 1,
variation: {
magnitude: 0 (%)
}
}

It turns out that the code responsible for merging the data
and comparison datapoints made a mistake by mixing the keys
'foo' and 'fooAggregate', with the consequence that the
variations were not correctly computed in the situation
described above.

This is fixed in this commit.

closes odoo/odoo#33118

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

Make the 'Custom Message' field translatable since it is supposed to be
used on the website and displayed in the language of the user.

opw-2008088

closes odoo/odoo#34344

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

Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.

This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.

Task-ID 2026101

closes odoo/odoo#34291

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

- Set 2 banks accounts for a partner A
- Create a credit note
- Choose partner A => a default bank account is chosen, and both are
available in the list.
- Save, go back to the tree view, then reopen the same credit note

It is not possible to choose among both bank accounts anymore.

It is due to the domain set on the view, which is valid for customer
invoices but not for credit notes. It works at creation since
`_onchange_partner_id` overrides the domain for `out_refund`.

In this specific case, a domain in the view is not appropriate: the same
view is used for 2 invoice types although they require a different
domain. Therefore we set the domain only in the onchange. The drawback
is that all bank accounts are shown when we reopen a customer invoice or
a credit note from the tree view since the onchange is not triggered.
However, the constraint `validate_partner_bank_id` still protects
against an incorrect configuration.

opw-2010017

closes odoo/odoo#34292

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

In certain case, a non blocking traceback pops-up.
It happens when the page loads, if the dom is modified
before the tour has been fully loaded.

Theorical steps to reproduce:
- Open a page with an active tour
- Trigger any domain change before the tip-dot is loaded

On every change in the DOM, the MutationObserver tries
to update the page. If the tip-dot has not been loaded yet,
it will try to update the position of a non-existing element.
In that case, we simply ignore it. The update will be called
anyway when the tip-dot has finished his loading.

opws:
1923348
1965964
2011027
2008708
2001867
2000228
1998906
1972914
1972629
1963173
1961373
1956962
1949591
1947390
1947286
1944577
1944459
1941764
1938887
1936518
1935831
1934788
1934471
1934225
2006977
1970672
1931721
1931593

closes odoo/odoo#34199

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

- Configure Stripe with 'Save Cards' set to 'Let the customer decide' or
'Always'.
- Go to the eCommerce, buy an item
- Use Stripe to pay, make sure to check 'Save my payment data'

No payment token is saved.

It occurs because 2 calls are performed to `/shop/payment/transaction`.
The second call, which is used to record the transaction, doesn't
contain the `save_token` parameter is not sent.

Ideally, we should only make a single call, but since Stripe works a bit
differently, we can't prevent it (in stable, at least). Therefore, we
work around it by searching the checkbox value.

opw-2008275

closes odoo/odoo#34242

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

- Set the 'Editor Features: image and links' karma point to zero.
- Set a user with a total karma points < 30

The user doesn't see the links buttons in the editor.

This is because of an old fallback from 2014 which doesn't make sense
anymore today.

opw-2026025

closes odoo/odoo#34325

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

Set the building icon next to the rounding method label since it is a
multi-company setting.

opw-2026025

closes odoo/odoo#34315

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

For custom fields, the _module attribute is False, this means that
during the reflection of the model, the custom field's xmlid would be
set up as being introduced in the module of its model's original
definition, which is wrong (because it has no module).

E.g. field x_foo introduced in my_mod by extending model bom from
mrp, the resulting xmlid would be `field_mrp_bom__x_foo` when in reality
it should be `field_my_mod_bom__x_foo`, however this patch simply
disables the feature for custom fields as there is little to no use for
them to have an automatic xmlid.

Task-ID: 2025151

closes odoo/odoo#34265

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

Before this commit, in project overview, there was an advance payment
line under 'Timesheets' section which was unnecessary for the timesheet.

After this commit, down payment line will not considered in project overview.

task-1957272

closes odoo/odoo#34062

Signed-off-by: Jérome Maes (jem) <jem@openerp.com>

- From Accounting dashboard > Configuration panel > Configure fiscal year
- Set opening date: 01/07/2018
- Set fiscal year end: June 30
- Click Apply button

An error is raised: 'Invalid fiscal year last day'.

This is because the 3 fields are linked by the constraint
`_check_fiscalyear_last_day`. However, non-stored writeable related
fields are evaluated one at a time, meaning that the constraint is
evaluated one value at a time.

We do a fancy workaround to write the 3 values at once on the company,
hence evaluating the constraint for the 3 fields once.

opw-2024927

closes odoo/odoo#34275

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

Configure your system to be in the Mexico timezone, configure your Odoo
profile accordingly. Go to calendar, show daily events, add an event at
the end of the day (like 10pm). The resulting event is not visible on
the daily view although it is on the weekly view. The same problem
occurs on the weekly view if the event was create late the last day.

The problem is the initial `search_read` has a domain to filter the
events using 00:00 UTC to 23:59 UTC boundaries. Those boundaries are not locale
aware, they should be shifted to the MX timezone.

opw-2009877

closes odoo/odoo#34247

Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

The field module_account_accountant is called "Account" in account module
but was changed to "Account Accountant" in hr_payroll, making the source of
a translated record to change based on the module installed (which can lead
to confused translators or broken universes)

Terms export was unified at #34296

closes odoo/odoo#34298

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

The view content was changed at 3b5f3328 but the changes were not
reflected in the pot file

opw-2025750

closes odoo/odoo#34296

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

As we will move those from other localizations to base,
we add those for Mongolia to base already.

closes odoo/odoo#34281

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

We correct the income/expense account and add
the stock input/output/valuation accounts.
Mn also uses Anglo-Saxon accounting.

Closes #34002

DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).

1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).

Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.

2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.

closes odoo/odoo#34243

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

The fix added in 3a0f05f3 doesn't work if an already existing user in company A
trys to modify his address on a website linked to company B. The form will try to change the company_id
of the res.partner which will then conflit with the company_id of the associated res.user, ultimately leading
to a UserError and a 500 error on the website.

opw-2025457

closes odoo/odoo#34262

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

Commit 6b14ceb2 introduced a smarter way to find the default
journal based on the currency. However, it missed the fallback if no
journal is found.

opw-2009934
opw-2024204
opw-2011321

closes odoo/odoo#34263

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

Steps to reproduce the bug:
- Create an hr.leave.allocation with mode = 'By Employee Tag'
- Select Employee Tag = 'Employee'
- Set all the other required values
- Log with Demo User(Marc Demo)
- Go to Leaves > My Leaves > New Request

Bug:

An access right error was raised due to the record rule: "Allocations: employee: read own"
With this record rule the user can only read the hr.leave.allocation linked to his employee's user.
But with allocations in mode 'By Employee Tag', in the function get_days it tried to compute
the 'number_of_hours_display' of all the allocations linked to the current employee's user and
in the function _compute_number_of_hours_display, it also computes the parent_id of these allocations.
As the parent_id is not linked to the employee's user, it raised an access right error.

opw:2006686

closes odoo/odoo#34236

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

The months name in momentjs used an arabic translation with the month
then some crap (or the month said a second time) after.

This does not seem expected, and has been solved in moment.js library 2
years ago:
https://github.com/moment/moment/pull/4271



This PR apply this change in moment.js localization included in Odoo.

opw-2006265
closes #34248

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

A pie chart widget aims to instantiate a graph view in mode
'pie', with a measure and a single groupby specified via some
attributes. It turns out that if a pie chart is instantiated
in a context in which the keys 'graph_mode', 'graph_measure',
and 'graph_groupbys' are present, that keys prevail over the
pie chart specification. This can produce a line chart for
instance. This fix corrects that situation.

A test has been added in a corresponding commit in enterprise
(historically, the pie chart widgets are tested in dashboard
views).

closes odoo/odoo#34234

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

- Create a leave type valid from June 1st
- Create a leave in May using the created leave type

Nothing prevents the user to do it.

It is because the constraint is implemented only if there is a validity
start and end date.

Fixes #32107
opw-2009800

closes odoo/odoo#34225

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

Steps to reproduce the bug:
- Create a vendor receipt in a journal with a foreign currency with taxes
- Validate it

Bug:

A UserError was raised because it tried to create unbalanced entries

Technically: the debit and credit of the VAT account move line were not converted
in the currency of the of the voucher's company.

opw:2007760

closes odoo/odoo#34203

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