auth_totp module added user_id in session_info, but it's not in the depends of project and web_editor module.
To avoid traceback after uninstalling auth_totp module:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '0'),
we should use uid instead of user_id in js code.
closesodoo/odoo#96880
X-original-commit: 81b92a61907028f71b1337b11d0d60ee98bb5775
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit introduces some information/instructions regarding the access
to the project/tasks depending on what the user has selected for the project visibility.
This should reduce confusion and thus increase productivity on the user side by
making the task of granting access rights more straightforward to the user.
closesodoo/odoo#95947
Task: 2917471
Related: odoo/enterprise#29455
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
form
Before this commit, when the internal user without any access rights to
the Project app and has a link to access to the form view of a "public"
project, an access error is occurred when that user when to access to
the
project form view. The reason is the `project.collaborator` is only
accessible to the user with an access right to the Project App and since
the number of collaborators displayed in a stat button is computed with
the access rights of the current user, the compute cannot be done for
the
internal user.
This commit executes the compute is superuser to prevent the user having
access error and to correctly access to the project form view as before.
Steps to reproduce the bug:
--------------------------
1) Create a Project P and add *Marc Demo* in the followers of that
project
if the Privacy Visibility is "Invited internal users".
2) Remove the access rights to the Project app for *Marc Demo* user.
3) Copy the link to the form view of project P.
4) Log in as *Marc Demo*.
5) Paste the link copied in step 3 to access to the form view of project
P.
Actual Behavior:
---------------
An access error is occurred because the user without any access to the
Project app cannot access to the `project.collaborator` model.
Expected Behavior:
-----------------
The internal user without any access rights to the Project App should
access
to the form view of the project P.
closesodoo/odoo#96497
X-original-commit: c725c3fbb29eff49eff3794aff9d407175599e63
Signed-off-by: Xavier <xbo@odoo.com>
Purpose of this commit
======================
The Burndown Chart report was very slow on big databases as it was not
possible for Postgresql to optimize the query as it was based on a view
that was using several generate series.
This commit aims to improve the performance by injecting the constraints
at a lower level than it was in the past, lowering the amount of data
processed in the higher level of the query.
/!\ Important note
------------------
Overwriting the `read_group_raw` is really not a good practice and should
be avoided in most case. If you fall on this implementation by grepping
the source code, please be advised that this is not the right way of doing
things.
Implementation details
----------------------
- The report is now run by generating the `SQL` that is executed by the
`read_group_raw`. This allows inserting `SQL` constraints at a lower
level and simnifically improves performance. As there is no other way
to do it, the code is unfortunately a modified copy of the actual
`read_group_raw`.
- The pivot view has been removed as it had no meaning and was creating
confusing data.
- The `Group By` menu has been limited to `stage_id` and `date` as bringing
more data trough the different `GROUP BY` statements up to the higher level
is costly. Further more, additional `Group By` did not bring added value
as the Chart was less readable.
- The JS code has been adapted in order to force a group by both `stage_id`
and `date` so that the date displayed is always making sense.
- The sort ascending and descending options have been removed as creating
confusing data.
- The compare with previous period has also been removed as the chart only
really make sense when seen chronologically.
- A lot of tests have been added in order to ensure that changes that would
be harmful for the report will trigger test fails.
task-2845729
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Prior to this commit, `test_delete_project_with_task` is part of `TestProjectCommon`
which is inherited in several tests. Because of that, `test_delete_project_with_task`
is run several times, which is not relevant.
This commit moves the tests into a new class in order to prevent it to be run
several times.
task-2845729
Steps to reproduce the bug:
- Let's consider a project P with 2 stages S1 and S2 where S2 is a closing stage
- Create a task T in P and set T in S1 with a deadline in the past
- Pass T to S2
Bug:
T was still appearing when selecting the filter Late tasks
opw:2900663
closesodoo/odoo#96308
X-original-commit: a88611e634ca74478308c274e43ea0de0d4716b2
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit does the following changes:
- Improve some project filter and views
- Align the module kanban buttons
- Sort the module in uninstallation wizard
task-2731708
closesodoo/odoo#83339
Related: odoo/enterprise#23783
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit directly add the `default_project_id` key in the
`ProjectRightSidePanelComponent` component to get it in all components
which extends on the that component.
task-2861207
Part-of: odoo/odoo#95721
Before this commit, the route used for the project sharing always used
the old one.
This commit changes the url to use the new one to avoid redirecting the
old route to the new one each time the user goes to the Project Sharing
feature.
closesodoo/odoo#95677
X-original-commit: 73e6438f1b294ac274dffccc9c4b97dbfc0e3e50
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, the redirection does not take into account the
parameters passed into the url.
This commit uses the full path instead of the path to get the url with
the GET parameters.
X-original-commit: 9570d284324ffef4d11575115f1f232e0191b895
Part-of: odoo/odoo#95677
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Since https://github.com/odoo/odoo/pull/85176, following a conflict resolution in a forward-bot,
the domain used to show the "Recurrent" option in the form view
of tasks is wrong, and the option is shown for all unarchived tasks,
regardless of whether the setting is enabled.
This commit fixes this domain.
closesodoo/odoo#95015
X-original-commit: f26d864da52a3543d9f9733b2833a3210d5449f6
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Setup was conditionally done in render lifecycle methods, but it could be moved
to init instead, allowing to simplify the code and remove unnecessary methods
and overrides.
Part of task-2871070
closesodoo/odoo#94307
Related: odoo/enterprise#28893
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
- Let's consider a project P with a task T
- P has has two stages S1 and S2
- From T, create a new sub task ST1 with a new stage S3
- From T, create an other new sub task ST2 and try to select S3 as stage
Bug:
ST3 was not displayed in the available stages
Fix:
The stage ST3 is available for every task or sub task
opw:2873640
closesodoo/odoo#94487
X-original-commit: 5254407f5a593f37a1f21d43a725504c8dc0ab6d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
This commit brings some user experience improvement:
- Add a line break between the content of the email and the
'this customer survey has been sent...' indication in mail template
- Move the project_ids field out of the debug mode
task-2792027
closesodoo/odoo#92048
Related: odoo/upgrade#3579
Related: odoo/enterprise#27655
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, portal followers of a project and its tasks are removed when
the project visibility is changed to something else than portal.
=> We want to keep the behavior, but only when changing the visibility
from portal to something else.
When the project visibility is changed to portal, we currently add
its customer to its followers.
=> In that case, we also want to add the customer of the tasks to the
followers of the corresponding task.
When the customer of a project in portal visibility is changed, the
new customer is added to the followers of the project.
=> We want to remove this behavior.
When a project is created with a customer and the portal visibility,
the customer is added to the followers of the project.
=> We want to remove this behavior to avoid mistakenly showing a project
that is not ready yet to the customer.
This commit implements those changes, and also adds a warning when
changing the visibility of the project if that change will automatically
add/remove followers to the project and its tasks.
Related: https://github.com/odoo/enterprise/pull/25800
Task-2812551
closesodoo/odoo#87747
Related: odoo/enterprise#25800
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, all of the tasks contained in a stage are archived
when the stage is archived. However, the tasks remained archived
when the stage is unarchived.
So in this commit, If the user unarchives a stage, ask the user to
unarchive the tasks it contains in the process.
task-2835624
closesodoo/odoo#94008
Related: odoo/enterprise#28301
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this PR to improve generic UI of project app.
So, in this PR done following changes:
- Added group by assigned to under reporting -> customer ratings
- In quick search, changed "rated rated" operator to "assigned to" under
project.project search view
- Removed rating_status field from project > configuration > settings > customer
ratings
- Switched the 'timesheets' and 'planning' features from place from
project > configuration > settings
- In project.task extra info notebook:
- Added the 'parent task' field above the 'analytic account' field
- Added the 'company' field above the 'sequence' field
- Added send mail and sms action in project.project and project.task
list view.
task-2806292
closesodoo/odoo#88446
Related: odoo/upgrade#3459
Related: odoo/enterprise#26207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The project privacy_visibility tooltip doesn't reflect the actual behavior
for the "Invited portal users and all internal users" selection.
This commit rephrases the tooltip of that field in order to correctly match its behavior.
It also slightly changes the name of the options to match the new tooltip.
Task-2871771
closesodoo/odoo#93911
X-original-commit: 9ef7030e3346eda267bc27b47a8a168acdc4a7b9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when we use a domain list made by the old
implementation of the Domain in js and in this domain we have a date in
a right leaf then this date is an object of Date class. However, with
the new implementation of the Domain, the date will be converted into a
PyDate/PyDatetine object and so when we create a domain with the new
implementation by giving a list containing the result of the old
implementation. The date will be converted as a plain object instead of
a date formatted or instead of a date object.
This commit converts the list in string before using `Domain.and` with
the new implementation to having a date formatted as a string to avoid
the issue.
for instance, when the user choose a filter containing a date in the
right of a leaf in the domain. The old implementation of domain class
will return `[['date', '=', new Date(1970, 1, 1)]]`
```js
new Domain([['date', '=', new Date(1970, 1, 1)]]).toList()
// result: [['date', '=', {day: 1, month: 1, year: 1970}]]
```
if the list is converted as a string before passing the result will be:
```js
new Domain(JSON.stringify([['date', '=', new Date(1970, 1, 1)]])).toList()
// result: [['date', '=', '1970-01-01']]
```
closesodoo/odoo#93884
X-original-commit: 44d4a44dc4695b40a52c7d4cfccf0e9238d39b19
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Steps to reproduce
------------------
1. Install project and fsm.
2. Enable a basic project feature (sub-tasks/task dependencies) in the settings.
3. Enable the same feature on the fsm project.
4. Disable the feature in the settings.
5. The feature is still enabled on the fsm project
- This can be hard to see since the field will be hidden on the settings of the project, but you can see that the "Sub-tasks" tab is still visible on tasks if you enabled sub-tasks.
- Also, when re-enabling the feature globally, it should be disabled for the fsm project, but won't be.
Expected behavior
-----------------
The feature should be disabled on all projects, including fsm ones, when disabling it globally
---
This commit fixes this bug by selecting all projects, and not just basic ones,
when disabling a basic feature globally, to disable that feature on all projects.
Related: https://github.com/odoo/enterprise/pull/28036
Task-2871448
closesodoo/odoo#93820
X-original-commit: 84f8957533e85672d3b17d1a9004193b091f9fea
Related: odoo/enterprise#28488
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
This commit ensures that, when creating a private task, the current user
is always part of the assignees.
This commit also adds tests on the different `project.task` creation scenari
to ensure it gets not broken in the future.
task-2818486
closesodoo/odoo#89041
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, it was possible to assign a non-personal stage on a private task,
which is a nonsense as the task does not belong to a project. Only personal stages
should be set to a private task.
After this commit, if a non-personal stage is set on a private task, a UserError is raised.
task-2818486
Part-of: odoo/odoo#89041
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Currently, when we click on week_days checkbox the
'next occurrences' dates are not updated due to fieldDependencies
fields are loaded by js and due to that on_change on fields is not
calculated.
so in this commit, add those fieldDependencies field in xml view so
that dependent field(recurrence_message) will be computed properly
with the help of on_change.
task-2823432
closesodoo/odoo#93450
X-original-commit: f223aefebeec0fc0fcc0d68e3d982a4ab1294d71
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The purpose of this commit, is to make improvements in Project.
In this commit, following changes are made:
-rename 'Duration' to Hours/Days Spent
-rename hours/days to Hours/Days Spent
-add links to Sales Order, Quotation, Ticket and Invoices linked
the task in left panel
-indicate email of the assignee
-indicate email of the partner
-indicate 'Draft Invoice' instead of '/' for invoices
-display 'remaning hours on SO' value in red if value is less
than 0
task-2743512
closesodoo/odoo#86422
Related: odoo/enterprise#25280
Related: odoo/upgrade#3406
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Use case:
---------
Create a task with public user
At the end of the transaction sometimes the flush
is done with an env where su is False.
This cause the public user enable to read data needed
for the recomputation of is_closed field which is related_sudo=False
Why is this random ?
--------------------
The flush in transaction select the first env in the set of
env with a user. Since the order in the set is not deterministic
Sometimes an env with su=True is choosen and everything is fine
but sometimes it's not and we get an access error
It happened in 3 acts
this commit f98470e6cf add
related_sudo=False for perf improvement pre v13.0
this commit 42c430a539 introduce
a new related field is_closed that copy paste the related_sudo=False
this commit cf8bb933ac3a9fd6344ca79617a2f7317fbc20af stored the field
and stored computed field should always be compute_sudo=True
Solution
--------
Remove all the related_sudo=False, they don't make sense since v13.0
closesodoo/odoo#93349
X-original-commit: e0fe5c5a1c6932f02ca0822c5c26618c91fd50b3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Crrently, 'parent task' stat button is visible even if the
'sub-tasks' feature is disabled.
So in this commit fixes the issue by adding the subtask group
on button.
task-2834743
closesodoo/odoo#93115
X-original-commit: cd7db331ae36ef2ecbb1b6795522cf469608c855
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit gives a name to the Analytics section in the settings
to allow us to change its name easily with an xpath.
It also extracts the attachments domain in tasks so that it can be
overriden in documents_project to exclude attachements linked
to a document.
Related: https://github.com/odoo/enterprise/pull/26696
Related: https://github.com/odoo/upgrade/pull/3557
Task-2802803
Part-of: odoo/odoo#92044
Before this committ:
- Stats buttons were hidden when records are zero
- Some wordings were insignificant
- Existing filters don't allow us to check blocked, blocking and tasks soon in overtime and some other information
- Product form fields need some changes in their order
After this commit:
- All stats button are displayed when records are zero
- Wordings fixed
- New filters added to check blocked, blocking tasks and tasks in overtime soon
- Fields were rearanged
task-2726465
closesodoo/odoo#82253
Related: odoo/enterprise#23257
Related: odoo/upgrade#3185
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose
=======
The goal of this PR is to create a link between milestones and tasks. Indeed, milestones usually contain a set of tasks. Once all of these tasks are done, the milestone can be considered as reached. This link would help users organize their projects more efficiently and have a better overview of what needs to be done when.
## Implementation details
- A new many2one field is added in the `project.task` called `milestone_id` to link a milestone to tasks.
- Add `Milestones` as global setting and project setting. It means the user will can globally enable the feature and choose in which project he wants to use the feature.
- In the form view of milestone, a stat button is added to display the tasks linked to current milestone.
- Add `Late Milestone` filter in tasks, when this filter is applied the user will see the tasks linked to a milestone with a deadline in the past. This filter is also added in the Burndown chart and Tasks analysis report.
- When the user set a milestone on a task and no SOL is found in the project and/or parent task related then set the SOL of the milestone as a default SOL for the task.
- Display in green the milestone in project update view if all tasks linked to that milestone are in a closed stage.
- When a user changes a stage of a task to a closed stage, a wizard will be displayed if the task is linked to a milestone and all others tasks are in a closed stage too. This wizard will allow the user to reach the milestone since all tasks linked to that milestone are considered as finished.
- Remove `delivered_milestone` option in the `invoice_policy` selection field in `product.template` model when the Milestones feature is globally disabled. If some products are milestone one than they will be converted into a manual service ones to allow the user to manually set the quantity delivered for those products.
- Display the milestone field in task in Project Sharing feature.
task-2829542
closesodoo/odoo#90972
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Continuity of b859d78c. The assets generated for project sharing feature
suffer from the same issue than `point_of_sale`. In master, we have to
properly declare every file we need instead of realying on the whole
`web.assets_backend`.
Part of task 2860257
closesodoo/odoo#92577
X-original-commit: 45db27c3230a7c341206e9f990e8e5a133342c9f
Related: odoo/enterprise#27914
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Before this commit, the external collaborator cannot see in which
milestone the tasks in the project are linked in the Project Sharing
feature.
This commit adds the milestone field in the Project Sharing to show the
milestone linked to a task in the project shared.
task-2829542
Before this commit, when the `Milestones` feature is disable, the user
can always defined a service product with invoice policy equals to
'Based on Milestones' but since the feature is disabled he cannot add
this product on a milestone and so this configuratiom is useless without
the feature.
This commit removes the item into the invoice_policy field Selection
when the feature is disabled. Moreover, when the feature is disabled,
the existing products with this setting should be updated to be a
service product with `invoice_policy='delivered_manual'`. The quantity
delivered method of the existing SOLs containing those products should
also be updated to allow the user to manually edit the quantity
delivered of those SOLs when the `Milestones` feature is disabled.
However, when the `Milestones` feature is enabled again, only the
products contained in SOL linked to a milestone will be updated because
we cannot assume all service products with
`invoice_policy='delivered_manual'` were a service products with invoice
policy based on Milestones. Also the existing SOLs containing the
products updated will not be updated too to not impact the quantity
delivered.
task-2829542
jlzhou