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
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
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
- 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
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.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Add contraint to limit the level of subtask to
only one. A task can either be 'mother' or 'child'
but not both ! For now, the UI only prevent this,
but xml rpc script can do whatever it wants.
Also move the recursive check from hr_timesheet
to project, since subtask mecanism is now native
from project module.
This commit aims to improve duration field calculation
with subtask. So this commit :
- provides `subtask_planned_hours`as the total of planned our from
children tasks
- removes useless/unclear fields : delay_hours and total_hours
- makes progress computation independent from the stage (before,
progress
of task in fold stage was 100%)
- split the `hour_get` compute method into smaller ones in order to
improve
performances and code readability.
- makes 'progress' and subtask effective hours not including allocated
hours
Task: 38498
This commit improves subtask mecanism, on several points:
1) Drop the project constraint: before this commit, creating
subtask in non parent project was not possible. Now you can move
subtask to any project.
The default project of a subtask is the one from the parent.
2) When setting a parent task, we want to force some field to have
the same value as its parent, like `partner_id` or the `sale_line_id`.
The idea is here, we work for the same client; a subtask count for the
same goal (SO line or customer). Those fields should be readonly on the
view.
3) Refactor some methods
Task: 38498
Purpose
* move notify in message_post instead of always doing it at message
creation
Specifications
* message create should only create a message
* message post should be in charge of calling the notification process
Displaying the rating of project is moved directly
in project module, since it does not depends on website.
User may want to display rating of its support project
even without website.
Since rating in on project directly, and task
and issue are merged, we can simplify some domain
and replaced them by default filters.
The search domain will be less complex and the
performance will be better.
Impacted modules: project, rating_project,
sale_service_rating and website_rating_project.
Removed modules: rating_project and sale_service_rating.
Move code to empty 'rating_project' module, in order
to kill it.
Code is not modified, simply copy/paste at the right
place in 'project' module code.
However, 'enable rating on task' options is convert
into a res.groups that can be activated from the
project settings.
When adding a partner (without any backend or portal access) as a
follower of an invoice, project, task or SO, the mail received contains
a 'View ...' button. When clicked, it redirects to the login page.
In the case of projects and tasks, no `auth_token` exist, so the user
faces an access error in the backend. For the other objects, it
redirects normally to a frontend page.
This feature is not yet complete in v11. So simply hide the button until
this is properly developed in master.
opw-785824
Géry Debongnie