Current behaviour:
If you disable the recurrence for 1 task in a suite of recurrence,
if you had other tasks belonging to the same recurrence suite, they
would still be with recurrence activated.
Expected behaviour:
It doesn't make sense for some of the tasks in a suite of tasks in a
recurrence to enabled and others disabled. If we disable the
recurrence on 1 such tasks, all tasks should linked to that
recurrence should be set as non-recurrent, regardless if the
edit-mode is set on "This task".
Steps to reproduce:
- For 14.0 -> saas-16.1:
- Install Project, Studio
- Turn on in Settings the "Recurrent Tasks"
- Create a new project and a task in it
- With studio, in debug mode, add a related field to the task form
that relates to `next_recurrence_date`. Make sure it's not "read
only"
- On the task, turn on the recurrence, set the frequency to each
day, set the `next_recurrence_date` as a day in the past
- Run the Scheduled Action "Project : Create Recurring Tasks"
- On one of the task, disable the recurrence
- Go to the other task, see that their recurrence is still active,
and the frequency changed to the defaults values of once a week.
- For saas-16.2 -> master:
- Install Project
- Turn on in Settings the "Recurrent Tasks"
- Create a new project and a task in it
- Activate the recurrence on the task, set a planned date in the past
- Set the task as "Done", this should create an new instance of the
recurrence.
- Disable the recurrence option in one of the task, observe that
is doesn't change for the other task, and the recurrence
frequency is reset to default values.
Reason for the problem:
When disabling the recurrence on 1 task, with the edit-mode set as
"This task", the recurrence is being deleted, but we don't disable
the recurrence of the other tasks linked to that recurrence.
Fix:
When we are writing `False` on `recurring_task` on a task, we
explicitely write `False` on `recurring_task` on all tasks that belong
to the recurrence after the deletion of the recurrence itself.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3265212
closesodoo/odoo#128703
X-original-commit: 0a83f4030b07aba25b054aa453d81c0e27b98cc8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Adds missing index on `project.task` `state`, this field is used in
a lot of searches as a search criteria like "open tasks".
task-3416393
closesodoo/odoo#127841
X-original-commit: 147446d86d7d33a83f83a8699c930fcdd3dbb99b
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
------
When we want to add a newly-created user
who does not yet have "personal stages" to an fsm task,
it triggers a User Error.
Cause:
------
There's a mistake in the `project_id` field,
which is missing the 's'.
Therefore, when creating the personal stage,
the ORM does not find the value in the context
and inserts the command to set the default project.
As a result, when checking constraints,
we will trigger an error for the
`_check_personal_stage_not_linked_to_projects` method.
opw-3390169
closesodoo/odoo#127694
X-original-commit: 05722c9710f74a073833235de9bbe4743485174a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
If a project had a single rating associated to its tasks, opening the
customer rating view would create a traceback. This happened because
both the mail.thread model and the rating.parent.mixin model have a
rating_ids field, and project inherits from both of them (mail.thread
on its own doesn't have it, but the rating mixin adds it).
In the action_view_all_rating method, we try to access the first element of the
rating_ids recordset, if the rating_count field is equal to 1. But since
the rating_ids field belonged to the mail.thread mixin, and not to
the rating.parent.mixin, there could be occurences where rating_count was equal
to 1 while the recordset was actually empty ; accessing the first element of the
recordset would then create a traceback.
To fix this, the rating.parent.mixin model was put before the
mail.thread model in the _inherit list, this way the rating_ids field
from rating.parent.mixin has the priority. A test was also added to check
if the rating_ids is working correctly.
task-3360029
closesodoo/odoo#127243
X-original-commit: 1039c80a8ff5e219e9c2679505015288c8d8dd35
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps
=====
- Install module industry_fsm
- Create a task from the kanban view
- In the form view, add a title but no customer
- Open the subtasks tab of the notebook
- Add a subtask and add a title to it
- Save the created parent task
- A pop-up indicate that the customer is missing
- Add a customer and save the task
Issue
=====
A pop-up indicate that the subtasks field is invalid and there is no way
to save the current task with its subtask.
Cause
=====
the module industry_fsm introduces a required=True for the field
"partner_id" when edited from a view in the app Field Service. When a
parent task is created without a "partner_id" id set, it can not be
saved, but subtasks can still be created from it. Those child tasks
should have the "partner_id" set to the same value as the one of their
parent. As it is not set in the parent task, its value will be False for
the child task, and changing it in the parent task (by adding a
customer) will not update the child task. As this field is required when
a task is edited from the app Field Service, the task can not be saved.
Fix
===
A dependency to "parent_id.partner_id" is added to the method
"_compute_partner_id" of model project.task allowing to updating it if
needed when a "partner_id" is set on the parent task.
task-3343423
closesodoo/odoo#127088
X-original-commit: 7f8da6a4148c86b61d994bf692725378f8dafc52
Related: odoo/enterprise#43515
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit In the task's form view, the parent field shows the other
task but also shows the current task.
In this commit, the domain is applied, ensuring that the id is not the same
as the current id. As a result, the parent field of the task does not
include itself
task-3330841
closesodoo/odoo#122286
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the user installs `sale_project` and some
of his projects has no partner set but a partner is set on some
tasks of those projects then the user will no longer see the partner
field in those tasks because the project is not billable.
This commit checks if one of the tasks has a partner set to make the
project linked billable if it is not yet the case.
closesodoo/odoo#126880
X-original-commit: b0cb255577a7a0c49c2c764dbad715d3842b9508
Related: odoo/enterprise#43384
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: account, event_booth, gamification, hr, project,
website_event_track, website_hr_recruitment, website_slides
HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.
This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.
opw-3267589
closesodoo/odoo#126708
X-original-commit: 7fd28afaf3e45cafbef80b69aa45c58b31fb3de6
Related: odoo/enterprise#43311
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When a user creates the task without a name field and directly clicks on the
'Mark as Done' button, will give UnboundLocalError like the local variable
'task' referenced before assignment.
Steps to produce:
- Install the 'Field Service' module.
- Field Service > My Tasks > Open any task.
- Make the name field unrequired (Studio or Edit form View)
- Create a new task > Set the Customer field and leave the Name field as blank.
- Before saving the task click on the 'Mark as Done' button > Discard Changes.
- Error will be produced.
Fixing the indentation for `task.date_last_stage_update = now` will solve this
issue. We have used the task variable in for loop.
Sentry-4276832131
closesodoo/odoo#126752
X-original-commit: c3649a32c98d7093610a4367b1e72c1b4b0085b7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Issue:
In the portal view of the project AGR project has 11 Tasks on the list view
but when you click on it, inside there are 12 tasks, not 11
Cause:
The Kanban view of the project includes a button for task
count, which displays the total number of open tasks in the project.
It seems that the task count button displays the correct count because the form
view of the task includes a default filter for 'Open Tasks'.
The form view of the project-sharing feature does not have the default filter of
'Open Tasks'. As a result, the count displayed by the task count button in the
kanban view is different from the count displayed in the list and Kanban views.
Fix:
In this commit, a default filter is passed through the context to ensure that
the task count displayed by the task count button is the same as that displayed
in the list and Kanban views.
task-3289941
X-original-commit: 96304e9b237c06a5d0b459d304df3afbf7607f04
Part-of: odoo/odoo#126446
Steps to reproduce:
-------------------
- create a stage without selecting a project.
Issue:
------
The new stage is inaccessible.
Cause:
------
When the project is not defined, the following ORM command is used:
`[6, False, []]` for the `project_ids` field.
Solution:
---------
When we create a project stage (project task type),
it is essential that we link it to a project.
Add the possibility to override `_get_default_project_ids`.
Set default project as first fsm project if not project in
the context.
opw-3322992
closesodoo/odoo#126338
X-original-commit: 69c09684e37accdaf1248f31a7c97f0c20434b76
Related: odoo/enterprise#43134
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
This commit increases the priority of the sequence in the ordering of tasks
so that reordering by drag & dropping is more useful.
Task-3371921
closesodoo/odoo#125073
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when selecting tags for a task with no project (private
task) on mobile, a warning is displayed. On top of that, the amount
available tags is way more limited than in classical view and the
selection of some exesting tags is impossible.
Steps
=====
1. Warning when selecting tags
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
A warning is displayed (on the server logs) stating:
"The domain term '('project_ids', 'in', False)' should use the '=' or
'!=' operator."
2. Limited tag choice
- Install module project
- In mobile view, go to the view "Tasks -> My Tasks"
- Open or create a private task (task with no project)
- Click on the tags field
- The tags that are only related to project(s) are not displayed in this
view
- Try to create a tag with the same name than an existing tag that does
not appear.
- A traceback is displayed because this tag already exists.
Cause
=====
As noted from the test of expression.py, M2M fields in the domain should
be compared to list of elements. It is not the case here. When a
project_id exits in the context, nothing happens, but there exists a
check in the ORM to ensure that '=' or '!=' operator is used if the
second element of the domain leaf is a boolean. In this case, there is
not project_id set in the context for private task, resulting in
the previous warning (False used instead of project_id).
Fix
===
We use the improved implementation of _name_search to get the ordered
list of id of records project.tags to display. This list has the
advantage to not be restricted to the current project, while still
presenting the tags of the current project at the top of the list. The
mobile view uses the method search_read to get the list of project.tags
record values, therefore we call the _name_search in this method and use
an optimized sorting function to sort the resulting records accordingly.
task-3302370
closesodoo/odoo#126091
X-original-commit: a03a93aa8cf5567f79dd66ced5911721b82a3802
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- steps to reproduce bug:
In project.task sharing form view, When clicking on any of the stat buttons (subtasks or parent task)
when you arrive on the actual task formview a MissingError saying 'missing record' appears
- Issue:
The record loads accordingly but the Missing Error shouldn't appear
- Cause:
It is coming from the project_sharing_form_compiler which gave the projectSharingId props to the ChatterContainer element
but the projectSharingId is equal to the "props.record.context.active_id" of the action, and in the context of the
chatter we want the active_id to be equal to the project_id, which was the case when we are coming from the KanbanView and
sub-list views but when coming from the task stat button the active_id is equal to the task_id and the env can't find
the document 'project.project' with the id of the task. (in portal.py _document_check_access())
- Fix:
We simply change the projectSharingId to take the "props.record.contect.active_id_chatter" the give an
active_id_chatter= active_id in the Project Sharing task_action which will always equal the Id of the project
Task-3284755
closesodoo/odoo#126092
X-original-commit: 22c0825b70bbe8234dee57060bdd5640001f74d7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
In 16.2, we have implemented a nice tool to set various fields at the creation of a task from
the Kanban quick create using shortcuts.
This implementation is simple (only a few lines of code), but is not very flexible.
Indeed, shortcuts need to be in a specific order and at a specific place for them to work.
As a consequence, it is very easy for the user to fail in the creation of their tasks using shortcuts.
This task aims at making this feature more robust and complex so that it works in more cases.
In this commit:
It should be possible for the #tag, 23h, @demo, ! shortcuts to be put in whatever order, as long as they are at the end of the name
task-3349154
closesodoo/odoo#124155
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit we change following points:
- changed string of analytic_plan_id field in res setting.
- project set as default in the analytic plan of the project setting
task-3251642
closesodoo/odoo#120522
Related: odoo/enterprise#40702
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When the hr_timesheet module is not installed and a customer uses the
action_project_timesheets action through customization, a traceback will
occur because he will not get the action of hr_timesheet.
closesodoo/odoo#125600
X-original-commit: cdeeb70ada8364c681c93961c2bd29f1069cebbf
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Prior this commit:
In project when tasks was moved to different stages users will get notify with
emails where there is a field showing assigned_date and deadline.
After this commit:
Instead of those fields it's showing only Stage: Stage name
Task-3285822
closesodoo/odoo#119973
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit removes the tooltip of the `fold` field because
the second part is no longer true and the first part does not
provide any added value.
It also makes `project_ids` field required in the form view of
Task Stage model (`project.task.type`) to force the user to link
his new stage to a project. Otherwise, the stage won't ever be
visible anywhere in the interface. Indeed, stages not holding
tasks are hidden in cross-projects views.
task-3251621
closesodoo/odoo#121154
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The following changes are made in this PR:
- sort projects by favorite > sequence > name for project
- add the 'tasks' stat button for project form view
- when creating a project on the fly from a task's form view, allow_billable
should be set to true by default
- Display only the colored dot, hide the status label for project list view
- remove following fields from project
allow_recurring_tasks
task-3251656
closesodoo/odoo#119154
Related: odoo/upgrade#4569
Related: odoo/enterprise#40050
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- Removal of 'my team's ratings' and the 'my department's ratings'
filters in order to be more consistent with the project.task search view
- UI improvements in the project form ratting settings
TaskId-3251609
closesodoo/odoo#120633
Related: odoo/upgrade#4632
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
New features developed in this PR:
- Write Javascript tests for the project.task.state widget
- Tests are in the project_task_state_selection.js
- rewrite Research & Development demo data
- Created a digest tip for task state selection (in Settings > technical > digest tips)
- Tip: Use task state to keep track of the task progression
- Fix Sharingview (Readonly) icons for the project.task.state widget, previously only the color bubble were displayed in readonly sharing views, now all of the icons are displayed
- Display state in the Calendar view
- Display the same widget as in the kanban/list views
- Remove is_closed References
- Adapt Kanban stages Exemples
- Kanban exemples are available when creating a new stage in kanban view
- improve Progressbar colors (different color for approved/done, in_progress/waiting)
Task-3213526
closesodoo/odoo#117968
Related: odoo/enterprise#39714
Related: odoo/upgrade#4548
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
X2many fields tracking was not supported in the implementation of
`mail` module:
* not needed in the past
* the logic was not hooked in the same place before. Now that it is
managed pre-commit, x2many values don't have to be handled as commands,
but can be compared as records.
* ...
The support was added for two specific models in specific modules, but
it's a good opportunity to clean that and to support it directly in `mail`.
Task-3316528
Part-of: odoo/odoo#121244
This commit reverts a previous commit which allowed to
display the current stage when the state is changed.
The reverted PR: https://github.com/odoo/odoo/pull/119925
The reversion was done as what was implemented does not
follow the standard display of tracking messages and
because it doesn't look good in the chatter.
Task-3336184
closesodoo/odoo#123797
X-original-commit: eff511140175ba8224c2f9be59a798a3e1dee6da
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Previous commit (https://github.com/odoo/odoo/pull/116570) renamed
this method _get_subtasks_recursively.
But instead of calling itself in the return statment, the
method _get_all_subtasks was called resulting in a non-recursive
function and to potential undesired behavior as _get_all_subtasks calls
_get_subtask_ids_per_task_id that calls _get_subtasks_recursively in
some cases.
With this commit, we just call _get_subtasks_recursively on the children
to make it actually recursive, like it was in the first place.
closesodoo/odoo#123149
X-original-commit: 3a6f5e4d8eddaa4effbf96d8b59d47afc0ee9503
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
- Impacted modules:
- project_todo (new module)
- note (deleted module)
- project
- mail (test adaptation)
- test_discuss_full (test adaptation)
- Changes summary: The application Notes is removed and replaced by a
new app To-do. This new app is based on the model project.task and other
related models, allowing to have a nice link with project. To-dos are
actually private task that are displayed in both Project and To-do
app. The reason why To-do could be used is that it introduces clean
views and simplified widgets to work on these tasks/to-dos.
- Commits description:
- ***[ADD] todo, note,...: replace Notes with To-do***: Deprecation
of Notes and create of To-do (module project_todo). The model
project.task is slightly modified to be able to be used in the
module project_todo (mainly security and personal stages management
methods). Views and activities are adapted to the new model.
- ***[IMP] todo: make the name of a to-do editable from the
breadcrumbs***: The name of a To-do is made editable directly in the
breadcrumbs.
- ***[IMP] todo: add conversion form for todo->task***: A new action
is introduced in To-do to be able to convert a to-do to a task in a
project.
- ***[IMP] todo,...: add an onboarding to-do***: An onboarding to-do
is added to describe the functionalities of the new app to the
users.
- ***[IMP] project: avoid to add OdooBot as default assignee on
tasks***: Improvement of the UX for both Project and To-do.
- ***[IMP] todo: integrate mark as done in To-do app***: This commit
introduces a new widget in To-do that can be used to set a to-do as
done. This widget used the new states recently introduced in Project
but present them in a simplified binary value in To-do.
- ***[MOV] project_todo: rename module todo to project_todo***:
Technical renaming to avoid confusion.
- ***[REM] note,...: remove module note***: Removing of module note.
task-3085077
closesodoo/odoo#115390
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit task action from kanban click and from
stat button does not have same behavior like kanban click
does show archive task for archive project and does not
display New button while other on does not.
This commit make both action consistance to have same
behavior in both actions.
task-3224627
closesodoo/odoo#121473
X-original-commit: c95278e78325aa3831f6bfb02a7f3e377d0a8028
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
During the creation of a private task (model project.task with not
project_id set), the current user is added as assignee. For all the demo
data, OdooBot is therefore added as a default assignee. This commit
avoid this situation by performing a check on user id at creation of a
private task.
task-3085077
- Impacted modules:
- todo (new module)
- note (deprecated app)
- project
- test_discuss_full (adding a dependency)
- Main changes:
- The Notes app is deprecated
- A To-do app is created to replace it
- The To-do app uses the model project.task (from module project)
for to-dos. To-dos are equivalent to private tasks (tasks without
project) with no parent task set.
- Private tasks/to-dos can either be displayed in the My Tasks menu
of the Project app or in the To-do app that proposes simplified
views to edit them.
- Details:
- depracation of Notes: Before the module note can be fully removed,
some changes still need to be done in other modules that use its
models (mainly note.note model). This commit deprecate the Notes
app in the meantime by removing it from the main menu/dashboard
and by replacing the creation of notes directly from the systray
by the creation of private tasks (to-dos).
- activity: In the systray, it is currently not possible to
segregate records using the same model. Therefore to-dos will
appear in the task section. This will change in the future when
this possibility will be implemented in mail.
- name generation: When edited from To-do, a name is auto-genrated
for private tasks. This behavior is similar to the one existing in
notes with a few adaptation to Todo UX. When a to-do is untitled
and saved (through the save button or when leaving the form view),
a name is generated based on the first line of the description of
this to-do. If the generated name is longer than 100 characters it
is truncated.
- security:
- project.task model need to be accessible in all crud modes to
all internal users as it is used in the to-do module. This is
a big change compared to the previous behavior where only
project users could edit tasks.
- project.tags model access is way more permisive now. All users
have access to edition/delition of tags as they are use in the
to-do app.
- Record rules: A similar behavior as the current one is
implemented, i.e:
- project users can access all tasks (with edition rights)
verifying one of the following conditions:
- they follow the task
- they follow the project the task belongs to
- they are assigned to the task
- the project the task belongs to is accessible for all
internal users.
- internal users have only read-access to the non-private
tasks shared with them.
- Those changes related to security only occurs when the app
To-do is installed. When it is note, the current behavior of
Project security-wise is kept unchanged.
Note on this last point: As the write access of internal users to
project.task is now managed with record rules, the form of this model
won't be displayed in read-only anymore when To-do is installed. This
will results in access error message for the tasks for which the write
access is restricted. Unfortunatelly, there is no better solution at the
moment as neither restricted read access, nor extendent write access for
internal users are desired. An improvement of the framework to deal with
such situation could be benificial.
task-3085077
Description of the issue/feature this PR addresses:
Before this commit assign_me button and clock icon from start button is shown in
project task , project sharing as well as helpdesk ticket.
This commit remove assign_me buttom and clock icon from start button in project
task, project sharing and helpdesk ticket.
task-3292056
closesodoo/odoo#120378
Related: odoo/enterprise#40630
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the user changes the state, the followers
receive a notification about this change. Since the label of the
state is no longer customize by stage, the followers cannot know
in which stage the task is before clicking on the link to go to
the task form view. And so, if one of those followers has to
check the task in a specific, he has to click on the link in
the notification to know in which stage the task is.
This commit fixes the issue by adding the curent stage in the
notification to inform the user who received the notification
in which stage the task is when the state has been changed.
task-3284597
closesodoo/odoo#120959
X-original-commit: d78c79d9a9f8ac108251c57c732cfb5b71b53fd5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The refactor of the kanban quick create implemented in
https://github.com/odoo/odoo/pull/117449 introduced a traceback when
creating a task from the My Tasks kanban view due to the presence of
'default_personal_stage_type_ids' key in the context.
This commit fix that by removing this key from the context in the
customization of the kanban view for project.task model. It also add a
js tour test to ensure that personal tasks can be created from the quick
create form in the My Tasks kanban view.
Steps
=====
- Install module project
- Go to the view "Tasks -> My Tasks"
- In the main Kanban View click on "New"
- Enter a Task title and clicl on "ADD"
Issue
=====
A traceback appears indicating that the value of the field user_id is
missing for the model project.task.stage.personal and the task is not
created.
Cause
=====
In kanban and list views, when the records a grouped by a given field, a
key is added in the context when creating a record from one of the
resulting categories. This key is of the form:
`default_fieldGroupedBy: current_category_value`
In the case of the view My Tasks, the records are grouped by their
fields personal_stage_type_ids (M2M). Therefore, the key
default_personal_stage_type_ids will results in a write in that M2M
table when creating the record. But the way personal stages are managed
in project is as confusing as it is mindblowing and the M2M table
storing the relation between task and personal stages is also the table
that store records from the model project.task.stage.personal. And this
model also as a field user_id that is required. Therefore
at creation of the project.task record with that key, the orm will miss
a user_id for the newly created project.task.stage.personal.
Fix
===
The correct way to add/modify a record project.task by setting its
personal stage is actually to use the already existing methods of
project.task, i.e. _inverse_personal_stage_type_id. Therfore, instead of
modifying directly the M2M relation, update the computed M2O field and
let the inverse method to the job of personal stage assignment.
To do that, the value contained in the context for the M2M relation is
copied in the write value of the M2O (personal_stage_type_id) and the
key in the context corresponding to the M2M relation is deleted.
task-3281005
closesodoo/odoo#119055
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
On a brand new task with no assignees, when we add an user to follow
the task with an email, there is a link "I take it" that is supposed
to assign the newly following user as the assignee of the task. This
link is dead, returning a 404.
Expected behaviour:
Either correct the link, or remove it from the email header.
Steps to reproduce:
- Install Project
- Create a task, with no assignees
- Add a new follower to the task with Send Email checked.
- Check the outgoing email, and click on the link "I take it".
- 404 response
Reason for the problem:
The route which we were using for this `/mail/assign` doesn't exist
anymore since version 15. This was an intended design change, to
remove noice. The user can click on "See task" and assign himself on
there.
Fix:
Remove the "I take it" link from the email header.
Affected versions:
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3276036
closesodoo/odoo#119920
X-original-commit: 2d3134381c23675199bd8e14fafb1804d54339e6
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit:
1- project sharing task form: Internal users can't see and edit all fields.
They need to go back to backend interface. Some users don't even know the
difference between project sharing and backend, and the others need to navigate
manually to that interface
2- portal tasks list view: Currently, the name of tasks will be cropped if it is
too long. However, the user has no choice but to open the form view to get the
full name of the task. This can be quite bothersome when each task has to be open
individually in order to differentiate them
3- portal tasks list view: Currently, projects are displayed as tags
After this commit:
1- we added a shortcut to redirect them in one click.
2- display the full name of the task on hover
3- display project as a normal field
task-3186689
closesodoo/odoo#114531
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this notification actions are shown as such:
MODEL RECORD_NAME won | lost | settings
After they will be shown as such:
MODEL won lost settings RECORD_NAME
with the action links colored to match the company color.
The aim is to streamline the layout of e-mails and make actions
clearer.
task-3067315
closesodoo/odoo#106307
Related: odoo/enterprise#34284
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit there is a sub-type to notify parent
if child stage change but with new to-do state feature
we don't to unnecessory notification on parent which is
more problemation then informative.
This commit remove task dependency sub-type and it's related
code.
task-3252755
closesodoo/odoo#118418
Related: odoo/enterprise#39972
Related: odoo/upgrade#4542
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
*_= project, sale_timesheet,
The purpose of this commit is to improve the UX of the project and timesheet app
So in this commit done following changes:
- In the timesheet time off form view changes the label from
timesheet to timesheets
- In the timesheet list view added a 'no_open' option on the SOL field to
make not be clickable
- In project form view removed the 'quick' create option from the
user_id field
- In project task form view added a 'no_open' option on the SOL field to
make not be clickable
- Color of the Gantt and calendar views in project app
My Tasks:
the color used should be according to the personal stage set on the task.
All tasks:
the color used should be according to the project set on the task.
When the user clicks on a project in the main view of Project app:
the color used should be according to the stage.
task-3125942
closesodoo/odoo#111688
Related: odoo/enterprise#36615
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
When duplicating a project, new milestones are copied for the new
project, but none of them are assigned to the copied tasks like in
the original project.
Expected behaviour:
The new tasks in the new project should have the corresponding copy
of the milestone that were assigned in the original project.
Steps to reproduce:
- Install Project
- Duplicate "Office Design" (it has milestones)
- Observe that the tasks in the new project don't have milestones
assigned to them, like in the original project.
Reason for the problem:
When we copy the tasks, they have the milestones of the original
project correctly assigned to them, but since the project of the
milestone is different from the project of the task (former
references the original project, while the latter references the
copied project), so in `_compute_milestone_id`, the milestone of the
task is set to False.
Fix:
Remove `copy=True` from `milestone_ids` on the project, and copy the
milestone by hand. This allows us to use an overwrite of `copy()`
for `project.milestone`, and we create a mapping between the old
milestones and the new ones in the context, similar to how we did
with `task_mapping`. With this we can assign the newly created
milestones on the copied tasks correctly (while preserving the
mapping like in the original project).
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3254868
closesodoo/odoo#118487
X-original-commit: aad60a2c8a887f3ea226af99be9b162673c33ec8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Purpose of this commit tags order would be more logical to
the user if they were sorted by alphabetical order instead
of id.
So, in this commit sort tags by alphabetical order instead of
id.
task-3165202
Part-of: odoo/odoo#112620
In this commit made following changes:
- added copy writing content in project form view for
access_instruction_message field.
task-3067151
Part-of: odoo/odoo#106233
Before this commit:
- The burndown chart displayed the stage in order of the data fetching which wasn't logical especial for a chart that supposed to represent the evolution of the tasks in the project
- When sorting all/my tasks by stage, It was possible to select any project in any quickcreate of the stages which didn't make much sense
After this commit:
The burndown chart legend is now ordered according to the stage sequence (previously was ordered randomly by comming data)
Modified the burndownChartModel, simply makes a RPC to get the stages and sequences then sort the legend elements (one by stage) with it
Display only the projects which uses the stage in the dropdown menu of the task kanban quickcreate (when grouping by stage)
When sorting by all/my tasks by stage, the quickcreate now only display the projects which contains the stage selected
done by adding a domain in the quickcreate form
(shoutout to LTU and AUON who actually found the fix)
Task-3067445
closesodoo/odoo#105694
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Victor Piryns (pivi)