While this is important to read the replies
you get in the threads you follow, `Unread messages`
is more accurate to describe what these filters
displays.
opw-666739
project_time_mode_id is the timesheet UoM. However, all timesheet
widgets assume that project_time_mode_id is hours, therefore it is not
supposed to be changed.
Analytic accounts are inherited by project.project, and in some cases it is useful to have a link from the account to the project.
This is a usability-fix, not a code-fix
Commit bb1200adc7 introduced the automatic
addition of cc as followers of tasks and issues. However it seems to
automatically create partners if the address it not recognized. This
does not seem a good idea.
Project users should have acces to the Search menu in project. Indeed it
contains the tasks and issues menu entries, allowing to directly jump
to a custom list of task / issues.
In project, stages are shared between projects. However demo projects do not
have any stage by default but stages are assigned to some random stages. This
leads to columns disappearing from the kanban view when there are no more
tasks or issues in it.
Also fixed the addition of followers in a demo project. Instead of hardcoding
the followers use a message_subscribe instead. It was impossible to reload
the project module before that fix.
project.project: alias should be visible without being in technical group.
Indeed the alias is displayed in the kanban view. However in order to edit
it the user has to go into technical mode, which is confusing. The alias
is now displayed in the form view, but advanced alias configuration is still
in technical group.
project.stage: show projects using the stage. Without that field it is quite
impossible to configure the use of stages in the project application.
The onchange of the project field
removed the default partner loaded of the task
if there was no project set on the task, or if the
project was not associated to a specific partner.
There is no obvious reasons to do so,
and the revision 3fe06da634
introducing the regression doesn't explain why
it has been done. At first sight, there is no reason.
opw-657876
In 6fd7fc9 the issue was solved in some instance, but there was still an
issue with the combination of IE11 / Odoo community / Overflowing content.
fixes#9696
related to opw-653477
IE11 and IE Edge presented issue in the project kanban view with content
overflowing its container.
On IE Edge it could be solved by "min-width:0" on the left part of a
kanban card, so it was an issue in the computation of widths order.
But on IE11 that wasn't enough so a less elegant fix has been used.
opw-653477
(solution found mainly by qsm)
project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.
project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.
The project and sale_timesheet modules both define a project_time_mode_id field on res.company but they are not dependent on each other. This causes problem because the first module that creates the field "wins" the xmlid and will delete the field on uninstall, regardless of the other module (which will then stop working until you do an update that will recreate the field).
To work around this in a stable version, we manually create xmlids for the field in each module; on uninstall the field will not be deleted if an xmlid still refers it (which will be the case if the other module is installed).
Inheriting fields from modules that are not dependent in a direct way (ancestor-child) is not supported, so normally you should use modularity to define the field in a parent module. Since 9.0 is a stable version, we need a small workaround.
Since we're not duplicating work items when duplicating tasks during
project duplication, it doesn't make sense to duplicate the
likely correspondingly adjusted remaining hour.
Behave as if the planned hours had just been set/reset and set the
remaining hours of the new task to that instead.
fixes#8985
Denis Ledoux