The default values for --limit-memory-(soft|hard) had been changed in
Odoo v8.0, but this change wasn't reflected in the cmdline --help.

Closes #22315

The action is not used anywhere but was not working

Closes #27034

When sorting by a many2many fields (e.g. partner_ids) with one of the record
having an empty value on the sorted field, the comparison method used to compare
and empty record (e.g. res.partner()) and a name_get result (e.g. "Agrolait").

This is because the sort_field was initialized with the result of self[field]
but never assigned a new value below.

Fallback on an empty string when no record is found

Fixes #26908

Complement of commit d5b46020, applied to the generic
Intrastat report.

opw-1878590

- Create a partner in Germany
- Set an invoice address for this partner in Poland
- Create an invoice for the Poland address, but the delivery to Germany
- Validate invoice

The Intrastat reports the transaction in Poland, while it should be
Germany.

opw-1878590

The depreciation was hardcoded as starting the first of January.
If a user changed the configuration to set a different value than 31/12 it had
no impact.

In saas-11.3, this was improved to allow to configure the behaviour at 805f3a61

opw-1878927

It has been argued that a regression took place because of e2efec8e
Before that commit, everything was reconciled together
After, only payments and orders with a partner set were

While that commit improved performances (there are much less move lines to reconcile),
it introduced an inconvenience business wise because of the noise created
by the unreconciled lines

This commit proposes to cut the pear in half by introducing an ir parameter
to choose between the two options

OPW 1883594
closes #26971

Causes a traceback "Expected singleton" when opening the Reconciliation
from the accounting dashboard

Google Important Updated: API keys are now required
We began enforcing the use of API keys, effective June 11th 2018.
Keyless usage will result in a degraded experience, or an error.

https://developers.google.com/maps/billing/important-updates

This is a backport of 5a53e5b8 as requested at #26638
Added Florian Kantelberg to our team of contributors

The 'help' of window action is often fiddled with, adding thing before,
after or arround it.

For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".

But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:

  Click to add a new opportunity
  Click to add a new opportunity
  Click to add a new opportunity
  [Original help content]
  All email incoming to * will automatically create new...
  All email incoming to * will automatically create new...
  All email incoming to * will automatically create new...

And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).

With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).

note: for 10.0 up to not including 11.0 which is fixed by #26911

opw-1877663
closes #26912

Since 76b72429 if we have a recurring event with 3 occurences:

 [4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]

And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:

- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]

And wrongly apply the current filtering over:

 [14th 4:00-4th 5:00] [24th 4:00-14th 5:00]

So the issue hides recurrences of event wrongly if:

- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
  number of detached previous events) is not in the current filtering.

With this change, the stops are also filtered based on start of
occurrence + duration.

Without the change, the added test fails with:

 False != '155-20120301120100' : Last event should be found searching it by date range

note: for 10.0 up to not including 11.0 which is solved with #26901

opw-1866151
closes #26887

If currency set on account, all journal items part of this account must have either the same
currency or no currency.

Commit https://github.com/odoo/odoo/commit/2b587d34ff30147c03baf16e998effe46ce5d9cf#diff-2d656902930900b836412f086c924643R164
incorrectly removed the content of the cron.

Indeed, `membership_state` is a computed field which depends on time
(which is usually a bad idea). Therefore, we must force its
recomputation.

opw-1878878

In a multicompany environment, if the user is not logged-in in the same company as the statement's company (even though he might have access to it), the reconcile interface was filtering on the user's company instead of the bank statement lines's company.

Was PR #26782

Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.

This is because in the refactoring adding modules (e8a00bc5) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.

But there was still an usage of the removed implementation.

opw-1880766
closes #26816

When two transactions conflicts (eg. deleting same data, see [1]) Odoo
will retry the whole transaction several times hoping for the best.

But when rendering template, the error handling would prevent this
feature. For example a recurring issue was:

- loading quickly two times the /web route
- for each recompute the assets

=> this could lead to 2 concurrents transactions that would delete
previous same attachment (ie. DELETE FROM ir_attachment where id=3).

With this changeset, when getting a template fails because of a
transaction rollback, we let the issue bubble up so our retry system is
used.

So instead of a "500 Internal Server Error" page and in log:

  bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
  ERROR: could not serialize access due to concurrent update
  "GET /web HTTP/1.1" 200 -
  "GET /web HTTP/1.1" 500 -
  ... big traceback ...
  load could not load template

