This commit fixes two issues:
- If a partner has multiple users and if any of these users is a
share user, then the access button on mail notifications is not displayed.
- If a project.task is either assigned or has its stage folded
the access button may not be displayed for certain users.
The users affected by this bug are the one who have their user's
partner is linked to multiple users with at least one flagged as a share user.
'project_time_mode_id' is the field used to determined the UoM to
use when logging timesheets. It is not used in project alone, but
in timesheet. Moving it make sense, and does not cause any problems.
For now, no UI allow the end user to change it: it is set with the
Hours UoM (hardcoded).
This is a technical move to prepare the feature that will allow
people timesheeting in Days or Hours.
Task #39079
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
Purpose of commit is to implement KPIs about opened tasks for project
digest emails. Opened tasks are nor archived nor in a final stage. Those
are added in the default digest template.
A tip is added to remind to use the mail gateway.
This commit is linked to task ID 30655 and PR #18318.
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
With 82ca3d3f in 11.0 it was possible to have an email address on a
task, without specifying a partner.
Because of a small issue, this address was not suggested as a possible
recipients like it was in a project.issue object.
opw-1858170
closes#25427
This allows to better control the posting process, notably using custom
layout to encapsulate emails. Previously to this commit a simple email was
send using a template. Now this template is used to post a message on the
record asking for customer request.
New parameters are added on the request send method
* a subtype, allowing some custom behavior with followers; by default the
behavior is to log a note with the customer being in the recipients list;
* composition_mode can be given and propagated to message_post_with_template
allowing a comment or mass mailing mode;
This commit is related to task 51122 (and PR #24052).
Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
Purpose is to limit the uninstallation of modules without being clearly
notified of it. In project ticking timesheet may have a great impact
depending on modules already installed: sale_timesheet, timesheet_grid,
...
We therefore decided to remove those options from settings to prevent
users from uninstalling it.
This commit is related to task ID 1841221.
The subtask_project_id field was removed by task #38498, amongst many
other changes.
This change makes some workflows much more difficult: for example, using
a different project with its own columns is kind of awkward. It
requires many more clicks and custom filters to achieve the same result
as previously.
With this commit, we simply reintroduce the field and use it to set the
default project_id of a subtask.
Until this revision,
this was possible to set as parent task the current task.
From then, it was impossible to compute the field
`subtask_count` because of an infinite loop.
This resulted to the inability to open the task
form, which contains this field.
opw-1847982
- Activate sub-tasks in projects
- Enter a project's tasks, click on the stat button 'Sub-tasks'
- Reload the page (F5)
A traceback occurs since `project_id` is undefined.
The fields `project_id` and `partner_id` are only defined in the context
of the stat button.
opw-1844334
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.
Christophe Simonis