Purpose
=======
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
=============
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
closesodoo/odoo#43321
Taskid: 2088891
Forward-port-of: odoo/odoo#43230
Forward-port-of: odoo/odoo#42418
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose fo the task is to improve the UX of timesheet, project and task.
Done the chages for below point:
- improve the stage demo data to unified the project stage
- on the task timesheet 'sub-tasks hours spent' should be clickable
and on click, it will display the list of subtask timesheet.
- display in warning tasks for which Remaining Hours < 0 if Planned Hours > 0 in task list view
- improve the settings of collabrative pad and planning and project form view
Task-2129052
closes odoo/odoo#41092
Closes: #41092
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
=======
Purpose
=======
Currently for a user to be allowed to see a private project they must follow the
project. This means that they will be added as a follower of all new tasks in the
project which causes them to receive 1000000 notifications, especially if there are a
lot of tasks in a project.
==============
Specifications
==============
1) Add an Employee m2m field on project next to 'Invited Employees'
- only visible if the 'Invited Employees' option is selected
- the project should only be visible to employees selected there (regardless if they
are followers or not)
2) Add an Employee m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Invited Employees' option is selected on the related project
- should be pre-filled with what is set on the project
- the task should be visible to employees selected there (regardless if they are
followers or not)
3) Add a Portal users m2m field on project next to 'Portal users and all employees'
- only visible if the 'Portal users and all employees' option is selected
- the project should only be visible to portal users selected there (regardless if
they are followers or not)
- rename the option into 'Invited portal users and all employees'
4) Add a Portal users m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Portal users and all employees' option is selected
- should be pre-filled with what is set on the project
- the task should be visible to portal users selected there (regardless if they are
followers or not)
5) Following a project/task should not grant the user/employee the ability to see the
project/task
Task 2031527
closesodoo/odoo#40505
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install Projects & Studio
- Go into projects app
- Edit a project (... => Edit)
- Click on x attachments stat button
You can't edit with studio
Cause
Writing the action manually instead of using the base one
result with an empty xml_id (and a lot of missing data).
Solution
Use base.action_attachment like others modules do (e.g. helpdesk).
OPW-2146741
closesodoo/odoo#43263
X-original-commit: 856b09d7055ebbfebbe3b5dc3093e429c8c930ff
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Purpose of the task is that when creating a multi level sub-task
and going back on click of sub-task breadcrumb, sub task is not
going to visible. We need to refresh or go to the parent task
than after its visible.
so display all the sub task when click is press on sub-task
breadcrumb.
replaced action domain with 'child_of' instead of 'in' because the
child_of will return the same result as method returns.
closes odoo/odoo#42916
Task: 2157055
Closes: #42163
X-original-commit: befdce11075753d7530c8b15d1ae2b536c3caace
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the task is, when some one remove the default filter
at that time kanban view is really a mess so when go though the
project always apply the domain of current project instead
of filter.
The breadcrumb should be the name of the project instead of name
of the action(tasks) so pass display_name from method to change the
breadcrum when view the task from kanban view.
closes odoo/odoo#40922
Task: 2124377
Closes: #40922
Related: odoo/enterprise#6903
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
Reproduce the issue
- Select a language (done by default)
- Install Project
- Create a project
- Create a task with a formatted date
- Reset the language
- Go on the project
Traceback
Cause
In 7e42c663, I format the date_deadline based on the user's language
but did'nt know that we could have no language selected.
This commit uses the `format_date` method from `odoo.tools.misc`
which fallback on the first language installed if there is no
language selected.
OPW-2146479
closesodoo/odoo#41057
X-original-commit: 7d06135712b6646816b0558a63e55bc10622e59c
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Reproduce the issue
- Install Projects
- Create a project
- Create a task with a deadline
The deadline format is correct in the form view but not in the
kanban view.
Cause
In the kanban view, there is some code applied on the `date_deadline`
field to add a class when the deadline is near.
As it uses a `span` with a `t-esc`, the only way to get the date
is to do `record.date_deadline.raw_value` which return the raw
value of the datetime object (a big string with all the infos).
This commit creates a char field for the formatted date and uses it
only for the display.
OPW-2122928
closesodoo/odoo#40707
Related: odoo/enterprise#6832
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
Currently, it is only possible to have 1 level of sub-tasks per task.
The user may want several levels of granurality.
Specifications
==============
Allow having multi levels of sub-tasks
- Move the parent_id field out of the debug mode and display it above the
Deadline field
- Remove the 'parent task' stat button
- Add the parent_id field to the project.task optional list view
- Display the sub-tasks stat button on sub-tasks
- The 'sub-tasks' stat button should only count/display tasks from the
first level of sub-tasks
- The name of the sub-task should be
parent task: sub task level 1: sub task level 2: sub task level 3...
- The sub-task should be created in the sub-task project set on the
parent task's project
- The subtask_planned_hours and the subtask_effective_hours fields should
take into account the planned hours of all sub-level tasks
TaskID: 2107078
Purpose
=======
Merge the form views of project tasks and fsm tasks so that it is
consistent and coherent wherever the user is in odoo.
closesodoo/odoo#40273
Taskid: 2070964
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Change some wording and layout things to be more in line with what
already exists, and add a tooltip to the deadline for clarity.
Additionally, much like the date whose data and format are controlled by
template variables so that the industry_fsm module can modify them, so
is the tooltip so that it can be modified by that module to reflect that
it represents the starting date or hour instead of the deadline.
TaskID: 2075174
Purpose
=======
When you create a task independently and link it to a Parent task later on,
several changes are applied: the person assigned on the sub-task switches
to the one set on the parent task, same for the customer, and so on.
This creates frustration because the user most likely set specific data on the
sub task for a reason. In addition, the changes are made implicitely, so the
user might not notice it or get confused as to what changed from the original
task.
Specification
=============
Values for fields `partner_id`, `email_from`, `project_id`, `sale_line_id` should be
transfered from parent task to children task, only if the value is not already set
on the child.
This was already partially implemented by 749810a and 45396f7.
But to achieve it, similar code was duplicated in several methods:
default_get, onchanges, write, create.
Since the new ORM, the same behavior can be achieved with only computed fields
with store=True and readonly=False. This commit changes the previous implementation
to take advantage of this which greatly improves code readability and maintainability.
Tests by Maximilen Larue
Business code by Lucas Lefèvre
closesodoo/odoo#39369
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: MaxLarue <mla@odoo.com>
Create a Project with tasks, archive it, delete it.
The project is deleted, but this should not happen:
tasks are present, but they are hidden because when the project is
archived all its tasks are archived too (active flag is set to false).
On project unlinking only active tasks are checked, thus allowing the
deletion. Using a context flag to avoid filtering the non active tasks.
opw-2080515
closesodoo/odoo#38320
X-original-commit: 71a79f26e6319c6987397950c7f9df6c61dfb0d9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When copying a task, we need its company to be the
one in its new project.
Task-1999686
closesodoo/odoo#37108
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit makes possible the task delegation in a multi company
environement. A subtask is a normal task with a parent, but can
now be in a different company, to be use as subcontracting task in
another company.
Tests are added to check multi company consistency for the project
app in general and for the subtask cases.
Task-1999686
This commit completes what was initiated a few time ago : a substask
is like a normal task and can now live its own life, being in another
project, attached to another customer, billed on another sale line, ...
than its mother.
The informations coming from the parent are only use as default values to
prefill the form view (with default options on creation, or though `onchange`
when setting the parent on existing task).
No values are forced now.
Form, default context, and others views has been adapted to make this feature
works.
Task-1982072
The goal here is to share the same kanban between fsm and project. A few tweaks are also done to the project kanban.
As in fsm the kanban group by is different we still had to do a primary inherit in fsm.
related task 2009563
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
In Project app, we now ensure the company of a task. Indeed, since that
model can be billed, and is important in some business, we need to ensure
its link to a company. A task can live outside a project, so the company
of a task can not be related. Task company can be set by user, but must
be the same as the project (is set), as the task can be billed depending
on project properties.
Task-1999686
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the number of hours the task is
open is computed using the resource calendar. The same
measure expressed in days simply divide the number of
hour by 24. This is not what we intend: we want to know
the number of working days since the task was created,
and not a simple conversion from hours to days.
Task-37561
closesodoo/odoo#30092
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Enable the subtasks in the settings. Create two project "A" and "B",
create two tasks "A.a" and "B.b". Set the parent task of "B.b" to "A.a".
╭─ Project A ─╮ ╭─ Project B ─╮
│ │┏━parent━┿━━━▶ B.b │
│ A.a ━━━━┿┛ ╰─────────────╯
╰─────────────╯
In normal situation, each task and subtasks are in the same subproject,
in such case, the parent task has been duplicated and it is important to
relink duplicated subtasks to the new parent task. In the case the
parent task is not within the current project, the subtask cannot be
relinked to a duplicated parent as it does not exist.
We could either let the link as is or remove it, we decided to remove
the link.
opw-2037623
closesodoo/odoo#35023
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Using api.constrains should be used instead
Simply leave a warning in case a model uses a non-empty attribute
`_constraints`.
closesodoo/odoo#34679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to remove of the legend_priority field in the crm
and project addons since they are not used anywhere.
Those were initially introduced at dd343c8633 . Purpose was to be able
to customize displayed label of priority field used in kanban view in
replacement of standard string. However kanban view does not support it
anymore since whatever web refactoring and this feature will not be
reintroduced. Let us therefore remove the fields.
Linked to task ID 1935620
closesodoo/odoo#33444
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When allowing timesheet on a project, the project generate
an analytic account if not given. When creating that account,
the company should be the one of the project (origin document)
rather than the one of the current user.
Task-1999686
As task can be billed, it became a important business model. To avoid mistakes in a multi company
environment, we need to make the company_id field required. Indeed shared task can be problematic
with access rights when a employee will log timesheet from another company in a task that is not in
the same company as its project.
To populate this field, we recommend to take the company of task's project, or to fallback on
the company of the user that created one.
Task-1999686
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Before this commit, the date_last_stage_update field in fill everytime at task creation. This does not make sense if ther is no project linked to the task or if there is no stages associated to the project/task.
This commit populates the date_last_stage_update field only when needed. So, we can now have newly created task without date_last_stage_update filled.
closesodoo/odoo#31999
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Odoo's Mergebot