This commit changes some of the way that users will
work with subtasks in the project app.
Initially, it changes subtasks from a many2many to
a one2many field.
We also add the ability for subtasks to be viewed
straight from the kanban view by drawing a list of
them inside of the kanban box of the parent task.
task-3085016
closesodoo/odoo#112279
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit:
- project tasks kanban view: if partner_is_company, we display partner_id
else commercial_partner_id -> this information is useless so we decided to
display partner_id in both cases.
- manager_id is not used in any view -> drop the field
- when creating a task by mail, email_from is set to the sender email then will
be changed depending on partner_id and parent_id, the field name is not significant
as it change and no more contain the original email sender, it's also a duplicated
information that can be got from partner / parent -> delete the field and create
a new partner if no one already exist with the same email.
- when project.analytic_account_id is changed, only tasks that have the same old
analytic_account_id will follow the name value -> we decided to change the behavior
and apply the new value for all tasks.
- project_analytic_account_id not used in any view and in only place in python
-> delete field
- project.project: partner_email, partner_phone are not used in any view ->
delete field
- project.task: partner_email not used -> delete field
- ancestor_id is no more used in any view or python reference as it's a complicated
field to understand by users -> remove ancestor_id from project.task and remove also
ancestor_task_id that is related it to it in timesheet context and replace it with
parent_task_id which is more simpler to understand by users.
task-3103701
closesodoo/odoo#110101
Related: odoo/enterprise#37246
Related: odoo/upgrade#4269
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The goal of this task is to ease the deletion/archiving of recurrent
tasks by giving the user the option to either continue
or stop the recurrence. The two main use-cases are:
\- You have a recurring task for a weekly meeting.
Next week, the user will be on time off. You are thus deleting the task.
However, you would still like tasks generated for the following meetings
and to keep track of the previous meetings.
\- You have a recurring task for a weekly meeting with an employee
that has just been fired. You are thus deleting the task and
you won't need this recurrence anymore.
(You may or may not want to keep track of the previous meetings.)
The main issue we are currently facing is that we need a task that acts
as a template for the recurrence to continue. This means that a user
cannot delete all of his tasks without breaking their recurrence.
Consequently, we will be using a "task template" for each recurrence,
which will only serve technical purposes and be invisible to the users.
When the recurrence is stopped, the task template is deleted.
This simplifies the technical and functional implementation as the user
won't be able to modify the template themselves.
\- Added task templates to recurrences in the data.
\- Deleted "all tasks" option form recurence update and changed "this
and following tasks" to "this and future tasks". Most of the time, the
user is going to update the most recent task, and it doesn't make
any functional sense to update past ones.
\- Same options for delete and archive.
\- No recurrent subtasks allowed anymore.
\- `date_deadline` is copied. We compute it by adding the delta between
the create date and the `date_deadline` of the template to the next
recurrence date.
\- Added filter to several view not to display task templates.
task-2937565
closesodoo/odoo#98088
Related: odoo/upgrade#4232
Related: odoo/enterprise#30416
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
You cannot set the Default Analytic Plan for projects in the settings.
Expected behaviour:
You should be able to set the default plan, like any other settings.
Steps to reproduce:
- Install Accounting, Project, (Timesheets if you want to test
project creation with an auto-created analytic account)
- Settings > Check Analytic Accounts
- Try to change the Default Plan in Settings > Project
- Upon saving, the change is lost
Reason for the problem:
The `analytic_plan_id` in the project's `res.config.settings` is
related to the same field on the `res.company` model.
The `analytic_plan_id` that is set on the company upon installing the
project module is a non-stored computed field, which makes a call to a
`_get_default` -> the field cannot be set. It will always return
the first default plan in the sequence.
Fix:
Since the field isn't stored (which would have worked if it was),
we use `ir.config_parameter` to write and read to it, per company.
In master we should just add a `store=True` and write a migration
for it?
Affected versions:
- 16.0
- saas-16.1
- master
opw-3127638
closesodoo/odoo#111635
X-original-commit: 11b0e2556ce824048bb4c760893b05e98537d171
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Add a constraint preventing the user from switching the project from company
if the partner doesn't belong to that company, and vice versa.
task-3126301
closesodoo/odoo#109464
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When a message is processed through the mail gateway, the partner should
never be set as the assignee of that task.
This commit allow to correctly let pass `{'default_user_ids': False}`
context from `message_new()` down to `create()`
closesodoo/odoo#110124
X-original-commit: 08e24d683bf19a77982a7ffba6c64b5fc6fdf85a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description of the features in this PR:
add the date deadline to the order of tasks (sort priority)
add the day of the week (only the first 3 letters) for the recurrence message in recurrent tasks
display the name of the project in the action instead of 'Project Sharing'
By changing the sorting order of the Project.Task model
some indexations in the tests didn't point to the right tasks
Now each task that has a deadline will be placed in front of other tasks (except for the high priority task)
Task-3034635
closesodoo/odoo#105701
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when a db is loaded without demo data, or that a user has no
task assigned and no personnal stage, the view 'My tasks' is empty. The
purpose of this commit is to assign default personnal stage to a user in
these case to ease the understanding of new user of what the view can be
used for.
This commit :
- add default personnal stage to user the first time he clicks on the
'My tasks' menu if the user has no personnal stage and no task are assigned
to him.
task-3047496
closesodoo/odoo#105940
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Computing the recurrences of a task repeating every X months until a
certain date generates too much dates
Steps to reproduce:
1. Install Project
2. Go to Settings > Project > Tasks Management and enable Recurring
Tasks
3. Open any project in the Project app and create a new task then edit
it
4. Enable the Recurrent field of the task
5. In the Recurrence tab, edit:
- Repeat Every: 6 Months
- Until: End Date: one year from now
6. The recurrence message says there are 11 tasks but there should only
be 2
Solution:
Generate the recurrences until the `repeat_until` date is reached if the
`repeat_type` is 'until', otherwise generate as much recurrences as the
count
Also relax the constraint on the `repeat_day` and `repeat_until` to not
raise an error if `repeat_until` is the last day of the month
Problem:
The recurrence of a task with `repeat_unit` month and `repeat_interval`
different than 1 with a `repeat_type` until creates too much tasks,
exceeding the `repeat_until`
opw-3076593
closesodoo/odoo#107910
X-original-commit: 236b383fd9d1ad6a5d39d8c4232b49864ec19b37
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- activate "Recurring Tasks" option inside Project settings;
- go to "Field Service" app;
- create a task;
- check recurrence box;
- make the following configuration in the recurrence tab:
* Repeat Every 6 Months
* Repeat On Date of the Month 1
* Until End Date [your choice]
Issue:
The dates calculated for the recurrence are not correct.
Cause:
When we select an interval other than 1 for a frequency in months, we do not divide the number of months between the start and end date.
And therefore the loop that calculates the recurrence dates goes too far into the dates.
Solution:
Divide the number of months between the start date and the end date by the interval.
opw-3078084
closesodoo/odoo#107320
X-original-commit: 5d44d7d595dab866695945e5a6d2091ddd9df342
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit:
Let's consider project P1 having no stages.
Let's consider project P2 having Stage 1, Stage 2
When importing tasks via csv file:
- Task 1 for project P1 and Stage 1
- Task 2 for project P1 and Stage 2
Stage 1 and Stage 2 are still assigned only to project P1.
After this commit:
Stage 1 and Stage 2 are now assigned to P1 and P2.
Task-2996393
closesodoo/odoo#103819
X-original-commit: 2e6a7741dd2c993daa1b1aafe4ebd422cd57235c
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, when the domain used in `read_group` and `search` to
check if the portal user can access to the fields used in the domain
does not take into account the `TRUE_LEAF` (that is, `(1, '=', 1)`) and
`FALSE_LEAF` (that is, `(0, '=', 1)`). In other words, when the
`TRUE_LEAF` or `FALSE_LEAF` is in the domain, an access error is raised
saying the field name `1` or `0` cannot be accessible by the portal user.
This commit allows to add `TRUE_LEAF` and `FALSE_LEAF` in the domain to
avoid having an access error because of that.
close#103214closesodoo/odoo#103465
X-original-commit: 953033e1ab20a01918dae7ca495654cddef14af3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, the form view in project sharing was always in
legacy. Moreover, in that view, the chatter used is the portal one
and so it is also a legacy widget.
This commit converts the form view and then convert the chatter in
OWL to be able to correctly compile and add the chatter in the form
view.
Also, some styling has been done to remove the overflow. Only the
overflow on the y axis in the chatter can be scrolled on the page.
task-2947516
X-original-commit: 175430f3593337ce582cbec644b9d630894c074b
Steps to reproduce:
- have a project with a stage having the user_id set to Mitchell Admin (in this scenario you would have to add the field in the view)
- create a task in this stage
- log in with Marc Demo
- Try to open the project
Issue:
There will be an access error
Cause:
The domain allows to fetch all tasks from a project; even those from a prohibited stage
Solution:
- As in d4252825f5, we'll restrict the domain and "hide task stages if user is set".
- Prevent the user to create/modify a record to it with with a `user_id` and `project_ids`
opw-2917631
closesodoo/odoo#101965
X-original-commit: fdaef9276b89e2170128e205a4b7fd0b8defc2b1
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
This commit (and its enterprise equivalent) purpose is to smooth the
user experience and remove unnecessary steps.
The commits:
- Remove all stat buttons except the status and collaborators one from
the project edit form.
- Add multiple small changes to string/name fo fields in views
- Change the custom O2M widget for a standard M2M for the management of
child tasks
- Add the milestone field to the portal page of shared project.
- Remove the wizard 'marked_as_reached_milestone'
- Add the automatic generation of milestone when a SO is confirmed if
some SOL need it
task-2941835
closesodoo/odoo#98546
Related: odoo/enterprise#30628
Related: odoo/upgrade#3798
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the portal user changes the stage of a task and
the new stage contains a rating template email, he got a traceback
saying he has no access to `mail.template` model.
This commit fixes the issue by sending the email in superuser when we
are sure the user can write on that task.
Steps to reproduce:
==================
1) Enable the rating feature in the settings of Project App
2) Create a Project A and edit it to enable the rating feature on that
project and select "Rating when changing stage" (if it is not already
the case)
3) Set a rating email template on a stage of the project
4) Create a new task and save
5) Change the stage of that task to the stage contained the rating email
template
Actual Behavior:
---------------
A traceback is occurred saying the user has no access to `mail.template`
model.
Expected Behavior:
-----------------
The stage of the task should be changed and the rating email should be
sent.
closesodoo/odoo#99248
X-original-commit: c5093988411e5697f49ca2a128e93203c2d6aac9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Running tests for `project` module only fails with the following error:
```
2022-08-02 08:19:41,777 5669 ERROR testdb odoo.addons.project.tests.test_project_report: FAIL: TestProjectReport.test_avg_rating_measure
Traceback (most recent call last):
File "/build/odoo/saas-15.3/addons/project/tests/test_project_report.py", line 22, in test_avg_rating_measure
self.assertEqual(self.task_1.rating_last_value, 5.0)
AssertionError: 4.0 != 5.0
```
With the ORM flush mechanisms when multiple ratings are created at once
they all have the same `create_date` and/or `write_date`, this commit
ensure the order is deterministic.
closesodoo/odoo#97691
X-original-commit: 567d27cc600bdbb39d62e7aa75b37d48b33d27a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done following changes:
- when deleting a project, delete all of its tasks in the process instead of
raising an error
- make the list view editable bottom
- add a 'view task' button to open the task form view
- the 'download' and 'print' buttons should be centred
- rename 'planned hours' into 'allocated hours' (or 'allocated days' if the
timesheet encoding unit is in days)
- when a project is linked to an SO manually, he should appear in the
'projects' stat button of the SO; same goes for tasks
- remove the 'profitability' setting
- display the SOL and the quantity in red as well if the milestone hasn't been
reached yet for update right side panel
- add a project field for quickcreate in kanban view
- 'fa-check-square-o x/y' in muted on the project kanban cards
task-2838372
closesodoo/odoo#92262
Related: odoo/enterprise#27758
Related: odoo/upgrade#3561
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Purpose of this commit
======================
The Burndown Chart report was very slow on big databases as it was not
possible for Postgresql to optimize the query as it was based on a view
that was using several generate series.
This commit aims to improve the performance by injecting the constraints
at a lower level than it was in the past, lowering the amount of data
processed in the higher level of the query.
/!\ Important note
------------------
Overwriting the `read_group_raw` is really not a good practice and should
be avoided in most case. If you fall on this implementation by grepping
the source code, please be advised that this is not the right way of doing
things.
Implementation details
----------------------
- The report is now run by generating the `SQL` that is executed by the
`read_group_raw`. This allows inserting `SQL` constraints at a lower
level and simnifically improves performance. As there is no other way
to do it, the code is unfortunately a modified copy of the actual
`read_group_raw`.
- The pivot view has been removed as it had no meaning and was creating
confusing data.
- The `Group By` menu has been limited to `stage_id` and `date` as bringing
more data trough the different `GROUP BY` statements up to the higher level
is costly. Further more, additional `Group By` did not bring added value
as the Chart was less readable.
- The JS code has been adapted in order to force a group by both `stage_id`
and `date` so that the date displayed is always making sense.
- The sort ascending and descending options have been removed as creating
confusing data.
- The compare with previous period has also been removed as the chart only
really make sense when seen chronologically.
- A lot of tests have been added in order to ensure that changes that would
be harmful for the report will trigger test fails.
task-2845729
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Prior to this commit, `test_delete_project_with_task` is part of `TestProjectCommon`
which is inherited in several tests. Because of that, `test_delete_project_with_task`
is run several times, which is not relevant.
This commit moves the tests into a new class in order to prevent it to be run
several times.
task-2845729
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Currently, portal followers of a project and its tasks are removed when
the project visibility is changed to something else than portal.
=> We want to keep the behavior, but only when changing the visibility
from portal to something else.
When the project visibility is changed to portal, we currently add
its customer to its followers.
=> In that case, we also want to add the customer of the tasks to the
followers of the corresponding task.
When the customer of a project in portal visibility is changed, the
new customer is added to the followers of the project.
=> We want to remove this behavior.
When a project is created with a customer and the portal visibility,
the customer is added to the followers of the project.
=> We want to remove this behavior to avoid mistakenly showing a project
that is not ready yet to the customer.
This commit implements those changes, and also adds a warning when
changing the visibility of the project if that change will automatically
add/remove followers to the project and its tasks.
Related: https://github.com/odoo/enterprise/pull/25800
Task-2812551
closesodoo/odoo#87747
Related: odoo/enterprise#25800
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit ensures that, when creating a private task, the current user
is always part of the assignees.
This commit also adds tests on the different `project.task` creation scenari
to ensure it gets not broken in the future.
task-2818486
closesodoo/odoo#89041
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the milestones are only linked to a project without
any link to the tasks of the same project. However, the tasks could be
considered as steps to reach a project milestone.
This commit adds a link between the `project.task` and
`project.milestone` models. This link is added in the `project.task`
model with the Many2One field called `milestone_id`. With this field,
the user will be able to link a milestone to a task.
task-2829542
This commit allows project users to create and modify their own personal
stages.
A lot of overrides have been done on the kanban view to handle our
multiple cases.
Project user will now only see the options to create columns/edit stages
when grouping by personal stage.
This is hardcoded and does not follow possible custom access rules
however.
Any stage created while grouping by personal stage will directly be
assigned to the user and will be seen in the 'My Tasks' menu.
A special method has been added to delete a personal stage.
Upon deletion any task assigned to this personal stage will move to a
lower sequence stage if possible otherwise the next in line.
TaskId-2858445
closesodoo/odoo#92103
X-original-commit: 7b3acbc0b0c21ab106b1b34d9f5c8bc1ceb2fe58
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds a test to check the email is correctly sent when the email
is linked to a project stage and a project arrives in that stage.
task-2723662
Part-of: odoo/odoo#88889
tasks assigned to the current user should be in the 'inbox' stage by default.
tasks with no project set should only be visible to the users assigned to them.
task-2723662
Part-of: odoo/odoo#88889
-Test the creation of sub-tasks through the notebook
-Set a parent task on an existing task
-Test the creation of sub-sub-tasks
-Check the correct nb of sub-tasks is displayed in the 'sub-tasks' stat button
and on the parent task kanban card
-Sub-tasks should be copied when the parent task is duplicated
-The parent task should take into account the timesheets of its sub-tasks
task-2723662
Part-of: odoo/odoo#88889
Before this commit, the current user can create a private task for
another user.
This commit fixes the access rights to avoid the user to create private
tasks for another user.
closesodoo/odoo#90938
X-original-commit: 106826b1ffcd9a18ce5d4674c526bce4f2efca9e
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Purpose of this commit to improve generic usage of project
app.
So, in this commit done following changes:
- add 'my department' filter in project search view.
- add 'my department's tasks' and 'my department's projects filter
in task search view.
- add quick search, filter and groupby in task analysis report search view
to make task analysis report search view same as task's search view.
- improve portal template of my/tasks page.
- project.task form view > timesheets: display the employee avatar
on mobile.
- make 'Task: Rating Request' template auto_delete false.
- settings: make following features disabled by default: sub-tasks,
task dependencies, recurring tasks.
- project.update kanban list: align the stat buttons with the kanban
list cards.
- add sample data to the project stages > list view.
- project.task quickcreate: enable the creation of new users on the
fly.
- move tags quick search below project.
- add title to show project full name on hover of project name in kanban
view of project.
- copy user_ids for task in recurrence.
- improve UI visibility of planned_hours and subtask_planned_hours field in
timesheet page of task form view.
- improve project sharing wizard and project.collaborator tree
view.
- add grid,kanban,pivot and graph views to 'hours spent on
sub-tasks' button's action.
closes: #83482
task-2742725
Related: odoo/enterprise#23788
Related: odoo/upgrade#3480
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Step to reproduce:
- Create a project with 2 task A and B
- Set task A blocked by task B
- Duplicate Project
Current behaviour:
- Duplicate project is also blocked by original project's task
- Original project's tasks are blocked by new duplicate project's
task
Behaviour after PR:
- Original project's tasks are not changed
- Duplicate project's tasks are blocked by duplicate project's task
if they were blocked by the original project.
- Tasks are still blocked by tasks not linked to the original
project
opw-2818476
closesodoo/odoo#90256
X-original-commit: 5c184628b2278814d2b28366587c8e4b813d0374
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Before this commit:
- Join between task and rating is made on parent_res_id
- Displayed value is the sum of tasks average_rating
- No Unit test to cover this case
- Measure displayed when customer rating setting is not active
- [Demo data] Each task is rated one time so average_rating and last_rating are the same
After this commit:
- Join is made on res_id which is the task_id
- Displayed value is the avg of tasks average_rating
- Unit test added to cover mesaures calculation
- Measure dusplayed only when setting active
- New demo record added to let average_rating be different from last_rating
closesodoo/odoo#89764
X-original-commit: 3a5d816ef26a164fc38965154e38b45e33f9a81e
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In a project burndown chart, we currently have two measures, "Count" and "# of tasks".
Those measures are identical, but the default "Count" one is less explicit.
We only want to keep "# of tasks", but rather than discarding the default measure,
we could rename it and remove the other one.
This commit removes the "# of tasks" measure, and renames the default "Count"
into "# of tasks".
Task-2734458
closesodoo/odoo#86110
Related: odoo/upgrade#3357
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the portal user can read the `project.update`
and `project.milestone` records but there is no reason to grant this
access for those models.
This commit removes the read access for thoses models since we don't
show the data in its portal.
X-original-commit: f0331531826974ddaab5dff28739115c37a351c0
Forward-port-of: #88546
Forward-port-of: #88509
Part-of: odoo/odoo#88819
Before this commit, when the user duplicates a project with subtasks the
subtasks are duplicating twice. This is because we now duplicate the
subtasks when a task is duplicated.
This commit fixes this issue to duplicate once the subtasks when the
project is duplicated.
Steps to reproduce:
==================
1) Create a project A
2) Create a task T with a subtask
3) Duplicate the project A
Expected Behaviour:
==================
The duplicated project should have 2 tasks (subtasks included)
Actual Behaviour:
================
The duplicated project has 3 tasks (subtasks included), the subtask is
duplicated twice.
This bug has been found during the development of task-2726465
Related PR: #86997closesodoo/odoo#88264
X-original-commit: dcf780026bfa7d76a58aa766b8d190022818ce45
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds a generic method for all sections in the project
profitability to get the correct action based on the which section the
user clicks. Moreover, a new parameter is added into
`_get_profitability_items` method to add the action data in the
profitability items or not. This parameter will be useful for the unit
tests.
task-2710808
This commit reviews the project profitability displayed in right side
panel of project update kanban view. The goal of this commit is to add
more information to allow the user to see all information concerning the
profitability of his project.
task-2710808
test_task_postal_no_read` calls `assertEqual`, which internally
creates a savepoint which flushes pending computations.
This is done by flushing the transaction (through the cursor), which
in turn goes and flushes the models.
The environment being used to flush the models is arbitrary, picked
from the set of all living environments associated with the
transaction favoring those with a user set. This means the environment
used to perform the pending computation can be a lot more restrictive
than the operation used to initiate said computation, which may lead
to the computation being flushed not being *possible to perform*.
The issue here is that the test specifically involves a restricted
user ("Portal user", created for the occasion). Logging the set, at
the start of the test function there are 11 active environments
associated with the superuser (uid1) and one (1) environment
associated with that user, let's call it 19 (because that's the uid it
gets when running only that job).
On the runbot the envset seems to shuffle really well and about 2/10
of the runs will have the env(uid=19) in leading position[0], thus try
to flush the *creation of the task* with the portal user, which
specifically does not have access to tasks.
This works around the issue by flushing the task creation in the
`setUp`, however the underlying issues remain.
[0]: This also seems to require some load on the runbots, if the
runbots are pretty much unloaded (no pending builds)
reproduction is never achieved. It is not clear why load
would matter.
Local reproduction was not successful, even using a dump from the
runbot and inducing artificial load (via stress-ng).
closesodoo/odoo#87512
X-original-commit: fc08ff42ec8886f6258bde6586c4293b64c89456
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, when the current user is in project sharing and see
the form view of a task with at least a subtask. He cannot create
another one because of an error in the `_compute_portal_user_names`
method. Indeed, it is because we want to update the cache to get the
user_ids of the task related since the portal user cannot see the
users assigned to the task since he cannot access an internal user. This
update cache is made by calling the `_read` method but this method
checks after having fetching the data if the self is equal to the
recordset fetched. If the `self` contained newIds, then the method will
raise an error because a Task with newId != Task with id in db.
This commit fixes the compute method to call the _read method only on a
self with no NewIds to avoid this issue and correctly updates the cache
to get the name of the users assigned to a task in project sharing for
the portal user.
Fix found by Florian Damhaut <flda@odoo.com>
Co-authored-by Florian Damhaut <flda@odoo.com>
opw-2745857
closesodoo/odoo#84298
X-original-commit: f61c4f43365d38a955c497e022f0e8f18f50a6b2
Forward-port-of: #84189
Related: odoo/enterprise#24207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the portal user is assigned to the subtask if he
creates a subtask via the project sharing feature. We recently hides the
`Assign to me` button to those users.
This commit removes the `default_user_ids` in the context used when we
create a subtask in the project sharing feature to not assign the user
to that new subtask.
Related PR: #84006
X-original-commit: f3a241e97f80007f6d7ce2567dd22784cb35de26
Forward-port-of: #84189
Part-of: odoo/odoo#84298
Beforer this commit, we display a emoji to show if the customer is
satisfied, okay or not for the task via the last rating value. The
problem is we use only the value for the last rating for each task.
This commit uses all ratings for each by using the average of rating
value for each task to know if all the customers that done a rating are
satisfied or not.
Moreover, we add 4 filters in the project.task model using the average
of rating values.
1. Satisfied => rating_avg >= 3.66
2. Okay => 2.33 >= rating_avg < 3.66
3. Dissatisfied => rating_avg < 2.33
4. No rating => show the tasks without any ratings.
task-2671848
Closes#81027
While investigating an issue with the x2many tracking, we found a
better way that to track those field while also fixing the issue.
Fixes an issue with `default_*` context keys that are used in the
project app upon writing on tasks.
TaskId-2725014
closesodoo/odoo#82189
X-original-commit: a281a18fc84a09177f7b5e8aab98b8dc34dcc3b8
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Panagiotis Kyriakou