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>

- Create a calendar event
- In debug mode, remove the responsible

The 'Avatar Undefined' string is displayed at the botton of the
responsibles' list.

Do no fetch an image for a falsy value (= falsy id)

opw-2010007

closes odoo/odoo#34215

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

The search buttons visibility is saved in the local storage. Rev.
6448420c changed the API of the LocalStorage servive (by JSON
parsing the values), and didn't adapt the calls done for the
search buttons.

Closes #33833

closes odoo/odoo#34206

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

As a convention, JPY currency symbol normally shows before the amount.

closes odoo/odoo#34113

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

Do not crash at currency conversion when no company is set.

closes odoo/odoo#34155

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

The way to find a matching about structured communication is done by:
1 - making a filter to keep only numerical values.
2 - splitting the result into array.
3 - finding an intersect between the sets.

For example,
"Payment about +++123/456789+++ and +++987/654321+++" is matching "123456789 blablabla"?
1 - "123456789 987654321" is matching "123456789" ?
2 - ["123456789", "987654321"] is matching ["123456789"]
3 - YES because "123456789" intersects both sets.

This commit is about the check is always TRUE when both sets are empty.
In this specific case, the result must be FALSE.

-opw: 2008299

closes odoo/odoo#34115

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

Stock.locations should be in no-update:
Limit the impact of recompute fields during the upgrade of stock module. (especially method _compute_product_availability)
Limit the impact on migration

Method _compute_product_availability is triggered during an upgrade of module and during migrations.
This may take a lot of time of big databases

closes odoo/odoo#34074

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

In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.

The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.

opw-2006647

closes odoo/odoo#34076

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

On `WebRequest` `__exit__`, when an exception occured,
(in `self.registry.signal_changes` or `self.registry.reset_changes`)
cursor were left unclosed as `self._cr.close` was not called
in such cases.

Having exceptions in the above mentioned method do not happen
often, but when it does it left unclosed and unusable cursors
in the connection pool, and in the extreme case explained below,
it left the connection pool with only unclosed and unusable cursors.
The entire server was then unusable as it no longer had working cursors.

Case:
- Start a multi-thread server with db_maxconn set to 5
- Ensure you do not send any request to the server,
not even with a left open tab on `http://localhost:8069` in your browser
- Send 6 parallel HTTP requests to `/web/login`
thanks to an external thread python script
(See below, at the end of this long commit message)

According to your registry state (if you have a lot of modules installed or not),
and the native Python Garbage Collecting state,
you might end with
- either warnings telling some unclosed cursor were garbage collected,
and therefore closed (by a kind of luck thanks to the Python garbage collecting),
- either, a server completely blocked not accepting any other request
(you can try for instance `curl http://localhost:8069`
and you end up with a `500 Internal Server Error`

This observed issue looks to appear only in 11.0. Not 10.0 or 12.0.
This is because only 11.0 clear the cache during registry loading:
`https://github.com/odoo/odoo/blob/f1706c848d41c47646dabca771996e9b9f788241/odoo/modules/loading.py#L236`
This cache clearing doesn't happen in 10.0 nor 12.0
(in 12.0, thanks to e181f592)

When sending the 6 parallel requests,
it uses instantly all the 5 available cursors of the connection pool to handle these requests,
and when each request exits, in `__exit__`, it calls `self.registry.signal_changes()`
which tries to open a new cursor because of
- `self.cache_invalidated` which is True, for all the 6 requests, thanks to the call to `clear_caches`
explained above during the registry loading and the fact all requests have been treated in parallel,
- `with closing(self.cursor()) as cr:`, `self.cursor()` attempting to use a new cursor
(the `closing(...)` does not have any incidence on this issue, despite it could look like guilty)

The attempt to use a new cursor fails, as there is no more available (`db_maxconn` is reached),
raising a `PoolError('The Connection Pool Is Full')` exception.

In the request `__exit__` method, because of this exception raised when calling `signal_changes`,
`self._cr.close` is never reached, and the parallel request therefore left only unclosed
cursors in the connection pool,
therefore leaving the server in a state where it only has unusable cursors
and therefore can't do anything more.

This might look like really bad luck to land in such a state,
but we observed multiple actual case on Odoo.sh,
the one referenced in this commit (opw-2008340) was because of an Outlook client
which launched 18 parallel requests to fetch the email images,
and the server wasn't spawned, therefore neither was the registry.
The server registry was therefore just loaded when it received the 18 parallel requests,
and it therefore triggered this extreme use case.
The server was left unusable for several minutes, until a forced restart.

For reference, here is the script that has been used to trigger the 6 parallel requests:
```
import requests
import threading

threads = []
for i in range(6):
threads.append(threading.Thread(target=lambda: requests.get('http://localhost:8069/web/login'))

)
for thread in threads:
thread.start()

```

opw-2008340

closes odoo/odoo#34071

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.

opw-2008491

closes odoo/odoo#34067

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

Installing test_new_api without demo will fail since demo_user
does not exists. This is a problem if we want to test migration
with all modules installed. This simple fix solve the problem.

closes odoo/odoo#34065

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

Have a multi-company setup, with shared products.
Write the default code of a product; an access error is raised on inventory.line

On inventory.line, the field product_code is defined as related to
'product_id.default_code', and stored.
So when writing on the default_code of a product, we get the inventory lines of
other companies. For obvious reasons their access is protected by the record
rule "Inventory Line multi-company", therefore the access error is raised.

To avoid that situation stored related fields should be in compute_sudo.

Note that similarly this is necessary for product_name.
There is one more subtlety: directly writing on the product.product does trigger
the access error, but writing it on the product.template does not.

opw 2007167

closes odoo/odoo#34019

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

This commit shouldn't have been land in saas~11.3
See https://git.io/fjg2o

This reverts commit a25f6e1b.