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>
-* = sale_timesheet, sale_project
Issue:
Currently, the fields and description are not appeared in the full width in the
project setting.
Technical description:
Currently, the content does not appear in full row because col-lg-6 is given in the
settings component. Other col-lg-6 is empty.So in this commit we have shown content in
full row.
task-3183771
closesodoo/odoo#114405
Related: odoo/enterprise#37802
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>
Current behaviour:
Sale Order Items on a task shows only SO related to the current
customer, or all SO if there is no customer on the task.
Expected behaviour:
If we have a customer on the task, show also SOs from child contact
of that customer (mirror the SO count in `Contacts` app)
Steps to reproduce:
- Install Contacts, Sales, Field Services
- Create 4 contacts, a company, with child contact A and B, a
contact C who is child of A
- For each contact create an SO and confirm a field service product
- Now on any task, add the company as customer.
- In the Sale Order Item we can't select any of the SOs from the
child contacts of the company.
Reason for the problem:
Since 41116c81cd where we wanted to
show all SOs when no `partner_id` was set on the task, we made use
of `=?` operator which is `True` when there is no `partner_id`, but
it matched only for `=` when it's not the case, not taking into
account `child_of` of said contact.
Fix:
Extend the domain with an `OR` to take child contacts if the
`partner_id` is not `False`.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3374191
closesodoo/odoo#126898
X-original-commit: 027ba2e682ba046459fc60a76e59792fa6bbeda9
Related: odoo/enterprise#43395
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>
Current behaviour:
Any product type of product that is sellable can add
`service_tracking` option on the product.
Expected behaviour:
`service_tracking` should be available only for services that are
sellable.
Steps to reproduce:
- Install `sale_project`
- Create a new product, type `consu`
- Observe we have the `service_tracking` option available (create
project/task/project&task on SO confirmation)
Reason for the problem:
Incorrect domain for the `service_tracking` field in the view.
Fix:
Correct domain for the field. The field should be `invisible` only
when the product `type` is not a service *or* it's not sellable.
Affected versions:
- saas-16.3
- master
opw-3366909
closesodoo/odoo#126750
X-original-commit: 1634019df17d25167bad091933d757f706f7549b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
The following changes are made in this PR:
- sort projects by favorite > sequence > name for project
- add the 'tasks' stat button for project form view
- when creating a project on the fly from a task's form view, allow_billable
should be set to true by default
- Display only the colored dot, hide the status label for project list view
- remove following fields from project
allow_recurring_tasks
task-3251656
closesodoo/odoo#119154
Related: odoo/upgrade#4569
Related: odoo/enterprise#40050
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit SOL field on task visible when user no
sale access and field is set but SOL field is readonly when
user has no sale access there is not point showing readonly
empty field.
This commit hide SOL field when user has no sale access and
field is not set.
task-3186438
closesodoo/odoo#115474
Related: odoo/enterprise#38186
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
New features developed in this PR:
- Write Javascript tests for the project.task.state widget
- Tests are in the project_task_state_selection.js
- rewrite Research & Development demo data
- Created a digest tip for task state selection (in Settings > technical > digest tips)
- Tip: Use task state to keep track of the task progression
- Fix Sharingview (Readonly) icons for the project.task.state widget, previously only the color bubble were displayed in readonly sharing views, now all of the icons are displayed
- Display state in the Calendar view
- Display the same widget as in the kanban/list views
- Remove is_closed References
- Adapt Kanban stages Exemples
- Kanban exemples are available when creating a new stage in kanban view
- improve Progressbar colors (different color for approved/done, in_progress/waiting)
Task-3213526
closesodoo/odoo#117968
Related: odoo/enterprise#39714
Related: odoo/upgrade#4548
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the user set a subtask and wants to directly
set the SOL of that subtask in the subtree view of a task form view. He
cannot because the field is in readonly.
This commit makes the field editable if the user has access to Sales app
as it is the case for the SOL field in the form view of task.
task-3336215
closesodoo/odoo#124563
X-original-commit: 0373abdf24e1139706e6d7610873cc89ada60e74
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>
Current behaviour:
All sold services in another currency than the companie's one are not
being converted in the project profitability, but the currency
symbol is correctly set to the one of the project. (related to company)
Expected behaviour:
Sold services in another currency should be converted in the project
profitability.
Steps to reproduce:
- Install Sales, Accounting, Project, and a localization (ex: Sweden)
- Switch to the Swedish company.
- Settings:
- Activate analytic accounts
- Make sure the company currency is SEK
- Update the conversions rates of the currencies
- In products: create a new service (ex: $100)
- Create a new project (make sure it creates an analytic account)
- Sell 1 unit of that service, make sure the pricelist before adding
the line is "USD Public pricelist" (so the line should be $100),
add the analytic account to the line. Confirm the SO.
- Add a task in the project, and add the SO as ref to it.
- Go to the project profitability panel, observe that the value of
the service we just sold is 100 kr (the value of $100, but with
the symbol for SEK kr).
Reason for the problem:
Lack of currency conversion for services when computing the
profitability items for the project update panel.
Fix:
Similar fix to 68b4ea69c173dd5894bcb42b99e6818f241f9734, but in that
fix we missed the conversion for revenues coming from analytic
accounts (aka services).
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3274626
closesodoo/odoo#123527
X-original-commit: bf8766b4c15946adac9e2e16a31f11df54cb30f8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The purpose of this PR is to improve the generic usage of the project app.
So in this PR done following changes:
- switched Sales Orders button and planning, document button from their place in
the project kanban card burger menu
- In milestone form view added decoration-danger on quantity % if it is equal
to 0 and there is an SOL set
- On milestone creation the SOL of the project set default if it is of
milestone type
- In the product form view Uom is set as 'hours' if the service is either
prepaid or invoiced based on timesheets.
- In project.milestone list view changed quantity_percentage label to
to Quantity(%).
- Added product_uom_qty field in project.milestone list view .
- In project.sharing improved remaining hours widget now only the frame is
displayed in orange/red, not the background (as in the back-end)
- project.update right-side panel added the ref of the SO in the nameget
of the SOL
- In project.update right-side panel added Confirmation when trying to delete
a milestone
- Reduced the size of project and task sharing wizard
task-2989828
closesodoo/odoo#106284
Related: odoo/upgrade#4198
Related: odoo/enterprise#34322
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
- When a project is created on SO confirmation,
the new project (assuming there is no project template
set on the product) is added with one stage with name=New
- When portal users drag & drop columns from the kanban view
of project.task, an access rights error is displayed.
After this commit:
- When a project is created on SO confirmation,
set the following stages for the new project
(assuming there is no project template set on the product):
to do - in progress - done (folded) - canceled (folded).
- Disable dragging and dropping project tasks for portal
user.
task-2929871
closesodoo/odoo#97220
Related: odoo/enterprise#29911
Signed-off-by: Xavier Bol (xbo) <xbo@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>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the multi-company context, it is possible to create
an analytic account without a defined company.
The result is that the analytic account
will not have a currency.
A traceback will be triggered when calculating the
profitability of a project
(for example by changing its status when
the 'sale_timesheet' module is installed).
Solution:
Use the currency of the project.
Introduced by:
68b4ea69c173dd5894bcb42b99e6818f241f9734
opw-3292417
closesodoo/odoo#121143
X-original-commit: 90512da68f776459a8a65bed285f5a178f9dd77d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@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>
Current behaviour:
In the project update section, if the project has only draft
invoices linked to the analytic account of the project, the invoices
smart button isn't present. But once we have at least 1 posted
invoice, the button is shown, and when triggering the action, we see
both the posted invoice and all the draft invoices that were not
shown previously.
Expected behaviour:
The button should be visible, even if the only invoices linked to
the analytic account of the project are only in draft.
Steps to reproduce:
- Install Project, Sales, Accounting
- Activate Analytic Accounting in the Settings
- Create a Project and make sure it has an analytic account linked to it
- Create a new invoice in draft, make sure on the line you have set
the analytic account of the project we just created. Save.
- Go to the project update page, there is no smart button that will
go to the invoice we just created.
Reason for the problem:
The Invoices smart button is shown only when the `invoice_count` is > 0.
`invoice_count` is a related field to the same field name of the
analytic account, which is a compute. In that compute we explicitly
only take invoices that are posted, since in the context of an
analytic account, it only makes sense to take actually posted
invoices, since those are real revenues. So the button is shown only
when we have at least 1 posted invoice. The action itself is just
fetching all the `in_invoice, out_refund` invoices that are linked to
this analytic account.
Fix:
Transform the `invoice_count` in `sale_project` module from a
related to a regular compute and do a query with the same heuristics
for the action of the invoice smart button.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3227421
closesodoo/odoo#119578
X-original-commit: 1b45e22530cb07ca437d2fd53bda3af2c918c223
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit have consistent list views between
project.task and the sub-tasks / blocked by o2m so that when
a change is done in one place it also impacts the other
places.
So, in this commit add/update sub-task and blocked by page list
views to make them identical.
task-3165202
closesodoo/odoo#112620
Related: odoo/enterprise#37055
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit to avoid having a default group by that
would impact all views without distinction by using the new
attribute that was recently introduced for the list view.
So this commit add group the kanban and list views by stage by
using an attribute on list and kanban view instead of a default
group by in action.
task-3165202
Part-of: odoo/odoo#112620
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this PR to do generic improvement.
So in this PR done following improvements:
- add context in partner fields in various places to display
customer partner first in selection of partner field.
task-3099758
closesodoo/odoo#107913
Related: odoo/enterprise#34950
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>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- adding a label 'last update' to the stat button in project form view.
- indicate 'my project' in the tab instead of 'project sharing view in portal' in project sharing.
- set the first non-folded stage of the project as default on newly created tasks.
- remove user confirming the SO as the default project manager.
- hide fields service_tracking, service_upsell_threshold if sale_ok is false.
- set purchase_method to purchase by default if product is of service type.
- remove the : next to the totals labels and decrease the font-size for values of 'total hours'
and 'remaining hours' in timesheets notebook in project task form view.
task-2897867
closesodoo/odoo#96548
Related: odoo/enterprise#29774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Manisha Tulsiyani <matu@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>
Purpose:
- Improve some generic UX of project app.
Specification:
- make milestone field option hide in task tree view.
- set default 'Tasks' to label_tasks field on creation when
label_tasks field is empty.
- order stat buttons of project update right side panel
according to user usage.
- hide project field for list, calendar, graph and activity
view of act_project_project_2_project_task_all action.
- archive task ratings template when ratings is disabled and
unarchive that template when its not.
task-3083855
closesodoo/odoo#107467
Related: odoo/enterprise#34778
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
We created an index in the mixin, but the `init` was never called
as there was a missing `super` in `account_move_line`.
We also remove the index in `sales_project`, as it now is done in
the mixin (and we don't want different names for it).
closesodoo/odoo#115948
X-original-commit: 98a556031180cf72680b4f082a5c5d7b491742b7
Signed-off-by: William André (wan) <wan@odoo.com>
*=hr_timesheet,project,sale_project,sale_timesheet
Currently, the configuration of the recurrence is quite complete
and allows a lot of flexibility, but it is costly
in terms of implementation as it requires a lot of fields.
The goal of this task is thus to simplify this implementation.
In addition, a lot of people are complaining
that tasks are only generated when the recurrence date is reached,
as it doesn't allow to anticipate the planning of field service tasks.
In this task, we are thus going to immediately generate a new task
once the previous one is marked as done.
Concretely, we:
- describe a recurrence in terms of
"once every n day/week/month/year for ever/until a date"
and delete all fields that don't fit into it.
- remove the cron. The new occurrence is created when
marking the last task as done, and copied from the latter.
Deleting the last task deletes the recurrence.
The recurrence fields stay useful, as they form a delta t
that will be added to deadline/planned dates fields to get the new
values.
- use an boolean icon button to activate recurrence,
and place it at the end of deadline field's line.
The recurrence fields appear on the next line.
- delete in the form: the div explaining when the next tasks will be
created and the header to choose how to save the changes in the
recurrence.
task-3084945
closesodoo/odoo#112764
Related: odoo/upgrade#4343
Related: odoo/enterprise#37114
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
Down payments are taking into account in the project profitability in
the section "Other Cost". When invoicing fully an SO, the total sum
in profitability is the sum of the invoiced amount on the SO + the
down payment.
Expected behaviour:
Down payments should not be present in the project profitability, to
avoid incorrect sums.
Steps to reproduce:
- Install Sales, Accounting, Timesheets
- Activate Analytics in the Settings
- Set a Service Product that is invoiced based on fixed price
- Make sure that it generates a Project + Task
- Create a Quotation, confirm the SO with that product
- Create a down payment for 50% of the SO
- Confirm that invoice
- Create another invoice for the SO for the rest of the SO and
confirm it
- Go to the project's profitability tab for the SO, you can see that
we have the value of the SO + the amount of the down payment,
leading to an incorrect sum, in the section Invoiced.
Reason for the problem:
When taking the invoices for the profitability of the project, since
a down payment is another `sale.order.line`, we handle it in the
method `_get_revenues_items_from_invoices`, and there we are taking
into account the down payments.
Fix:
Elaborate the domain used to fetch the invoices in
`_get_revenues_items_from_invoices_domain` to not take those that
are down payments.
Affected versions:
- 16.0
- saas-16.1
- master
opw-3195016
closesodoo/odoo#115050
X-original-commit: ae151ec16a0054420f5c2827a1924c87e5b672ba
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
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>
issue: When creating a sale order, with a service that involves the creation of a project, with analytic accounting activated, the default analytic account is not the default one set in the settings of the Project app.
Steps to reproduce the issue :
- activate analytic accounting in the Accounting app.
- in the settings of the Project app, set the default analytic plan to any value but the first one.
- create a product in the Sale app, with a product type 'Service', that involves the creation of a 'Project'.
- create a sale order with the product
- go in the analytic accounting menu in Accounting app
-> the analytic plan is not the one set by default in the settings of the Project app.
closesodoo/odoo#114302
Task: 3169483
X-original-commit: e801b3fa1bbc31713375cc669c6d47b32b175f53
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
Before this commit, when the user wants to see the project.update of a
project billable to see the project profitability, the project
profitability could take more 20 seconds to be loaded because of a
search on account.move.line to get the others revenues (that is, the
invoices manually created without any SO linked) for which the AA of
those invoices are the one of the project. The problem is the AA of a
account.move.line is stored as key in a JSON field called
`analytic_distribution` and so the fetch of related
`account.move.line` could be slower when there are many records
in the `account_move_line` table.
This commit adds a new index on `account.move.line` to spped up the
search in `analytic_distribution` field. By doing that, the project
update is loaded in less than 2sec instead of 15-20sec.
closesodoo/odoo#114301
X-original-commit: a0b608c3a45ca33bcd535cfb4b1c73b73fa17317
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: SEINLET Nicolas <nse@odoo.com>
Steps to reproduce:
- create a project with an analytic account;
- create sale orders/invoices and purchase order/bills for a project;
- use other currencies;
- go to the "Project Updates".
Issue:
The amounts are used without being converted
into the currency of the analytic account.
Solution:
Convert amounts used in the currency of the analytic account.
Note:
For performance reasons, it is acceptable to fetch all currency
on the same date to get the conversion rate.
In this case, today's date is the most appropriate
(as the project is in progress).
opw-3193676
closesodoo/odoo#113684
X-original-commit: 68b4ea69c173dd5894bcb42b99e6818f241f9734
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>
Since https://github.com/odoo/odoo/pull/106015, we override a few project actions in `sale_project` to add a context key
allowing to search SOLs by their partner's name. However, this override is not taking the existing context from project
into account and removes it.
This commit restores that context by adding it in the action overrides.
closesodoo/odoo#111789
X-original-commit: 391152f53fe499aa41d4f4fef35c4462f0c1cce5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Vincent Larcin