Sale Order --> Sales Order
Sale Report --> Sales Report
Sale Team -> Sales Team
Payment Term --> Payment Terms

fp request

Signed at #13920

Purpose:
--------

Rename and remove some sections to make planner easier to go through

This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.

New models are

 * mail.activity.type: used to categorize activities. Each type is a different
   kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
   available for all models using activities; or specific to a model in which
   case res_model_id field should be used.
 * mail.activity: an actual activity to perform. Activities are linked to
   documents using res_id and res_model_id fields. Activities have a deadline
   that can be used in kanban view to display a status. Once done activities
   are unlinked and a message is posted. This message has a new activity_type_id
   field that indicates the activity linked to the message.

This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.

Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.

There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.

Next commits will aim at integrating activities inside main Odoo addons.

Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.

survey.survey model now supports activities. Filters have been added to ease
their management.

stock.picking model now supports activities. Filters have been added to ease
their management.

sale.order and purchase.order models now support activities. Filters have been
added to ease their management.

project.task and project.issue models now support activities. Filters have been
added to ease their management.

note.note model now supports activities. Filters have been added to ease
their management.

mrp.production and mrp.repair models now supports activities. Filters have been
added to ease their management.

maintenance.equipment and maintenance.request models now supports activities.
Filters have been added to ease their management.

hr.applicant model now supports activities. Filters have been added to ease
their management.

crm.lead model now supports activities. Filters have been added to ease
their management. Mail activities replace the old crm.activity model. All code
related to crm.activity is then removed, including views and custom widget.
Standard activities feature is now used widely in Odoo addons and replace
those custom activities.

A small update is required in website_crm_partner_assign. Now the portal user
can only update or create its own activities aka assigned to him. If he has
an activity assigned to him it is displayed in the opportunity website view.
If not editing the opportunity will create a new activity assigned to him.

account.invoice model now supports activities. Filters have been added to ease
their management.

This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.

New models are

 * mail.activity.type: used to categorize activities. Each type is a different
   kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
   available for all models using activities; or specific to a model in which
   case res_model_id field should be used.
 * mail.activity: an actual activity to perform. Activities are linked to
   documents using res_id and res_model_id fields. Activities have a deadline
   that can be used in kanban view to display a status. Once done activities
   are unlinked and a message is posted. This message has a new activity_type_id
   field that indicates the activity linked to the message.

This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.

Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.

There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.

Next commits will aim at integrating activities inside main Odoo addons.

Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.

Otherwise ze bouboule is not aligned with other elements being in the same
line of the vignette.

This is a manual forward-port of commit 03ac47b9

Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.

Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.

Compared to original commit tests are slightly updated because there are now
default internal subtypes in data. Not in 10.0 and previous versions.

[IMP] sale_timesheet: add ability to assign a task to a SO line for invoicing (debug mode); better ux

The base amount was miscalculated. Now we use numbers that are already computed by the pos.order.line model

[IMP] account: define the m2m relation between bank statement lines and account.move.line instead of account.move

This is needed in order to support use cases where we have several account.move.line on an account_id of internal_type 'bank' inside a single account.move. Indeed, each journal item should be linked to a bank statement line in order to disappear from the bank reconciliation widget and, previously, setting the reference to the second bank statement line was removing the first as both info had to be filled in a single m2o. OPW: 696842

Closes #14358

"HR" is consistently used in Odoo, instead of "Hr".

Frenchiglisation of labels

Before this commit, the list of channel members is fetched once, and never reloaded.
So, when a new member is invited, he cannot be mentionned by the autocompletion.
With this commit, we remove the 'members_deferred' from the channel,
which will cause the member list to be refetched next time it is needed.

It is used in mrp_account, but the module doesn't depend on account_batch_deposit

The model does not actually need this feature, as the hierarchies of packages
are not expected to be deep.  Performance wise, updating columns `parent_left`
and `parent_right` may actually suffer from concurrent updates that require
retrying requests.

Rewrote help tooltip to improve English and clarity.

Closes #14696

This reverts commit d5c24abe which is
broken since e945b86d but hasn't been
noticed due to non-validation of views (fixed by fe02b79a).