Purpose of the commit is to improve the task analysis report
of the project app.
So in this commit, done the below changes:
- removed the # of tasks measure
- added the following measures: Rating Value (/5), Working Hours to Assign, Working Hours to Close
- removed the # from the labels of the following measures: Days to Deadline, Working Days to Assign,Working Days to Close
- renamed 'task title' into 'task'
- added a search on tag_ids and sale_order_id
- added the following filters:
-My Projects + My Team's Projects
-My Tasks + My Team's Tasks (rename 'Unassigned' into 'Unassigned Tasks')
-Starred
-Tasks Late + Tasks in Overtime
- added the following group bys: task, customer, kanban state, assignment date, creation date, deadline, last stage update
closesodoo/odoo#72587
Taskid: 2508645
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
The UX of the 4 main views (kanban, form, list, portal) of the project app has been globally improved.
In particular, different icons color/style were changed along with several strings, and the order of a few elements was revised to improve readability.
task-2508723
See odoo/enterprise#18387closesodoo/odoo#71011
Related: odoo/upgrade#2506
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Purpose of the commit is to improve the usability and onboarding
of the project app.
So in this commit, done the below changes:
- Rename column "Kanban state" in list view screens
- Hide column "analytic account" when not needed
- Do not show "Internal" project
PS: Moved leave_timesheet_project_id into hr_timesheet and rename
it as internal_project_id and we used it in the domain in the
kanban/action to the kanban in order not to have it in the result.
closesodoo/odoo#68857
Taskid: 2451722
Related: odoo/upgrade#2479
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
It seems some terms are no translatable so purpose of the task is
to find those terms ans update to make them translatable.
So in this commit, translate the text attribute when the node is field
tag and this node contains widget='url' in its attributes. and
also make the project name as translatable.
closesodoo/odoo#71406
Taskid: 2487710
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: xavierbol <xbo@odoo.com>
Currently, when go to project > settings > enable 'sub-tasks'
create a task >> add a sub-task and archive the sub-task
then the archived sub-task is still displayed in the sub-tasks list
so in this commit, removed the active_test context from the field to
hide the archived sub-task. also include the timesheet of archived
task while calculating the subtask_effective_hours and on click
of sub task hour open the timesheet of archived tasks.
PS: revert of the commit: https://github.com/odoo/odoo/commit/7a2cba3c8934064b311da4312ef2fbd07c6329ec
As we would deduct archived tasks from the count and the number of planning hours,
and keep them included in the timesheets.
closesodoo/odoo#71719
Taskid: 2534898
X-original-commit: e527ed80e25f638390fd8c56296e690b1630ec49
Related: odoo/enterprise#18744
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Signed-off-by: Mahendra Barad <mba-odoo@users.noreply.github.com>
This commit adds a right panel in the project update view.
This is done by extending each View and Controller by mixins handling
the RightPanel functionnality.
In the RightPanelControllerMixin, we use the component Adapter to launch
the Owl RightPanel Component from a Legacy Controller.
This solution is based on SearchPanel and ControlPanel implementation.
In the RendererMixin we handle some styling just as it's done for the
SearchPanel.
In the ViewMixin, we add the handling of a RightSidePanel config
parameter which is passed to the Controller via params.
The Project RightPanel Component gets information about the active
project in the context through a rpc call and render the resulting data
in a owl template. This template doen't have the ambition to be generic
but only specific to this view.
Serverside, the data are collected in a dict through few methods in
order to be easily extended.
Mixins are used in kanban and list views, each time a project update
view is added, the developper will have to extend the dedicated View,
Renderer and Controller.
PR: #68899
task-2393768
This commit aims to add a button in the control panel to easily display
the current project update status.
This is done by extending ControlPanel Component and template.
We must add a context value `show_project_update` to enable the
button in the breadcrumb and it's done only once; e.g. when we click to
see all project tasks of an active project.
The button redirects to a kanban list view of the project_updates.
The activity rng is modified in order to accept js_class definition.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
This commit adds project updates in project to take in stock the current
status of the project : which task or milestone changed in the past 30
days.
The project manager is able to add a status on the project update, and
edit the description of the update. There is also a chatter in which
he/she can discuss some points with other project users.
The description is build with informations retrieved from mail tracking
values or from project.* models. Those informations are collected in a
dict and rendered in a template to ease the inheritence in further
modules needs.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
Before this commit, when the partner_id in the project, we display the
partner_id selected in this project in the kanban card of it.
This committ displays the commercial_partner_id rather than the
partner_id in the kanban card of each project in the kanban view to be
consist with task's kanban card.
task-2232042
closes#51471
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>
Prior to this commit, the default stage didn't follow the value of the
display project id as the project_id was only updated after the write
call.
This commit makes the project_id to be updated after the display
project id changes.
This allows the default stage to be updated too once the onchange is
done.
Tests
---------------
This commit changes the behavior of a test making the use case more
smooth.
Previously, when a user removed both display project id and parent id
from a subtask, the project id was set to False. Now, if the display
project id is removed, the project id goes back to parent project, and
when the parent is set to False, it doesn't affect the display project.
PR: #50576
task-2522066
closesodoo/odoo#71029
X-original-commit: a908b9e8e6577bb7f8c8769db730c855fcad9504
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
In case X several recurrences are processed in the same cron execution,
only the last recurring task was created X times, while the other tasks
were not created. There is also a missing id preventing a correct use of
the default stage for the new created task.
closesodoo/odoo#70784
X-original-commit: 5ea2fcbecf572be24af9b2aac76de9e5d5709d2c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.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 task is to do a generic UX improvement in project
Specification:
--------------
1) Stages(project.task.type)
* List view:
- move the 'folded in kanban' field to the right of the project_ids one
- remove the description field from the list view
- make the list view editable in batch
* Form view
- rename 'stage name' into 'name'
- move the sequence field below the 'rating email template' one
- change the copy of the tooltips to: "At each stage, employees can
block tasks or mark them as ready for the next step. You can customize
here the labels for each state."
- the tags should be colored according to the project's color
- reduce the space in between the icons and the name of the states
- add some space in between the legend_done field and the description
- when creating a new mail template, set 'project.task' as model_id
of the template
* move the 'Stages' menu into below the 'Projects' one
* add the project_ids field to the kanban view
* search: rename 'Tasks Stages' into 'Name'
2) Tags(project.tags):
- configuration > tags menu: change the helper to: "Tags are perfect
for categorizing your tasks."
- add an optional list view -> only the color field should be optional
and displayed by default
- new tags should be created at the top of the list
- Also removed some of the unused(deprecated) css which are not applied
anywhere in the project.
closesodoo/odoo#69636
Taskid: 2508642
Related: odoo/enterprise#17865
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
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>
Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.
Followup of odoo/odoo#63292 .
Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849
X-original-commit: e618597876692f2d24f8e9308c747b8d1f2d8905
This commit fixes a regression introduced in #62577 .
Tasks are only taken into account iff their project_id is in self.ids.
closesodoo/odoo#69303
X-original-commit: 5be4970ddec2d9052d3b044e6e156aef94442c9a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit odoo/odoo@7059b17.
This commit translates tests introduced in this reverted commit to be
aligned with the current workflow.
This commit reverts functionality or business logic linked to the
reverted commit :
- odoo/odoo#47248 : You no longer have to be an allowed user to see the
timesheets but only a message partner.
- odoo/odoo#49021 : We no longer deal with allowed_user_ids or
allowed_portal_user_ids
- odoo/odoo@f2a1a00 : We no longer deal with the allowed users lists.
This commit removes the button project_privacy_visibility for functional
reasons.
Closes: #65367
task-2439329
Related: odoo/upgrade#2128
Related: odoo/enterprise#16067
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, we add various buttons in the bottom of each card with a
certain condition, the problem is the lack of place to display more and
more information in each project kanban card.
This commit reviews the dropdown menus in each project kanban card.
Two sections is added one for another 'Views' to redirect to documents,
timesheets, sales order and planning, for instance. And the last section
for 'Reporting' like burndown chart.
task-2458017
closes#68343
Prior to this commit:
Once the user clicked on View Task in the "Blocked By" task list, the
Create button in the form view of the targetted task is hidden. Also,
in the subtask notebook the user is not able to create additionnal
subtasks.
Reason:
In the action, the create argument is set to False.
After this commit:
We merge the two action_open_task and action_open_task_form into a
unique one. We remove the create set to false.
Related PR : #66740closesodoo/odoo#68652
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Prior to this commit:
1) The display_project_id was not set if user created a task from the
form view.
2) The project_id followed the display_project_id once the
parent_id and display_project_id was modified and set to False
Reason:
1) The display_project_id was set to False in the vals and not overriden in
the create method.
2) The project_id always followed the display_project_id if the
display_project_id was modified.
After this commit:
1) The display_project_id follows the project_id if the task has no
parent_id.
The project_id follows the display_project_id if the task has a
display_project_id defined and a parent_id.
2) The display_project_id always follows its project_id if it has no
parent_id
The project_id always follows the display_project_id if set or the
parent_id.project_id if not and is changed only when the
display_project_id is modified.
task-2497080
closesodoo/odoo#68647
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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>
Purpose
======
Sometimes, a task can only be completed once another is (e.g. 'install boiler' can only be done once 'order boiler' is complete). Communicating this information is key to organize a project and for the users to know on what they can start working when.
## Settings in Project App
- Add a 'Task Dependencies' setting under the 'Tasks Management' section
- Add the same setting on the project form view.
- As for the sub-tasks feature, enabling this feature in the settings of the app, should enable it on all existing and newly created projects with is_fsm = false.
## Task form view
- Add a 'Blocked by' notebook.
- In this notebook:
- add new many2many field called *depend_on_ids* containing the tasks in which the current task depends on these tasks with the following fields displayed by default: name, user_id, date_deadline, stage_id.
- add a 'view task' button on each line that should open the corresponding form view.
- Filter task list for depend_on_ids Many2many field.
- Check no cyclic task dependencies.
task-2387984
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66740
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the commit is to do the generic improvement for the
refactoring of project.
So in this commit, done the following changes:
- move the date_deadline and the tag_ids field to the right column
- remove the warning 'by saving this change, the customer email and phone
number will also be updated.'
- track the priority field on task
- move the deadline field above the fa-star and fa-clock-o icons
- the name of archived tasks should be crossed out
- project form add a 'deadline' field below the user_id one
- project form remove the 'description' notebook
- remove the 'project' field from the quickcreate of task.
Related Ent PR: odoo/enterprise#16559
TaskID: 2451287
Before this commit, if we have for instance 3 tasks called A, B and C
where A depends on B and B depends on A then we have a cyclic dependency.
Another example with the same tasks, we can have a cyclic dependency if
A depends on B, B depends on C and C depends on A.
This commit checks we have no cyclic dependencies when the user adds a
dependency on a task.
task-2387984
closes#66740
Before this commit, we can add the same task as dependency or the tasks
in which the allow_task_dependencies is disabled.
This commit adds a domain to filter the task list when the user wants to
add a task as dependency.
task-2387984
closes#66740
This commit adds two new fields in the project.task model.
The first one called 'allow_task_dependencies' is a related field to the
one project.project model. The other field called 'depend_on_ids' is a
Many2many field will contain the tasks which the current task depend on.
In the form view of project.task model, these fields are added.
task-2387984
closes#66740
This commit brings a new feature for the Project App and project
configuration. This feature is called "Task Dependencies" and it allows
to the user to determine the order in which to perform tasks in a
project.
task-2387984
closes#66740
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` argument and support from ``message_subscribe`` and
``message_unsubscribe`` API. Indeed we do not support adding channel-based
followers anymore. Only partners should be added or removed from followers.
It also allows to simplify API and understanding of both methods.
Various addons are updated to match the simplified (un)subscribe API. Some
enterprise addons may also be impacted.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Steps to reproduce the bug:
- Let's consider a customer C1 with email address A1 and phone P1
- Let's consider a project PR with C1 as customer
- Let's consider a service product P with:
- Milestones (manually set quantities on order) as Service Invoicing Policy
- Create a new project but no task as service tracking
- PR as project template
- Create a sale order SO with C2 as customer with A2 as email address and P2 as phone
- Confirm the SO
Bug:
The email address and phone of C2 were changed into A1 and P1 instead of keeping A2 and P2
opw:2439459
closesodoo/odoo#66709
X-original-commit: 1c23eba5ab4dc4108ef6209ebc529ab363c3cc6b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit:
A method action_subtask is including the other actions context if have which
reflects while clicking on the Sub-tasks stat button. For examples:
- When click on the stat button 'Sub-tasks' of any task which one is clicked by
systray activity icon results
- When click on the task menu in project there a default search filter 'My task'
which also passes when click on 'sub tasks' stat button
After this commit:
Remove the context that startswith `search_default'.
Hence, now subtask will display with the correct context.
Task-2413127
closesodoo/odoo#66401
X-original-commit: b13fc817d150f642254c4738cfbd91ac2ecaa65f
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
before this commit:
while changing subtypes of the project it was only
propagating those subtypes to the task, whose parent_id is set.
internal subtypes are not propagating in the task of a project.
So, filter internal subtypes and concat them with the subtypes which
have parent_id.
after this commit:
internal subtypes will also propagate to their tasks
closesodoo/odoo#64767
X-original-commit: f29e9e5edbe08e1a356ceb7c2dbb2f60fb6d3ff5
X-original-pr: odoo/odoo#47336
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Restore Project Kanban view for mobile.
Added a name for the default stage of the tasks in the Internal project
Removal of redundancy for the creation of the Internal project and its tasks
Fix task_reccurrence for the type 'after'. (too much task created or bad task created)
Task-2326258
closesodoo/odoo#64607
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The issue was triggered by the fact that editable fields are no longer
computed when they have a default value.
closesodoo/odoo#64503
X-original-commit: f047e0bdbcea2b707ecd24c6badbc3bfff0a71e9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
for repeat_type = 'forever' recurrences.
Consider a recurrence creating a task every 15th day of the month.
When the cron runs, it updates the next recurrence dates of the
recurrence.
But currently, the updated "next_recurrence_date" can be set to an
earlier date than today, if the fixed day of the recurring task is
earlier than the current day.
This means that the recurring task to create every 15th of the month
will be created the 15, the 16, the 17, the 18, ... until the next month
begins (no task will be created when the cron runs before the 15th of a
month).
This commit enforces the next recurrence_date to be set after the
current cron run, to ensure a task isn't wrongly created multiple times.
This commit also includes the tests that led to the discovery of this
bug.
closesodoo/odoo#63989
X-original-commit: e4943afef0f66703bafd78780764ff6f0b039d3e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For recurrences of repeat_type = 'after', the daily cron would create
tasks infinitely.
* The cron creates recurring task for all recurrences for which
next_recurrence_date < today.
* next_recurrence_date was never updated.
This commit ensures that next_recurrence_date is set to False for
repeat_type = 'after' recurrences, when the last recurrence is created.
X-original-commit: e7be857bea964628b80d4d3c1314dc231e0da947
You may want to use an analytic account for several projects of different companies, thus the correct way to proceed should be removing the company of the analytic account.
closesodoo/odoo#63172
X-original-commit: f1005e7624e84e6ee7ef467ae3bbccd16c59ce99
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently, The customer that is not selected anymore is suggested
as a recipient
steps to reproduce:
1. create a project task without a customer set
2. select a customer, then remove it, then save
3. send a message in the chatter
--> the customer that is not selected anymore is still suggested as
a recipient.
The issue is due to invalid value of partner's email in the field
email_from on task.
So in this commit, when the customer is not defined or is not a child
task then keep the email_From of the task.
(Here we are checking the task.parent_id because when someone update
the email_from on parent it should be updated in child task's
email_from and when we remove the email_From in parent it should not
be removed from child task)
closesodoo/odoo#63055
Taskid: 2339894
X-original-commit: 46fd7d7979f25c5fe8fe36999186a10ffb6376dc
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since commit 62024ca the portal customer of a task were missing the
"View Task" button.
closesodoo/odoo#63008
Taskid: 2393286
X-original-commit: 98c69f50d04f1a86ca62937eb2a4c5676a2b9cfe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@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.
The rating emails were still sent even if the rating feature was
disabled on the specific project.
This commit ensures the emails are only sent to project with the feature
enabled.
closesodoo/odoo#62181
Taskid: 2390802
X-original-commit: 3fe5416f07e76ccca6c0bb05a6fa12d8e2ca0e6c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The constraint method _check_parent_id was defined twice.
This commit removes the second definition, less efficient because not using
_check_recursion correctly (it can be called on a recordset with multiple records directly).
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
This commit fixes various types of language errors in strings visible to the
user, including
- singular/plural mix-ups
- missing or incorrect punctuation
- missing or incorrect articles
- inconsistent use of title case and sentence case and other capitalization
errors
- mixed-up words
- missing words
- incorrect prepositions
- missing or incorrect apostrophes
closesodoo/odoo#60189
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Cedric Prieels (cpr)