In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
before this commit, in project module there is a syntax
error in xml file
opening and ending tag was mismatched
on exporting the translation of project module shows
warning in the log
after this commit, no warning/error will be shown
in log
closesodoo/odoo#132263
X-original-commit: 4709ff342b603ac3f085f2e2c63812dfdc880f66
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>
The purpose of this PR is to improve the generic usage of the project app.
So in this PR done following changes:
- In reporting > tasks analysis measures:
- removed the # of tasks and average rating measures
- Changed rating value (/5) to rating (/5)
- In task analysis reporting formatted overtime as hh: mm
- In the project burndown chart added tip to action helper
- In project.task search view > quick searches:
- changed sale order to sales order
- under the SO one, a 'sales order item' has been added to the quick search
- Added many2one_avatar_employee widget in project sharing-> timesheets notebook
- In project.project form view > share editable added text in muted
- Added tip in the project.project form view > invoicing notebook under
employee/SOL o2m
- A placeholder has been added to the rating email template field in the project
task stages: 'Task: Rating Request'
- now rating submission page is editable
- In task stages list view :
- moved the project field on the right of the name
- switched the 'SMS template' and 'email template' fields from the place
- In project.task > recurrence notebook:
- moved the 'next tasks' list to the right of the recurrence
configuration fields
- In project.task > sub-tasks notebook > optional fields >
renamed 'initially planned hours' into 'allocated hours'
- In project.task portal form view: renamed
'history' into 'Message and communication history'
- Added 'open' filter in my tasks menu search view
- Added 'schedule an activity' status in the kanban activity widget
task-2903637
closesodoo/odoo#95971
Related: odoo/enterprise#29467
Related: odoo/upgrade#4095
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>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@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
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Steps to reproduce
==================
- Enter studio
- Create a new app
- Create a new model with "pipeline stages" enabled
- Close studio
- Switch to the kanban view
- Add a new stage
`ValueError: Invalid field 'name' on model 'x_test_stage'`
Cause of the issue
==================
A model _rec_name is not always name. This is the case for example with
studio stages. In that case, `_rec_name == 'x_name'`.
Since [commit], we do a create instead of a name_create.
Solution
========
First do a name_create to handle custom _rec_name. Then if there is
still some field to be written, do a simple write.
[commit]: 4e974e5
opw-3432017
closesodoo/odoo#130921
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, since we used to show custom label for project and assignees
as 'private' and 'unassigned' section in pivot view, if we want to display show
custom label for groupby with sub group type we might get confuse with passing
'groupby' attribute on _getEmptyGroupLabel pivot method.
In this commit, fixes groupby issue by passing 'fieldname' instead of 'groupby'
cause groupby contains 'groupname : subgroup' like 'deadline : year'.
closesodoo/odoo#130960
Task: 3186578
X-original-commit: cae3531deb032289f5f823df7ffa565ee89189ea
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit, we show a helper message in case there
are no records to show under those section (milestone, profitability,
sales section) in project right side panel.
task-3293012
closesodoo/odoo#128220
Related: odoo/enterprise#43972
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when the creation of an user access is set to `invitation
only` in the website settings, a project shared to a partner with no
user account will not be accessible to that partner. The link sent to
this partner will instead redirect him to the homepage of the website.
This commit address this situation by allowing the partner that receive
the link to create a portal access. The user that share the project is
warned that partners will be able to create user accounts and offered
the option to proceed or not.
task-3356419
closesodoo/odoo#129790
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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 the user defines a planned date for a project
in the form view, he has to click on `Add end date` button to be able
to select the start and end dates directly in the date picker.
This commit allows to directly select the both dates in the date picker
instead of having the planned date end optional in the form and list
views of project.
X-original-commit: e4f11e7a694c26e23ecf1437f3a98b2d3dd3bd7d
Part-of: odoo/odoo#130651
This commit removes the legacy implementations of Domain, Context
and the pyjs library. All of them exist in the new codebase, and
the few pieces of code that were still using the legacy ones have
been adapted.
Part of task~3439226
closesodoo/odoo#130647
Related: odoo/enterprise#45129
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Those fields are no longer used since all client actions and the
studio report editor have been converted to owl.
Part of task~3439226
closesodoo/odoo#130462
Related: odoo/enterprise#45015
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
1. Purpose: be consistent with the information indicated in the
description of the form view + add a way for users to analyze the margin
of their project is relative terms
- updates right-side panel > display the margin % under the margin
- apply the same color code and visibility conditions as for the margin
- The margin section is visible only if there are revenues and costs for
the current project.
2. Purpose: currently, SOLs and associated revenues are only taken into
account in the project updates right-side panel when it is set either on
the project, its tasks or its timesheets. This was designed this way to
manage the use-case where the AA of the project would be linked to
multiple projects. We wanted to avoid duplicate information.However, in
practice, it seems that the current behavior is confusing and is
generating a lot of questions from customers (according to our
colleagues at the support and the PS). IMO, the use-case where an AA
would be shared with multiple projects is not very common and we should
privilege the basic use-case.In addition, even if we have duplicate
information in case of a shared AA, it is still possible to have the
detail per project from the accounting app by setting a corresponding
analytic distribution.
- SOLs and associated revenues should be taken into account in the
project updates right-side panel if their SO share the same analytic
account as the project, regardless if the SOLs are set on the
projects, its tasks or timesheets, or not.
task-3330274
closesodoo/odoo#128439
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
*=sale_timesheet.
In this commit improve following UI in task analysis and list view,
- aggregate the sum of following fields in project.task list view, hours spent
on sub-tasks, total hours, progress.
- in project.task list view move 'id' after the 'state'.
- from task analysis remove the measure 'remaining hours percentage'
from graph and pivot view.
task-3330295
closesodoo/odoo#124396
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>
steps:
- install account module
- Create company Odoo IN
- Got to account > Configuration > analytic Plan
- Open Project and set company as Odoo IN
- install project module
issue-
Analytical plan and project both have different company so traceback come up.
Fix:
We have set company of analytic plan in project company.
task-3138082
closesodoo/odoo#130318
X-original-commit: d6171eb1c0e94cb1a22241dd250bc23247de3481
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
luxon and moment are both used in the solution,
but these two libraries facilitate the manipulation
of dates. It was decided to replace all uses of
moment with luxon so we can then remove
moment.js from the code and lighten the assets.
task-3391739
closesodoo/odoo#128752
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, the `project_enterprise_tour` has a step to
check `allow_billable` field in project to make the new project
billable to get partner field visible. The problem is this step
cannot be achieved if `sale_project` module is not installed.
This commit moves `project_enterprise_tour` is project module
to easily override it in `sale_project` and `project_enterprise`
modules to be sure the tour works when `sale_project` is not installed
and also when that module is installed.
X-original-commit: f09245f4dae4c3503630c9cd92b9d9ab5bfb6e78
Part-of: odoo/odoo#129584
The DataManager is no longer used as all views and models have
been converted to wowl.
Part of task~3439226
closesodoo/odoo#129725
Related: odoo/enterprise#44611
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit adapts the spaces and table layouts to maintain concistency
with Milk design.
task-3382174
Part of task-3326263
closesodoo/odoo#129571
X-original-commit: 68611ce40f48c6c8a143a24ac05e9ef72a8f69e4
Related: odoo/enterprise#44558
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit removes a lot of legacy code that we kept for the few
legacy client actions that were still to be converted to owl. Now
that the last one has been converted, we can finally get rid of a
lot of legacy code (ActionAdapter, ActionMixin, ControlPanel,
ActionMenus, DropdownMenu(Item), Pager, DomainSelector...).
Part of task~3439226
closesodoo/odoo#129314
Related: odoo/enterprise#44465
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@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>
Before this commit, avatars images were not aligned correctly
NB: The bug is only present in Firefox and pre v15.4 Safari because
these browsers don't support `:has` CSS selector. This selector is used
to set a `display: flex` on `.o_field_many2many_avatar_user` if it has
no `.o_tags_input` child in `many2many_avatar_user_field.scss`
task-3422356
part of task-3326263
closesodoo/odoo#129129
X-original-commit: fedf405aa821cf57b566c7992b0b14ad331bf80f
Signed-off-by: Pierre Paridans (app) <app@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 makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
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
Steps:
- Go to portal and select tasks and search anything in search bar.
- Showing no tasks available
- choose group by none and search anything it will show table labels.
Fix:
shows warning when there is no record when groupby by none.
task-3183771
closesodoo/odoo#128560
X-original-commit: 1d858798f53d56e5b81cc9df0fa70113dedd4f50
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Pierre Paridans