Before this commit, when the project has no SO set in its model and it
has a task with a SO set. When the user clicks on the Sales Order stat
button shown in project form or the project update. He sees a form view
of `sale.order` to create a new record because the action does not give
the id of the Sales Order related. Indeed, we give the id of the SO set
on the project if we found only one SO related to the project.
This commit fixes the issue by given the id of the SO related to allow
the user to see the SO related to the project.
Steps to reproduce:
==================
1) Create a project A with allow_billable set to `True`.
2) Create a Quotation for a customer C with a SOL containing service
product and confirm it to create a SO.
3) Create a task in the project A and set the customer C to this task
and set the SOL of the SO created in the step 2.
4) Go to the project update of the project A
5) Click on the 'x Sales Orders' stat button.
Expected Behaviour:
==================
The user should see the SO related to the project, that is the one
selected in the related task.
Actual Behaviour:
================
The user sees an empty form view of `sale.order` to create a SO because
no SO is found.
Part of task-2710808
Closes#81940closesodoo/odoo#82284
X-original-commit: de702d921a321a8b783af020538ceaf4ef3af10f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the project has a SO related, the 'Sales Order'
stat button is shown in right side panel in project update even if the
allow_billable=False in this project. If `allow_billable=False` then the
project should be non billable and thus this stat button should not be
visible.
This commit hides the stat button when the project is
non billable.
Steps to reproduce:
==================
1) Install sale_timesheet module
2) Create a billable Project
3) Edit the project to set a SOL (Set a customer and a SOL) and save.
4) Edit the project and set `allow_billable` to `False`.
5) Go to the kanban view of the Project Update.
Expected Behaviour:
==================
The 'x Sales Orders' stat button should not be visible.
Actual Behaviour:
================
The 'x Sales Orders' stat button is visible.
Part of task-2710808
Closes#81940
X-original-commit: bc0226583a48f9eefc79c3e2a8e7069d6181f8ea
Part-of: odoo/odoo#82284
-if an analytic tags are inserted on the project, it will be added to the timesheet /invoice
analytic tag.
-In this commit, analytic tags field is added on project in order to gain in
granularity.Those tags are passed to the invoice lines generated from the
project's SO lines.
-set the analytic account and analytic tag of the project by default on its tasks.
-added string 'Analytic Tags' analytic_tag_ids field on task.
closes#78973
task-2667754
Purpose of the commit is to improve the generic UX of task
and project views.
task-2590412
closesodoo/odoo#75509
Related: odoo/enterprise#20423
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Previous implementation was generating an unoptimised query which
lead to unacceptable loading time on large databases.
task-2697814
closesodoo/odoo#80316
X-original-commit: fa1578abea4ebe887d4e23a81bb1011ed986cc0c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this commit to improve generic UX for the project app.
So, In this commit done following changes:
- add 'subtask_effective_hours' and 'total_hours_spent' fields in the page of
subtask in task form view.
- change invisible attrs to column_invisible attrs for block_by page in task
form view.
- add 'task in progress' subtype for project.task and move 'stage changed'
subtype above 'task blocked'.
- remove the 'is_close' field and all its references from project.task.type.
- unarchive all of its tasks when the user unarchives the task stage.
- sort projects on 'is_favorite'.
- internal users following the project automatically follow its updates and
their notification preferences propagated accordingly.
- duplicating a task will duplicate all of its subtasks.
- move parent task field in extra info page of task form view.
- change the label of 'edit' to 'view' in the burger menu of project kanban view.
- user can delete task without sale_order validation error.
- add constraints for 'seller_ids' field.
- add remaining_hours_so field in task tree view.
- add unusual_days in task calendar view.
- add 'no content helper' in action of burndown chart.
task-2536044
closesodoo/odoo#74018
Related: odoo/enterprise#19880
Related: odoo/upgrade#2801
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Kartik Chavda <kcv@odoo.com>
The project overview is a significant technical debt
as it is a custom qweb view. It is quite limited:
It is not possible to group the data, to filter on dates,
SOs or Field Service projects.
Improving this is very difficult and would require weeks
of development that are not worth it.
In any case, all the information provided by the project overview
can be found elsewhere. The stat buttons of the report are basically
duplicates of the ones from the project form view.
Therefore, we are removing this report and its twin,
the Project Costs and Revenues.
In addition, analytic items lack context for the user to understand
what generated a certain cost or revenue:
there is no link to the source document;
the entries are not categorized (e.g. it is not easy to understand
if a cost comes from a timesheet cost, a purchase order or an expense);
the billable type group by works fine for timesheets but then all
the other entries are flagged as Undefined, which is not very helpful;
there is no option to easily isolate costs from revenues.
task-2646234
See odoo/enterprise#20936closesodoo/odoo#76553
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
* = hr_timesheet, sale_project, test_main_flows
Smaller changes:
- Projects created on the fly (through `name_create`) will now come with a
default `new` stage in order for them to not be empty.
- Removed task auto assign upon creation besides in FSM's 'My tasks' menu.
- Allow the reordering of projects without needing to group by
anything.
- Make `project.task`.`description` and `project.tags`.`name`
translatable.
- Disable the creation of records in the view when clicking on `Tasks
in recurrence` stat button.
- Track the planned date of the task in the chatter
- Disable the creation of records in the view when clicking on
'invoices' stat button and add the kanban view to that action.
- Make milestones completely available to regular project users.
- Remove the 'Documents' button in the project's kanban settings menu.
- Add kanban, pivot and graph views to the 'Hours Recorded' stat button
on projects
- Add the calendar view on the 'Hours Forecast' stat button on projects
- The 'Sales Orders' stat button on the `project.project`'s form view
will now display the amount of sales order linked to the whole
project. So the one linked to the project itself if it exists + all
the tasks. It will also open them, form view if 1 else list view.
- Fix a typo in the settings 'projets' => 'projects'
- The analytic account of the project will now be assigned to the
sales order when a task is created through the 'Create a task in an
existing project' option.
Changed the portal task view to include a sidebar similar to sales
orders, with a simple menu leading to different parts of the screen.
Changed the `project.task` 'rating' stat button:
- The icon will now represent the latest review.
- The action will directly lead to the record's form view if there is
only 1 rating.
- Make some fields readonly in the form view.
- Display the % of satisfaction instead of the number of ratings.
Reorder all stat buttons on the `project.task` form view in this order:
- Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours
Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and
lastly Customer Preview
Make the status of the project editable directly through the kanban
view. A new widget has been added to handle that properly. When editing
the status through that means, a `project.update` will be created with
the current date and the appropriate status. In addition to that a new
status has been added (only on `project.task`, not `project.status`)
namely `to_define` in order to differentiate new and running projects.
Projects now start with the `to_define` status.
The `project.project`'s rating stat button has been changed in the
following ways:
- The icon will now change in function of the satisfaction percentage,
smile above 66%, meh between 33% and 66% and frown below 33%.
- The color will also change depending on the rate, smile is green, meh
is orange and frown is red.
- The ratings will now be in function of the last 30 days instead of
all time and the action will also filter on those 30 days.
- Change the action name from 'Rating' to 'Ratings'.
`project.project` ticket stat button:
- Will now open the form view when there is only one record.
- Added the activity view.
- Disable the creation of new records.
- Rename the action to 'Tickets'.
Closes: odoo/odoo#75269
See: odoo/enterprise#20334
Task ID: 2611006
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the compute _compute_has_any_so_to_invoice was not triggered
in case of user change, which means that it could take incorrect values depending
on the value of the group as it was missing the proper decorator.
Also, performances were not optimal and have been improved.
closesodoo/odoo#77748
X-original-commit: 1270bd5dbd51a80b3e60695da4374092c55d6e06
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
-- This is a follow-up of odoo/enterprise#72736 --
The project overview is a significant technical debt
as it is a custom qweb view. It is quite limited:
It is not possible to group the data, to filter on dates,
SOs or Field Service projects.
Improving this is very difficult and would require weeks
of development that are not worth it.
In any case, all the information provided by the project overview
can be found elsewhere. The stat buttons of the report are basically
duplicates of the ones from the project form view.
Therefore, we are removing this report and its twin,
the Project Costs and Revenues.
In addition, analytic items lack context for the user to understand
what generated a certain cost or revenue:
there is no link to the source document;
the entries are not categorized (e.g. it is not easy to understand
if a cost comes from a timesheet cost, a purchase order or an expense);
the billable type group by works fine for timesheets but then all
the other entries are flagged as Undefined, which is not very helpful;
there is no option to easily isolate costs from revenues.
task-2637495
See odoo/enterprise#20740closesodoo/odoo#77547
X-original-commit: 9bbfd3c8f948a3a947cbc0eb73ffc5d89c23d4ca
Related: odoo/enterprise#21324
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
We are copying 3 stats buttons from the project
view form (manufacturing orders, work orders and bills of materials)
and we add them to the project update page.
See task-2638359
closesodoo/odoo#76421
X-original-commit: 4572e710a5e755c0c75c95a6d033e44f0a2799f8
Related: odoo/enterprise#20811
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit extends project form and panel in order to add buttons
which allow user to view documents linked to the project analytic
account.
This commit removes the computed field related to project overview
feature which is removed in the following commits.
This commit adds bridge modules in order to handle those extensions.
PR : #72736
See odoo/upgrade#2706
task-2545084
Previously, all costs allocated to a task were associated, if set, to
the analytic account of their project.
This commit adds a deeper level of granularity, as the user will be able
to override the project analytic account and add analytic tags.
When creating timesheets or creating account move line related to SO
linked to a task, the analytic account of the task is now taken into
account rather than the one defined on the project. If an analytic
account is set on the SO, it remains the default account used.
If a task is related to an SOL and an invoice line is created from this
SOL, the analytic tags of the task are also given to the account move
line.
If different analytic account are linked to a same SOL through the
project using this SOL or the tasks using this SOL, than no default
analytic account is set on the invoice line.
PR : #70527
task-2458135
Previously when a user added products to a task, when invoicing the
customer, in default case, no analytic account was defined on the
invoice line generated for the sale order line.
With this commit, we define a default analytic account based on the
information of the sale order line.
If the sale order line has a generated task or project associated to
it, we set the project analytic account.
If the sale order line is used on tasks or projects which all use the
same analytic account, then the invoice line created will take this
unique analytic account as default value.
If a sale order line is used in distinct project or tasks
from distinct project, then no default analytic account is defined.
PR : #70527
task-2458135
Adds personal stages to tasks.
Users assigned to tasks will be able to have their own pipeline to
handle their tasks independently of the project's pipeline.
The assignee field on Tasks has also been changed to a Many2many to
support multiple assignees on one task.
The same table is used to store those information, essentially a triplet
(task, user, stage), to ensure that:
1) personal stages only apply to tasks to which you are assigned to.
2) synchronizing to make sure that you don't have a personal stage for a
task on which you are not assigned anymore.
Alongside those changes, some minor changes have also been made:
- Modified the task's tree view.
- Renamed the Tasks menu to 'My Tasks'.
- The default view is now the kanban view for the 'My Tasks' action.
- project_id is not required anymore, tasks with no project are
considered 'private', those tasks are only visible to those that are
assigned to it.
- Added tracking of both user_ids and depend_on_ids in the chatter.
Closesodoo/odoo#74087
Task ID: 2398734
Since now, there was no possibilities to pay a Sale Order in a point of
sale without re-encoding every lines of the sale order in a pos order.
So we've now added the possibility to choose a sale order from the point
of sale, and apply a down payment or settle the selected order. You
still get the possibility to invoice it, and the stock is correctly
managed.
The SO is then updated accordingly to what have been done throught the
POS.
closesodoo/odoo#74096
Task-id: 2500902
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Previously, the button Sale Order in a Project form could only be seen when the sale_timesheet module (installed automatically with the Timesheet, Sales and Project apps) is installed.
Now, only the Sales and Project apps are needed to be able to display the Sale Order button.
opw-2530161
closesodoo/odoo#74048
X-original-commit: 42fcb59373fda8c82b2402b5524160215553df68
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>
Generic UX improvements for the task portal.
Added new sort by, group by and searches options in the tasks portal.
Some options have been renamed as well, while the style has been slightly revised.
The timesheet details of each sub-task from the parent form view has also been removed.
task-2508883
closesodoo/odoo#70305
Related: odoo/upgrade#2580
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Purpose
=======
During the development of the task #2169100, it appeared that the synchronisation
of a task's partner_id according to its project's partner_id and its parent's
partner_id was not very clear.
A first idea was to simplify the partner_id management: as it could be annoying
for the customer to see all the task's partner_id overriden after project's
partner_id modification, the idea was to just use the parent's parnter_id or the
project's partner_id as default value of the task's partner_id. Then, if the
partner_id of the project or of the parent is changed, there is no more impact
on the task partner_id itself.
The main problem of this solution is that the management of the task's partner_id
is also extended in several others modules like sale_project and sale_timesheet.
You can find below what seems to happen with all these task partners.
Start following rules according to which module is installed.
(for the record: sale_timesheet depends on sale_project which depends on project).
Rules are applied in the order they are written.
Rules labelled "O" only apply when changing the project through the task form view.
Rules labelled "C" apply everywhere.
technical: C=compute, O=onchange
project
C.1 If parent's partner changes and the partner is not set, then set the parent's
partner
C.2 Else if project's partner changes ant the partner is not set, then set the
project's partner
sale_project [+ project]
C.1 If the project's sale order line's partner changes and the partner is not set,
then set the project's sale order line's partner
C.2 Else apply (project.C) rules
sale_timesheet + [sale_project + project]
C.1 Apply (sale_project.C) rules
O.1 If the project is billed "At Project rate" or "At Employee Rate" and the
partner is not set, then set the project's sale order's partner
the sale order line's partner
Specification
=============
- If the partner changes, we ignore all current tasks and let them be. We set the
new partner as default value on all new tasks. In detail, we have done
this:
- When the user creates a task give the customer of the default project or the
task parent as default customer for the task.
- When the user changes the project and no partner in the task, we take the
partner of the new project (if this project has a customer).
- When the user changes the customer of the project, the linked tasks are not
impacted by this changes, even if some tasks have not a customer yet.
- When the user changes the customerf of the parent task, the child tasks are
not impacted by this changes, event if these tasks have not a customer yet.
- remove the onchange rule to remain consistent.
TaskID: 2232042
closes#51471
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Currently, empty help content are not properly added so in this
task add the proper help content on several menu and add module
field service in community.
So in this commit done the below changes:
- Task form view: change the tooltip of the sale_line_id field
- Change the empty help content in below menu:
- reporting > tasks analysis
- Configuration > Stages
- Project > Reporting > Project Costs and Revenues
- base: The industry_fsm module should show up under Apps in community,
with the usual 'upgrade' button
closesodoo/odoo#68940
Taskid: 2465012
Related: odoo/upgrade#2369
Related: odoo/enterprise#17548
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Steps to reproduce:
- Create an SO for a prepaid service in company A and confirm it
- Create a project and a task in company B and select the customer linked to the SO you previously created
- Unselect company A from the multi-company widget; only display the records from company B
- Timesheet on the task you previously created
Observed behavior:
- The SOL set by default belongs to company A, thus generating an access right error when trying to timesheet on the task
Expected behavior:
- The SOL set by default should belong to the same company as the task
task-2515259
closesodoo/odoo#70451
X-original-commit: af3c0e1b273d83323a9428f5b369387993ae225f
Related: odoo/enterprise#18160
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
Purpose of the commit is to do the generic improvement for the
refactoring of some module's view.
So in this commit, done the following changes:
- Reporting > Tasks Analysis , average progress of each task display correctly
- In project overview:
- state button is fit correctly in report view
- In task quick create, added placeholder for name field
- In Product form view:
- service_tarcking field: rename 'don't create task' into 'don't create a task'
- display the share button if privacy_visibility should be portal
- remove the 'Documents' stat button
- In Tasks list view, allow users to edit the stage of the task in batch if the project is in the context
- In project kanban view, remove the 'profitability' link and the corresponding stat button on sale.order
task-2458123
closesodoo/odoo#68146
Related: odoo/enterprise#17201
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, when the user configures his project and wants to
set a default SOL, he must first define the customer of the project
before setting the SOL. Same process for the SOL in employee mappings.
This commit allows the user to choose a SOL as default SOL or the one in
the employee mappings in his project even if no customer is defined into
it.
task-2442683
closes#66181
Before this commit, the user can select the SO in the project to filter
the SOLs in its tasks and in SOL fields in the project form view. But
since, the user can now select any SOLs of the customer defined in the
project or task. Then this field is useless to defined in the project
form view.
This commit converts the sale_order_id field into a related field of
the one in the sale_line_id field of the project. Moreover, the
sale_order_id field is now invisible in the view, the user just need to
select the default sales order item in the project and the SO of the
project will be the SO of the default sales order item.
Then, some unit tests have been updated to essentially remove the
sale_order_id in the using of create and write methods of
project.project model.
Finally, the sale_timesheet_tour has been updated in this commit to
remove the step when the user selects the default sales order of the
project.
task-2442683
closes#66181
Before this commit, when the SO is defined in the project, the user can
only select the SOLs defined in this SO.
This commit removes this filter to select all service SOLs with their
state is equal to 'sale' or 'done'.
task-2442683
closes#66181
Before this commit, when the pricing type of the project is either
project rate or employee rate, the list of possible SOLs in sale_line_id
is filtered to have only the SOLs in the SO.
This commit removes this filter because we just want to use the SOL set
in the project as a default value.
task-2442683
closesodoo/odoo#66181
on large database module installation may be aborted because of timeout error.
---
opw-2475335
closesodoo/odoo#69298
X-original-commit: f66fc7b9c410e60ab08ccb3882d39631e4d1eccc
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
We want to ease user experience regarding sub task creation and
management. We thus enforce the values of subtask stage, project and
parent task. we want to remove the ability of a user to choose a
third-party subtask project different than the actual one. Also, we want
to remove the ability to make one sub task recurrent. In general, We
want to improve and strengthen the relation parent-childs for Tasks. A
sub task is dependant of its parent all along the workflow.
This commit address those needs and, especially, removes the subtask
project configuration discussed in :
- odoo/odoo@66a0e5a
- odoo/odoo@b709e22
1) With this commit we want to change the way to link a subtask with its
project for UI reasons, we want to be able to easily distinguish
subtasks that are linked to the project of their parent from subtasks
that are linked to another project. To do so, the idea is to create a
field display_project_id not required. Only relevant tasks are linked
to their project through this display_project_id, the other are linked
to their project only via project_id. As a result, domains in the
application are only based on the fact that tasks have
display_project_id. The other are simply hidden.
2) The number of subtasks is shown on kanban and list views with a
wigdet to easily render it and extend the UI.
3) The default sub-task assignee is the assignee of the parent task.
4) Task form is modified to integrate those changes.
5) Various searches on project task are restricted with a clause where
display_project_id must be not null. Except in portal, in which context
we always display all tasks and subtasks.
PR community: #62577
PR enterprise: odoo/enterprise#15043
PR upgrade: odoo/upgrade#1984
task-2388034
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The error message raised when linking a wrong SOline and a task used
unclear/incomplete information.
This commit improves the displayed message, replacing:
* the SO id by the SO reference, since record ids are not really useful to
end users.
* the product name by its display name, to include variants details.
closesodoo/odoo#68041
X-original-commit: 8db6e654a50d38001c42247b33392aad90cab821
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the user can select a sales order which is always a
quotation and he cannot select a sales order line because the state of
the sales order is not equal to 'sale' or 'done'.
This commit adds ('state', 'in' ['sale', 'done']) in the domain of the
sale_order_id field in project.project model.
closesodoo/odoo#66804
X-original-commit: eb642e7e73f6ea3bb93a25629317a7c49e5770cc
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
This PR is in continuity of #62360 and #62900 done in 14.0.
The goal of this PR essentially updates and improves the changes done in 14.0.
## Details
- Remove the context key added in 14.0 to keep the 'Create Sale Order' button in task and helpdesk.ticket. Because at the end we remove this button in these models.
- Remove non_allow_billable field in tasks and timesheets.
- Remove the partner_email from task form view.
- Remove timesheet_product_id from task form view
- Merge sale_timesheet_edit module with sale_timesheet module.
- Remove timesheet table in portal sales order and invoice (deprecated templates in #62900).
- Remove override of project kanban controller (deprecated file from #62360).
- Store remaining_hours field in sale.order.line model (this field has been introduced in the following PR #62900).
- Remove _onchange_task_id_employee_id, the process in the method is done in _compute_so_line.
- Merge bill_type and pricing_type in project.project.
- Move partner_id field in project form view.
- Remove value selected in SO and SOL in project if the customer does not fit with the SO selected.
- Changes SOL in mapping when the pricing type of the current project is "employee rate" if the customer changes.
- Hide the timesheet_product_id field if the project is not a fsm project.
- Move sql constraint for timesheet_product_id in industry_fsm_sale, because this field is no longer mandatory in project which is not fsm project.
- Changes the search of timesheets in portal > timesheets.
- we allows the user to search with name of SO and invoice to find the timesheets about the wanted SO or invoice rathan than the id of SOL and invoice.
- Move View Timesheets button in portal > invoice
- Remove deprecated codes.
- Miscellaneous fixes.
Task-2424382
closesodoo/odoo#64474
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
When the user changes the project customer we need to check if the SO
and SOL are always for the customer defined in the project. If not we
remove the SO and SOL in project.
task-2424382
=======
This PR is in the continuity of odoo#62360.
- Display remaining hours in task sales_line_id (name_get + task form view)
- Remove internal reference from services demo data
- Display sol in project timesheets list if project is billable
- Remove use of non_allow_billable in timesheets as it has been removed from project and task in previous PR (see above)
- Only recompute planned_hours for service product
- Determine the correct SOL for timesheet
- Set the last SOL of customer on timesheet if none is set on task or project
- Allow edition of so_line in timesheet
- Restrict SOL on project to sale lines with a service product
- Use same widget on partner_id many2One than in sale.order (using ranking)
- Remove timesheets table in SO and invoice portal.They were added in previous PR (see above). This introduces the use of links to /my/timesheets/.
- Review portal timesheets (my/timesheets/ and link from orders and invoices)
- Activate group_uom "Units of Measure" on sale_timesheet install
- Hide partner phone number in task form view
- Only determine SOL of task and timesheet if allow_billable=True
- Filter SOL in task so that it matches the SOL of the project SO
- Display red label if remaining hours is negative
- Change SO compute behavior
- Only open SO for salesman on project overview
task-2409761
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closes odoo/odoo#63695
Forward-port-of: #62900
X-original-commit: b1985773f3a67e28049f9e2bb635bcab059ad9c0
Related: odoo/enterprise#15427
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Step to reproduce:
1. Install module "sale_project"
2. In Project > Configuration > Settings, turn on "Recurring Tasks"
3. Create a recurrent task
4. Set the "next_recurrence_date" for the recurrence ahead of today
5. Run scheduled action " Project: Create Recurring Tasks"
=> error: 'project.task' object has no attribute 'is_fsm'
Reason:
"is_fsm" is defined in the module "industry_fsm" and the module "sale_project" does not depend on that module.
opw-2412370
closesodoo/odoo#63325
X-original-commit: 36c3fb0e1d16f5cce21e3edcb01ee8a39a35caa8
Related: odoo/enterprise#15288
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The project overview statbutton will only be shown when there's a proper
Project Overview to display (when there are timesheets, etc.)
closesodoo/odoo#57698
Taskid: 2257764
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
This commit is mainly a revert to 13 functionalities in project_*
modules as functional changes introduced in 14 do not seem to be well
accepted by users.
Details:
- sale_timesheet: rename 'Ordered quantities' service_policy into 'Prepaid' project, sale_project, sale_timesheet: refactor task form view
- sale_timesheet: modify sale_line_employee_ids many2one widget on project form
- sale_timesheet: add link between ticket and sale order
- sale_timesheet: remove the option 'link to an existing SOL'
- sale_timesheet: remove the warning messages in project.task
- sale_timesheet: reword labels in customer_type and pricing
- sale_timesheet: adapt timesheet section on invoices in portal
- sale_timesheet: add timesheet section on orders in portal
- sale_timesheet: remove employee rate related warning on projects in Kanban view
- sale_timesheet: update sale_line_id of all the not invoiced timesheets accordingly to the employee mappings
- sale_timesheet: timesheet entries for employees that have no mapped SOL in project get the sol of the task or project
task-2388500
closesodoo/odoo#62568
Related: odoo/enterprise#15040
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Problem
-------
When a sale order has more than one task within the same project
clicking on X tasks lead to an access error since regular user
cannot read action anymore
Solution
---------
use _for_xml_id method to fetch action data
closesodoo/odoo#61953
X-original-commit: ff43c875a7566ef4473452fc359e73fbf589b615
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If a portal user was a customer but not a follower of a project
he didn't have access to the timesheets linked to the project.
Task-2299286
closesodoo/odoo#59252
X-original-commit: 13fc0ab18eb1e1d4ba47b7a1e66cd5079d692d8b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Install sale_project
- Go to Project > All Tasks and open an Task
- Toggle Studio:
* Activate "Show invisible elements" in View menu tab
* Select "Sales Order" field and uncheck invisible option
- Go to Sales and create a Quotation (i.e. SO0001)
- Go to Project > All Tasks and create a Task with SO0001 as SO
- Go back to Quotation SO0001
The created Task is not counted in the Tasks smart button.
Tasks smart button on SO only shows Tasks associated to a SO line
and does not show Tasks associated to SO.
opw-2335040
closesodoo/odoo#58926
X-original-commit: 1ffa2b5677d028c51a06f884d635cd8429730aae
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Xavier BOL (xbo)