we would get the requested page without error and:

  bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
  ERROR: could not serialize access due to concurrent update
  "GET /web HTTP/1.1" 200 -
  SERIALIZATION_FAILURE, retry 1/5 in 0.8920 sec..
  "GET /web HTTP/1.1" 200 -

As a side node, the issue was exacerbated in some instances:

- when running a database on another server: assets are recomputed
- when a module was installed/uninstalled: assets may are recomputed
- when updating the source code: assets may be recomputed
- when starting server: requests could be stacked waiting for readiness
- when using google chrome: the "Use a prediction service to load pages
  more quickly" option may load a page two times. for example:
    -> an URL is entered in address bar
    -> a prediction request to it is started URL
    -> go to this page (Enter) when that request is not already resolved
    -> the prediction request is cancelled and a new request is started

[1] https://www.postgresql.org/docs/9.6/static/transaction-iso.html#XACT-REPEATABLE-READ

note: 10.0 backport of 11.0 #26778

opw-1849167
closes #26785

Add the image name in the website for SEO purpose. This is a backport
of:
88a5d9a0
886c07da
152e3f86

opw-1880472

In Employees views, selecting New Hired filters leads to an access error
with a simple user.

With this commit, this filter is limited to the corresponding users
group.

Backport of 804b9b7c

fixup e65c8826
fixup da2140b7

closes #26746

If we do:

- one change that will be saved in history
- go back to the document before any change
- do other change

we can easily get in a state were the history is no longer recorded.

The history is kept like this:

- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved

so for example if we start without change (at originalState):

  {pos: 0, aUndo=[], toSnap=null}

Then we do two changes (change1, change2):

  {pos: 2, aUndo=[originalState, change1], toSnap=change2}

If we make an undo, we will get to:

  {pos: 1, aUndo=[originalState,change1,change2], toSnap=null)

If we make another change (change3):

  {pos: 2, aUndo=[originalState, change1], toSnap=change3}

So the history after the position is removed.

But when we get back to the original, the state would forever be:

  {pos: 0, aUndo=[originalState], toSnap=change85}

because when doing a change, the code only removed history from the
max(pos, 1) index.

opw-1870119
closes #26701

In the editor in a table cell, when we press UP/DOWN keys:

- we have default editor/browser behavior if there is content before
  (UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior

But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:

```
<table>
<tr><td>
  <p>hello <b>world</b></p>
  <p>cruel</p>
</td></tr>
<tr><td>
  <p>bingo</p>
</td></tr>
</table>
```

if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.

Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.

opw-1870119
closes #26701

The override of fields_get adds "virtual" fields corresponding to
groups.

If for example we make "res.users" have inherit "mail.thread", we get
these "virtual" field as if they had "track_visibility", since we do a
"fields_get" with fields having track_visibility expecting to only get
back "track_visibility" ones.

So the system would then fail trying to track visibility on fields like
"in_group_5" and for example a res.users could not be created anymore.

With this fix, we fix the fields_get so it respect the fields we ask of
it.

fixes #22332
opw-1878654
closes #22338
closes #26705

Co-authored-by: Wolfgang Pichler <wpichler@callino.at>

Some users are confused by the generic error message asking to confirm a sale
order that is in locked or cancelled state.
We add specific error messages in these two cases.

opw 1871019

According to discussion on jvOrsouw/Odoo11#1

Closes #20605

Unless there is a a bug, do not remove a currency conversion.

This reverts commit 5028da38.

compute method called 2 times in t-esc case when monetary field has "from_currency ::
 1) value_to_html: compute method call when qweb monetary widget is return value as a html.
     see https://github.com/odoo/odoo/blob/10.0/odoo/addons/base/ir/ir_qweb/fields.py#L325
 2) compute_currency : compute_currency method is pass from controller into render engine and it is call the compute method.
So, we removed compute_currency method from qweb template in the t-esc with monetary widget.

FIXUP da2140b7

The above commmit was half-right in the business logic, but overlooked that if a user is not
in the company of the project, it will crash.
This use case worked before that commit

While agreeing that a little more clear access right is needed
like for example be able to get the project_time_mode_id on the companies
that are in user.company_ids,
the aim of this present commit is to avoid regression

OPW 1878204
closes #26539

Steps to reproduce:

Create a customer invoice with 2 product A and refund 1 product A.
Display account.invoice.report for this custumer.

Bug:

The quantity should be 1 not 3.

Fine tuning of this commit: e8906826

opw:1868116