Currently, the `plan_id` used to create analytic accounts is not the one set in the settings.
Steps to reproduce:
-------------------
* Go to the **Settings**
* Enable developper mode
* Select **User & Companies** > **Groups**
* Select `Technical/Analytic Accounting`
* Add user
* Go to the **Project** app
* Select **Configuration** > **Settings**
* Under **Time Management**, enable Timesheets
* Under **Analytics** > **Analytic Plan**, select Projects
* Create a new project
* Go into the settings of the project
* Under the **Settings** tab, select the internal link for the **Analytic Account**
> **Observation**: The Plan is set to Projects
* Go to **Conffiguration** > **Settings**
* Under **Analytics** > **Analytic Plan**, change Projects to Departments
* Create a new project
* Go into the settings of the project
* Under the **Settings** tab, select the internal link for the **Analytic Account**
> **Observation**: The Plan is still set to Projects
Why the fix:
------------
When creating, an analytic account, the plan is computed with `_get_all_plans()`.
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903
Inside `__get_all_plans()` the plan is computed as follows:
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L07
However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`.
https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22
This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings.
opw-3751661
closesodoo/odoo#157247
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
to reproduce:
=============
- make a task recureent
- change its state to a closing one
-> Validation Error
Problem:
========
- when creating the next occurence, we insert the followers of the original
task in the new one, but it happens that we create a `mail_followers` twice
which violates an SQL constraint of `mail_followers`.
https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262
the create method will create `mail_followers` for the task and as the condition
that follows is truthy in this use-case `_insert_followers` will be called
and create `mail_followers` again.
- In previous versions we didn't face this issue because the creation of
occurences was done by a cron, so the condition was never truthy thanks to
`and self.env.user.active`.
Solution:
=========
to make sure the conditon stays falsy, we set `mail_create_nosubscribe`
in context to `True` when creating the next occurence.
opw-3742737
closesodoo/odoo#156945
X-original-commit: 64ca453bc36740ce4afcd46c1afbbb31abffdf7c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
How to reproduce the bug :
- Go to one project from portal user
- Open a task
- Create a subtask of this task
- Open the subtask
- Click on "Parent Task" button
=> Traceback
Fix :
- The search view is not loaded when opening the parent task
- We add manually the search view id in the action opening the
parent
taskid:3551354
closesodoo/odoo#156183
X-original-commit: 536638a92d6d7b242e27ae6f73431c61267b4eeb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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>
Before this commit, when the task_count is too huge, the number of
open tasks displayed in each kanban card of project returns `NaN` value
the reason is because, for instance, the number is 1026 and using `value`
will format the value and return `NaN` when the soustraction is made
between 2 numbers formatted (task_count - closed_task_count).
This commit introduces a new field called `open_task_count` to get
the number of open tasks and use it in the kanban instead of doing
the soustraction between `task_count` and `closed_task_count` fields
since we cannot really format the result.
closesodoo/odoo#149637
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>
Steps
=====
- Install module project
- Open the form view of a project
- Set a planned date
- Click anywhere on the page to remove the focus from the date picker
Issue
=====
The chosen date disappeared without any explanation to the user
Cause
=====
odoo#123268 introduced some changes related
to the planned dates of projects.
1. the write method is modified to avoid the write of only a start/end
date (both date should be set or none of them)
2. a required is added on the start date field in the form view of
project
3. an onchange is added to avoid to have one of both field set and not
the other
This last change is problematic as it overrides the required behavior of
the date fields.
On top of that, https://github.com/odoo/odoo/pull/143509 changed the
behavior of the datepicker widget that only display the full range by
default if both fields are required (which is not the case here if they
are empty).
The combination of those changes have the consequence that the planned
date field is unusable in the form view of projects.
Fix
===
The onchange being only useful in form view, it is deprecated as the
required attribute is sufficient for this usecase and provide the user
warnings if he forget a field. On top of that a required attribute is
also set on the end date field.
task-3628069
closesodoo/odoo#145167
Related: odoo/enterprise#52280
Signed-off-by: Julien Mougenot (jum) <jum@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>
Steps:
- Install project & accounting
- Open project
- Open project.update
- There is profitability section
- Go to accounting module configuration,settings
- Analytic accounting field true or false
Issue:
- Analytic accounting feature true or false the profitability section always
visible in project.update
Cause:
- There is no condition for profitability section visibility
Fix:
- Added required conditions for profitability section visibility
Task-3484413
closesodoo/odoo#135108
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Install Stock and Project
- Create a new proect with current company as customer
(3 dots menu on project overview to the customer)
- Create a new warehouse for the current company
- Error pops
Bug:
since commit[1] check company is enforced on the project_id field of
partners in bothways
when creating a new warehouse CheckCompany fields are editted on the
partner if set (property_stock_customer/supplier) the issue is if
the partner's company_id is False while project belongs to company
"_check_company" fails
Fix:
Remove check company on project_ids from the partner's side and
implement it as python constraint
opw-3507952
[1]:https://github.com/odoo/odoo/pull/109464closesodoo/odoo#143679
X-original-commit: 3741557dc4b5e84876247db851e9d2c862fcb93b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
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>
Sarah Bellefroid