The mail code had to override both new and old form views to add the
chatter feature. Since we converted (almost) all uses of the legacy
form view to the new owl views, the old override is no longer necessary.
This commit removes it, and also removes the 'legacy_form' entry in the
registry so all screens should fall back to the new form view, which is
stable.
closesodoo/odoo#110168
Related: odoo/enterprise#35924
Signed-off-by: Aaron Bohy (aab) <aab@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
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Change 'auto_delete_message' into 'auto_delete_keep_log' that has the inverse
meaning. Indeed it is unclear what 'auto_delete_message' really does. It is
used when automatically removing emails sent through mass mailing, to know
if message created through inherits are kept or not. Purpose of keeping them
is to have a log on the document. Deleting the message therefore removes the
log.
In this commit we change the meaning to something positive, keeping logs being
clearer when choosing which option to activate. Functional usage of the field
itself does not change with this commit.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When a message is processed through the mail gateway, the partner should
never be set as the assignee of that task.
This commit allow to correctly let pass `{'default_user_ids': False}`
context from `message_new()` down to `create()`
closesodoo/odoo#110124
X-original-commit: 08e24d683bf19a77982a7ffba6c64b5fc6fdf85a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The function remove_domain_leaf is currently used for project burdown
chart. Due to an increasing need of such a function in multiple modules
for various functional cases, it has been decided to:
- Move this function in 'resource' that is imported in all the modules
where this function is needed.
- Implement extensive unit test to ensure that it address corner cases.
- Refactor the function to address the corner cases it was not
addressing until now.
The refactored function 'filter_domain_leaf' is used to transform a
given domain to a new domain using only the leaves that verify a given
check (more precisely, the leaves whose first element verify this check). To perform this transformation, the leaves that do not verify
this check are considered as undetermined. All the logical operators
dealing with undetermined leaves are ignored, which means:
- AND(leaf, ?) = leaf
- OR(leaf, ?) = leaf
- AND(? , ?) = ?
- OR(?, ?) = ?
- NOT(?) = ?
If the result of the operation is undetermined, it is returned as an
empty domain ([]).
closesodoo/odoo#105470
Related: odoo/enterprise#33657
Related: odoo/upgrade#4221
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*=hr_timesheet,sale_project,sale_timesheet,spreadsheet_dashboard_hr_timesheet
The main goal of this PR is to minimize code duplication for the search and list views for tasks and projects.
Task search views
-----------------
The most important change was to merge the search views used in the task reports with the "normal" corresponding search view. The reporting search view should now be almost identical to the normal one in both project and fsm.
The `project.task`/`project.task.user` search views are now following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
┌──┤4│ │7├──┐
│ └┬┘ └┬┘ │
│ │ │ │
┌▼┐ ┌▼┐ ┌▼┐ ┌▼┐
│5│ │6│ │8│ │9│
└─┘ └─┘ └─┘ └─┘
```
1. `view_task_search_form_base`: Base search view containing all the fields/filters common to project, project sharing and fsm
2. `project_sharing_project_task_view_search`: Search view for project sharing.
3. `view_task_search_form_project_fsm_base`: Base search view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_search_form_project_base`: Base search view for project only, with fields/filter common to the normal search view and the one used in reporting.
5. `view_task_search_form`: Search view for project.
6. `view_task_project_user_search`: Search view for the project report.
7. `project_task_view_search_fsm_base`: Base search view for fsm only, with fields/filter common to the normal search view and the one used in reporting.
8. `project_task_view_search_fsm`: Search view for fsm.
9. `report_project_task_user_fsm_view_search`: Search view for the project report.
With this organization, we can easily add a field to both fsm and project at once, and even to project sharing at the same time. Since the goal is to keep the reproting search views identical to the normal ones, it'll also add the field to both of them.
Task list views
---------------
Similarly to the search views, the task list views were also refactored to minimize code duplication, following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
│4│ │5│
└─┘ └─┘
```
1. `project_task_view_tree_main_base`: Base list view containing all the fields/filters common to project, project sharing and fsm.
2. `project_sharing_project_task_view_tree`: List view for project sharing.
3. `project_task_view_tree_base`: Base list view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_tree2`: List view for project
5. `project_task_view_list_fsm`: List view for fsm.
Project views
-----------------
The search and list views for projects in fsm now inherit the ones from project, since our goal moving forward will be to keep those as similar as possible.
Other changes
-----------------
- Merged and removed many filters/fields from the task search views.
- Changed `total_hours_spent` and ` subtask_effective_hours` labels in `project.task` model to avoid changing them manually in many views.
- Renamed `state` into `kanban_state`, `hours_planned` into `planned_hours` and `hours_effective` into `effective_hours` in `report.project.task.user` to make it consistent with `project.task` (so we can keep the same views for both of those models).
- Moved the sale line filed in the "Settings" tab in the project form view (so that the `sale_line_employee_ids` field in "Invoicing" takes the full width).
---
Enterprise: https://github.com/odoo/enterprise/pull/34106
Upgrade: https://github.com/odoo/upgrade/pull/4216
Task-2746370
closesodoo/odoo#106015
Related: odoo/upgrade#4216
Related: odoo/enterprise#34106
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit adds default groupBy for task list view
to represent data properly menu vise.
- add default groupBy stage for tasks from project action.
- add default groupBy personal stage for `My Task` menu.
- add default groupBy project for `All Tasks` menu.
task-3084850
closesodoo/odoo#109281
Related: odoo/documentation#3311
Related: odoo/enterprise#35504
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit when user creates a private task user
still able to customer and sol field which no use for
private task.
This commit hide customer and sol field for private task
and reset customer field when user make non private task
to private task.
task-3084850
Part-of: odoo/odoo#109281
The form view of project.task in project sharing is modified to be
similar to the classical form view of tasks (in backend). A
priorititization is added to the views of project.task for project
sharing used in the following modules:
- project
- sale_project
- hr_timesheet
- sale_timesheet
task-3119935
closesodoo/odoo#109067
Related: odoo/enterprise#35421
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
When sending an email with an inlined image to an alias of a project,
the image is broken in the task description.
Expected behaviour:
The image should be rendered correctly.
Steps to reproduce:
- Install Project
- In Settings add a custom email server and set a domain alias
- Create a new Project and in it's settings create an email alias
- Send an email with an *inlined* image. (not attachment)\
- Image is not rendered correctly in the newly created task.
Reason for the problem:
Email with an embedded/inlined images are multipart, one is containing
the base64 encoded image and has a `content-id`, another one is the
html body that has an `<img/>` which source is a `cid` that references
the `content-id` of the encoded image. When parsing the email when
creating the task, we only take into account the `html` part of the email,
which becomes the `message.body` which is used to fill in the description.
Therefor we have an `<img src="cid:..."/>` that references nothing.
Fix:
Use the already parsed and sanitized `message.body` from the message's thread,
which converts the `content-ids` into relative links to web images.
We fill with that the description's body.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3062444
closesodoo/odoo#109354
X-original-commit: 3c805400045f2ccc8ad4228eb5718af0e22a8027
Related: odoo/enterprise#35543
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
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>
Before this commit, when the user cannot write on a certain field
an error is occurred to notice the user, he cannot write on that field.
The problem is the `on` is never translated.
This commit fixes the issue to be sure the whole error message is
translated.
closesodoo/odoo#109288
X-original-commit: 5098c59cc6d1a853210f8c4f5340f0d4ee8dd883
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit will reduce the width used by the task name in form view to 75% of the
space available, except when in mobile view where it'll take full width.
The title doesn't need to take the whole space but only about 3/4 of it in form view
Side note: this may need to change once the mark-as-done 2 task is merged
because a new wider widget will replace the kanban_state widget
closesodoo/odoo#109258
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 moves some parts of the code used by the progress bar of kanban
to its own component. It is now clearer to distinguished its code from the
renderer code (see crm_kanban_renderer). Also, it allows to re-use this
component in other views without making a direct use of 'kanban' elements.
The KanbanAnimatedNumber component has simply be renamed to AnimatedNumber,
as this naming suggested the element was only used as a Kanban element. This
more generic name now indicates that the element can be imported and used in
other places.
Part-of: odoo/odoo#107916
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>
Before this commit, the content of the stat button not aligned.
So this commit fixes by the stat button's content is aligned to the left and vertically centered.
task-3054386
closesodoo/odoo#108504
X-original-commit: e87284cebe64cc1f5bf31198ca221f14cffdc671
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when alias name is too long then it was going to
display in the new line and ui is broken in the project kanban card.
So in this commit, if alias_name is too long then truncate the
text and display the ellipsis for name in project kanban card.
task-3052597
X-original-commit: fb111d1f828a4e7580afe758e5c6dbfc9d16a51d
Part-of: odoo/odoo#108440
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
Description of the features in this PR:
add the date deadline to the order of tasks (sort priority)
add the day of the week (only the first 3 letters) for the recurrence message in recurrent tasks
display the name of the project in the action instead of 'Project Sharing'
By changing the sorting order of the Project.Task model
some indexations in the tests didn't point to the right tasks
Now each task that has a deadline will be placed in front of other tasks (except for the high priority task)
Task-3034635
closesodoo/odoo#105701
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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
The method domain_remove_leaf is used to remove leaves from a domain
corresponding to given fields. The particular case ['|', leaf_to_remove,
leaf_to_remove] is replaced by [true_leaf] however the check of the
second element of this subdomain was incorrectly done. This fix
addresses this issue.
Fixes https://github.com/odoo/odoo/pull/93225closesodoo/odoo#108188
X-original-commit: 44578077b16b540a0270ea7257f902a2e917f79c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when a db is loaded without demo data, or that a user has no
task assigned and no personnal stage, the view 'My tasks' is empty. The
purpose of this commit is to assign default personnal stage to a user in
these case to ease the understanding of new user of what the view can be
used for.
This commit :
- add default personnal stage to user the first time he clicks on the
'My tasks' menu if the user has no personnal stage and no task are assigned
to him.
task-3047496
closesodoo/odoo#105940
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Computing the recurrences of a task repeating every X months until a
certain date generates too much dates
Steps to reproduce:
1. Install Project
2. Go to Settings > Project > Tasks Management and enable Recurring
Tasks
3. Open any project in the Project app and create a new task then edit
it
4. Enable the Recurrent field of the task
5. In the Recurrence tab, edit:
- Repeat Every: 6 Months
- Until: End Date: one year from now
6. The recurrence message says there are 11 tasks but there should only
be 2
Solution:
Generate the recurrences until the `repeat_until` date is reached if the
`repeat_type` is 'until', otherwise generate as much recurrences as the
count
Also relax the constraint on the `repeat_day` and `repeat_until` to not
raise an error if `repeat_until` is the last day of the month
Problem:
The recurrence of a task with `repeat_unit` month and `repeat_interval`
different than 1 with a `repeat_type` until creates too much tasks,
exceeding the `repeat_until`
opw-3076593
closesodoo/odoo#107910
X-original-commit: 236b383fd9d1ad6a5d39d8c4232b49864ec19b37
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Small fixup for already merged PR: 103318
stage_display column should have 'Stage' as a header, not 'Stage Display'
added the stage_display field to 'All Tasks' list view
Task-3024152
closesodoo/odoo#107407
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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>
Steps to reproduce:
- activate "Recurring Tasks" option inside Project settings;
- go to "Field Service" app;
- create a task;
- check recurrence box;
- make the following configuration in the recurrence tab:
* Repeat Every 6 Months
* Repeat On Date of the Month 1
* Until End Date [your choice]
Issue:
The dates calculated for the recurrence are not correct.
Cause:
When we select an interval other than 1 for a frequency in months, we do not divide the number of months between the start and end date.
And therefore the loop that calculates the recurrence dates goes too far into the dates.
Solution:
Divide the number of months between the start date and the end date by the interval.
opw-3078084
closesodoo/odoo#107320
X-original-commit: 5d44d7d595dab866695945e5a6d2091ddd9df342
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- project.task form view:
- move the tag_ids field below the user_ids one
- move the 'allocated hours' field above the 'deadline' one
- remove the 'progress' field and indicate (x%) next to
'allocated hours' instead
- the final output should look something like
- 10:00 (incl. 05:00 on Subtasks) (50%)
- the timesheets o2m takes the whole width of the notebook
task-3046210
closesodoo/odoo#104677
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@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>
Before this commit, the progress bar was missing since the progress bar CSS
wasn't loaded to the project sharing webclient.
So in this commit, the progress bar CSS path has been added to the manifest file
for the project web client.
task-3014420
X-original-commit: 84caa0bb2f8a3095c4b98b35ab72f85fd456943a
Part-of: odoo/odoo#106815
- 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>
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done following changes:
- rename 'total hours' into 'total hours spent' (or 'total days spent' if the
timesheet encoding unit is in days) for project.task
- timesheets (billed on timesheets) section > group the graph view by
invoice > employee
- add default action project update > profitability> timesheets
(billed on timesheets) section > group the grid view by
invoice > employee (display sections)
- add default the 'timesheet costs' measure in pivot view
- display 'hours remaining' in red if the number is negative for project.task
form view
- display the 'week' scale by default in the grid view
task-2819458
closesodoo/odoo#90270
Related: odoo/enterprise#26795
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit:
When task project is changed in through the view the kanban_state remain the same
until the record is saved.
After this commit:
When changing project, kanban_state is changed to 'normal' direclty.
task-2849291
closesodoo/odoo#91174
Related: odoo/upgrade#3523
Related: odoo/enterprise#27287
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
After this commit:
- When duplicating project or task, assignment notifications and emails on stages are not sent
task-2849291
Part-of: odoo/odoo#91174
Before this commit:
- Task followers are not copied when creating subtasks
After this commit:
- Created subtasks have the same followers as their parent task with the same subtype_ids
task-2849291
Part-of: odoo/odoo#91174
Purpose of the commit is to do the generic improvements for project app.
So in this commit did the following changes:
- add the 'creation date', 'last stage update', 'SOL', 'my deadline' fields in
project task list view.
- add the 'my deadline', 'next activity' fields in project list view.
- crop the label of the stage after x characters in task portal form view.
- remove the 'collaborators' stat button from project update right-side panel.
- renamed sold->sales, services->sales order items, effective->delivered,
remove the totals, include non-service SOLs, increase the size of the SOL
column
task-2928100
closesodoo/odoo#97870
Related: odoo/enterprise#30268
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the user removes a personal stage in Project
app and this personal stage has some tasks, the kanban model will reload
the data instead of delete the group. However, since the
`default_group_by` is personal stages then the group deleted stays
visible in the UI even if it is deleted for the backend side.
This commit flags the group deleted to avoid readd the empty group
when the reload is done to correctly remove the group in the UI.
task-2968326
closesodoo/odoo#105801
X-original-commit: ad5a569b6ee50cc2c643975b52f23b9df385b753
Related: odoo/enterprise#33967
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, in project right side panel (when the user goes to
project update of a project) when the screen width is below then 1600px
the number of stat buttons is reduced to 3 stat buttons instead of 4.
The problem is in mobile view, there is no enough space to display 3
stat buttons in a row.
This commit reduces the number of stat buttons to 2 instead of 3 when
the user is in a mobile view.
task-2968326
X-original-commit: 50d710993d0a37526f75430f87310b2a2d67d69d
Part-of: odoo/odoo#105801
Before this commit, when the user accesses to project update
view of a project with a mobile, the view auto scroll to the kanban
renderer and so the user will not directly see the right side panel
displayed above the kanban renderer when the view is a mobile view.
This commit changes the position of the right side panel to add the
ProjectRightSidePanel before the KanbanRenderer (or ListRenderer)
component, to avoid using `flex-direction: column-reverse;` in mobile
view because there is a auto-scroll because of that css property. And
so, the `flex-direction` will be `row-reverse` by default and when the
view is a mobile one, the `flex-direction` will be `column`.
task-2968326
X-original-commit: 05e46f779b9eb625dcd17a00c1c2228650a8f8d8
Part-of: odoo/odoo#105801
Before this commit, when the user resizes a column to increase its size,
the list view will be below the right side panel and it was impossible
for the user to horizontally scroll to see the part of the list view
below the project right side panel.
This commit removes the `overflow-x: hidden;` on the list to be able to
horizontally scroll the list view as it is the case for the all others
list views when the size of list view is bigger than the width of the
screen.
task-2968326
X-original-commit: 865c510d7c015db97e19c77609dac864b7065f92
Part-of: odoo/odoo#105801
Géry Debongnie