Steps:
- Create a contact with 2 sub contacts Sub1 and Sub2.
- Create a service product with project creation on order.
- Create a quotation for Sub1 and the created product and confirm.
- Go to the created project and create a task.
- Edit the task and change the customer to Sub2.
- Empty the sale order item.
Issue:
The sale order doesn't appear in the drop list.
Cause:
Wrong domain on ``ProjectTask.sale_line_id``.
opw-3441194
closesodoo/odoo#139670
X-original-commit: 8b6bd8c92402a92efed71f97de61eaeffb0caea7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose
=======
Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts
| Country | Product Type |
| ------- | ------------ |
| BE | Drinks |
| LU | Food |
And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg
We want to be able to display the following pivot tables:
| | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE | 1000 | 2000 | 3000 |
| LU | 0 | 3000 | 3000 |
| Tot | 1000 | 5000 | 6000 |
| | Total |
| ------ | ----- |
| Food | 5000 |
| * BE | 2000 |
| * LU | 3000 |
| Drinks | 1000 |
| * BE | 1000 |
| Total | 6000 |
Implementation
==============
* `ir.fields` are added/removed dynamically on `account.analytic.line`
* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
meaning that all the companies have access to all the plans. This
means that the applicability fields and lines are now company
dependent, and those can be used to know which fields/plans to display
for which company.
* There can no longer be one "Project" plan per company, even if the
accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
which is `_get_plan_columns`
task-3497653
closesodoo/odoo#139225
Related: odoo/upgrade#5306
Related: odoo/enterprise#49226
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william <wan@odoo.com>
Co-authored-by: h4818 <ayh@odoo.com>
Since it is cached by the ORM (see parent commit), there is no need to
manage the caching in the business code anymore.
In most cases in addition to making the code shorter, it also makes it
more readable by making the direction of the rate more obvious with the
use of the `to_currency` parameter.
closesodoo/odoo#137609
Signed-off-by: Raphael Collet <rco@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue:
Reading on the field `tasks_ids` of the `sale.order` model in some
context can be slow, leading to really slow creation and duplication
of tasks on a medium sized database.
Analysis:
After creation of a task, when the ORM flushes the model, it
recomputes all the inverse dependencies that needs to be recomputed.
Currently `task_ids` doesn't implement a `search` routine on the
field, so `task_ids` needs to be recomputed for *all* sales orders,
since we don't know which sales order needs computation. So for
*all* sales orders, we trigger the compute `_compute_tasks_ids`,
which is badly implemented using the general performance anti-pattern
```py
for record in records:
field = self.env['model'].search(domain)
```
which makes 1 query per record that we are computing.
Solution:
Correct the implementation of `_compute_tasks_ids`, which now uses a
`_read_group` instead so we do 1 query for the whole recordset.
And implement the `search` on the non-stored `tasks_ids` field,
which speeds up the context of re-computations. This allows the ORM
to know for which sales order the field `task_ids` needs re-computation.
Results:
In the context a mid-size database (less than 10k records for the
concerned models)
Task creation/duplication:
| | Before | After |
|-------------|--------|-------|
| Time | 1 min | 1 sec |
| Query count | 40k | 300 |
Reference:
opw-3445565
closesodoo/odoo#138007
X-original-commit: 81ae499ce975a96c12b6e379581ba40167d025db
Related: odoo/enterprise#48610
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit when we confirm SO then create project button appears
In this commit we have made that if product is based on timesheets or
based on milestones then only create project button will appear when we confirm SO
task-3468706
closesodoo/odoo#133410
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the case where we have multiple projects, we also want to filter on
tasks linked to the SO. In the current implmementation, the default sale
order passed in the context is used to filter by name which results in
including tasks where name of the SO contains the name of the SO instead
of being equal.
opw-3499181
closesodoo/odoo#136895
X-original-commit: f24dc0b681db398755dcd5656c707273d3d72ef4
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
This commit improves the visual indication of company dependent fields.
add icon of 'fa fa-building' on side of fields label.
task-3186717
closesodoo/odoo#130163
Related: odoo/enterprise#44830
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
- There is a bug in odoo enterprise.
project.project form view > invoicing notebook > services created using create and edit
should be configured by default with an 'invoicing policy' set to 'based on timesheets'.
Technically, while we're using 'default_service_policy' with the right value, we're
getting a different value in the form.
After this commit:
- The bug is fixed.
closesodoo/odoo#134552
X-original-commit: 6bb68d9f3263c2154eb87ec22559d142e880c084
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Abderraouf Ghrissi (abgh) <abgh@odoo.com>
Steps:
- Install project & sales app
- Open project app
- Open Project
- Select any project
- Add sale order item
Issue:
- - the creation of SOLs on the fly , doesn't seem to be working anymore
Cause:
- There is no option for creating new sale order item
Fix:
- Appear create and edit the option for creation of Sale order item
Task: 3470877
closesodoo/odoo#134566
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ritika Shekhawat (rish) <rish@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Before this commit, the group by in the gantt view of project didn't
allow the user to find records for which there were not scheduled tasks.
For example, if a Sale Order didn't have a scheduled task, when grouping
by Sale Order, the latter was not displayed. And searching for its name
was not displaying it either.
After this commit, when a user is searching for a sale order, even if
the latter does not have any scheduled task, it is displayed in order to
facilitate the scheduling of new tasks.
In order to do so, a group expand on sale_order_id for the project.task
model have been introduced.
closesodoo/odoo#121819
Taskid: 3251630
Related: odoo/enterprise#41257
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
In project profitability, `account.move.line` from invoices without
the corresponding sales order with negative amounts where not taking
into account for the computation of the profit margins.
Steps to reproduce:
- Install Sales, Accounting, Project, Inventory
- Create 3 products:
- 1 service (S1), fixed price, creates project on confirm
- 1 service (S2), fixed price, creates nothing
- 1 storable (P), a lot of quantity on hand, invoiced when delivered
- Create an SO with SOL:
- S1 with price 0 (1 qty)
- S2 with price -320 (1 qty)
- P with price 320 (1 qty)
- Confirm SO, deliver P, create invoice
- Confirm invoice > Duplicate > confirm
- Go to the proj.profitability of the SO, notice that the negative
lines were not taken into account, leading to the addition of the
"Other Revenues" section with a positive 320 margin.
Cause:
The domain for the `account.move.line` was excluding lines whos
subtotal was not > 0.
Fix:
Change that domain leaf to be != 0.
Affected versions:
16.0 up to master
Reference:
opw-3389670
closesodoo/odoo#133597
X-original-commit: fc327869651158aee2ca01760606a36a464fa7b6
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description of the issue/feature this PR addresses:
In the sales module, when creating a new product, it is important to ensure that
the product type is set to Service and that the invoicing policy is based on
milestones. Additionally, selecting the project field is necessary to ensure
that the product is linked to a specific project. Once the product is linked
to a project, it is important to make sure that there is at least one milestone
available within the project.
Once the above steps are completed, creating a sales order (SO) and adding the
newly created product will allow for the milestone stat button to be available
in the draft state.
Current behavior before PR:
The inclusion of the milestone product triggers the visibility of the stat
button.
Desired behavior after PR is merged:
If the state is draft, the milestone stat button ought not to be visible.
Fix:
Adding a condition prevents the stat button from being displayed when the
the current state is draft
task-3374861
closesodoo/odoo#133025
X-original-commit: 2b046e2c6c1e473f71c638c17c588b5b7fed7173
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
Two services which difference is that one is expensable with an
expense policy different of none, the expensable service is not
included in the project profitability as revenue from a service,
even it's not actually an expense, just a service that "could be"
expensed. The other service which is not marked as "can be expensed"
is correctly computed in the project profitability.
Steps to reproduce:
- Install Project, Accounting, Sales, Expenses
- Settings > activate analytic accounting
- Create a service, invoiced on milestones, creates a project on SO
confirmation, can be expensed with an expense policy of Sales price.
- Create an SO, confirm the SO
- Set the milestone to 50% reached, invoice the SO, post it
- Go to the project profitability of the project, notice there is no
revenue section for the service.
- If you follow these same steps for a service which is not set "can
be expensed", the service is correctly included as revenue from
service billable milestone.
Cause:
When computing the profitability items from services, we first get
the `sale_line_ids` (whose domain excludes the expenses), then we get
the product that are linked to those sale_line_ids, but we exclude
products that have an expense_policy different than 'no'. This
domain may not be necessary, because `sale_line_ids` already exclude
expenses.
Fix:
Remove the particular domain leaf.
Affected versions:
16 up to master
Reference:
opw-3430020
closesodoo/odoo#133307
X-original-commit: ac02616c4d54120defa53e9ef463cdcbab69063b
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Project Sharing subtasks view's notebook, hide the Billable field which is an
read-only field
task-3374861
X-original-commit: 2d932181d6c7d86b26a07d10990b453f7b86a938
Part-of: odoo/odoo#132986
steps:
-install sale module.
-create product with product type as course
-Generate a sale order containing the newly created product.
-link the sale order to any project task, and then attempt to view the tasks
stat button by clicking. However, encounter an unexpected traceback or error
message during this action.
issue:
In the sale module quotation view, the traceback is occurring when clicking on
the tasks stat button
fix:
Improved action_view_task method in sale_order model to handle missing sales
order lines with 'service' products. Set default project ID when no suitable
sales order line is found, preventing errors and ensuring smooth functionality.
Refactor involved using conditional expressions for better readability and
maintaining default behavior.
task-3436556
closesodoo/odoo#132981
X-original-commit: 10838145c0981e46221b2cbf65b2c4ce84c3b8c7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit quantity_percentage field was not editable in list view
Issue:
- when trying to edit quantity field in milestone , it's not editable in list view
Fix
- when trying to edit quantity field in milestone it becomes editable by making
field readonly false
task-3444728
closesodoo/odoo#132958
X-original-commit: 562a454731326a054f8f4c54e8350a2faf1c1c7f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit 'project.task' model 'planned_hours' field
is inconsistent to the 'allocated_hours' field.
After this commit rename the 'planned_hours' to 'allocated_hours'
and related string change to 'Allocated Time'.
task-3231680
closesodoo/odoo#120405
Related: odoo/upgrade#4617
Related: odoo/enterprise#40643
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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
Prior to this commit:
When we open the portal view of the project which is project sharing and search
in a project, we have two different filters for searching sale orders and sale
order item which is unnecessary. Hence we can make the search resourceful by
combining both filters just like the working of sale order filter in the Search
View of the project.
Post this commit:
Combining both filters under the name sale order to make a seamless search.
closesodoo/odoo#131810
Task: 3391908
X-original-commit: fb31cea2aeb666e71f49b4f99813bf592a96d6b2
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
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>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
Before this commit, when `sale_project` module is installed and not
`sale_timesheet` module, `allow_billable` field is displayed in
Settings tab in form view of project but not in the form view
simplified. In the simplified one, `allow_billable` field is only
displayed when `sale_timesheet` is installed.
This commit displays `allow_billable` field in form view simplified
of `project.project` when `sale_project` is installed to be coherent
with the main form view.
closesodoo/odoo#129584
X-original-commit: ae203aa3cccc1187197ff0be98a884ca8ce6d6d1
Related: odoo/enterprise#44566
Related: odoo/upgrade#4975
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the `project_enterprise_tour` has a step to
check `allow_billable` field in project to make the new project
billable to get partner field visible. The problem is this step
cannot be achieved if `sale_project` module is not installed.
This commit moves `project_enterprise_tour` is project module
to easily override it in `sale_project` and `project_enterprise`
modules to be sure the tour works when `sale_project` is not installed
and also when that module is installed.
X-original-commit: f09245f4dae4c3503630c9cd92b9d9ab5bfb6e78
Part-of: odoo/odoo#129584
This commit adapts the spaces and table layouts to maintain concistency
with Milk design.
task-3382174
Part of task-3326263
closesodoo/odoo#129571
X-original-commit: 68611ce40f48c6c8a143a24ac05e9ef72a8f69e4
Related: odoo/enterprise#44558
Signed-off-by: Pierre Paridans (app) <app@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 hides the "Sales Order Line" field on tasks when no customer is set on them.
It doesn't really make sense to have a SOL without a partner, and it eases other flows to be able to assume that a SOL implies that there is a partner.
Task-3278895
This commit moves the "Sales Order Line" field in the project form view from `sale_timesheet` to `sale_project`,
as the field itself is introduced in `sale_project`
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
* = project,timesheet
This commit changes the label when grouping tasks and timesheets by sol in the
portal for records without sol from "No Sales Order Item" to "Not Billed",
which conveys more clearly to the user that the records are not billed.
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>
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>
Louis (wil)