Note that we do not do a custom build anymore, since we lazyload the
files anyway.  A custom build will save a few kb, but will not do any
meaningful change to the user experience.  However, it dies impact
negatively our ease of maintenance, so standard build it is.

create_date is not required but may be assumed as always set such as in
base.partner.merge comparison
The administrator had no create_date set

Avoid errors in merge wizard if one of the record has no create_date

Fixes #22730

In multi pages list view, the scroll position is reset to top when
the user switches between pages. This wasn't working if he first
reset the limit, and then switched between pages.

This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):

 - generalize the scroll position handling from web_enterprise to
   web to make it available in the community webclient as well
 - also restore left scroll position, not only top (especially
   useful for grouped Kanban views with a lot of columns)
 - handle the case where the scrolling area is a sub element of
   the view (e.g. the grouped Kanban view in mobile).

Task 34037

Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>

In order to avoid people selecting a bank account not belonging to the partner's company, we now filter using a domain.
Original idea from PR #23480. Courtesy of Miquel Raich (Eficent)

crediting is not refunding

Closes #19001

Given the following variables:
    * Module A
    * Module B
    * Model M
    * Field X of model M

If module A defines M.X and is installed, an xmlid for this field is
generated in the form of A.field_M_X

Before this commit:

If module B defines M.X as well and is installed after module A, no
xmlid is generated.

This means that if module A is uninstalled, the single xmlid pointing to
M.X will be deleted and thus, the field itself will be deleted as well,
therefore any views from module B referencing M.X will crash.

After this commit:

If module B (or any subsequent modules) define M.X, an xmlid will be
generated in the form of B.field_M_X.

If module A is uninstalled, the xmlid A.field_M_X will be deleted, but
B.field_M_X will remain and thus the field itself won't be deleted.

This system means that for a single actual field, there can be multiple
xmlids, each xmlid sharing the same field, thus the name "shared
fields".

Task ID 38016

From 'Accounting Dashboard', creating a new payment was raising an error 'Record does not exist or has been deleted.'.
That's because since cdca5d47 the default_get() was expecting to be called directly from the account.invoice model, using 'active_ids' to compute default values. Since it was incorrect, we now also check for the active_model to avoid raising this error.

Was PR #23548
Was task: 1824893

Commit 42659dc7 recently done in saas-11.2 added performance test cases
in test_mail module allowing to cover more use cases. Since release of
saas-11.2 some optimizations already landed in master pre-saas-11.3 and
some features have been refactored.

This implies updating the performance counters. This is done in a separate
commit to distinguish previous-counters from current counters instead of
loosing it in a diff.

Most message-post related tests have been improved by some queries as
message creation has been speeded up at f727e9d9. Some other commits
like 9de5d417 also slightly improved performances. Activities-related
performance have been improved at e8998123. Tests case involving
assignation notification perform worst than in saas-11.1 . It is linked to
the feature using more advanced email and templates as well as working for
Inbox too which is not the case in saas-11.2. This improvement has been done
at e9734f49 .

This commit is related to task 1824965. Thanks to @KangOl for being
nice with people trying to make its forward-port more difficult.

This commit is a manual forward-port of saas-11.2's 42659dc7 .

In test_mail there are performance tests involving several followers and give
counters for some heavy real-life-like use cases. Purpose of this commit is to
have more basic performance tests for main mail features, like simple post,
simple subscription of one follower. It allows to have an idea of the basic
cost of various features.

Adding use cases for message_post includes
 * posting without followers (aka, no notification)
 * posting with a ping (by email or by inbox)
 * logging a note with optimized method _message_log or with message_post

Adding use cases for activities includes setting an activity as done. This
action posts a message and is therefore interesting to evaluate.

Adding use cases for subscription includes
 * adding and re-adding one follower, with default or specified subtypes
 * updating responsible field triggering a simple tracking and an assignation
   email or notification (not completely supported in saas 11.2 meaning this
   counter will increase when forward-ported)
 * note that some subscription tests have already been added at a01933c9

Finally some heavier tests are added for assignation and tracking based
on QWeb view.

This commit is related to task ID 1824965 . This one is an ongoing task
and several commits may be linked to that task.

This commit is a manual forward- port of saas-11.2's a01933c9 .

Purpose of this commit is to test existing behavior of followers subscription
as well as adding some query count tests about message_subscribe method. As
followers subscription technical implementation may change in a near future
in order to be optimized it is a good idea to have current behavior and query
count validated.

This commit adds

 * test for followers update using message_subscribe API. Tests are added
   with forced and unforced subtypes to ensure behavior will not change or
   will be changed while knowing it;
 * performance test about message_subscribe, about adding new followers,
   and subscribing already-existing followers in force mode or not;

Query count performance test shows that message_subscribe could probably
be improved. It does several things that require queries (check of access
rights, check for existing subscriptions, ensure customers have no access
to internal subtypes, ...). However we feel it could be improved in order
to speed-up the subscription of followers.

This is linked to task 49265; it is only the first steps of it.

In test_mail there are performance tests involving several followers and give
counters for some heavy real-life-like use cases. Purpose of this commit is to
have more basic performance tests for main mail features, like simple post,
simple subscription of one follower. It allows to have an idea of the basic
cost of various features.

