Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
The group_by was passed from context from the action spawning a new view.
This meant that it could give a group_by a field that was not defined on the
destination view, causing a js traceback.
opw 1884035
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.
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.
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.
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
'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;
Christophe Simonis