decided to add the domain condition in the project.task user_ids field definition,
which means we can remove identical domains in views
Task-3698867
closesodoo/odoo#155044
X-original-commit: c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Oversight in 06919a232251cbd68a28500757aef5cd2e3363a0
Need to handle `default_child_ids` and `default_tag_ids` as well.
closesodoo/odoo#153397
X-original-commit: 7d521b129c82e38afe50cd8b81cb2081c157aceb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Restrict collaborator portals to:
- Change unallowed fields on subtasks
- Create/Update/Delete tags.
They can only link, unlink tags to tasks.
task-3698146
closesodoo/odoo#152992
X-original-commit: 32c21d651c32c978f3cf67105e1c2eca9de2334d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- create a project and a task inside
- set date_deadline on the task
- copy the project
=> the copied task has date_deadline = False
Source:
- date_deadline copy property wasn't changed to True when the field
was merged with planned_date_end in 17.0
Fix:
- copy was removed as its default value is True
closesodoo/odoo#152006
X-original-commit: https://github.com/odoo/odoo/commit/56073896a69d9f68ce7e7938d9dec7ef094e19b3
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- install to project_enterpise module
- Go to project > all tasks in the Gantt view
- Group by customers
- Filter any customer
Issue:
The wrong domain is passed in the search method so traceback occurred.
Cause:
Currently, we don't replace `child_of ` operator with `ilike` in _search_on_comodel method so
child_of is passed in the search method and orm is not handled.
Before this commit domain:
`[('name', 'child_of', 'admin')]`
After this commit domain:
`[('name', 'ilike', 'admin')]`
Fixed:
We correct the domain.
Issue in this commit-
https://github.com/odoo/enterprise/pull/41257/commits/57eb5b72796e0aeff6d8368219281760acb7c307
task-3625825
closesodoo/odoo#144989
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when a project user shares a recurrent task to an
internal user, the internal user cannot open the form view of that task
because he does not have access to `project.task.recurrence` model.
The reason is because the compute methods to set the recurrence fields
assumed the user has access to that model.
This commit adds `groups="project.project_group_user"` to recurrent fields
to be sure the user has access to `project.task.recurrence` model before
computing the field.
task-3430762
closesodoo/odoo#148636
X-original-commit: c1623c7c8b1a3c5c69a866b55db77e69958e8754
Related: odoo/enterprise#53911
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Versions:
---------
- saas-16.2+
Steps to reproduce:
-------------------
1. Have a project with tasks & sub-tasks;
2. invite portal user to project;
3. log in as portal user;
4. go to a sub-task;
5. click the parent task button.
Issue:
------
Javascript is trying to get the type attribute of an `undefined` value.
Cause:
------
Commit 590beec447 added `task_properties`
to `view_task_search_form`, this search view is used by
`action_project_sharing_view_parent_task`, bringing it into view for
portal users who do not have read access to this field.
Solution:
---------
Add a `search_view_ref` to the context to force using
`project_sharing_project_task_view_search` instead.
opw-3498012
closesodoo/odoo#147377
X-original-commit: 47b0f6a42464ff41d40507cec5771b6dc3131d47
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description:
Indexes on a Selection field are never used in a `NOT IN` where clause,
as PostgreSQL doesn't have the complementary values (in DB a Selection
field is just a VarChar) to make use of an index on the field.
The ORM currently doesn't invert
`not in <selection>` -> `in <complement of selection>`.
Benchmark:
Positive impact in the project modules all around, specially for long running
projects where the proportion of "done" tasks are >90% of the
project's task. On a populated project with 10k tasks, 200 of those are
open, there were around 10x improvement on the requests linked to
rendering the kanban view of the project. More elaborate benchmarks are
available in the referenced task.
Reference:
task-3576802
closesodoo/odoo#146168
X-original-commit: 403a7c78f06f6b99233e6fc045bde67f0c670702
Related: odoo/enterprise#52708
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Steps:
- Open Project
- Go to Tasks > My Tasks or All Tasks
- Create New Task
- Create Project from Quick Create
- Clicking on Save, will give a Validation Error
Issue:
- Validation Error is raised and thus, we aren't able to add the project and
thus creating a task.
Cause:
- Due to the addition of context, the default_type_ids isn't obtained, and thus
the SQL error occurs as the name of the task stage isn't set which is a mandatory
field.
Fix:
- removing the context from the form view of Quick Create and set the stage
closesodoo/odoo#145599
Task: 3378510
X-original-commit: 83119d5de49ae69d08a0f798453d9c5c56b2276a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description of the issue/feature this PR addresses:
in project task form, allocated time of parent task. The 'incl. x on sub-tasks'
field is taking allocated time of all the child task as well as sub-tasks of its
child task. Field should only take into account time allocated to the first
level of sub-tasks.
Current behavior before PR:
field shows allocated hours of child task as well as sub-task of child-tasks.
Desired behavior after PR is merged:
field shows allocated hours of only child-tasks.
Fix:
removed child_task.subtask_planned_hour from the compute method of
subtask_planned_hour fields so that its only add the hours of its child-tasks
and not its sub-task of child-tasks.
task-3277977
closesodoo/odoo#140989
X-original-commit: f42cfb351a86f8ec551066d71271b97a56ce92b4
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Open Field service
- Select planning then by user
- Group by project
- The trace back is coming
Issue:
- when we trying to group by projects the trace back is raised.
Cause:
- In '_search_on_comodel' method filtered_domain does't set perfectly,
The filtered_domain it is not set for the additional_domain , when we
given on additional_domain, on that time filter_domain does not consider
the additional_domain, because of that traceback will be coming.
Fix:
- By adding an 'if' condition for cases when you provide an additional
domain, it will work fine.
task-3522178
closesodoo/odoo#140661
Related: odoo/enterprise#48652
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Personal stages of project.stage records are based on two main field:
- personal_stage_type_ids: the list of all personal stages linked to a
task (M2M)
- personal_stage_type_id: a computed field (not stored) indicating the
personal stage of a task for the current user.
When reading a set of project.task records grouped by personal stages,
two options are possible:
- Group the records by personal_stage_type_id (approach used in former
app Notes): in which case the read_group method has to ne rewritten as
it can be used on a non-stored field.
- Group the records by personal_stage_type_ids (approach used in app
Project) in which case, the kanban view has to be overriden to be able
to drag and drop a task between personal stages (which is not possible
by default, when grouping according to a M2M field).
The main evolution proposed by this refactor is to use an hybrid
approach that would:
1. Group the project.task records by personal_stage_type_id
2. Use the read_group with groupby set to 'personal_stage_type_ids' as
this should give the same result.
This would allow to:
- Avoid a complex and costly (performance wise) read_group override
- Avoid an override of the kanban view that is costly to maintain
- Simplify the implementation (and thus readability) of personal stage
management (among which, removal of the model
project.task.stage.personal).
task-3345132
Part-of: odoo/odoo#140050
Currently both incoming and outgoing emails are using the same 'email'
message_type. However both flows are not linked in any way.
Purpose of 'message_type' is to distinguish who generated the message.
In this case incoming emails are generated by the mailgateway while outgoing
emails are generated by mailins e.g. using the composer in mailing mode.
We now distinguish outgoing emails from incoming emails by using a specific
type for outgoing emails. Addons are updated accordingly.
Default 'message_type' value when removing sms/snailmail/whatsapp is now
'comment' instead of 'email', as default value of messages should be
comment as discuss is the main source of messages.
Task-3285720
closesodoo/odoo#139814
Related: odoo/enterprise#49597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The onchange on the stage_id/project_id wasn't triggered when modifing tasks in batch
we are now putting the same conditions as the onchange but in the task write() method
closesodoo/odoo#139491
X-original-commit: 0accffc0eb65f40e44d31402a0a362abaaa9b9bd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the domain term was using = or != as an operator
with an array as a right expression. This creates a warning in the log
when normalizing the leaf of the domain.
Now, the operations = or != are replaced by in or not in.
closesodoo/odoo#139032
Related: odoo/enterprise#49115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The system tray has been simplified:
- only one clickable area per activity group
- by default, a click on an activity group open the list view, except for some
model (ex.: journal entries, project, task, documents where the activity view
is opened). This can be defined per model using the _systray_view attribute on
the model.
- the clock icon providing access to the activity view has been removed. As it
is the only action, we also remove "actions" returned by systray_get_activities
in res_users.
- the KPIs are no longer clickable
The tests have been updated (for example, because we open the list view instead
of the kanban view) and one removed "activity menu widget: activity view icon"
as we only have one clickable area now and no more icons.
Task-3300854
Part-of: odoo/odoo#138135
In the project.task model, the method _get_all_subtasks allows to get
all the subtasks linked to a recordset (recursively). This method uses
the method _get_subtask_ids_per_task_id that retrieves all subtasks ids
for each task record in the recordset using a sql query to optimize
performances (see odoo/odoo#117624).
This commit adds an additional WHERE clause in this request to avoid
looking for subtasks in records that have no parent_id set. On top of
that, a unit test is added for both methods.
task-3504339
closesodoo/odoo#139132
X-original-commit: c2e59b337b9fd705f35473f560733c42227502cd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
-------------------
- create a project;
- set project visibility of project as
'Invited portal users and all internal users (public)';
- share that project with a portal user;
- create a task in that project and set one of user in 'Assignee' of the task;
- login in website as that portal user;
- from kanban view of task, open a task.
Issue:
------
The 'Assignees' are not visible in the opened form view.
The `portal_user_name` field will be empty, with the result
that no assignees to the task will be displayed in the project task form view.
Cause:
------
In the business flow, we first perform a `read` (with portal rights)
which will set the value:
`project.task.user_ids: {project_id: ()}` in the cache.
After, we try to get `user_ids` inside the `_compute_portal_user_names` method.
The `insert_missing` method of the cache does not overwrite existing values in cache.
Note:
fetch method uses `_determine_fields_to_fetch` with
parameter `ignore_when_in_cache` equal to `True`.
Solution:
---------
It is necessary to invalidate the cache for this field for the recordset
to make sure the value is updated.
opw-3536187
closesodoo/odoo#138557
X-original-commit: e533daf44c7946fae1e4467e70f9363f675dad07
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Step:
- Install project app
- Activated Task Dependencies
- Create project and task
- Add sub-task
- Click sub-task action
issue:
In the commit below we have passed the default_project reference so we get the
current project stage.
Fix:
we pass 'subtask_action' context to subtask action and we checked that context
in _read_group_stage_ids method if subtask_action context is found then we will not
fetch project's stages.
Side effect of this commit-https://github.com/odoo/odoo/commit/23cf9318084c8a00f37ffcefefa3e056583d2d77
task-3390279
closesodoo/odoo#138024
X-original-commit: 82c29c03cbaa351600b782082554378b4a320b73
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description:
In eedf37d6e2 the index on
`create_date` was removed, but it was still left on our production
database. After recent analysis on the usage of the index over the
span of 2 months (start July 2023 -> end of August 2023), this index
was hit over *100M* times. It's heavily used in custom filters when
grouping by `create_date`. So the goal of this PR is to add it back
in standard code.
Reference:
task-3263544
closesodoo/odoo#134313
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
- The existing of two dates behaving as and end date for project_task
(date_deadline and planned_date_end) is confusing.
In this commit:
- The main goal is to simplify the interface by having one field/widget
that acts as both the deadline and the end date, instead of having two separate fields.
So we removed planned_date_end (changes can be seen in the enterprise related pr (link at
the end) and changed the date_deadline type from date to datetime in project_task and
report_project_task_user
Related PRs:
Enterprise: odoo/enterprise#40866
task-3084978
closesodoo/odoo#120953
Related: odoo/upgrade#4654
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As `handle_history_divergence` is not used in the controllers, it makes
no sense to have it in `controllers/main.py`.
task-3217965
closesodoo/odoo#136277
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the group by in the gantt view of project didn't
allow the user to find records for which there were not scheduled tasks.
For example, if a Sale Order didn't have a scheduled task, when grouping
by Sale Order, the latter was not displayed. And searching for its name
was not displaying it either.
After this commit, when a user is searching for a sale order, even if
the latter does not have any scheduled task, it is displayed in order to
facilitate the scheduling of new tasks.
In order to do so, a group expand on sale_order_id for the project.task
model have been introduced.
closesodoo/odoo#121819
Taskid: 3251630
Related: odoo/enterprise#41257
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the conversion from a subtask to a standalone task
or the opposite was possible in debug mode. In order to provide for
users a way to convert task to subtask or the opposite without polluting
the interface, a action is added. Also, when the user clicks on search
more on a many2one field pointing on `project.task`, if the active_model
and the active_id are defined then if we will try to load the last
update status by using `active_id` even if `active_model` is not the
`project.project` model.
This commit adds a action that opens a form dialog. The user
can choose to put a parent task or not. If not, the task becomes a
standalone task. Otherwise, the selected parent task becomes the parent.
This commit adds also an additional check before loading and displaying
the last update status of the project active to be sure the `active_id`
is the id of a project, that is, `active_model` has to be equal to
`project.project` to be able to load the last project update status.
Moreover, a UI change in the stat button showing the number of subtask
is modified in order to display also the number of closed sub tasks.
task-3251617
closesodoo/odoo#120911
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, the field date_last_stage_update is updated when the state of the task is changed,
but only if the target stage is a closing state.
It could however be useful to know when the state was last changed regardless of if it's closing or not.
This commit makes it so that the field is updated after any state change.
Task-3455177
Part-of: odoo/odoo#130880
Before this commit 'project.task' model 'planned_hours' field
is inconsistent to the 'allocated_hours' field.
After this commit rename the 'planned_hours' to 'allocated_hours'
and related string change to 'Allocated Time'.
task-3231680
closesodoo/odoo#120405
Related: odoo/upgrade#4617
Related: odoo/enterprise#40643
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This will improve the following generic UX
- rename 'personal user stage' into 'personal stage' for private task
- added the 'personal stage' field to the right of the stage optional=hide
- earlier gantt view open with the user now it will open with groupby project
- removed groupby stage in pivot view
- rename 'undefined' into 'private' for graph view of private task
task-3251648
closesodoo/odoo#120094
Related: odoo/upgrade#4607
Related: odoo/enterprise#40515
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As sub-tasks are a sub-set of a task that should logically be completed
for the parent task to be completed, it would make sense for the
sub-tasks to share the same milestone as their parent task by default.
The milestone of a parent task is automatically set to its subtasks if:
- The subtask has no milestone set
- AND They belong to the same project or the subtask has no project set
- OR they shared the same milestone before the change on the parent
task (side effect for that case: if an invalide milestone is set on the
parent task, both parent task's and subtasks' milestones which are equal
are gonna be reset)
task-3450281
closesodoo/odoo#130439
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when deleting a task with subtasks, only the parent
task was deleted. As child tasks are the required to have the same
project_id as their parent, they could end up views of another project
with no clear link to it. Generally speaking, keeping child task, when
their container (parent task) is removed does not make sense.
Therefore, this commit changes the default behavior for task
deletion. When a parent task is removed, all its child tasks are removed
as well. To avoid such a behavior in exceptional situation where child
task can make sense without their parents, the user first need to remove
this link before unlinking the parent task.
A warning is added in all the views where a task can be deleted (form,
calendar and list) to warn the user of this new behavior when he deletes
a task.
task-3044991
closesodoo/odoo#121260
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
_*: hr_timesheet,sale_project,sale_timesheet
Generally, you don't want subtasks to be displayed at the same level
as their parent tasks. You want to consider the subtasks as part of
their parent's project, but don't want to see them directly in this
project. Rather, you want them to be accessible only via their parent.
(There are exceptions to that and we want to stay flexible.)
First solution that comes to mind is to have `project_id` set to False
for the latter tasks, but then how to get the value of the fields that
are related to the project?
So, second solution would be to have a field `project_root_id`,
which would be the project of the parent, or the grand-parent, etc.
The issue now is that we have to fields "project", and it isn't obvious
when to use one or the other.
The most simple way to answer this need is to keep one field "project",
that will always be set for (non-private) tasks,
and create a boolean field : `display_in_project`.
But we want it to be technical (no checkbox in the view).
So, when the user unsets the project on a subtask, the view will act
as if the project was unset, but in the back-end,
we'll set `display_in_project` to False and set `project_id` back.
The fact that all tasks have a project allows us to know if action x
can be perform on this task t, dependind on t.project_id.allow_x.
task-3367246
closesodoo/odoo#128281
Related: odoo/enterprise#43996
Related: odoo/upgrade#4930
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit's purpose is to allow the user to set the company_id of a project to False, meaning the project is no longer restricted for the user who does not have access to the company of the project. This change induces a lot of other small behavior changes/approximation. Since some fields (currency_id, resource_calendar_id, etc) were company dependent, we had to updates some use cases.
task-3084819
closesodoo/odoo#122144
Related: odoo/enterprise#41363
Related: odoo/upgrade#4947
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit implements the `mail.tracking.duration.mixin` with the
`statusbar_duration` widget for `crm.lead` and `project.task`.
The goal is to compute and display how long a record has spent in each stage in
the statusbar of their form view.
Task-3032773
Part-of: odoo/odoo#108554
Current behaviour:
If you disable the recurrence for 1 task in a suite of recurrence,
if you had other tasks belonging to the same recurrence suite, they
would still be with recurrence activated.
Expected behaviour:
It doesn't make sense for some of the tasks in a suite of tasks in a
recurrence to enabled and others disabled. If we disable the
recurrence on 1 such tasks, all tasks should linked to that
recurrence should be set as non-recurrent, regardless if the
edit-mode is set on "This task".
Steps to reproduce:
- For 14.0 -> saas-16.1:
- Install Project, Studio
- Turn on in Settings the "Recurrent Tasks"
- Create a new project and a task in it
- With studio, in debug mode, add a related field to the task form
that relates to `next_recurrence_date`. Make sure it's not "read
only"
- On the task, turn on the recurrence, set the frequency to each
day, set the `next_recurrence_date` as a day in the past
- Run the Scheduled Action "Project : Create Recurring Tasks"
- On one of the task, disable the recurrence
- Go to the other task, see that their recurrence is still active,
and the frequency changed to the defaults values of once a week.
- For saas-16.2 -> master:
- Install Project
- Turn on in Settings the "Recurrent Tasks"
- Create a new project and a task in it
- Activate the recurrence on the task, set a planned date in the past
- Set the task as "Done", this should create an new instance of the
recurrence.
- Disable the recurrence option in one of the task, observe that
is doesn't change for the other task, and the recurrence
frequency is reset to default values.
Reason for the problem:
When disabling the recurrence on 1 task, with the edit-mode set as
"This task", the recurrence is being deleted, but we don't disable
the recurrence of the other tasks linked to that recurrence.
Fix:
When we are writing `False` on `recurring_task` on a task, we
explicitely write `False` on `recurring_task` on all tasks that belong
to the recurrence after the deletion of the recurrence itself.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3265212
closesodoo/odoo#128703
X-original-commit: 0a83f4030b07aba25b054aa453d81c0e27b98cc8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Adds missing index on `project.task` `state`, this field is used in
a lot of searches as a search criteria like "open tasks".
task-3416393
closesodoo/odoo#127841
X-original-commit: 147446d86d7d33a83f83a8699c930fcdd3dbb99b
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
------
When we want to add a newly-created user
who does not yet have "personal stages" to an fsm task,
it triggers a User Error.
Cause:
------
There's a mistake in the `project_id` field,
which is missing the 's'.
Therefore, when creating the personal stage,
the ORM does not find the value in the context
and inserts the command to set the default project.
As a result, when checking constraints,
we will trigger an error for the
`_check_personal_stage_not_linked_to_projects` method.
opw-3390169
closesodoo/odoo#127694
X-original-commit: 05722c9710f74a073833235de9bbe4743485174a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps
=====
- Install module industry_fsm
- Create a task from the kanban view
- In the form view, add a title but no customer
- Open the subtasks tab of the notebook
- Add a subtask and add a title to it
- Save the created parent task
- A pop-up indicate that the customer is missing
- Add a customer and save the task
Issue
=====
A pop-up indicate that the subtasks field is invalid and there is no way
to save the current task with its subtask.
Cause
=====
the module industry_fsm introduces a required=True for the field
"partner_id" when edited from a view in the app Field Service. When a
parent task is created without a "partner_id" id set, it can not be
saved, but subtasks can still be created from it. Those child tasks
should have the "partner_id" set to the same value as the one of their
parent. As it is not set in the parent task, its value will be False for
the child task, and changing it in the parent task (by adding a
customer) will not update the child task. As this field is required when
a task is edited from the app Field Service, the task can not be saved.
Fix
===
A dependency to "parent_id.partner_id" is added to the method
"_compute_partner_id" of model project.task allowing to updating it if
needed when a "partner_id" is set on the parent task.
task-3343423
closesodoo/odoo#127088
X-original-commit: 7f8da6a4148c86b61d994bf692725378f8dafc52
Related: odoo/enterprise#43515
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit In the task's form view, the parent field shows the other
task but also shows the current task.
In this commit, the domain is applied, ensuring that the id is not the same
as the current id. As a result, the parent field of the task does not
include itself
task-3330841
closesodoo/odoo#122286
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the user installs `sale_project` and some
of his projects has no partner set but a partner is set on some
tasks of those projects then the user will no longer see the partner
field in those tasks because the project is not billable.
This commit checks if one of the tasks has a partner set to make the
project linked billable if it is not yet the case.
closesodoo/odoo#126880
X-original-commit: b0cb255577a7a0c49c2c764dbad715d3842b9508
Related: odoo/enterprise#43384
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: account, event_booth, gamification, hr, project,
website_event_track, website_hr_recruitment, website_slides
HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.
This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.
opw-3267589
closesodoo/odoo#126708
X-original-commit: 7fd28afaf3e45cafbef80b69aa45c58b31fb3de6
Related: odoo/enterprise#43311
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When a user creates the task without a name field and directly clicks on the
'Mark as Done' button, will give UnboundLocalError like the local variable
'task' referenced before assignment.
Steps to produce:
- Install the 'Field Service' module.
- Field Service > My Tasks > Open any task.
- Make the name field unrequired (Studio or Edit form View)
- Create a new task > Set the Customer field and leave the Name field as blank.
- Before saving the task click on the 'Mark as Done' button > Discard Changes.
- Error will be produced.
Fixing the indentation for `task.date_last_stage_update = now` will solve this
issue. We have used the task variable in for loop.
Sentry-4276832131
closesodoo/odoo#126752
X-original-commit: c3649a32c98d7093610a4367b1e72c1b4b0085b7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit increases the priority of the sequence in the ordering of tasks
so that reordering by drag & dropping is more useful.
Task-3371921
closesodoo/odoo#125073
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
In 16.2, we have implemented a nice tool to set various fields at the creation of a task from
the Kanban quick create using shortcuts.
This implementation is simple (only a few lines of code), but is not very flexible.
Indeed, shortcuts need to be in a specific order and at a specific place for them to work.
As a consequence, it is very easy for the user to fail in the creation of their tasks using shortcuts.
This task aims at making this feature more robust and complex so that it works in more cases.
In this commit:
It should be possible for the #tag, 23h, @demo, ! shortcuts to be put in whatever order, as long as they are at the end of the name
task-3349154
closesodoo/odoo#124155
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Prior this commit:
In project when tasks was moved to different stages users will get notify with
emails where there is a field showing assigned_date and deadline.
After this commit:
Instead of those fields it's showing only Stage: Stage name
Task-3285822
closesodoo/odoo#119973
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The following changes are made in this PR:
- sort projects by favorite > sequence > name for project
- add the 'tasks' stat button for project form view
- when creating a project on the fly from a task's form view, allow_billable
should be set to true by default
- Display only the colored dot, hide the status label for project list view
- remove following fields from project
allow_recurring_tasks
task-3251656
closesodoo/odoo#119154
Related: odoo/upgrade#4569
Related: odoo/enterprise#40050
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
New features developed in this PR:
- Write Javascript tests for the project.task.state widget
- Tests are in the project_task_state_selection.js
- rewrite Research & Development demo data
- Created a digest tip for task state selection (in Settings > technical > digest tips)
- Tip: Use task state to keep track of the task progression
- Fix Sharingview (Readonly) icons for the project.task.state widget, previously only the color bubble were displayed in readonly sharing views, now all of the icons are displayed
- Display state in the Calendar view
- Display the same widget as in the kanban/list views
- Remove is_closed References
- Adapt Kanban stages Exemples
- Kanban exemples are available when creating a new stage in kanban view
- improve Progressbar colors (different color for approved/done, in_progress/waiting)
Task-3213526
closesodoo/odoo#117968
Related: odoo/enterprise#39714
Related: odoo/upgrade#4548
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
Bastien (bvdn)