*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the project onboarding tour: the step to create a new stage
get validated if the user clicks on the 'add' button without actually creating a
new stage
After this commit, it will point first to the text area for the name and then
add tooltip will be highlighted so tour does not consumed without adding the
stage.
task-3049636
closesodoo/odoo#118825
X-original-commit: 255fa6245114531d3a0fad4f4f0739e5ab57d3b8
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
- The burndown chart displayed the stage in order of the data fetching which wasn't logical especial for a chart that supposed to represent the evolution of the tasks in the project
- When sorting all/my tasks by stage, It was possible to select any project in any quickcreate of the stages which didn't make much sense
After this commit:
The burndown chart legend is now ordered according to the stage sequence (previously was ordered randomly by comming data)
Modified the burndownChartModel, simply makes a RPC to get the stages and sequences then sort the legend elements (one by stage) with it
Display only the projects which uses the stage in the dropdown menu of the task kanban quickcreate (when grouping by stage)
When sorting by all/my tasks by stage, the quickcreate now only display the projects which contains the stage selected
done by adding a domain in the quickcreate form
(shoutout to LTU and AUON who actually found the fix)
Task-3067445
closesodoo/odoo#105694
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
- project tasks view: when we group by company, milestone, customer,
worksheet template or any m2o field, the KanbanColumnQuickCreate is
displayed for that field, we can add a new one or apply examples,
but thoses examples are stages.
That doesn't make any sens to add them in a project or milestone context,
then if you add a new column manually or via the apply examples, it will
disappear once refreshing the page.
To summarize, stage is the only valid group by that can have the
KanbanColumnQuickCreate.
- all tasks view: same problem as the previous point + quick creating
is also not valid for group by stage as we are in all tasks context that
are linked to different project and the examples are mainly applied for a specific
project, if you try to add manually or via the examples and refresh they are going
to disappear as they are not linked to any project.
- my tasks view, same problem for previous point + quick creating when grouping
by personal stage is valid but apply examples button is displayed to show stages and if
used, it will not add anything, so it should be hidden.
- Project Kanban examples stages are all created as not folded.
Some users don't know that 'folded in kanban' option is available on the stages,
and that tasks in a folded stage are considered as done.
After this commit:
- project tasks: KanbanColumnQuickCreate and applying examples are only available
when grouping by stage.
- all tasks: KanbanColumnQuickCreate is not available.
- my tasks: KanbanColumnQuickCreate is only available when grouping by personal stages.
applying examples is not available.
- some example stages are folded..
task-3092925
closesodoo/odoo#107633
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: project
This commit adds test to this component and removes unused props. Since commit (1),
it is now considered as a core component. Those props have been removed from the
props declaration, to better match the real usage of the component.
Since the className props was not present:
- The o_kanban_tag class given in theory were not set in practice. The rules
corresponding to that class were already adapted to fix the display of tags in the
kanban view. It was possible to get rid of the references to the o_kanban_tag class.
- The o_field_property_tag_readonly class was also missing, and the logic to prevent
the click on tags was duplicated in the onTagClick function. This makes the class
useless. I removed mentions to this classname. Instead, each tag has the pe-none class
using the same condition, but set in the tag declaration.
(1): 129fa3f150
Part-of: odoo/odoo#117751
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- adding a label 'last update' to the stat button in project form view.
- indicate 'my project' in the tab instead of 'project sharing view in portal' in project sharing.
- set the first non-folded stage of the project as default on newly created tasks.
- remove user confirming the SO as the default project manager.
- hide fields service_tracking, service_upsell_threshold if sale_ok is false.
- set purchase_method to purchase by default if product is of service type.
- remove the : next to the totals labels and decrease the font-size for values of 'total hours'
and 'remaining hours' in timesheets notebook in project task form view.
task-2897867
closesodoo/odoo#96548
Related: odoo/enterprise#29774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Manisha Tulsiyani <matu@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit reviews the UX and UI in Project app and improves the usability of the
new features recently added (subtasks list in kanban card, state field replacing
kanban_state field, etc).
The following changes are made in this commit:
- swap of user_id icon in the kanban box and the removal of the allow_unassign field and setting
- change the ordering of the fields in the subtask list
- make small layout changes in the project.task and project.project kanban cards
- remove the "lock-icon private" sub-title of private tasks, replace it with a
little lock icon on the bottom right icons of the kanban card.
- remove the break tag in the project.task kanban card that was unecessary
given the new display and margin style settings
- lock icon is bigger
- kanban icons are better aligned
- state is as big as avatar
- remove the 'remaining hours on SO' field
- deadline field will be optional and hidden by default in project.task list view
- remove the rating field
- add stage field as optional in project.task list views
- priority and state fields will no longer be optional
- stage_id will be copied when duplicating a task, except when the task is
generated through the recurrence
- remove the tooltip of the tag_ids field
- When duplicating a task having sub-tasks, '(copy)' is no longer
added to the name of the sub-tasks of this task.
- project.task kanban view:
* (+ x tasks) mention next to the name is removed
* The caret is replaced with 'fa-check-square-o x/y'
which will represent the number of sub-tasks closed
compared to the total number of sub-tasks
* Only open subtasks are displayed
* When changing the state of a sub-task to a closing one,
the sub-task is muted and removed from the list on the view reload
* The name of the parent task on the kanban card of sub-tasks is
displayed except when viewing the sub-tasks of a particular task
through the sub-tasks stat button
* project.project kanban view: the fa-check-square-o icon of
milestones is replaced with fa-flag-o
* project.task kanban card: the fa-play and fa-pause icons
are moved on the right of the remaining hours widge.
* Allow users to edit the stage_id in batch from the list view of tasks
if all of the selected tasks are part of the same project.
* the state will have the same size as the avatar
* change the opacity of the tasks that are closed
* state is at the right of subtask list
* the striked should be replaced by the opacity on the kanban card
Enterprise PR: odoo/enterprise#38132
Task-3229873
closesodoo/odoo#116628
X-original-commit: 09b5d5843096d27b5a4ab0f603ad44bdb2e74723
Related: odoo/upgrade#4478
Related: odoo/enterprise#38771
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Panagiotis Kyriakou <paky@odoo.com>
Co-authored-by: Bastien (bvdn) <bvdn@odoo.com>
Purpose:
- In the project, My Tasks and All Tasks menu are related to the task model so
having two main menus for the same model which display almost the same
thing would not be great for UI and it'll not look good if we add another menu
in the future or via customer customization.
So in this Commit:
- We have added a menu named Tasks which has 2 sub-menus My Tasks and All Tasks
which would be great to display tasks
task-3180910
closesodoo/odoo#113335
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: project,utm
**Before this commit**
With the following steps, it is possible to use kanban column quick
creation with unexpected fields, i.e. creating projects instead of
stages inside a project:
- Project > New > Groupby 'Project'
- Click on the "see examples" link in the column in creation
- Apply any column examples
- Instead of stages inside the project, new projects are created
**After this commit**
The kanban_examples registry elements should now clearly
state which are the allowed groupby fields.
The 'See examples' link will not be displayed if the groupby field
is not allowed.
**Usage**
See the modified files in project and utm modules in this commit.
Taskid: 3246042
Part-of: odoo/odoo#115909
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit c1cbfb07516d2d06c3311d66e220b1de87c1b681, fieldsToFetch
has been renamed to relatedFields.
Apparently, some commits were merged after this one without using the
new name.
closesodoo/odoo#116623
X-original-commit: dea116bf4c65295e93cc7894132d9f48f98e4189
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the state mode for subtask without any project set
is not the toggle one as it is the case for the private task.
This commit changes the state mode to have the toggle mode when the
task has no project set, that is, the subtask without any project set
or the private task since a subtask without a project set could be see
as a todo task and not a task in a real process as it is the case for a
task linked to a specific project.
task-3230063
closesodoo/odoo#115781
X-original-commit: e2d7ee73222ab3330da9c45570a4a6330d87c016
Related: odoo/enterprise#38378
Related: odoo/upgrade#4448
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, since the display_project_id field has been removed and
the project_id field could be unset on subtasks (default value as the
`display_project_id` field), the widget `project_private_task` consider
a task as private if the task has no project_id set.
This commit changes the widget to check if `is_private` field is true
to display the `Private` on `project_id` field value.
task-3230063
X-original-commit: b0a8a9aedb3b5cfb2acb6ff3b10a77c279bda8fd
Part-of: odoo/odoo#115781
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
*=hr_timesheet,project,sale_project,sale_timesheet
Currently, the configuration of the recurrence is quite complete
and allows a lot of flexibility, but it is costly
in terms of implementation as it requires a lot of fields.
The goal of this task is thus to simplify this implementation.
In addition, a lot of people are complaining
that tasks are only generated when the recurrence date is reached,
as it doesn't allow to anticipate the planning of field service tasks.
In this task, we are thus going to immediately generate a new task
once the previous one is marked as done.
Concretely, we:
- describe a recurrence in terms of
"once every n day/week/month/year for ever/until a date"
and delete all fields that don't fit into it.
- remove the cron. The new occurrence is created when
marking the last task as done, and copied from the latter.
Deleting the last task deletes the recurrence.
The recurrence fields stay useful, as they form a delta t
that will be added to deadline/planned dates fields to get the new
values.
- use an boolean icon button to activate recurrence,
and place it at the end of deadline field's line.
The recurrence fields appear on the next line.
- delete in the form: the div explaining when the next tasks will be
created and the header to choose how to save the changes in the
recurrence.
task-3084945
closesodoo/odoo#112764
Related: odoo/upgrade#4343
Related: odoo/enterprise#37114
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this PR the task state was fixed by the kanban_state field which was useful when you use the stage of the project as parts of a pipeline,
but not relevant when users are using stages as bucket lists. (specific examples at the end of the specs)
The goal of this PR is to provide users a way to mark their tasks as done with a simple button press,
while keeping the option to label a task as Approved, Canceled or Requesting changes like in the old kanban_state field.
The kanban_state of a task had no impact whatsoever on other tasks of the pipe, we would like to change that and make the task state have an influence on its dependent tasks.
The state will also have influence over the 'recurrent' tasks (to be implemented in Task #3084945)
If you want a better description of those changes with screenshot and colors check specs of:
Task-3084930
PRs:
See odoo/enterprise#35359
See odoo/upgrade#4367
-----------------------------------------
Interaction with blocking tasks:
the closed values which mark the task as closed or finished:
- Done
- Canceled
The Open values when the task isn't finished yet:
- In progress
- Changes Requested
- Approved
- Waiting (which is not selectable)
Where to change the state of a task:
- For kanban and form views: same place as kanban_state (bottom right of kanban card, top right of form view)
- For list view: left of list (after task priority)
more details about the state widget in state field widgets part
Interaction with existing fields
- is_closed: which was determined by the task.stage_id.fold, now a task is closed when in one of the following stages
- Done
- Canceled
a closed task is considered as finished, the time of the closing will be stored in the date_last_stage_update field
- is_blocked: a task is considered blocked if ANY of its blocking task is in one of the blocking states (more details about this in the following part Interaction with blocking tasks):
- in Progress
- Changes Requested
- Approved
- Waiting
!! important !! is_closed and is_blocked are not mutually exclusive, you can have a task that blocked and is closed at the same time, the reason why will be explained late
date_last_stage_update: this field is updated everytime the task goes into a closing state OR when the task changes stage.
We need to check that the value is updated in each case (using the already available filter)
Interaction with blocking tasks
the state of a task can now be changed by its blocking tasks following the logic:
if ANY of the blocking tasks is NOT closed (so its state is in one of the open values) the task is considered as blocked
- if a task is blocked and NOT closed its state will switch to Waiting
- the Waiting state will display an unclickable hourglass icon on the task kanban/list views, once in the waiting state you can't change the state of the taskfrom the kanban/list views
- a blocked task state can be changed through the form view, so you can override the 'block' by choosing a closed state (only done or canceled)
- once overriden, the task will change to the closed state the user wants, but the task is still blocked so in case where the user comes back to an open state, the task will automatically switch back to the waiting state (according to the state before the block)
- if the blocking task switches to a non-blocking state, the task will not be considered as blocked anymore and its state will switch back to In Progress
Default values
the default value is always in progress
Special cases
when a task is moved from a stage to another one
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
when a task is moved from a project to another one
- the state goes back to In Progress
when a task is duplicated
- if the state was in one of the open states (approved, changes requested, in progress ) the state goes back to In Progress
- if not, the state stays the same
closesodoo/odoo#107593
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit,
-We Ease the quick creation of tasks by providing shortcuts allowing the user
to set different fields (planned_hours, tags, priority, and assign to users)
without opening the form view.
task-3145203
closesodoo/odoo#112821
Related: odoo/enterprise#37166
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is to replace all uses of activeFields in Field components
by passing fieldInfos to extractProps. We will therefore retrieve the
node-dependent information in the extractProps function.
Why?
This ensures that the info used is that of the correct node. Because the
activeFields function contains the information from the last node that
referred to the same field.
Example:
<tree>
<field name="a"/>
<field name="a" context='{'b':"yop"}'/>
</tree>
For the first field:
FieldInfo.context = {}
activeField.context = {'b':"yop"}
For the second field:
FieldInfo.context = {'b':"yop"}
activeField.context = {'b':"yop"}
Part of task: 3179751
closesodoo/odoo#113874
Related: odoo/enterprise#37621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We take advantage of the change of api made in commit
145540921f to rename FieldsToFetch to
relatedFields.These two commits are in the same version of odoo (16.2).
FieldsToFetch is not a good name for defining the fields to be fetch for
relational fields. So we decided to rename it to relatedFields.
Part of Task: 3179751
closesodoo/odoo#113963
Related: odoo/enterprise#37651
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit changes some of the way that users will
work with subtasks in the project app.
Initially, it changes subtasks from a many2many to
a one2many field.
We also add the ability for subtasks to be viewed
straight from the kanban view by drawing a list of
them inside of the kanban box of the parent task.
task-3085016
closesodoo/odoo#112279
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this task is to ease the deletion/archiving of recurrent
tasks by giving the user the option to either continue
or stop the recurrence. The two main use-cases are:
\- You have a recurring task for a weekly meeting.
Next week, the user will be on time off. You are thus deleting the task.
However, you would still like tasks generated for the following meetings
and to keep track of the previous meetings.
\- You have a recurring task for a weekly meeting with an employee
that has just been fired. You are thus deleting the task and
you won't need this recurrence anymore.
(You may or may not want to keep track of the previous meetings.)
The main issue we are currently facing is that we need a task that acts
as a template for the recurrence to continue. This means that a user
cannot delete all of his tasks without breaking their recurrence.
Consequently, we will be using a "task template" for each recurrence,
which will only serve technical purposes and be invisible to the users.
When the recurrence is stopped, the task template is deleted.
This simplifies the technical and functional implementation as the user
won't be able to modify the template themselves.
\- Added task templates to recurrences in the data.
\- Deleted "all tasks" option form recurence update and changed "this
and following tasks" to "this and future tasks". Most of the time, the
user is going to update the most recent task, and it doesn't make
any functional sense to update past ones.
\- Same options for delete and archive.
\- No recurrent subtasks allowed anymore.
\- `date_deadline` is copied. We compute it by adding the delta between
the create date and the `date_deadline` of the template to the next
recurrence date.
\- Added filter to several view not to display task templates.
task-2937565
closesodoo/odoo#98088
Related: odoo/upgrade#4232
Related: odoo/enterprise#30416
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, when the user drags and drops a task from a stage
to another one in the kanban view of tasks of a project, the kanban
records in the destination stage will be re-sequenced and this
re-sequence will re-render the kanban. For this reason, the
`onWillUpdate` hook in the control panel will be trigger many times
and each trigger will fetch the last project update.
This commit will remove the `onWillUpdate` hook to avoid re-fetching
the last project update when a change is done in the kanban view and
so, the last update of the project will be just fetch when the
component is mounted since the last update is not impacting when a
task changes stage.# Please enter the commit message for your changes.
closesodoo/odoo#110961
X-original-commit: 6117f41f52c45710d313c128bbce1d364dc40b93
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- Description: before this fix, some tips of the project tour poped up
in other apps when the tour was not finished. With this fix, those
particular tips are only displayed in the project app.
- Implementation: Some triggers used in the project tour are generic
class that are also used in other modules (in this case, classes
related to the chatter). When leaving the tour at those steps, the
tip in question will pops up every time this class appears in other
apps (i.e. often for classes related to the chatter). To fix this, the
parameter extra-trigger is used for tour steps related to a generic
class.
closesodoo/odoo#110716
Task: 3024151
X-original-commit: c8f86844a427e0f9665b6f9c5e9e182795fb809e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
When a project is shared as editable and the url keeps the access token,
it causes a traceback when a task is open. This is due to owl trying to
evaluate a the access token value as a string.
This commit fix it by wrapping the value so the owl component can
evaluate it and get the access token value as a value and not as a
string.
task-3073965
closesodoo/odoo#109351
X-original-commit: 865a45bd170ad15a10b3a3572471f4bf6b5648e4
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project, web
This commit converts the Activity view to the current framework shared by
other views. Instead of extending Kanban view/elements, the Activity view
has been implemented by its own.
The project customization of the view has also been converted, as legacy
files have been removed.
Some tests have been adapted since some classnames might differ from the old
implementation, resulting to failing tests. But the overall testing cases
have been conserved.
closesodoo/odoo#107916
Related: odoo/enterprise#35177
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Florent Dardenne <dafl@odoo.com>
This commit adds the ability to quick create records from the
kanban view when it is grouped by a many2many field.
This feature improve the user experience for multiple views, here are
some examples of new possible workflows:
- Project -> My tasks (this view is grouped by m2m) -> quick create
- Project -> Select a project -> group by Assignees -> quick create
- Multiples module -> group by tags -> quick create
The "My Tasks" view is grouped by the m2m `personal_stage_type_ids`
field which is a complicated computed field on which we cannot write. A
custom behaviour in their `ProjectTaskRecord` was necessary in order to
support this feature. Previously, they also implemented a custom
behaviour for this field to be able to move records between groups.
closesodoo/odoo#108150
Task-id: 2960497
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, the translation banner is displayed inside the project
sharing view.
So in this commit hide the translation alert on sharing view of
the task.
task-3052597
X-original-commit: b39a5e4a1f074a53bf0bd0831b73564f52757d6e
Part-of: odoo/odoo#108440
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Description:
- project: Apply default filters when selecting a 'blocked by'
task in task form (project.task form view > blocked by notebook >
add a line > apply a default filter on the current project and on
open tasks)
- project, hr_timesheet: uniformize remaining hours display in
kanban view for tasks and projects (project.project kanban view:
add a frame around remaining hours. The color of the frame follows
the same rules as the one used in project.task kanban view)
task-3034806
closesodoo/odoo#104250
Related: odoo/enterprise#33309
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- switch the id and the priority fields from place for task list view
- add a 'view sales order' button that should open the form view of the SO
linked to the SOL set on the milestone for milestone list view
- add a 'sales order' stat button that should open the form view of the SO
linked to the SOL set on the milestone for milestone form view
- add a 'done' option; represent it in purple in status field
- if there is only 1 assignee, display its name on the card instead of
1 assignee for project sharing kanban view
- add an 'all tasks' menu on the right of the 'my tasks' one
task-2917086
closesodoo/odoo#97669
Related: odoo/upgrade#3893
Related: odoo/enterprise#30195
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Bruno Boi