_*: hr_timesheet,sale_project,sale_timesheet
Generally, you don't want subtasks to be displayed at the same level
as their parent tasks. You want to consider the subtasks as part of
their parent's project, but don't want to see them directly in this
project. Rather, you want them to be accessible only via their parent.
(There are exceptions to that and we want to stay flexible.)
First solution that comes to mind is to have `project_id` set to False
for the latter tasks, but then how to get the value of the fields that
are related to the project?
So, second solution would be to have a field `project_root_id`,
which would be the project of the parent, or the grand-parent, etc.
The issue now is that we have to fields "project", and it isn't obvious
when to use one or the other.
The most simple way to answer this need is to keep one field "project",
that will always be set for (non-private) tasks,
and create a boolean field : `display_in_project`.
But we want it to be technical (no checkbox in the view).
So, when the user unsets the project on a subtask, the view will act
as if the project was unset, but in the back-end,
we'll set `display_in_project` to False and set `project_id` back.
The fact that all tasks have a project allows us to know if action x
can be perform on this task t, dependind on t.project_id.allow_x.
task-3367246
closesodoo/odoo#128281
Related: odoo/enterprise#43996
Related: odoo/upgrade#4930
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit's purpose is to allow the user to set the company_id of a project to False, meaning the project is no longer restricted for the user who does not have access to the company of the project. This change induces a lot of other small behavior changes/approximation. Since some fields (currency_id, resource_calendar_id, etc) were company dependent, we had to updates some use cases.
task-3084819
closesodoo/odoo#122144
Related: odoo/enterprise#41363
Related: odoo/upgrade#4947
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The test `test_duplicate_project_duplicates_milestones_on_tasks` and the test class `TestSoLineMilestones`
fail when demo data are not installed.
This commit makes it demo data independent.
Task-3410352
closesodoo/odoo#128307
X-original-commit: 9193168d39a808d66e67ad8d5d704d72fdc5f3a0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
When creating a new quotation from an FSM task, if we use a template
that adds a line that is a service that would have added a task on
SO confirmation, no new task is generated.
Expected behaviour:
A new task should be created, just like when we add manually the
line with service without using a quotation template.
Steps to reproduce:
- Install FSM
- Activate "Extra Quotations" from Settings
- Create a new service that generates a task on SO confirmations
- Create a new quotation template, add a line that uses the service
we created.
- In a FSM task, click on "New Quotation"
- Add the template to the quotation and confirm it
- Observe there is no Task attached to the SO. No new task was created.
Reason for the problem:
When we create a new quotation view the action "New Quotation", we
add in the context a key `default_task_id` with the current task
that generated the quotation. When we add a template, an onchange is
triggered which creates the lines for the SO, and since we have a
`default_task_id` in the context, the related task of the new line
is set to the task we came from. This prevent subsequently the
creation of a task if the service was supposed to generate a new
task on SO confirmation.
Fix:
Add an override when generating the data used to create the lines
when the onchange is triggered, explicitly setting the `task_id` on
the line to `False` if the key is in the context and the service
would've generated a task.
Affected versions:
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3360403
closesodoo/odoo#127811
X-original-commit: 06eeefc94f08cc01786c82b769d1c488e0e1c483
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@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>
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
Steps to reproduce:
-------------------
- create two product of type "service";
- field "Create on Order" is set to "Project & Task";
- create a Sale Order with these two products;
- condirm the Sale Order;
Two tasks are created in a project and each task has its own Sale Order Line Item.
- create a subtask from both tasks respectively;
- select a project for the subtask.
Issue:
------
The same Sale Order Line is selected for the two subtasks.
It always take the first Sale Order line.
Cause:
------
To choose the sale order line, we first look to see if
the subtask belongs to a project.
If so, we take the sale order line which created the project.
Unfortunately, a subtask can belong to a project created with
a sale order line without belonging to the same sale order line
(in the case where a task is added to a project via another product
and therefore another sale order line).
Solution:
---------
- A project without parent --> use project's sale order line
- A parent without project --> no sale order line defined
- A parent in the same project --> use parent's sale order line
- A parent in an other project --> use parent's sale order line
opw-3333936
closesodoo/odoo#124260
X-original-commit: 323d7f631916f5acc5ab34f8531ae59bb0455828
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Current behaviour:
If in 1 SO we have 2 service lines, each making their own project (for
ex: 1 with a template project, the other without), these 2 lines are
present in both project profitability report, skewing the margins,
as costs calculated on a per-project basis, while sol are aggregated.
Expected behaviour:
Don't include services that have their have another project than the
current one in the profitability report. (Project profitability `A`
shouldn't show services that are linked to project `B`).
Steps to reproduce:
- Install Sales, Project, Accounting, Timesheets
- Activate Analytic Accounts in Settings
- Create a project template
- Create 2 service products, both create a Project when confirming
the SO, one has no project template, the other has a template (the
one we create just beforehand)
- Create an SO, add the 2 lines, 1 for each service, 5 and 3
quantity respectively > Confirm SO
- Go to the Project's Update panel of either created project, we can
see that both lines are present. If you timesheet in a task in
either project, it will show up in both project's profitability
report.
Reason for the problem:
In some places, when we are constructing the domain that is used to
fetch the sale order lines that will be added to the profitability
items, we fetch the correct sol (only linked to this project), then get
the sale order linked to this line, and we search all lines related
to that SO (so we included products that are not services, for
example materials necessary for a service). This flow includes lines
that may be linked to other projects.
Fix:
We fetch SOL linked to the current project or that have no project
(for materials).
⚠️ **known limitation** Material lines are shared between
projects (because of `('project_id', '=', False)`), but that's
already current behaviour, even before this fix.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3300322
closesodoo/odoo#123803
X-original-commit: d0735a6168f5c019d5c03190f930882addd2496a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit's purpose is to take into account the down payments for the
project profitability of the project update window.
Currently, if an SO has a total of 300$, and a down payment is created for 100$, the project
profitability will not compute the 100$ into the 'amount_invoiced'
column. After this commit, it will. A negative value of -100 is also
added in the 'amount_to_invoice' column in order to keep the total of
that column, and the total of the 'expected' column of the project
update consistent with the total of the SO.
task-3204827
closesodoo/odoo#116293
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
view
The goal of these changes is to make it easier for the user to manage
their SO. They can create new tickets/timesheets/etc without being
forced to leave the application to open the one they need, nor do they
need to manually link the new record to the SO
task-2954409
closesodoo/odoo#100300
Related: odoo/enterprise#31391
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
If we confirm an SO with a service with a delivery based on
milestones, that creates both a project & task, and we set a project
on the SO, the project for the milestone should be the one set on
the SO, a ValidationError is raised for missing project on milestone.
Expected behaviour:
No ValidationError, the milestone should use the project set on the SO.
Steps to reproduce:
- Install Sales, Project
- Check Milestones in Settings
- Create a new project.
- Create a new product, type service, delivery milestones, on
confirm create project & task
- Create an SO, add a line with the new product.
- Set a our new project on the SO (In the "Other Info" tab)
- Confirm the SO, you are met with a ValidationError.
Reason for the problem:
Since we are not *generating* a new project, `project_id` on the
sale_order_line is empty, and we base ourself on it when creating
the milestone in `_generate_milestone`, leading to the non-null
validation error, because this field is `required=True` on milestones.
Fix:
When creating the milestone in `_generate_milestone`, if the line
doesn't have a `project_id`, we take the one set on the order.
We don't set the `project_id` to the *determined_project*
(`_determine_project`) at line 305
(after: `so_line._timesheet_create_task(project=project)`) because
the `project_id` on the sale_order_line is marked as "Generated
Project", which is not true in our case (the project isn't generated
by the sale order line).
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3236235
closesodoo/odoo#121141
X-original-commit: 811bbf05722bc69d461306a8890235541c571457
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
project_profitability + change the name displayed in portal
This commit's purpose is to
- add the computation of the AAL for the project profitabity. If a the
analytic account of a project contains AAL that were manually added (
and thus not linked to any sol/purchase/etc ) those lines are not
computed in the 'other costs/other revenues section.
- to display the title of the ticket/task/project in the name of the page My ticket/My task/My project of the portal
task-2960753
closesodoo/odoo#106438
Related: odoo/enterprise#34344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit user able to see and add customers on non fsm and
non billable tasks/projects which is not provide any significance as
user don't need customer for normal tasks/projects.
So, in this commit hide customer field and also move partner phone
and city to field service app as it was only usefull for FSM project
and task.
task-3141350
closesodoo/odoo#111335
Related: odoo/upgrade#4274
Related: odoo/enterprise#36459
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
The project profitability panel doesn't take into account the AA
distribution of the project's AA for solo invoices and bills.
Expected behaviour:
It should take the distribution set into account.
Steps to reproduce:
- Install Accounting, Sales, Project, Purchase
- Settings > Activate AA
- Create a new project with a new AA for it.
- Create a new bill or invoice, on the line set the 2 AA, one with
the project's AA with some X%, and the other AA is irrelevant (the
sum of all AA on the line should be 100%)
- Confirm the invoice/bill
- Go to the project profitability report (project updates), see that
we have 100% of the line value that contributed, when it should have.
Reason for the problem:
The contribution of the AA was not taken into account when computing
the project profitability for solo invoices/bills (invoices/bills
w/o SO/PO respectively)
Fix:
Additionally get the analytic_distribution when fetch the
account_move_lines to compute the project's profitability.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3246199
closesodoo/odoo#117163
X-original-commit: c3c66d05d039514c9dd02ebdede20a3dff757728
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, the `display_project_id` field was a bit confusing
for the user to know what is the goal of this field. Also this field is
available when the user wants to import his data into Odoo, if he does not
know the goal of this field then he could be lost to know which field he
should for his data to import (or even export).
This commit removes the display_project_id field and so a task will be
private one if the project and the parent fields are not set. The
project to set to the timesheet will be the one set on the task or the
one set on one of its parent tasks.
task-3230063
X-original-commit: 22eda5a5ddcfcda9fa6597d6fe21eb20f525799f
Part-of: odoo/odoo#115781
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>
Before this commit when user creates a private task user
still able to customer and sol field which no use for
private task.
This commit hide customer and sol field for private task
and reset customer field when user make non private task
to private task.
task-3084850
Part-of: odoo/odoo#109281
Before this commit, non-service SOl was not displayed on
project update right-side panel view but non-SOLs products
contribute to the project's profitability,
e.g. you install a new kitchen -> you sell the installation service
and the furniture for the kitchen.
So in this commit include the non-service SOLs to the project
update panel.
task-2992368
X-original-commit: 49558c2f15d38bee870766421d237e5228f02718
Part-of: odoo/odoo#109111
Current behaviour:
In the project update dashboard, invoices and bills that are created
directly (without sales order or purchase order) are not taken into account
in the calculations for profits/costs.
Expected behaviour:
They should be taken into account, as long as the line on them has the
analytic account line on it.
Steps to reproduce:
- Install Project, Sales, Purchase, Accounting
- Activate "Analytic Accounting" in Settings
- Create a new Project and create a new analytic account for the project
- Create a Bill with a product (storable/consumable) and the analytic account
on the line
- Post the bill
- Go to your project update dashboard and notice the cost of the bill
is not taken into account, but we do have a smart button that goes to the bills
Reason for the problem:
Profits/Costs calculations are done based on the sales/purchase orders,
missing the "orphaned" invoices and bills. A side effect of this problem,
storable products on sales are also not taken into account, since Sales Orders
don't have an analytic account per line before version 16, unless that product
is a service (all services intrinsically have an analytic account)
Fix:
Get all invoices/bills that have lines with the project's analytic account,
and removing from those the lines that were already accounted for.
Affected versions:
- saas-15.3
- 16.0
- master
opw-3058198
closesodoo/odoo#108176
X-original-commit: 3d3f4109a06445b6ce9606770085c763ea206b35
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit move allow_billable field of task to sale_project from
sale_timesheet module.
task-3018123
closesodoo/odoo#106961
Related: odoo/upgrade#4093
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- Go to Projects and find one having field "sale_line_id" set
(example "AGR - S00048" with
"S00048 - Senior Architect (Invoice on Timesheets)")
- Go to Sales -> Quotations and :
1/ cancel
2/ set in draft
3/ edit Project to "AGR - SO00048"
4/ confirm again (see attached)
- Alter Marc Demo access right to have:
Sales -> Administrator
Project -> User
- With Marc Demo, go to Sales -> Quotations and open S00048
- Try to cancel it
Issue:
Access right error.
Cause:
When canceling a SO, we remove the related SO line on the project
however the current user have access to edit SO but not the project.
Solution:
Use sudo().
opw-2959627
closesodoo/odoo#99736
X-original-commit: fab2bd4428dcfec26b644351951f0855ad98fcd9
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@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 changes the activities that are displayed on the project update.
(Both in the table of the project update form view and on the right panel in project update)
Specifically it reduces the sale order items to only the ones that are directly
related to the project (the project itself or its tasks)
A test was modified in order to accomodate the change.
closesodoo/odoo#97985
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, when the `Milestones` feature is disable, the user
can always defined a service product with invoice policy equals to
'Based on Milestones' but since the feature is disabled he cannot add
this product on a milestone and so this configuratiom is useless without
the feature.
This commit removes the item into the invoice_policy field Selection
when the feature is disabled. Moreover, when the feature is disabled,
the existing products with this setting should be updated to be a
service product with `invoice_policy='delivered_manual'`. The quantity
delivered method of the existing SOLs containing those products should
also be updated to allow the user to manually edit the quantity
delivered of those SOLs when the `Milestones` feature is disabled.
However, when the `Milestones` feature is enabled again, only the
products contained in SOL linked to a milestone will be updated because
we cannot assume all service products with
`invoice_policy='delivered_manual'` were a service products with invoice
policy based on Milestones. Also the existing SOLs containing the
products updated will not be updated too to not impact the quantity
delivered.
task-2829542
Before this commit, the compute of `sale_line_id` field searches a SOL
to set to each task containing in `self` as default value for
`sale_line_id`. If no SOL is found in the parent task or the project set
into the task then no SOL will set. Since a milestone can be set to a
task and a milestone can have a SOL set in its model, the task could
have the one of the milestone if no SOL is found.
This commit sets the SOL from the milestone to the task if no SOL is
found in the project or the parent task related to that task.
task-2829542
Before this commit, when a SO linked to the project contained a section
or a note in its Sales Order Items, the `Sales` section displayed in the
project update view displays those Sales Order Items even if there is no
product set and so the UoM will be False for those Sales Order Items.
This commit adds a condition in the domain to exclude the `Section` and
`Note` Sales Order Items in the `Sales` section displayed in the project
update view.
task-2849122
closesodoo/odoo#91035
X-original-commit: 0eaafbe4e56fd9728ce17a58e2dd3b91abd44359
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
X-original-commit: 659ee179e1beed962026e3abac1bda322c2ac964
[FIX] account,*: Ensure tests using TestInvoicingCommon runs
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
closesodoo/odoo#90242
X-original-commit: ec36b403edda3fbe3b5bd5f30f31ef6bad680967
Related: odoo/enterprise#26791
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the order of rows shown in costs and revenues is not
fixed and depends on the order of the modules.
This commit adds a sequence on each row and then sort the rows to fix
the order of those rows.
task-2710808
Before this commit, the materials row displayed in the revenues of the
project profitability in the right side panel shows only the result of
all SOLs containing a material product. The user cannot see which SOLs
give that result.
This commit adds an action to see all SOLs related to that row. If the
user has access to the Sales app then the name in that row (that is,
'Material') will be clickable to redirect the user to the view of SOLs
found for that row.
task-2710808
This commit completly reviews the Sales section. This section will
display all Sales Order Items linked to the current project shown
instead of displaying the sold section with the total sold section.
This section will shown the name and ordered, delivered and
invoiced quantities for each Sales Order Item related.
The name displayed in this section will be clickable if the product linked to
the Sales Order Item is a service one and if there is at least one
timesheet linked.
Finally, this commit also moves the Sales section initially defined in
sale_timesheet module into the `sale_project` one.
task-2710808
Steps :
Install Sales, Project and Inventory.
Create a Storable Product.
Create a SO with this product, but do not confirm it.
Change this product :
> Type : Service
> Sales > Service Tracking : Create a task in SO's project
Confirm the SO.
Issue :
Neither a delivery or a task is created.
Cause :
Confirming the SO calls SO._timesheet_service_generation(),
which filtered its SOLs based on is_service to 'create on order'.
As this field is not updated when changing the type of the product,
the SOL with the service is filtered out.
Fix :
Update SOL_.is_service when changing SOL.product_id.type.
opw-2786655
closesodoo/odoo#87308
X-original-commit: f1518e8c9a6c7819a0d7f72a524c189cd9de5fc6
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, when we need to get all SOL linked to the project.
That is the SOL linked to the project and also the SOL linked to all
tasks of this project.
Technically, a fetch is made to get the SOL of the project, a fetch to
get all tasks of the project and then a fetch to get the SOL linked to
all tasks fetched, finally the union is made to avoid having duplicate
sale order items in the recordset
(`self.sale_line_id | self.tasks.sale_line_id`).
This way could be a performance issue if the project contained many
active tasks and so the project update could take more and more time to
compute the sold items shown in the right side panel of project update
view.
This commit does a query builder to fetch the SOLs linked to the project
and its active tasks to avoid doing the prefetchs.
part of task-2710808
closesodoo/odoo#85660
X-original-commit: 0734f4e
Related: odoo/enterprise#24918
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, a service can be configured to be invoiced on milestones.
This means that the user has to manually update the delivered quantity on the SO in order to invoice it.
We now also have the notion of milestones in the project module.
It would be nice to have a link in between the milestone and the corresponding SOL, so that the delivered quantity is automatically updated when the milestone is reached.
This would help the users save time, limit the risk of error and reduce the confusion of having unrelated milestones at two different places.
To this end, this commit adds a new "milestones" invoice policy that computes the delivered quantity of a SOL based on the milestones that have been reached, and renames the previous "milestones" policy into "manual".
Task-2558889
Closes https://github.com/odoo/odoo/pull/81684closesodoo/odoo#81684
Related: odoo/upgrade#3265
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.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
Purpose
=======
During the development of the task #2169100, it appeared that the synchronisation
of a task's partner_id according to its project's partner_id and its parent's
partner_id was not very clear.
A first idea was to simplify the partner_id management: as it could be annoying
for the customer to see all the task's partner_id overriden after project's
partner_id modification, the idea was to just use the parent's parnter_id or the
project's partner_id as default value of the task's partner_id. Then, if the
partner_id of the project or of the parent is changed, there is no more impact
on the task partner_id itself.
The main problem of this solution is that the management of the task's partner_id
is also extended in several others modules like sale_project and sale_timesheet.
You can find below what seems to happen with all these task partners.
Start following rules according to which module is installed.
(for the record: sale_timesheet depends on sale_project which depends on project).
Rules are applied in the order they are written.
Rules labelled "O" only apply when changing the project through the task form view.
Rules labelled "C" apply everywhere.
technical: C=compute, O=onchange
project
C.1 If parent's partner changes and the partner is not set, then set the parent's
partner
C.2 Else if project's partner changes ant the partner is not set, then set the
project's partner
sale_project [+ project]
C.1 If the project's sale order line's partner changes and the partner is not set,
then set the project's sale order line's partner
C.2 Else apply (project.C) rules
sale_timesheet + [sale_project + project]
C.1 Apply (sale_project.C) rules
O.1 If the project is billed "At Project rate" or "At Employee Rate" and the
partner is not set, then set the project's sale order's partner
the sale order line's partner
Specification
=============
- If the partner changes, we ignore all current tasks and let them be. We set the
new partner as default value on all new tasks. In detail, we have done
this:
- When the user creates a task give the customer of the default project or the
task parent as default customer for the task.
- When the user changes the project and no partner in the task, we take the
partner of the new project (if this project has a customer).
- When the user changes the customer of the project, the linked tasks are not
impacted by this changes, even if some tasks have not a customer yet.
- When the user changes the customerf of the parent task, the child tasks are
not impacted by this changes, event if these tasks have not a customer yet.
- remove the onchange rule to remain consistent.
TaskID: 2232042
closes#51471
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Purpose
=======
If the user doesn't have the timesheets app, it is not possible to generate
a task from an SOL. However, the user may want to generate a task without
necessarily timesheeting on it (e.g. a task in Field Service).
Specification
=============
Move the feature to a new module sale_project, sale_timesheet becomes
dependent on it.
Task-2123707
closes odoo/odoo#40594
Closes: #40594
Related: odoo/enterprise#6851
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Audric Onockx (auon)