Following CDN expansion (d98b262398)
portal attachment links now go through the CDN, which is an issue for
restricted-access attachments e.g. attachments bound to specific objects
(such as support tickets).
Add an access token to the attachment links in the /my/task template.
Cf OPW-1882014 (fixed ad-hoc by editing the relevant view on odoo.com)
When switch to list view for tasks, we want them to be grouped
by stage. This was removed at 8169134715 without
justified reason, so this commit reset the previous behavior.
Purpose is to limit the uninstallation of modules without being clearly
notified of it. In project ticking timesheet may have a great impact
depending on modules already installed: sale_timesheet, timesheet_grid,
...
We therefore decided to remove those options from settings to prevent
users from uninstalling it.
This commit is related to task ID 1841221.
The subtask_project_id field was removed by task #38498, amongst many
other changes.
This change makes some workflows much more difficult: for example, using
a different project with its own columns is kind of awkward. It
requires many more clicks and custom filters to achieve the same result
as previously.
With this commit, we simply reintroduce the field and use it to set the
default project_id of a subtask.
- Portal users do not have the rights to read on project.project.
This causes issues on the page "/my/tasks" as it is trying to read the label_tasks and the name of the tasks' project.
To address this issue we read those two fields using sudo
- Activate sub-tasks in projects
- Enter a project's tasks, click on the stat button 'Sub-tasks'
- Reload the page (F5)
A traceback occurs since `project_id` is undefined.
The fields `project_id` and `partner_id` are only defined in the context
of the stat button.
opw-1844334
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
During first scss convertion, classes called as mixins were changed to
an @extend instruction which was the best approximation given the fact
there is no equivalent in sass to do that. The problem is that the
instruction is slowing the scss computation a lot and might also break
the style in unexpected ways because of the complex unwanted selectors
the instruction induces.
This commit removes the need of extends. This is done case per case.
Sometimes this involves adding classes in xml, sometimes to change the
style a little, ... The button rendering refactoring which was made
at the start of the LESS to SASS merge was also done in prevision of
this.
After this commit, sass computation is like 5-6 times faster than less
computation while it was like 10 times *slower* before this commit.
'remaining_hours' is defined in project as a simple
float field, manually updateable, only displayed
when the group "Time Estimation on Task" is activated.
But for now, there is no setting to active this group.
Those are legacy useless stuff, so we can remove it.
The purpose is to make 'time estimation' feature only
available when timesheet is installed.
Thie commit also split the compute methods of
'remaining_hours' and 'progress' fields to make
'remaining_hours' updateable, though inverse method.
Without splitting the compute method, the calculation
of the progress was done correctly during onchange
but not when saving.
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
Purpose
========
The links on the project kanban cards are not always at the same place : https://drive.google.com/file/d/1aONUYkZerqqD7fSVmgozRScgLKR-QHtA/view
============
Specification
============
I get rid of the flex element to allow the placing of links using width
attribute. Create the .o_project_timesheet_box class to assure that the
timesheet/overview link is always placed in the middle.
I also deleted the needaction_count button to avoid breaking the display.
Task: 1817850
The widget statusbar was using an attribute `clickable` on the field widget
to define if the statusbar was clickable.
This attribute is in fact not a field attribute but a widget option so it
has been moved accordingly.
Note that a retro-compatibility adapation is done in the field widget.
This filter groups tasks based on a message_last_post field that is not
updated anymore since quite a long time. It has been implemented for some
internal custom use and not supported since.
As this field has no use and lead to wrong result it has to be removed. Its
purpose can still be achieved in custom using server actions activating the
message_last_post context key and adding the field in custom views.
Done after feedback from internal migration.
As tasks are now used for a lot of use cases including tickets and support
it seems fair to include the task ID as reference in the portal view
for customers. It eases the communication process as people can directly
give the reference (aka ID).
This commit therefore adds a column in portal list view with the task ID
as reference. It also adds it in the portal form view, just after the
task name.
Done after feedback from internal migration.
When something like this is in a html content:
```
<a href="hello">
<div>
<b>this</b>
<a href="world">!</a>
</div>
</a>
```
browsers may correct it to:
```
<a href="hello"> </a>
<div>
<a href="hello">
<b>this</b>
</a>
<a href="world">!</a>
</div>
</a>
```
which breaks our CSS.
This change transforms the inner tag in a button tag.
opw-1817668
closes#23373
Purpose of this commit is to ease project managers in their daily job
organization by ensuring that newly created activities in project
configuration are by default associated to tasks, and not global.
Activity types actions and views are moved in their own file in order
to match the guidelines.
- Connect as a user with only 'User' rights on projects
- Set a project as favorite (click the star)
The project is not set as favorite.
Since only project managers are allowed to write on projects, the field
`is_favorite` is set as read-only. Therefore, it is filtered out by
`_generateChanges`, and nothing happens.
First step is to set the attribute `force_save` in the view, so the RPC
`write` call is forced. Second step is to compute directly the inverse
thus bypassing access rights.
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
opw-814604
opw-801587
closes#22938
[IMP] project: "Task Title">Title (could be named differently)
[FIX] project: don't assign a person on a task during the tour
Someone is already assigned as tasks are created from the kanban,
directly, with a responsible by default.
The goal of this rev. is to improve the user onboarding on the
Project app: when the user creates a new project, he is now guided
to properly configure the stages of its project.
To do so, we added a new mechanism in the Kanban view, allowing to
define examples of processes that can be used in the corresponding
view.
The style of the ColumnQuickCreate widget has also been changed.
Part of task #38740
This rev. defines form views to use as quick create views in the
kanban view of models 'crm.lead', 'hr.applicant' and 'project.task'.
It uses a newly created mechanism allowing to specify a form view
xmlid in the Kanban arch, such that the referenced view is rendered
inside the QuickCreate widget (see parent commit).
Task #27475.
Yannick Tivisse