2 rules were defined with the same id thus only one was loaded in
database, resulting in missing read access on model
'project.task.history.cumulative'.
This patch fixes the ids of these rules and clarify their names
When we were trying to delete a stage in project where there were
some tasks, an error was raised because of the 'project.task.history.cumulative'
records that inherit 'project.task.history' which have a compute method on
on end_date.
To fix this, we set the 'compute' attribute to 'None' and the readonly
'attribute' to 'True'.
If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create a task directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created task. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the task, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
Commit 9b69184ff. removed field 'state' of model 'project.project', and
converts domains using it to use field 'active' instead. However, the domain
of the many2one field in the task form view hasn't been correctly converted
(['state', 'not in' , ['closed', 'cancelled']] should be ['active', '=', True]).
The module `sale_service` has been merged in the module
`sale_timesheet` in the revision
234f88a6af
We only remove the field from the view due
to the fact saas-11 is a stable. The field
has already been removed from the model
in newest releases (`saas-12`)
opw-682816
The field state was replaced by ‘active’ in project.project (see commit 9b69184).
However, someone forgot to update the arch for the default list view which
was not longer possible to open.
The onchange should have the signature with `ids` instead of `id` for a proper
guess.
Without this, the method can not be overriden with an api.multi (the return
result is a list of dictionnary which is not understood by the ORM as a proper
return format).
Fixes#12856
Split project to move portal features to a new module named website_project.
Portal users may now access their projects and tasks throught the
website_portal My account page. The Backend portal menuitem is removed.
Simplify the privacy settings of project, to be visible to portal users the
project must be in 'portal' mode.
Original authors: Vipul Bhatt, Florian Wintjens