Purpose
=======
To be able to customize the working flow on the task, based on their
project, we add a properties field on tasks, whose definition is stored
on their project.
Task-2965523
X-original-commit: 2f244769cbb1512875ae197aa8adc3efd34fd54b
Part-of: odoo/odoo#101487
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
This commit introduces the new calendar view written in owl.
closesodoo/odoo#101185
X-original-commit: e88988f58582d5b49a32d7102a74a176f40c4c69
Related: odoo/enterprise#31808
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
*: crm,link_tracker,project,sale,utm
Before this commit, in some form and kanban views, there were
missing whitespaces, typically between icons and texts. This was
due to the transition to owl views, because we simply ignored
`&nbsp;` in archs. This commit also fixes a layout issue in
a project view, where the icon and the field should be displayed
in the same line.
closesodoo/odoo#101040
X-original-commit: f5813e348b6052436a4fabaa5837ecc37b15430e
Related: odoo/enterprise#31746
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit transfers responsive related customizations for
ControlPanel, SearchView and SearchPanel to community which allows them
to render properly on smaller devices.
Note: a page reload (aka. F5) is required to properly adapt the UI after
a resize to a mobile-like size.
X-original-commit: 26a755610da36b01ba07ca224cc5937a672eb6a8
Part-of: odoo/odoo#100759
Before this commit, when the user wants to delete a stage in the My
Tasks menu, he got a user error because the context in the action cannot
be converted from string to a dictionary with literal_eval function. The
reason is `uid` is not replaced by the current user id before using the
`literal_eval` function.
This commit replaces the uid by the current user id and then apply the
literal_eval function.
Steps to reproduce the issue:
1. Go to Project App
2. Click on `My Tasks` menu
3. Add a group by `Stage`
4. Try to remove a stage in which there is no recurrence task
Current Behavior:
A traceback is occurred because the literal_eval cannot convert the
context from the action.
Expected Behavior:
The stage should be archived and tasks contained in that stage.
Bug found task-2944742
closesodoo/odoo#100599
X-original-commit: f4198e497fba8d22231ce22ea148b73e6e207d4c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The goal of this task is to review the copywriting of the tooltips
because some of them are not correct in English and others are not
valid anymore. This is also a good opportunity to make an inventory
of the tooltips we have and to add some that could be missing.
task-2862283
closesodoo/odoo#93261
Related: odoo/enterprise#28225
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Since odoo/odoo#98380, the `Set Status` can be selected in the `project.project`
kanban view, which was not previously feasible as considered as not suitable.
This commit prevents selecting that value.
task-2989015
closesodoo/odoo#100561
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The field personal_stage_type_id is dupplicated in the form view. It is once in
the status bar, once in the `Extra info` tab which is only displayed in debug mode.
This causes a traceback as this is not supported by the actual web client code.
closesodoo/odoo#100524
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this PR to improve generic usage of project app.
So, in this PR done following changes:
- In project.project form view :
- Divided settings into sections
- In project.update.search.view :
- Added author, description and status in quick search
- Added ancestor task in group by and replaced parent task with ancestor task
in search view
- In project.task search View:
- the filter for unread messages should be visible only if the current user
managing his notifications in Odoo
- Added my private task filter
- In project_task_view_graph
- Added a default project > stages group.
- In project.task form view:
- If stage is_closed added decoration-muted
- Replace/Add parent task with ancestor task' in group by and quick search
- analytic-tags set on project should be automatically applied to it's tasks
task-2844212
Part-of: odoo/odoo#93676
HtmlWithActionWidget was used in Project Updates
to handle <a/> tags in the html description.
Since odoo/odoo#72736 removes all those tags,
this widget is no longer needed.
closesodoo/odoo#100397
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
[IMP] core: store translated fields as JSONB columns
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
`NULL`
`{"en_US": "Foo"}`
`{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}`
`{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}`
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
` NULL`
`{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}`
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
`SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...`
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
closesodoo/odoo#97692
Task-id: 2081307
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose of this PR to improve the generic usage of project app
So in this commit done the following changes:
- when a project is archived, the 'tasks' stat button should
count/show archived tasks
- when delete project it's milestone should also be deleted automatically.
- project.task > blocked by notebook: it should be possible to select tasks
in projects that are not allowing 'task dependencies'
- project.task portal form view: hide the description if it is empty
task-2853991
closesodoo/odoo#94138
Related: odoo/enterprise#28654
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit allows to define steps in tours that drag&drop records
in (wowl) kanban views. The former helper is based on jQuery,
mostly because the drag&drop feature comes from jQuery. This
feature is still necessary for the legacy codebase using jQuery.
This commit thus introduces a new helper to allow the drag&drop
in wowl Component using, for instance, the `useSortable` hook.
This commit also fixes the project tour by making it use that
new helper. Note that even though the tour was broken (when run
"automatically", not in a user onboarding), runbot was green
because there's no test running this tour. It would be nice to
add one.
closesodoo/odoo#100208
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Now that web_studio no longer uses the legacy graph and pivot views and
that all their extensions have been converted, we can finally remove
them from the code base.
closesodoo/odoo#99734
Related: odoo/enterprise#31112
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since https://github.com/odoo/odoo/pull/90588, the personal stage is a required field in the task form view in debug mode.
However, we only generate personal stage for a given user when that user is first assigned to a task.
If a user creates their first task and assign it to themselves, they won't be able to give it a personal stage.
To prevent issues linked to the current users not having personal stages, this commit makes the field not required, but prevents the user from unsetting it
closesodoo/odoo#99735
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Since odoo#90588, the personal stage is a required field on the task form view in debug mode.
However, it does not make sense to have to set a personal stage when editing a task assigned to someone else.
This commit therefore hides the field when the user edits a task they are not assigned to.
Part-of: odoo/odoo#99735
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
Make mail_notification_layout as the default mail template and remove
message_notification_email. We now only have 2 main notification mail layout
templates (outside of a light one): the default one and one that inherits from
it to only change the signature to the responsible instead of the author one.
In this operation the layout of message_notification_email has been integrated
in mail_notification_layout to support outlook mail client for which
message_notification_email has just been reworked (odoo/odoo#92847).
Technical note: we have integrated the "internal communication" banner from
"message_notification_email" into the new default template
"mail_notification_layout" which cause one added query in the test for querying
the flag internal from mail.message.subtype.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
Before this commit, the commit [1] renames the routes to keep the url
and add the id when the user selects a task id.
However, the redirection is missing for `/my/task/<task_id>` due to
an issue in the routes selected for the redirection.
This commit redirects the `/my/task/<task_id>` to `/my/tasks/<task_id>`
to keep the old route accessible.
[1] b517fdc19dclosesodoo/odoo#99713
X-original-commit: db379b6838b8883ae8fef2659912854dd08cf31c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
- adapt the html field and mass_mailing_widget to be owl components
- adapt the mass mailing view to be an owl view
task-2898432
closesodoo/odoo#94875
Related: odoo/enterprise#30915
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the project field in task and timesheet models is
clickable in list view of those models.
This commit prevents to open the form view in the list view since the
form view of project is now more a view to configuration the project and
so once the configuration is done, the user will not always need to go
to that view.
closesodoo/odoo#99949
Related: odoo/enterprise#31212
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds the id of the project to the task values sent to the front end in the portal.
This allows us to easily know which project the task is in from the front end and direct the user to the right documents pages.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
closesodoo/odoo#99151
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit wraps the span containing the project name in the portal task list in a div, in order to allow easily adding the "Documents" button next to it.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
Part-of: odoo/odoo#99151
This commit renames a 'Task' variable to 'Task_sudo' in the _prepare_tasks_values method, to make it clearer that it does have sudo rights.
Enterprise: odoo/enterprise#30838
Upgrade: odoo/upgrade#3749
Task-2944247
Part-of: odoo/odoo#99151
Purpose of this PR to improve generic usage of project app.
So in this commit done the following changes:
- move the the filter 'tasks_due_today' and 'late_milestone' above the
'late' filter.
- change label for 'remaining_hours_on_so' according to timesheet uom.
- add placeholder in milestone wizard
- make remaining_hour field colour red when it's value < 0.
- added filter in project_sharing_view search view 'overtime',
'remaining_hours_percentage','tasks_due_today','late_milestone',
'open_tasks','closed_tasks','closed_last_7_days','closed_last_30_days'.
- added optional field in project_sharing_view sub-task list view
'subtask_effective_hours', 'total_hours_spent','priority','remaining_hours_so'.
- added optional field in portal tree view 'timesheet_uom','progress','priority',
'portal_user_names','remaining_hours_so'.
- re-arrange quick search options in search view options in portal view.
- make the 'subcontract service' field company dependent and add
fa-building icon on form view.
task-2889829
closesodoo/odoo#96149
Related: odoo/enterprise#29563
Related: odoo/upgrade#3712
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit introduces a new digest tip which
informs the user about the possibility to create
tasks in a project by receiving an email in its
email alias.
If a project with an email alias is set up it will
show it as an example. Otherwise the tip will be a
generic message.
This introduction will further help explain odoo
capabilities to its users.
Task-2973540
closesodoo/odoo#99740
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit (and its enterprise equivalent) purpose is to smooth the
user experience and remove unnecessary steps.
The commits:
- Remove all stat buttons except the status and collaborators one from
the project edit form.
- Add multiple small changes to string/name fo fields in views
- Change the custom O2M widget for a standard M2M for the management of
child tasks
- Add the milestone field to the portal page of shared project.
- Remove the wizard 'marked_as_reached_milestone'
- Add the automatic generation of milestone when a SO is confirmed if
some SOL need it
task-2941835
closesodoo/odoo#98546
Related: odoo/enterprise#30628
Related: odoo/upgrade#3798
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Prior to this commit and since odoo/odoo#98913 and odoo/odoo#95729
the `xpath` that are using `company_id` in the views that inherit
`project.view_task_tree2` and `view_task_form2` are no more working
as the `xpath` targets the first match.
This commit fixes this issue.
closesodoo/odoo#99232
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- apply the 'open tasks' filter by default for my task menu
- the search view set the one from accounting and not timesheet for
gross margin stat button
- add a 'stalling for 30 days+' filter that should return open tasks whose
last stage update was more than 30 days ago for project task form view
- move the 'stage' quicksearch above the 'project' one for burndown chart
- when archiving a project containing tasks that are recurrent, disable their recurrence instead of
raising an error
- format some field in timesheets notebook in project sharing
- display the 'rating email template' field by default for task stages
task-2899490
closesodoo/odoo#95636
Related: odoo/enterprise#29270
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The master plan finally comes to an end.
Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
on back-end views.
The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.
The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...
Not including the groups in the cache key allows:
- to have less cached versions,
(otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
(with the current cache key,
there is nothing to fetch from the database to compute the key)
Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
- parsing arch from/to string with etree is fast,
- removing the `groups=` nodes using etree is fast,
- adding the `create="False"`, `write="False"`, `delete="False"` on the view
root node according to the access right of the user on the model is fast.
This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.
Timing tests are available on the pull request of this revision.
Part-of: odoo/odoo#99417
Purpose of this PR to improve generic usage of project app.
So, in this PR done following changes:
- In project.project form view :
- Added name label above name field
- Changed placeholder name of field to 'e.g. Office Party'
- in project_project_view_form_simplified:
- displayed name as Title
- renamed 'create' into 'create project'
- in project.task form view > extra info notebook :
- added the 'personal stage' field (Only visible in debug mode)
- in project.project form view:
- based timesheet encoding unit set the 'cost' field name to Daily cost
if uom in Days or In Hourly cost if uom in Hours
- configuration > projects: if possible, clicking on a project kanban card
will be open its form view
task-2821488
closesodoo/odoo#90588
Related: odoo/enterprise#26977
Related: odoo/upgrade#3492
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the 'recurrent' field still be visible even if the
'recurring tasks' feature is disabled in the settings.
So in this commit, fixes the issue by adding the recurrent group and
updating the attrs on field.
task-2858336
closesodoo/odoo#99392
X-original-commit: f83451b9ba86fd919184fc78093535625c0459ef
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, Chatter in project sharing: the
'employees only' and 'visible' buttons are not toggled and both
are visible at same time.
So in this commit fixes the issue by making the 'employee only'
and 'visible' button as toggle button same as portal chatter.
task-2858336
closesodoo/odoo#99326
X-original-commit: eee722bb74db70a49ba88250afd0359c510e5ade
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In this commit we have modified the planning explanation in the project settings
in order to accomodate the removal of tasks from the planning app
(see enterprise repo of the same branch)
task-2941828
closesodoo/odoo#98035
Related: odoo/enterprise#30404
Related: odoo/upgrade#3771
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Non total order can lead to randomized order in some case, making some
test behaviour random and/or difficult to debug.
Adding some fallback 'id' order shouldn't hurt
closesodoo/odoo#99324
X-original-commit: 6e40e5fe775273a2d3a968ac113cbeb578318dd1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, when the portal user changes the stage of a task and
the new stage contains a rating template email, he got a traceback
saying he has no access to `mail.template` model.
This commit fixes the issue by sending the email in superuser when we
are sure the user can write on that task.
Steps to reproduce:
==================
1) Enable the rating feature in the settings of Project App
2) Create a Project A and edit it to enable the rating feature on that
project and select "Rating when changing stage" (if it is not already
the case)
3) Set a rating email template on a stage of the project
4) Create a new task and save
5) Change the stage of that task to the stage contained the rating email
template
Actual Behavior:
---------------
A traceback is occurred saying the user has no access to `mail.template`
model.
Expected Behavior:
-----------------
The stage of the task should be changed and the rating email should be
sent.
closesodoo/odoo#99248
X-original-commit: c5093988411e5697f49ca2a128e93203c2d6aac9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, all the custom code for the widgets, form, list and
kanban views are always in OWL and have to be migrate to the new JS
framework.
This commit converts all the widgets, list, kanban and form views used
in the project app in OWL. Some JS tours has been adapted according to
the OWL views, the project right side panel has been reviewed since it
was LegacyComponent (in old component in OWL)
task-2944742
Part-of: odoo/odoo#98380
The goal being to get rid of the `groups_id` feature for backend views
See the related commit in the enterprise part of this pull request.
Here is the commit message for easyness:
In this case, the renaming of the label to "planned date"
is done directly in the base view,
in the community part of this pull request.
It made no sense to change the label from "Dates" to "Date Planned"
when you became a planning user, for all projects.
Either it should be "Planned date" for everyone,
either it should be "Planned" date only for projects using planning.
But not when the user is granted "Planning / User".
It was decided to make this label by default in the base view
Part-of: odoo/odoo#98551
William Braeckman