Purpose of this commit is to allow mass mailing users to select an outgoing
mail sever when performing mass mailing. It includes

* add a field in mass_mailing to select specific outgoing mail server;
  it is put in debug mode because it sounds people would not understand
  what is its purpose;
* add an option in settings to set a default outgoing mail server;
* give read access to ir.mail_server to mass_mailing users;

This commit is related to task ID 31737.

Purpose of this commit is to standardize portal user creation when
creating new portal users (when 'Free sign up (B2C)' option activated). It
copies the portal user template. The same behavior now applies when
converting a partner into portal user using the portal wizard.

This commit is related to task ID 31399 .

Purpose of this commit is to standardize portal user behavior and creation.
As all portal required features (user, group, support) have moved to
base let us move the template user used to create portal users to base.

'Portal User Template' is therefore moved from auth_signup to base module.
Various config parameters are updated due to the change in xml id.

This commit is related to task ID 31399 .

Purpose of this commit is to finally stop adding extra padding to
website logo. Indeed not giving square logos lead to padding added
to images, leading to not so beautiful logo that makes people sad.

Before this commit
 * partner's image was resized to square 1024x1024. Extra padding was added
   if user provided rectangle image;
 * due to this website logo resized to square when rectangle logo provided;

After this commit,
 * sizes dict can be passed in image resizer of tools;
 * e.g. tools.image_resize_images(vals, sizes={'image': (512, 512),
   'image_small': (128, 128)})
 * image field in partner will resize with max width 1024 and height based
   on given image ratio (still image_medium, image_small will be default
   square images);
 * now website logo will respect actual aspect ratio

This commit is related to task ID 31994 . Future commits should probably
clean all that mess, but at least it seems we have something that works.

Before this commit there was no option to avoid resizing images when it
was smaller than expected size. This leads to several image being displayed
with extra and unnecessary padding due to resize. This option will allow
to avoid that behavior by allowing to propagate the parameter directly
to image_resize_image.

This commit is related to task ID 31994 .

test_mail only counters have not all been updated. Those may be different from runbot as
some tests depend on installed modules. Let us update it.

Closes #23663

*crm,project: css selector adapted in tours

This rev. improves the UX of the 'Invite users' and 'Pending
invitations' part of the Settings dashboard.

Task 32804
Closes #19531

Co-authored-by: Aaron Bohy <aab@odoo.com>

Closes #18443
Closes #23656

Co-authored-by: Yenthe V.G <yenthevg@gmail.com>

Done at #18443

To keep the same saleman and improve consistency

Closes #21496

Purpose of this merge is to remove
 * dead code related to mail features, like unnecessary overrides;
 * unnecessary subscription or message post that adds no value to the app
   while creating noise;
 * some deprecated code bits in mail;

Please see subcommits for more details. This merge is related to task
ID 61132. Closes #23624 .

Currently mail/view controller supports either a message_id, either a
model/res_id . Using a message_id is just a shortcut to find its model and
res_id before redirecting to the record view. If the message has been
removed the controller does not work anymore although with model and
res_id it still works while the record exists.

Same functional behavior can be achieved with only model and res_id. Let
us drop support of message_id to lessen code size.

Currently a message 'XX joined the Company network' is logged on the
user's partner profile when creating an user. This message is not sent
to anyone as it is a note. Moreover it does not add any value to the
discussion thread on partner profile.

Let us remove that code as it has no use.

Purpose of this commit is to clean a bit various classes and conditions.

First clean is the removal of o_mail_note class in activities less. It comes
from first implementation of activity widget and is not used anymore in
activity widgets rendering.

Second clean is the removal of o_mail_note class when displaying messages.
Only o_mail_discussion is used currently in chatter to make a different
background depending on whether the message is a discussion or not. All
we have to know to differentiate message display is whether it is a
discussion done by an user or not.

Tests have been updated to use o_mail_discussion class triggered by
the message being a discussion, aka a comment posted by an user.

Currently a note is posted on the fleet with 'name has been added to
the fleet'. It is not really interesting as it is no notified to
anyone and it makes some noise. Let us therefore fall back on the
standard behavior.

Mail holds some controllers used notably in notification emails to allow
some action directly from email buttons. It is used for example to redirect
people to the right view when clicking on 'view document' button.

Some deprecated controllers still exist in codebase but are not used
anymore. The 'new' controller notably has been removed at df01742f .
The '(un)follow' controllers have been removed recently at 11d2d30e .
Let us remove that dead code.

HR employee model automatically adds the employee's user as follower of
its own employee profile. It has been done at 8ab3e5d2 probably
when working on gamification and twitter-like employee profile. In that
use case adding the employee's user as follower was required to be able
to discuss on the employee form view. It is also a requirement to be sure
he receives news about received badges.

Since then however employee profile has been set as private and internal.
It is used only for HR purpose which is coherent with the model and the
business flow of various HR modules. Moreover it has never been really used
as intended in gamification or as a twitter-like profile. It seems therefore
not necessary to automatically add followers to this record.

If required, any message_post can add the employee's user in the recipients
if its attention is required on some message. It required only to set the
target users's partner in the partner_ids parameter of message_post that
is propagated to the message creation and notification.

An override of notification process can also be removed. It seems people
wanted to add the user to its profile but without notifying him. Let
us remove all that crap.

Finally the CTA button to (un)follow employees directly from the kanban
view is also removed for the same reasons as state hereunder.

An override related to mail.thread auto subscription has been added in
maintenance application at 23a2bac3 in 9.0. Since that version
however the field has been renamed to avoid confusion with user_id that is
generally a responsible with access rights to handle the document.

This code is therefore not necessary anymore and can be safely removed
without impacting any functional flow.

The widget statusbar was using an attribute `clickable` on the field widget
to define if the statusbar was clickable.

This attribute is in fact not a field attribute but a widget option so it
has been moved accordingly.

Note that a retro-compatibility adapation is done in the field widget.

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).