Adding use cases for message_post includes
 * posting without followers (aka, no notification)
 * posting with a ping (by email or by inbox)
 * logging a note with optimized method _message_log or with message_post

Adding use cases for activities includes setting an activity as done. This
action posts a message and is therefore interesting to evaluate.

Adding use cases for subscription includes
 * adding and re-adding one follower, with default or specified subtypes
 * updating responsible field triggering a simple tracking and an assignation
   email or notification (not completely supported in saas 11.2 meaning this
   counter will increase when forward-ported)
 * note that some subscription tests have already been added at a01933c9

Finally some heavier tests are added for assignation and tracking based
on QWeb view.

This commit is related to task ID 1824965 . This one is an ongoing task
and several commits may be linked to that task.

The value is made by the computed field.
Setting one has no effect (no inverse method).

If you have no value on a purchase order, you end up in the confusing situation
where you can not save a new PO without setting a value to date_planned but,
after saving, the value is reset (no lines).

Do not block the creation of a new purchase order without lines

Fixes #23275

The ChatManager has been refactored in saas-11.2 to make it fully
(and more easily) testable. This means that tests involving
messaging stuff written in previous versions need to be slightly
adapted when being forwardported to saas-11.2. In particular, the
3 tests adapted in this commit broke because of an include done in
the voip addon. Those tests have been added in 3809fc89.

This patches fixes the untested and broken draft of inetd and systemd
activation support in the threaded server.

This patch also introduces a change of behaviour in the `_reexec()`
function by keeping the environment when Odoo is respawning during the
following events:

    - SIGHUP signal is received
    - one click install has been triggered
    - code reload needed when using `--dev=reload`

Actions loaded from the url are flagged with 'pushState: false', to
prevent them from pushing their state back to the url, thus
producing an infinite loop. However, if the state of a loaded
action changes in the future (e.g. load an action in kanban view,
then switch to a form view), this state should be pushed to update
the url. Before this rev., this wasn't the case.

Changing it is not needed and generated missmatch against existing
entries (created by l10n_generic_coa demo data, thus depending on module
install order).

This could (should?) be considered a refactoring, but this is actually
trying to restore lost functionality.  In v10, the custom form widgets
were created with access to the node element that define them.  We lost
that in v11, with the new views.

However, it is actually very useful for generic widgets.  Since this is
not really a risky fix, I think that it can be done in 11.0.

Note: this feature was already reintroduced in master in commit
https://github.com/odoo/odoo/commit/b7aa439826df6b3e442b3f60bb593ff28efc8679

As of v11, project tasks and project issues have been merged.

Issues used to be ordered by:

        priority desc, create_date desc

whereas Tasks had the following historical ordering:

        priority desc, sequence, date_start, name, id

(where `date_start` corresponds to the creation date of the task, or the
time where task work began)

After the merge, the Task order was kept, but it became difficult to
understand for users, especially for converted issues.

This commit modifies the default order to a more obvious common order:

       priority desc, sequence, id desc

