Adding a company_id field in project.project.stage will allow companies
to have their own individual stages, which was not possible before since
all the stages were shared between all companies.
task-3330285
closesodoo/odoo#122597
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
This commit implements the `mail.tracking.duration.mixin` with the
`statusbar_duration` widget for `crm.lead` and `project.task`.
The goal is to compute and display how long a record has spent in each stage in
the statusbar of their form view.
Task-3032773
Part-of: odoo/odoo#108554
Before this PR the task state was fixed by the kanban_state field which was useful when you use the stage of the project as parts of a pipeline,
but not relevant when users are using stages as bucket lists. (specific examples at the end of the specs)
The goal of this PR is to provide users a way to mark their tasks as done with a simple button press,
while keeping the option to label a task as Approved, Canceled or Requesting changes like in the old kanban_state field.
The kanban_state of a task had no impact whatsoever on other tasks of the pipe, we would like to change that and make the task state have an influence on its dependent tasks.
The state will also have influence over the 'recurrent' tasks (to be implemented in Task #3084945)
If you want a better description of those changes with screenshot and colors check specs of:
Task-3084930
PRs:
See odoo/enterprise#35359
See odoo/upgrade#4367
-----------------------------------------
Interaction with blocking tasks:
the closed values which mark the task as closed or finished:
- Done
- Canceled
The Open values when the task isn't finished yet:
- In progress
- Changes Requested
- Approved
- Waiting (which is not selectable)
Where to change the state of a task:
- For kanban and form views: same place as kanban_state (bottom right of kanban card, top right of form view)
- For list view: left of list (after task priority)
more details about the state widget in state field widgets part
Interaction with existing fields
- is_closed: which was determined by the task.stage_id.fold, now a task is closed when in one of the following stages
- Done
- Canceled
a closed task is considered as finished, the time of the closing will be stored in the date_last_stage_update field
- is_blocked: a task is considered blocked if ANY of its blocking task is in one of the blocking states (more details about this in the following part Interaction with blocking tasks):
- in Progress
- Changes Requested
- Approved
- Waiting
!! important !! is_closed and is_blocked are not mutually exclusive, you can have a task that blocked and is closed at the same time, the reason why will be explained late
date_last_stage_update: this field is updated everytime the task goes into a closing state OR when the task changes stage.
We need to check that the value is updated in each case (using the already available filter)
Interaction with blocking tasks
the state of a task can now be changed by its blocking tasks following the logic:
if ANY of the blocking tasks is NOT closed (so its state is in one of the open values) the task is considered as blocked
- if a task is blocked and NOT closed its state will switch to Waiting
- the Waiting state will display an unclickable hourglass icon on the task kanban/list views, once in the waiting state you can't change the state of the taskfrom the kanban/list views
- a blocked task state can be changed through the form view, so you can override the 'block' by choosing a closed state (only done or canceled)
- once overriden, the task will change to the closed state the user wants, but the task is still blocked so in case where the user comes back to an open state, the task will automatically switch back to the waiting state (according to the state before the block)
- if the blocking task switches to a non-blocking state, the task will not be considered as blocked anymore and its state will switch back to In Progress
Default values
the default value is always in progress
Special cases
when a task is moved from a stage to another one
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
when a task is moved from a project to another one
- the state goes back to In Progress
when a task is duplicated
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
closesodoo/odoo#107593
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit,
-We Ease the quick creation of tasks by providing shortcuts allowing the user
to set different fields (planned_hours, tags, priority, and assign to users)
without opening the form view.
task-3145203
closesodoo/odoo#112821
Related: odoo/enterprise#37166
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>
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>
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
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>
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
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>
This commit fixes an issue since user_id was changed to user_ids.
The default behaviour of `_message_auto_subscribe_followers` could not
work with the user_ids field as it is only meant to work with user_id.
This also fixes a related issue due to the same problem where the
assignation emails were not sent.
TaskId-2691486
closesodoo/odoo#79831
X-original-commit: 3510251ad19d4394f4613924aa2af20abb7c35d9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds unit tests to check the access of portal user. That is,
we check if the readable fields are only available in read access and
writable fields are available for the edition of the task.
We also check if the other fields in task model raise a AccessError if
the portal user wants to access to one of them.
task-2633229
closes#77156
X-original-commit: 1e7185bcdd8913c006148466dec260b8f6d53c0b
This commit adds an unit test to start a tour with an internal user
connected to test the project sharing feature. Another test is
created to start a tour with a portal user connected to test the
project sharing feature.
part of task-2633229
closesodoo/odoo#76906
X-original-commit: db7825efb1b5cc052ecc795f9c81db5f3f58a5d3
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Adds personal stages to tasks.
Users assigned to tasks will be able to have their own pipeline to
handle their tasks independently of the project's pipeline.
The assignee field on Tasks has also been changed to a Many2many to
support multiple assignees on one task.
The same table is used to store those information, essentially a triplet
(task, user, stage), to ensure that:
1) personal stages only apply to tasks to which you are assigned to.
2) synchronizing to make sure that you don't have a personal stage for a
task on which you are not assigned anymore.
Alongside those changes, some minor changes have also been made:
- Modified the task's tree view.
- Renamed the Tasks menu to 'My Tasks'.
- The default view is now the kanban view for the 'My Tasks' action.
- project_id is not required anymore, tasks with no project are
considered 'private', those tasks are only visible to those that are
assigned to it.
- Added tracking of both user_ids and depend_on_ids in the chatter.
Closesodoo/odoo#74087
Task ID: 2398734
Before this commit, for the db with old active tasks and many
projects and tasks. The report takes several hours to execute the sql view.
Because we take the create date of the oldest task as the begin date
of each generate_series to calculate the different group bys (day, week,
month, quarter and year) until CURRENT_DATE.
This commit hugely improves the performance of the sql view execution
for the burndown chart report.
closesodoo/odoo#72664
X-original-commit: 89726a22862cf14f7b88e130fb79ddc74bffff5e
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Nicolas Seinlet (NSE) <nse@openerp.com>
Co-authored-by: Thibault Libioulle (TLE) <tle@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
This reverts commit odoo/odoo@7059b17.
This commit translates tests introduced in this reverted commit to be
aligned with the current workflow.
This commit reverts functionality or business logic linked to the
reverted commit :
- odoo/odoo#47248 : You no longer have to be an allowed user to see the
timesheets but only a message partner.
- odoo/odoo#49021 : We no longer deal with allowed_user_ids or
allowed_portal_user_ids
- odoo/odoo@f2a1a00 : We no longer deal with the allowed users lists.
This commit removes the button project_privacy_visibility for functional
reasons.
Closes: #65367
task-2439329
Related: odoo/upgrade#2128
Related: odoo/enterprise#16067
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds two new fields in the project.task model.
The first one called 'allow_task_dependencies' is a related field to the
one project.project model. The other field called 'depend_on_ids' is a
Many2many field will contain the tasks which the current task depend on.
In the form view of project.task model, these fields are added.
task-2387984
closes#66740
This change ensures that when the user activates optional features of the
project app, they are enabled in existing projects as well as newly created
projects automatically, which is likely what the user expects.
For most optional features, this behavior was already in place. It was not in
place yet for the sub-tasks and timesheets features, which this change fixes.
Two added tests check the behavior described above for features that are
activated through a `group_*` field on `res.config.settings` (sub-tasks,
recurring tasks and ratings). The tests do not cover features that are
activated through a `module_*` field, as such fields require the installation
of further modules and we cannot simulate this.
Task 2297054
closesodoo/odoo#60106
X-original-commit: 8dd0edae898a532dbe7e4f18c9118b9b68e57900
Related: odoo/enterprise#14119
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Kevin Baptiste <50135801+kba-odoo@users.noreply.github.com>
Some interventions are done on a regular basis (e.g. maintenance of
fire alarms, safety inspections). Having tasks auto-generate would
facilitate the process and would ensure that the next intervention
isn't missed/forgotten.
closesodoo/odoo#55517
Taskid: 2172156
Related: odoo/enterprise#12246
Related: odoo/upgrade#1604
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
=======
Purpose
=======
Currently for a user to be allowed to see a private project they must follow the
project. This means that they will be added as a follower of all new tasks in the
project which causes them to receive 1000000 notifications, especially if there are a
lot of tasks in a project.
==============
Specifications
==============
1) Add an Employee m2m field on project next to 'Invited Employees'
- only visible if the 'Invited Employees' option is selected
- the project should only be visible to employees selected there (regardless if they
are followers or not)
2) Add an Employee m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Invited Employees' option is selected on the related project
- should be pre-filled with what is set on the project
- the task should be visible to employees selected there (regardless if they are
followers or not)
3) Add a Portal users m2m field on project next to 'Portal users and all employees'
- only visible if the 'Portal users and all employees' option is selected
- the project should only be visible to portal users selected there (regardless if
they are followers or not)
- rename the option into 'Invited portal users and all employees'
4) Add a Portal users m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Portal users and all employees' option is selected
- should be pre-filled with what is set on the project
- the task should be visible to portal users selected there (regardless if they are
followers or not)
5) Following a project/task should not grant the user/employee the ability to see the
project/task
Task 2031527
closesodoo/odoo#40505
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes possible the task delegation in a multi company
environement. A subtask is a normal task with a parent, but can
now be in a different company, to be use as subcontracting task in
another company.
Tests are added to check multi company consistency for the project
app in general and for the subtask cases.
Task-1999686
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
Tests have been migrated to the new api to prepare the migration of the
mail module itself. Moreover tests have been cleaned: redundant tests
and unnecessary tests have been removed.
As the base test class in mail is used in other addons, other addons
have been updated :
- portal
- project
- portal_project
- website_project_issue
- sale
- purchase
Future commits will come with somes fixes for issues detected when cleaning
the tests.
dise