mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Have a task (A) with two subtasks (B and C)
Archive C
Before this commit, when using timesheets, the task A hours was misconputed and did not take C's timesheet into account
After this commit, hours are accounted for even if their task is archived
OPW 1829658
closes#23920
In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
'remaining_hours' is defined in project as a simple
float field, manually updateable, only displayed
when the group "Time Estimation on Task" is activated.
But for now, there is no setting to active this group.
Those are legacy useless stuff, so we can remove it.
The purpose is to make 'time estimation' feature only
available when timesheet is installed.
Thie commit also split the compute methods of
'remaining_hours' and 'progress' fields to make
'remaining_hours' updateable, though inverse method.
Without splitting the compute method, the calculation
of the progress was done correctly during onchange
but not when saving.
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
Purpose
========
The links on the project kanban cards are not always at the same place : https://drive.google.com/file/d/1aONUYkZerqqD7fSVmgozRScgLKR-QHtA/view
============
Specification
============
I get rid of the flex element to allow the placing of links using width
attribute. Create the .o_project_timesheet_box class to assure that the
timesheet/overview link is always placed in the middle.
I also deleted the needaction_count button to avoid breaking the display.
Task: 1817850
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Since e9734f4975 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 .
Currently crm and project parse incoming email body following an old
syntax to find some "set field - value" lines in the email content. It is
used to update the record linked to the discussion directly from the email.
However this feature is undocumented and not really supported anymore.
Moreover we don't think being able to update records from emails is a
reliable way of working. Moreover those update is limited to
* revenue and probably for leads; this should totally be managed from
the pipeline view by lead / opportunity responsible;
* priority update coming from a "priority" entry in the incoming email;
this code seems strange as priority is probably not standard in email
headers;
* planned hours for project; this should be managed by project user
and managers through dedicated views in Odoo;
Let us remove that old feature and let people use desktop or mobile
interface to update their records.
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.
This commit adds 3 indexes targeting project_task which are not only
useful in regular RW use cases, but help tremendously when deleting
tasks.
In a production scenario, deleting a single task record went from 685ms
to 5ms.
Equivalent queries for an existing database:
CREATE INDEX account_analytic_line_task_id_index ON account_analytic_line(task_id);
CREATE INDEX project_task_parent_id_index ON project_task(parent_id);
CREATE INDEX sale_order_line_task_id_index ON sale_order_line(task_id);
Customer portal has a widget to display a chatter-like communication
history. However only user comments are displayed. It seems interesting
for documents like tasks that also include tickets and support to
display incoming emails. Indeed most customers will use their email
to discuss with the responsible.
Done after feedback from internal migration.
Improves some aspect of timesheet for a better usability:
Rename "Subtask Planned hours" into "Subtasks" AND put "hours planned" next to the hours as units
changes track visibility of Deadline Planned hours so that a message will be generated when those values are changed.
Progress : it was possible to to have a progress higher than 100% when more time have been spend that the planned hours, but it doesn't reely makes sence for a progress bar.
Remaining hours should be editable: it is now possible to edit the remaining hours if needed, the field planned hours is updated in this case to keep informations consistent.
Also remove the default values of description for the subtasks when it was taken from the parent task name in some cases.
Task #58927
PR #23200
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Overrides of _notify_get_groups are used to add some buttons in notification
emails and control the display of "Access document" button. This commit
cleans some overrides :
* accounting: portal users that are not the customer have no access to the
invoice and should not have the access button;
* project: remove unnecessary override on project model and consider portal
users have access to the document through customer portal;
* sale: portal users that are not the customer have no access to the sale
order and should not have the access button;
* website_blog: display access button to everyone only if the post is
published; otherwise keep standard behavior;
* website_forum: display access button to everyone only if the post
has not been closed or deactivated; otherwise keep standard behavior;
* website_slides: display access button to everyone only if the slides
has been published; otherwise keep standard behavior;
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
For objects inherting from rating.mixin, when their parent model change
(e.i.: task from a project to another), the "Parent document name" does
not change. The rating is still considered belonging to the old parent
object (rating stat of project is not correct).
Change the rating API. In rating mixin, instead of having 2 methods
returning parent id and parent model (rating_get_parent_id and
rating_get_parent_model_name), we should have one method returning the
'parent relation field' (inevitably m2o field). Then we can deduce its
parent_res_id/parent_res_model, and check this parent field is in values
of write to trigger the recompute of parent_res_name.
Also, add "ondelete=cascade" on parent_res_model_id
Impacted modules: project, rating, helpdesk, livechat
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
Purpose is to enable override of mail.thread methods in portal mixin.
An example is the _notification_recipients method defined in mail.thread
and customized in portal.mixin.
- Create a project and a task
- Add a channel as follow of the project and task
- Set the channel to follow task stage change only
When changing the stage, the tracking is sometimes received in the
channel, sometimes it is not.
In the case of a stage change, the subtype returned for tracking depends
on the stage sequence. If the sequence is `<= 1`, the subtype for task
creation is returned. Therefore, if the channel is not following task
creation, the tracking message might or might not appear, depending on
the which stage is impacted.
We can remove this specific case, since the creation will be handled
when `user_id` is in the `init_values` or when `mail_create_nolog` is in
the context.
opw-802924
closes#22926
- Connect as a user with only 'User' rights on projects
- Set a project as favorite (click the star)
The project is not set as favorite.
Since only project managers are allowed to write on projects, the field
`is_favorite` is set as read-only. Therefore, it is filtered out by
`_generateChanges`, and nothing happens.
First step is to set the attribute `force_save` in the view, so the RPC
`write` call is forced. Second step is to compute directly the inverse
thus bypassing access rights.
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
opw-814604
opw-801587
closes#22938
Purpose
=======
Projects may have share columns. If we want to delete a stage on a project there's several use case
Specification
=============
Different use cases:
- The stage is shared
- There's no task in this stage for this project: Remove the stage from this project, don't delete it
- There's a task in this stage (Active or not): Raise an error from the ondelete restrict
- The stage is not shared
- There's no task in this stage: Delete the stage (unlink)
- There's a task in this stage (Active or not): Raise an error from the ondelete restrict
Purpose
=======
Avoid having people getting some tasks lost in the "undefined" column. Because they won't understand what it means an how they achieve it.
Specification
=============
Add an "ondelete='restrict'" on the stage field definition.
[IMP] project: "Task Title">Title (could be named differently)
[FIX] project: don't assign a person on a task during the tour
Someone is already assigned as tasks are created from the kanban,
directly, with a responsible by default.
Before this commit, we create a new dynamic action when creating a new
project. This is a problem for various reasons:
- we did not have the nocontent helper properly set (so, the kanban view
could not display the help message just after creating a project
- the dynamic action is slightly different from the one you get when you
click on an existing project (different views, ...)
- the dynamic action is not editable in studio
With this commit, we simply reuse the same action, but with a different
context. This solves all these issues at once, without duplicating
logic.
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
Thibault Delavallée