These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
In this commit, we show a helper message in case there
are no records to show under those section (milestone, profitability,
sales section) in project right side panel.
task-3293012
closesodoo/odoo#128220
Related: odoo/enterprise#43972
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
1. Purpose: be consistent with the information indicated in the
description of the form view + add a way for users to analyze the margin
of their project is relative terms
- updates right-side panel > display the margin % under the margin
- apply the same color code and visibility conditions as for the margin
- The margin section is visible only if there are revenues and costs for
the current project.
2. Purpose: currently, SOLs and associated revenues are only taken into
account in the project updates right-side panel when it is set either on
the project, its tasks or its timesheets. This was designed this way to
manage the use-case where the AA of the project would be linked to
multiple projects. We wanted to avoid duplicate information.However, in
practice, it seems that the current behavior is confusing and is
generating a lot of questions from customers (according to our
colleagues at the support and the PS). IMO, the use-case where an AA
would be shared with multiple projects is not very common and we should
privilege the basic use-case.In addition, even if we have duplicate
information in case of a shared AA, it is still possible to have the
detail per project from the accounting app by setting a corresponding
analytic distribution.
- SOLs and associated revenues should be taken into account in the
project updates right-side panel if their SO share the same analytic
account as the project, regardless if the SOLs are set on the
projects, its tasks or timesheets, or not.
task-3330274
closesodoo/odoo#128439
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
_*: 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>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit allows creating SOLs on the fly from various places:
- Project employee mapping list view
- Project from view
- Task form view
Task-3278895
This commit adds a "Sales Order Line" stat button in project updates to easily search among the SOLs of a project
and be able to create new ones.
Task-3278895
This commit adds a "Sales Order" stat button in the project form view to ease the creation of a SO from a project.
This stat button is displayed if the project is billable and has a partner.
Task-3278895
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>
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>
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
New features developed in this PR:
- Write Javascript tests for the project.task.state widget
- Tests are in the project_task_state_selection.js
- rewrite Research & Development demo data
- Created a digest tip for task state selection (in Settings > technical > digest tips)
- Tip: Use task state to keep track of the task progression
- Fix Sharingview (Readonly) icons for the project.task.state widget, previously only the color bubble were displayed in readonly sharing views, now all of the icons are displayed
- Display state in the Calendar view
- Display the same widget as in the kanban/list views
- Remove is_closed References
- Adapt Kanban stages Exemples
- Kanban exemples are available when creating a new stage in kanban view
- improve Progressbar colors (different color for approved/done, in_progress/waiting)
Task-3213526
closesodoo/odoo#117968
Related: odoo/enterprise#39714
Related: odoo/upgrade#4548
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
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>
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>
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>
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>
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>
Current behaviour:
When selling a recurrent service with fixed/prepaid invoicing, it
appears two times in the project profitability report, once as
"Fixed/Prepaid" Service, another time as a "Subscription".
Expected behaviour:
Such service should only be present in the "Subscription" section.
Steps to reproduce:
- Install Sales, Project, Subscription
- Create a Service that is invoiced "Fixed/Prepaid", creates a new
project on creation
- Create a new SO with that product, confirm it.
- Go to the Project's Update of the newly created project
- Observe that the services was accounted 2 times, onces in the
"Fixed/Prepaid" section, another time in the "Subscription".
Reason for the problem:
When calculating the profitability from "Fixed/Prepaid" services,
we ignore the fact if they are a subscription or not.
Fix:
Extend the domain to not take subscription into account when
generating the profitability items that are prepaid services.
Affected versions:
- 16.0
- master
opw-3113320
closesodoo/odoo#110074
X-original-commit: 840a867c5e3da818b3d7f8dd8d4f25c851536057
Related: odoo/enterprise#35877
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
- Impacted modules:
- sale_service (new module - installed only if sale
AND (project OR planning) are installed)
- sale
- sale_project
- Description: When looking for a SOL in services apps, the displayed
name is of the form "SO ref - SOL name - unit price (partner
ref/name)". The presence of some of those elements may vary:
- unit price is only displayed if it allows to clarify an
ambiguity (i.e. two SOL with identical name but different unit
price in the same SO).
- partner name is only used if the partner ref does not exist.
- partner name/ref is hidden in the name of planning slots to avoid
duplicates.
- Implementation: The behavior currently existing in sale needed to be
extended for services apps. This has been done with the following
changes:
- sale:
- sale.order.line: Current behavior for the name_get (display
partner ref) has been extended (display parnter name if has no
ref) and split a additional method that is extended in a new
module called..
- .. sale_service:
- sale.order.line: The additional behavior is extended to
display the unit price of the SOL when it avoids ambiguity. A
context parameter is used to keep this behavior inside
services apps.
task-3052812
Part-of: odoo/odoo#105470
*=hr_timesheet,sale_project,sale_timesheet,spreadsheet_dashboard_hr_timesheet
The main goal of this PR is to minimize code duplication for the search and list views for tasks and projects.
Task search views
-----------------
The most important change was to merge the search views used in the task reports with the "normal" corresponding search view. The reporting search view should now be almost identical to the normal one in both project and fsm.
The `project.task`/`project.task.user` search views are now following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
┌──┤4│ │7├──┐
│ └┬┘ └┬┘ │
│ │ │ │
┌▼┐ ┌▼┐ ┌▼┐ ┌▼┐
│5│ │6│ │8│ │9│
└─┘ └─┘ └─┘ └─┘
```
1. `view_task_search_form_base`: Base search view containing all the fields/filters common to project, project sharing and fsm
2. `project_sharing_project_task_view_search`: Search view for project sharing.
3. `view_task_search_form_project_fsm_base`: Base search view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_search_form_project_base`: Base search view for project only, with fields/filter common to the normal search view and the one used in reporting.
5. `view_task_search_form`: Search view for project.
6. `view_task_project_user_search`: Search view for the project report.
7. `project_task_view_search_fsm_base`: Base search view for fsm only, with fields/filter common to the normal search view and the one used in reporting.
8. `project_task_view_search_fsm`: Search view for fsm.
9. `report_project_task_user_fsm_view_search`: Search view for the project report.
With this organization, we can easily add a field to both fsm and project at once, and even to project sharing at the same time. Since the goal is to keep the reproting search views identical to the normal ones, it'll also add the field to both of them.
Task list views
---------------
Similarly to the search views, the task list views were also refactored to minimize code duplication, following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
│4│ │5│
└─┘ └─┘
```
1. `project_task_view_tree_main_base`: Base list view containing all the fields/filters common to project, project sharing and fsm.
2. `project_sharing_project_task_view_tree`: List view for project sharing.
3. `project_task_view_tree_base`: Base list view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_tree2`: List view for project
5. `project_task_view_list_fsm`: List view for fsm.
Project views
-----------------
The search and list views for projects in fsm now inherit the ones from project, since our goal moving forward will be to keep those as similar as possible.
Other changes
-----------------
- Merged and removed many filters/fields from the task search views.
- Changed `total_hours_spent` and ` subtask_effective_hours` labels in `project.task` model to avoid changing them manually in many views.
- Renamed `state` into `kanban_state`, `hours_planned` into `planned_hours` and `hours_effective` into `effective_hours` in `report.project.task.user` to make it consistent with `project.task` (so we can keep the same views for both of those models).
- Moved the sale line filed in the "Settings" tab in the project form view (so that the `sale_line_employee_ids` field in "Invoicing" takes the full width).
---
Enterprise: https://github.com/odoo/enterprise/pull/34106
Upgrade: https://github.com/odoo/upgrade/pull/4216
Task-2746370
closesodoo/odoo#106015
Related: odoo/upgrade#4216
Related: odoo/enterprise#34106
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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
Before this commit, the values of selection `service_policy` field are
given with a function and so the choices are dynamically given according
to the modules installed and the project settings. The problem is the
string for those values are not translated because the ORM cannot do
it automatically since the values are dynamically given and so
those string should be translated with `_` function.
This commit translates the string of those values with `_` function to
be sure the strings are translated in the language of the current user.
closesodoo/odoo#108154
X-original-commit: 90cf43789d849df3908f4636228cb643a005427f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Gorash