Courtesy of translators
Reexport .pot of modified modules

closes odoo/odoo#61002

Related: odoo/enterprise#14485
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The 'stage_id' field is now a stored-editable computed field.

The 'company_id' has been converted to a stored-editable computed field.

The modification of the 'partner_id' field in the onchange method has been
moved and merged into the _compute_partner_id method.

Remove the empty 'onchange' method from the project.task model and also remove
this method call from the sale_timesheet module, which inherits from the project.task model.

Adapt the _compute_partner_id to retrieve exactly the behaviour before the onchange
method deletion.

Update code and tests of the task/subtask partner_id management after discussion with Alexandra to clarify the behavior.

Add the 'multi_edit' attribute to tree views.

- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items

TASK ID : 1251

PURPOSE

Rating model should be available only for internal users. External users
access them only through dedicated routes or controllers using sudo and/or
granting access through tokens. Therefore simplifying ACLs should be feasible.

SPECIFICATIONS

Remove access to rating.rating for public and portal users. Only employees
can access it, with full access given to system admins.

Update various functional flows to use sudo() and check that access is
verified before using sudo.

Impacted modules

  * rating / mail: add groups on some rating related fields as only
    internal users should access them now;
  * rating / mail: set some statistics fields using compute_sudo as their
    value should be accessible for external people even without access to
    the underlying rating.rating records;
  * project: makes some use of rating and has to be updated, notably for
    the public rating page;
  * website_{livechat, rating, slides}: add sudo in public routes as access
    is already granted;
  * website_slides: set statistics field using compute_sudo as their
    value should be accessible for external people;

TASK ID 2053096
PR #36592

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

*: project, crm, maintenance, helpdesk,

It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.

We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)

This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key

Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.

We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.

Task: #1916916

closes odoo/odoo#31945

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

No functionnal changes are done in this commit. Everything
stays the same, but use the parent mixin mecanism.

Task-1903565

When creating a task, the satisfaction of the project is recomputed even
if the task has not rating. This can lead to performance issue:
concurrency error in Postgresql can happen if a task is created when
somebody else tries to update the project.
The satisfaction recomputation will give and concurrency error whereas
it will return the same satisfaction percentage, since the task has no
rating.  The same problem will happens in every modules implementing
the rating feature: project, helpdesk and livechat.

This problem leads us to create the rating.parent.mixin in order to
retrigger the computation only when a new rating appears on the
parent object. We also unstore the field to make its computation lazy.
Maybe in a near future, this field will be computed in SQL directly.
The parent mixin allow us to standardize the behavior to all parent
rating models.
These optimizations should reduce the number of computation and speed
up the task creation.

opw-1902502
Task-1903565

Since e9734f4975904b6196423b7f5de7dd211809d6f6 assignation is now a notification sent in the
inbox or by email to the newly-assigned responsible. It is therefore
considered as not necessary to link a subtype to the assignation itself.
Indeed having it logged in the discussion history as a classic tracking
in addition to the notification is considered as sufficient.

In project module the task opened subtype was linked to task creation and
task assignation. This subtype is now used only for task creation. It also
fixes a strange behavior. Changing assigned user in an ongoing task was
trigerring the task opened subtype which was strange. This is not the case
anymore.

This commit is related to task ID 60790. Closes #23244 .