With the following goals in mind:
- the ordering does not change without obvious actions of the user
  (starring a record moves it at the top, manually reordering records
   reorders them within the same "stars category), and creating new
   records adds them at the top, where they are visible
- the ordering is easy to grasp, based on stars and chronological
  order, while still allowing manual reordering when really necessary
  (by default all records will have the default sequence of 10)
- sorting by "id desc" is similar to the previous "create_date desc"
  but it can be sorted more efficiently by the database

One could argue about sorting on chronological or reverse chronological
order. Like blogs and timelines, everyone has their preferences.
The latter option was selected because our UI for quickly adding records
is at the top of the kanban view, so it is more natural to see new
records at the top, instead of having them disappear at the bottom
immediately.

Hopefully this will not disrupt user workflows too much, and will remain
intuitive enough.

The validation transactions introduced in
7d428c87 were not working properly for
Ogone, due to several problems:

- The refund requests when being sent via the orderdirect.asp API, which
  does not support refunding previous transactions, according to the
  Ingenico helpdesk. It only support creating independent refund
  transactions, which is something that requires special pre-approval
  from the payment acquirer, and generally not permitted.
  In order to cancel/refund a previous transaction, the direct
  maintenance API must be used instead[1].

- Maintenance requests to refund a previous transaction fully should use
  the RFS code, as explained in the API documentation [1], and should
  always mention the PAYID of the refunded transaction.

- Such maintenance requests must always be SHA-signed, as usual.

- The various transaction status codes for refunded transactions need to
  be taken into account as well (typically those beginning with 8)

This commit fixes these various problems.

[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/directlink
(5.2 Direct Maintenance)

As of today, Ingenico platform 4.125 has non-uniform handling of the
PARAMPLUS parameters that can be passed as part of transaction metadata.

This parameter is documented as being parsed[1] as a series of
parameter-value pairs, to be passed as extra parameters to the feedback
transaction. Based on this, it seems that the PARAMPLUS value should not
be urlencoded globally, but each field value should be urlencoded, as
the Ingenico side will have to be able to parse and re-emit these
individual parameters.
In one case we were missing this urlencoding step, so this commit fixes
it.

Without this, the querydirect.asp API would return invalid XML data when
we retrieve the status of a transaction that used a PARAMPLUS value with
an '=' sign!

For example with PARAMPLUS passed as

        return_url=/payment/confirm?tx_id=123

the value returned by querydirect.asp would contain the following:
  (note the invalid extra quote character in the `return_url` param)

```
<?xml version="1.0"?>
<ncresponse
(...)
ED="1234"
return_url="/payment/confirm?tx_id="123"
SCORING=""
SCO_CATEGORY="G">
</ncresponse>
```

Url-encoding the value of the return_url in PARAMPLUS fixes this
nonsensical result.

However, the Ingenico API then fails to decode the parameter value when
passing it to the feedback URL, such as the ACCEPTURL we depend on.

As a workaround, since we only pass a single parameter inside
PARAMPLUS, we'll url-unquote it afterwards.

[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/e-commerce#feedbackparameters_variablefeedbackparameters

Before this commit, a client action was simply a subclass of Widget.
This is quite simple, but not really enough for the ActionManager. The
ActionManager needs to handle client actions in a different way that
view actions. Sometimes, it needs to check if a method exists before
calling it.

With this commit, we introduce a new abstraction: the AbstractAction
class, which defines a common API for all actions managed by the web
client.

Note that the API proposed in this commit is just the beginning. We will
introduce other methods in the future, to manage the focus, or the
scroll position, for example.

Before this commit:
When editing a page URL through page properties it would redirect to that new
url afterward. If the url was not starting with '/' and had multiple level
before and after edition (eg: page/action to page/realaction) it would then
redirect to a wrong relative URL.

Now, we ensure that we redirect to the correct URL: the one slugified and
cleaned in the backend.

Step to reproduce:
  - Create a page '/page/action'
  - Go to that page and open Page Properties
  - Edit the URL to 'page/someaction'
  - You will be redirected to the incorrect relative URL /page/page/someaction

When the type of a product is changed by a user of company A, if this
product has been sold previously by company B, the user receives an
access error.

opw:1824548

Configurations uses an onchange to populate the fields visible to the
user. However, the related fields are by default called sudo, when it is
an onchange, there may be a missmatch in the cache, the cache used being
empty, there is no value to return (cache fix is not currently possible).

Before this fix we must use 'related_sudo=False' to use the good cache but
it's an inconsistent fix because in some case we must use sudo to avoid
access error.

opw-1823363

When looking for the move line associated to a quant, make sur to return
the move lines that took from the package or that put something in the
package.

opw-1824578

Oversight of previous forward-port

Before this commit, images in kanban view of the Contact app were not displayed
on non-latin languages, such as Russian.

This was caused by the is_bin_size helper that wrongly assumes that a certain
string is not a binary size, although it is (e.g. 64.2 Кб).

This commit fixes the issue by including such strings as valid binary sizes.

Bug found and fixed by @true-datura
Test by @alexkuhn

closes #23526
closes #22519

When a chatter is displayed and the document is accessed with a valid
access_token, the message related to the document are searched in sudo.

This bypass valid filtering we may down the line.

This change apply the filtering so note type messages are not displayed
for user who are not employees.

note: before 11.0 this logic was in 1b5c2ced. In future version it would
      probably be better to have a method eg. _get_domain_based_on_user
      that would be called before sudo and if not sudo.

opw-1819702
closes #23544

There is a test checking message access rights and search results. It
searches for messages created in the test class having a subject like
Test. However this search may return more results than expected. For
example project create messages containing Test. As we want to keep tests
independent let us rename the test data to ensure everything works as
intended.

There was an issue with the control panel in mobile since rev.
7b6056a0. In the enterprise webclient, by default, the search view
is hidden, and a search icon should be displayed on the top right
corner of the control panel so that the user can toggle the
searchview.

Before this rev., the icon was invisible at the first rendering of
a view, and only appeared once the view was reloaded.

The change in rev. 7b6056a0 that produced the issue is that the
control panel is now updated twice when a view is rendered (once
by the view itself with the buttons, searchview..., and once by
the ActionManager with the breadcrumbs). The control panel didn't
handle correctly that scenario.

A test case will been added in web_enterprise.

Before this rev., the field widget 'mail_activity' kept an internal
cache of fetched activities (like the 'mail_thread' and
'mail_followers'). However, for activities, this cache may cause
issues.

For instance, create a new lead in 'My pipeline', schedule a
'Meeting' activity on that lead (it opens the Calendar view so
that real meetings can be created), create a meeting 2 weeks from
now, go back to the lead form view: the activity still diplays that
the meeting is today (when the view is refreshed, the correct date
is displayed).

This rev. removes the internal cache for this field widget, as the
activities can easily be updated in business flows (unlike messages
or followers).

This rev. also fixes a bug in the BasicModel, where the res_ids of
a list datapoint was altered in place to return a list of x2many
commands instead of the list of ids when being stringified. This
caused a traceback when opening a lead with activities, as soon
as the internal cache had been removed.