Scenario:
- add doc_count field in project.project view
- create new project
Issue: error and can't create new project
> File "addons/project/models/project.py",
> line 190, in _compute_attached_docs_count
> psycopg2.errors.SyntaxError: syntax error at or near ")"
> LINE 6: AND res_id IN ()
Fix: only do the query if there is non-NewID IDs
opw-3584925
closesodoo/odoo#142074
X-original-commit: 4d9a5cedef9459f0e86f16631170f2dc965d0a3b
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
This commit introduces some adjustments to the dark mode color scheme
and the use of bootstrap classes in Community.
- Mini calendar contrast -
The colors were not using variables, making them non dynamic
and breaking the contrast in dark mode.
- Avoid !important rules spreadsheet -
Prior to this commit, spreadsheet top bar was using a `bg-white` class,
making it pure black in dark mode.
Since spreadsheet is designed with light colors and we don't provide a
dark mode for it, we remove that class and set a `background-color`
property using CSS in Enterprise.
- Input color -
This commit fixes the focus behavior on the searchbar in the control
panel, the `command_palette_search`, and the `start a conversation` in
discuss.
- Copy clipboard field border color -
Make use of the `text-primary` color for the copy to clipboard field
We use the o-theme-color function to avoid an undefined since primary
doesn't exist in the o-theme-text-color map in white mode.
- Web_editor toolbar variables -
The toolbar was using the `o-brand-primary` variable
which was set to a darker shade. This caused issue when activating an
option due to how vibrant the color is.
- Improve the controls on border-color -
Introducing a custom property on the border-color to allow
further control on individual components (such as the popover).
- Improve setting tabs colors use -
Prior to this commit, the colors of the settings tabs menu were kinda
inverted. The menu was light in dark mode and dark in light mode.
We fix this by changing the values associated to the CSS variables in
use.
- Make model field selector dark mode proof -
Fixing the design of the model field selector popover in both
light and dark mode. Since the popover was using custom style with
arbitrary values, it was not designed for the dark mode and had a lack
of consistency.
To improve the design, we use variables rather than custom style, and
make sure the desired render is as close as before.
- Sign colors use -
This commit aims to improve the sign module in both light and dark mode.
There were some readability issue with some `btn-light` having poor
contrasts in both light and dark mode, and the use of some classes was a
bit unexpected (e.g `card-header` to set a grey background with some
padding).
- Improve buttons design inside listview -
Prior to this commit, this button was using custom CSS to make it look
like a primary button, while it was using classes related to secondary
buttons.
We remove the custom CSS used to style it correctly and keep our button
design consistent.
- Messaging menu layout in mail -
This commit aims to improve the design of the notifications displayed
in the messaging menu. Prior to this commit, the notifications dropdown
was using custom CSS variables overriding the regular behavior
of our dropdowns.
In fact, the layout was generating some friction:
1) Marking a notification as read would turn its background into a
darker color
2) Effects like `:hover` were all based on the custom CSS variables
resulting in an inconsistent layout.
- Multi company selector adaptations -
In darkmode the multi company selection was using the btn-light which
creates a weird effect and overrides the dropdown default hover behavior
This commit uses the btn-link to display an hover effect on the
company switch and on the checkbox while blending with the background
and the default dropdown hover effect.
- Adapts default badge design -
Improve the design of the default badges in dark mode.
If you open the light mode, these badges are dark grey with a white
text. If you switch to dark mode, they are dark grey but with a dark
text, which makes them look either muted or off.
We make use of SCSS variables to handle the color of the component,
providing a good styling in both modes.
- Fix kanban cards borders inside dropdown -
Fixes the issue with the divider inside the kanban dropdown menu not
showing in dark mode.
To ensure it is visible, we assign it the `$dropdown-divider-bg`, which
is the color it should use, as the horizontal divider above uses.
- Fix tour pointer design for dark mode -
This commit aims to insert the tour pointer and its content inside the
styling we applied to our tooltip.
To do so, we make sure it uses CSS variables, allowing more control and
consistency, plus we replicate the overall look of our tooltips.
- Fix `text-primary` on action background contrast -
This commit improves the readability of our `text-primary` classes when
it's used on a `$o-component-active-bg` background.
Prior to this commit, the `text-primary` was not meeting the contrast
standard, mainly when you were using the `CMD+K` shortcut on the
app switcher.
To prevent that, we changed the background to a `$o-component-active-bg`
background with an opacity ensuring our text provides a good contrast.
- Fix input states -
Prior to this commit, the `--o-input-border-color` CSS variable was
using the `$o-form-lightsecondary` variable to define the standard color
of the `border-bottom` property of our inputs.
This was conflicting since `$o-form-light-secondary` is also used to
define the `background-color` of our table on focus.
With this commit, we separate these two element with different variables
to make sure they don't affect each others.
- Fix kanban ghost background -
Before this commit, if you created a project without any stage or element
in it, the ghost cards that act like placeholders would be pure `#000` in
dark mode, due to the `bg-white` class.
This commit replaces that class with a `bg-light`, providing a better
visual result in both light and dark mode.
- Fix new message design -
Improve the design of the new message element while
inside Discuss, using our danger color, ensuring a good visual result in
both modes.
task-3201038
closesodoo/odoo#139966
Related: odoo/enterprise#49666
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: chgo-odoo <chgo@odoo.com>
Co-authored-by: stefanorigano <sri@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>
Purpose
=======
Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts
| Country | Product Type |
| ------- | ------------ |
| BE | Drinks |
| LU | Food |
And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg
We want to be able to display the following pivot tables:
| | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE | 1000 | 2000 | 3000 |
| LU | 0 | 3000 | 3000 |
| Tot | 1000 | 5000 | 6000 |
| | Total |
| ------ | ----- |
| Food | 5000 |
| * BE | 2000 |
| * LU | 3000 |
| Drinks | 1000 |
| * BE | 1000 |
| Total | 6000 |
Implementation
==============
* `ir.fields` are added/removed dynamically on `account.analytic.line`
* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
meaning that all the companies have access to all the plans. This
means that the applicability fields and lines are now company
dependent, and those can be used to know which fields/plans to display
for which company.
* There can no longer be one "Project" plan per company, even if the
accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
which is `_get_plan_columns`
task-3497653
closesodoo/odoo#139225
Related: odoo/upgrade#5306
Related: odoo/enterprise#49226
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william <wan@odoo.com>
Co-authored-by: h4818 <ayh@odoo.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
Update fields used in form views. Use 'alias_domain_id' instead of domain
that is now simply a related on 'alias_domain_id.name'. To ease UI we add
a placeholder on this field as it is now writable e.g. in multi domains
environment. Avoid unwanted configuration change by making it generally
no_open / no_create_edit.
In project, remove an unnecessary field adding complexity for few real use
case now that aliases are more open to configuration.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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 new method should be used to generate an SQL object that represents
how to order by a field in an SQL query. We introduced the auxiliary
method _order_field_to_sql() so that one can specify some SQL for
ordering by a given field with a simple method override.
Part-of: odoo/odoo#138019
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>
The purpose of this commit is to do generic improvements to the project.
In Commit, made the following changes:
- replace the rating % by the value out of 5 in the project kanban card.
- replace the rating % by the value out of 5 and satisfaction by average rating in the
project update right-side panel.
- add the placeholder in project stages and project task type.
task-2962386
closesodoo/odoo#99474
Co-author-by: Manisha Tulsiyani <matu@odoo.com>
Related: odoo/enterprise#31013
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
How to reproduce:
- Link 2 distinct projects to at least 2 different companies
- Modify and save any setting in project settings (this action
should trigger the write function of the project)
--> Traceback: expected singleton
Why?
- If projects associated with differing companies are updated
collectively, the condition self.company_id.id anticipates a
singular value, but it’s possible for there to be multiple.
Solution:
- When we want to write a company_id on some projects, take back the
ones already with the right companyc(as we don't have to change their
stage) and then write the first stage found on the other records (
by putting self.company_id.ids in order to avoid the singleton
exception).
taskid:3520107
closesodoo/odoo#136614
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>
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
When user import records of project and if it contains tags in the file,
a traceback will appear.
Steps to reproduce the error:
- Go to project > Favorites > Import records > Upload File
Note: Make sure that file contains tags
Error: A traceback appears:
"TypeError: unsupported operand type(s) for +=: NoneType and list"
https://github.com/odoo/odoo/blob/0480005e4498d76fe7a3446693f41500122e41d7/addons/project/models/project.py#L2763
When user import records that contains tags, here args will be None.
So it will lead to above traceback.
sentry-4494554048
closesodoo/odoo#136973
X-original-commit: 9e14cf0fb618c517fe12138416e40c3e66383276
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Add a new column, after tasks that shows the following information :
Tasks: Total done tasks / Total tasks (ratio in percentage)
Timesheet: Hours spent/ allocated hours (ratio in percentage)
\> visibility: only show if the timesheet setting is activated.
Right side panel :
Add the Done icon before Tasks
Add hours spent/allocated hours information under the Timesheet
Extra time: Add a new stat button that shows
the overall extra time used for the project.
visible if hours spent > allocated hours.
By clicking on this it will redirect to the same view
as we have for the timesheet stat button.
task-3432102
closesodoo/odoo#129177
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Version:
--------
- saas-16.4 only
Issue:
------
When a project is duplicated, all tasks and sub-tasks
are visible in the new project's kanban view.
Cause:
------
When writing `project.write({'tasks': [Command.set(new_tasks.ids)]})`,
we trigger an inverse which writes the `project_id` field to the tasks.
This will set the value of `display_in_project` to `True`.
Solution:
---------
Rewrite the `display_in_project` field if necessary.
opw-3479714
closesodoo/odoo#136527
X-original-commit: 6f62d156b65b331a0a15406a90b174c265100491
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>
Adding a company_id field in project.project.stage will allow companies
to have their own individual stages, which was not possible before since
all the stages were shared between all companies.
task-3330285
closesodoo/odoo#122597
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
Issue:
After 213b6885312f3da3bf5bff995861758a1afcde76, some custom filters
on tags can throw a stacktrace.
Steps to reproduce:
- Install Project
- Project > Custom Filter > Tags contains 'Internal'
- Stacktrace
Cause:
When `limit=None`, which is explicitly set when creating custom
filters, the `name_search` crashes when comparing an `int` (the len
(ids)) with the limit which is `None`.
Fix:
Elaborate the condition to handle the case when `limit=None`.
Affected versions:
16.0 up to master
Reference:
opw-3510309
closesodoo/odoo#135982
X-original-commit: 5aefba4399f25e4e3cd3c205e0a6511173dffd11
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Description:
The commit 05855b6bb6d8a22ceb1f8b25332a146eed912660 introduced a
fast-path for the name_search on tags from the form view of tasks.
But the implementation was too complex and wasn't handling correctly
all possible operators (it just had a fallback on the default
parent name_search implementation).
The aim is to simplify the code for better robustness and
maintainability long term.
Fix:
Convert the query to it's equivalent python code. It has a slight
performance regression than the previous implementation (we are
making 3 queries worse-case instead of 1), but the regression is
non-significant and not critical.
Affected versions:
16.0 up to master
Reference:
task-3503721
closesodoo/odoo#135631
X-original-commit: 9d95314aaca7c087d7159e3f603bcea99f69b217
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@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>
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
This commit's purpose is to allow the user to remove the planned date
end, or the planned date start of a project from the list view, or the form
view of the project. If the user removes either the planned date end, or
the planned date start, both dates will be removed. If the user tries to
add only a date end or a date start while keeping the other date empty
on a project with no planned date, these changes will be discarded.
The goal of this fix is for the projects to always have either both dates
set, or both dates set to False.
closesodoo/odoo#130651
X-original-commit: 250a0d233c8c2e074b967d59d53b1d4aac5feba2
Related: odoo/enterprise#45131
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>
Before this commit, planning option is view in project
setting.
This commit planning option is move from project to planning setting
with named 'Project Planning'
task-3251687
closesodoo/odoo#125341
Related: odoo/enterprise#42675
Related: odoo/upgrade#4940
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>
If a project had a single rating associated to its tasks, opening the
customer rating view would create a traceback. This happened because
both the mail.thread model and the rating.parent.mixin model have a
rating_ids field, and project inherits from both of them (mail.thread
on its own doesn't have it, but the rating mixin adds it).
In the action_view_all_rating method, we try to access the first element of the
rating_ids recordset, if the rating_count field is equal to 1. But since
the rating_ids field belonged to the mail.thread mixin, and not to
the rating.parent.mixin, there could be occurences where rating_count was equal
to 1 while the recordset was actually empty ; accessing the first element of the
recordset would then create a traceback.
To fix this, the rating.parent.mixin model was put before the
mail.thread model in the _inherit list, this way the rating_ids field
from rating.parent.mixin has the priority. A test was also added to check
if the rating_ids is working correctly.
task-3360029
closesodoo/odoo#127243
X-original-commit: 1039c80a8ff5e219e9c2679505015288c8d8dd35
Signed-off-by: Xavier Bol (xbo) <xbo@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>
Nicolas Lempereur