test_task_postal_no_read` calls `assertEqual`, which internally
creates a savepoint which flushes pending computations.
This is done by flushing the transaction (through the cursor), which
in turn goes and flushes the models.
The environment being used to flush the models is arbitrary, picked
from the set of all living environments associated with the
transaction favoring those with a user set. This means the environment
used to perform the pending computation can be a lot more restrictive
than the operation used to initiate said computation, which may lead
to the computation being flushed not being *possible to perform*.
The issue here is that the test specifically involves a restricted
user ("Portal user", created for the occasion). Logging the set, at
the start of the test function there are 11 active environments
associated with the superuser (uid1) and one (1) environment
associated with that user, let's call it 19 (because that's the uid it
gets when running only that job).
On the runbot the envset seems to shuffle really well and about 2/10
of the runs will have the env(uid=19) in leading position[0], thus try
to flush the *creation of the task* with the portal user, which
specifically does not have access to tasks.
This works around the issue by flushing the task creation in the
`setUp`, however the underlying issues remain.
[0]: This also seems to require some load on the runbots, if the
runbots are pretty much unloaded (no pending builds)
reproduction is never achieved. It is not clear why load
would matter.
Local reproduction was not successful, even using a dump from the
runbot and inducing artificial load (via stress-ng).
closesodoo/odoo#87512
X-original-commit: fc08ff42ec8886f6258bde6586c4293b64c89456
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, when the current user is in project sharing and see
the form view of a task with at least a subtask. He cannot create
another one because of an error in the `_compute_portal_user_names`
method. Indeed, it is because we want to update the cache to get the
user_ids of the task related since the portal user cannot see the
users assigned to the task since he cannot access an internal user. This
update cache is made by calling the `_read` method but this method
checks after having fetching the data if the self is equal to the
recordset fetched. If the `self` contained newIds, then the method will
raise an error because a Task with newId != Task with id in db.
This commit fixes the compute method to call the _read method only on a
self with no NewIds to avoid this issue and correctly updates the cache
to get the name of the users assigned to a task in project sharing for
the portal user.
Fix found by Florian Damhaut <flda@odoo.com>
Co-authored-by Florian Damhaut <flda@odoo.com>
opw-2745857
closesodoo/odoo#84298
X-original-commit: f61c4f43365d38a955c497e022f0e8f18f50a6b2
Forward-port-of: #84189
Related: odoo/enterprise#24207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the portal user is assigned to the subtask if he
creates a subtask via the project sharing feature. We recently hides the
`Assign to me` button to those users.
This commit removes the `default_user_ids` in the context used when we
create a subtask in the project sharing feature to not assign the user
to that new subtask.
Related PR: #84006
X-original-commit: f3a241e97f80007f6d7ce2567dd22784cb35de26
Forward-port-of: #84189
Part-of: odoo/odoo#84298
Beforer this commit, we display a emoji to show if the customer is
satisfied, okay or not for the task via the last rating value. The
problem is we use only the value for the last rating for each task.
This commit uses all ratings for each by using the average of rating
value for each task to know if all the customers that done a rating are
satisfied or not.
Moreover, we add 4 filters in the project.task model using the average
of rating values.
1. Satisfied => rating_avg >= 3.66
2. Okay => 2.33 >= rating_avg < 3.66
3. Dissatisfied => rating_avg < 2.33
4. No rating => show the tasks without any ratings.
task-2671848
Closes#81027
While investigating an issue with the x2many tracking, we found a
better way that to track those field while also fixing the issue.
Fixes an issue with `default_*` context keys that are used in the
project app upon writing on tasks.
TaskId-2725014
closesodoo/odoo#82189
X-original-commit: a281a18fc84a09177f7b5e8aab98b8dc34dcc3b8
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the default assignee set to a rating in a task is
always empty because we check if the `project.task` has a `user_id`
field to give the partner of this user.
Since it is no longer the case because we can recently assign many users
to a task. That is, it is `user_ids` field and no longer `user_id`
field.
This commit overwrites `rating_get_rated_partner_id` method to set by
default the partner of the user contained in `user_ids` field if this
field contains at most one user. Otherwise, we set no partner. We choose
to not select the first user in the user_ids field because we cannot
consider it is the responsible of the task and not another one.
We cannot create a rating per user because the rating average will no
longer right because at the beginning of the task we could have 5 users
and after we could have more users or less users and so the number of
ratings for this task could be different each time we send a rating
review to the customer.
Part of task-2696911
closesodoo/odoo#81009
X-original-commit: 88e7d270bee962d6e4d40f6b62d25a9519abfcf2
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
This commit fixes an issue since user_id was changed to user_ids.
The default behaviour of `_message_auto_subscribe_followers` could not
work with the user_ids field as it is only meant to work with user_id.
This also fixes a related issue due to the same problem where the
assignation emails were not sent.
TaskId-2691486
closesodoo/odoo#79831
X-original-commit: 3510251ad19d4394f4613924aa2af20abb7c35d9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds unit tests to check the access of portal user. That is,
we check if the readable fields are only available in read access and
writable fields are available for the edition of the task.
We also check if the other fields in task model raise a AccessError if
the portal user wants to access to one of them.
task-2633229
closes#77156
X-original-commit: 1e7185bcdd8913c006148466dec260b8f6d53c0b
Prior to this commit, when a subtask is copied through the recurrence,
it loses its display_project_id in the copied sub-tasks.
Current Behavior
The display project id is left empty.
Expected Behavior
The display project id is copied.
task-2672243
closesodoo/odoo#79290
X-original-commit: 758b1a2f233bccd7fe7ac73119c12c4152d68e21
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>
Currently, unfollowing a project removes the user from all the tasks he was
following. Conversely, following a project or updating your notification
preferences makes the user a follower of all the tasks of the project without
distinction. These consequences are a bit extreme in case the user misclicked,
or simply decided he no longer wanted to be a follower of every newly created
task.
In this commit, when unfollowing a project should not remove the user from
the followers of all the tasks, and following a project should not add the user
to the followers of all the existing active tasks, neither should updating the
user's notification preferences But if the user explicitly update the user's
notification preferences for the project then its propagated to all the tasks
that the user is currently following.
closesodoo/odoo#67142
Task-id: 2440659
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds a python test for the task dependencies.
task-2663173
closesodoo/odoo#78980
X-original-commit: a71862fb86e6eef801093add300c2668458aa964
Related: odoo/enterprise#21887
Signed-off-by: Xavier <xbo@odoo.com>
Both developments 6c4910a and 7563b44 have been introduced nearly
at the same time in the saas-14.5 version, but the later one is
introducing a side effect that breaks the project sharing feature.
Indeed, before there was one assignee per task (user_id), and now
we can assign several collaborators (user_ids).
As the read on a M2O is just calling the name_get method, it wasn't
an issue.
Now, as it implies to read the res.users (and the res.partner) model,
the assigned users were filtered according to a specific ir.rule
for the portal users:
<record id="res_partner_rule" model="ir.rule">
<field name="name">openerp.portal.res.partner</field>
<field name="model_id" ref="base.model_res_partner"/>
<field name="groups" eval="[(6,0,[ref('group_openerp_portal')])]"/>
<field name="domain_force">[('id','child_of',user.commercial_partner_id.id)]</field>
</record>
This commit creates a new compute non-stored field called
`portal_user_names` to display the name of all assignees in each task in
the project sharing feature. Thus, the portal user can see all assignees
via this char field. The `user_ids` field is removed in the views of
project sharing since the portal cannot see all assignees with this
field.
By doing this, a collaborator cannot edit the field to assign or unassign
himself to a task. To keep this behaviour, two buttons are added in the
form view of task. One called 'Assign To Me', the current collaborator
will be able to assign himself to the task when he will click on this
button. The other button called 'Unassign Me' is to allow the
collaborator to unassign himself to the task.
part of task-2633229
closesodoo/odoo#78538
X-original-commit: 3b5a657df086b54def0bc0bdae89c19c89cb39f5
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit adds a test in order to strengthen the behaviour of
recurring subtasks.
This test asserts that child with depth > 3 are not copied in a
recurrence, that recurrent subtask are well copied with the recurrence
correctly set.
This commit prepares the recurrence refactoring.
task-2660756
closesodoo/odoo#77632
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
With the modification introducted in the PR #62577, create recurring
subtask was no more allowed.
This commits reverts this limitation and adds tests to verify this
behaviour.
PR : #77126
task-2522076
X-original-commit: f6b12588757bd7f2d7802264fc7cd1aaae4c6c57
This commit adds an unit test to start a tour with an internal user
connected to test the project sharing feature. Another test is
created to start a tour with a portal user connected to test the
project sharing feature.
part of task-2633229
closesodoo/odoo#76906
X-original-commit: db7825efb1b5cc052ecc795f9c81db5f3f58a5d3
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit improves the project updates panel and the data reported
in the update description.
This commit prepares the removal of the project overview feature.
PR : #72736
See odoo/upgrade#2706
task-2545084
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
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
This reverts commit fc7778f8c512202dc3361d6b87be8c28b299c3c8 because of
a change in the spec.
The access mode are removed and replaced by this access mode for portal
user:
- read: the user goes to the classic portal view
- edit: the user is added as collaborator of the shared project and can
access to project sharing views.
To do this, the portal share is inherited by the project share wizard.
This new wizard can be open to share in readonly and open to share in
edit mode via 2 buttons in the form view of the shared project.
A new stat button is added to form view of project to see the
collaborators of this project. That is, the ones can access to the
project sharing views. The project manager will can remove or also add
new collaborators via the views in this stat button.
task-2379518
closes#73341
Tasks that are blocked by other tasks don't get any other information
from those tasks.
In order to get updates on the state of the blocking tasks we now track
some fields (determined by the `task_dependency_tracking` attribute) in
the parent's chatter.
Task ID: 2601448
closesodoo/odoo#73965
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, for the db with old active tasks and many
projects and tasks. The report takes several hours to execute the sql view.
Because we take the create date of the oldest task as the begin date
of each generate_series to calculate the different group bys (day, week,
month, quarter and year) until CURRENT_DATE.
This commit hugely improves the performance of the sql view execution
for the burndown chart report.
closesodoo/odoo#72664
X-original-commit: 89726a22862cf14f7b88e130fb79ddc74bffff5e
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Nicolas Seinlet (NSE) <nse@openerp.com>
Co-authored-by: Thibault Libioulle (TLE) <tle@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.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>
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>
RATING
Rating texts currently have a negative skewness. Indeed apart top rating
all ratings have a negative feeling. In this commit we update them
to match more closely a 1-5 range from dissatisfied to satisfied, ok being
the middle value.
PROJECT
Filter customer rating were taking in account ratings from first e-mail
instead of current satisfaction.
IM LIVECHAT
Livechat did not catch feedbacks without comment.
Task ID-2439720
COM PR odoo/odoo#66992
ENT PR odoo/enterprise#16757
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>
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>
with this commit we adding weekly recurrent widget, currently proeject and
calendar shows boolean for each day vertically but with this widget we displays
week days and its boolean horizontally.
Here widget will display first day as per language's week_start field, also we
adds FieldDependencies on custom widget and consider those FieldDependencies
while processing view node in basic_view.js
We add support of registry to contain owl custom widgets and add support
of rendering owl custom widgets.
Also with this commit we removes fields like sun, mon, tue etc. from view and
instead use "web_weekly_recurrence" custom widget to display boolean for each
week day.
Co-authored-by: Mohammed Shekha <msh@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>
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
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
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
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
This change ensures that when the user activates optional features of the
project app, they are enabled in existing projects as well as newly created
projects automatically, which is likely what the user expects.
For most optional features, this behavior was already in place. It was not in
place yet for the sub-tasks and timesheets features, which this change fixes.
Two added tests check the behavior described above for features that are
activated through a `group_*` field on `res.config.settings` (sub-tasks,
recurring tasks and ratings). The tests do not cover features that are
activated through a `module_*` field, as such fields require the installation
of further modules and we cannot simulate this.
Task 2297054
closesodoo/odoo#60106
X-original-commit: 8dd0edae898a532dbe7e4f18c9118b9b68e57900
Related: odoo/enterprise#14119
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Kevin Baptiste <50135801+kba-odoo@users.noreply.github.com>
Some interventions are done on a regular basis (e.g. maintenance of
fire alarms, safety inspections). Having tasks auto-generate would
facilitate the process and would ensure that the next intervention
isn't missed/forgotten.
closesodoo/odoo#55517
Taskid: 2172156
Related: odoo/enterprise#12246
Related: odoo/upgrade#1604
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The 'stage_id' field is now a stored-editable computed field.
The 'company_id' has been converted to a stored-editable computed field.
The modification of the 'partner_id' field in the onchange method has been
moved and merged into the _compute_partner_id method.
Remove the empty 'onchange' method from the project.task model and also remove
this method call from the sale_timesheet module, which inherits from the project.task model.
Adapt the _compute_partner_id to retrieve exactly the behaviour before the onchange
method deletion.
Update code and tests of the task/subtask partner_id management after discussion with Alexandra to clarify the behavior.
Add the 'multi_edit' attribute to tree views.
- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items
TASK ID : 1251
Currently there are some issues wiht ACLs tests, notably transaction errors
due to new_test_user helper tool. Standard new_test_user tool allows to speedup
user creation in tests. It may cause issues if reset password is involved as
there is a savepoint done. Mail has an improved helper allowing to avoid that.
Also tests were actually not working due to cache being invalid. First fix
allowed to spot it and this is fixed now.
Followup of 7059b177ee .
Closes PR #49485closesodoo/odoo#49504
X-original-commit: 2c766fa8b66c4e05d373ae550a2d43fa2500616c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If you want to de-activate the multi company ir.rule, those checks will
still raise an error.
Task 2198433
closesodoo/odoo#47291
X-original-commit: 12a81a3a5265cbd18f5c00ab439cd1486696521b
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Purpose
=======
In Project, the configuration has to be done twice: in the settings of the
app and on each project.
During the onboarding, the user won't understand that a feature has to be
enabled at both places and will think that the system just doesn't work.
If the user enabled a feature, he most likely intends on using it for most
of his projects. Therefore, having to do a double configuration for each
new project is annoying.
By the way, sub-tasks is the only global feature (it can't be enabled or
disabled by project), so we are breaking it down by project to remain
consistent with the rest.
Specification
=============
1/ Enable subtasks per project
Before this commit, sub-tasks were a global feature (i.e. once enabled
they were enabled for all projects). This commit gives the ability to
enable/disable sub-tasks per project.
2/ Make project_id on planning required
3/ Change default rating status on new projects
4/ Default value for allow_subtasks
5/ Enable timesheets on existing projects
6/ Hide Total Hours if subtasks are disabled
7/ Create project in the company context.
Otherwise some records generation could use a default company which is not
the company for which we want to create a project.
8/ Default value for allow_forecast, is_fsm
9/ Change reference to timesheet product
10/ Fix tracback on industry_fsm_report.
Before this commit, there was a traceback when enabling "Worksheets"
(industry_fsm_report) after "Time and Material" (industry_fsm_sale).
11/ Convert some onchange method into computed editable stored fields
closesodoo/odoo#41218
Taskid: 2146474
Related: odoo/enterprise#6998
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Xavier Morel