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'.
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
The step consisting to go back to the app switcher doesn't work in community,
obviously, so this commit make it active in enterprise only.
Also make the Settings app selector more robust by accessing it through its
xmlid, as we do for other apps and menus.
[IMP] rating: website rating page: reviewed design, rate on click, update on submit
[IMP] rating_project: rating_status: 'no' instead of False
[IMP] rating_project/issue: smileys insteaf of thumbs for consistency in kanban
[IMP] rating: allow to update an existing rating (feedback + rate)
[IMP] rating: consistency on rating names (statisfied, not satisfied, higly dissatisfed)
[IMP] rating: avoid deadend after rating, button to go to Odoo
[IMP] rating: res_config better sentence
Purpose:
For our internal project management, we would like to track the customer
satisfaction on the open projects. We send them an email every one or 2
weeks allowing them to give a feedback by clicking on one of 3
smileys: Happy, Average, Angry. They can also put a additional explanation.
We already have something similar which is working on livechat with a
unusable reporting, and on issues but unusable. Our project are managed by tasks.
Specification:
- On the project : Selection fields : (Periodical Rating or Rating on Stage)
+ Fields to choose the period if periodical
- On the stage : email_template_id field.
- IF :
---> Periodical : Send an email to all the customers for the tasks on this stage periodically
---> On Stage : Send an email to the customer's tasks when the task reaches the stage
- That way, it's impossible to send a satisfaction request both periodically and sequentially.
FP request
- Who is the customer : The customer on the task OR the customer on the related sales order
OR the customer on the projet OR nobody
- The last feedback is displayed on the task kanban card (Thumb up, down, or neutral)
- On the project kanban card, the customer satisfaction is displayed. This is the simple
mean of all the previous ratings.
Also:
- removed onchange_partner_id() from 'project.project' model as
'pricelist_id' field does not exist in project nor in any inherit(s)
since its removal in 2008 by 07b1f0b9da
- removed 'type' field from _defaults dictionary of 'project.project'
model as it does not exists anymore, it used to be defined on
account.analytic.account
- removed on_change_template() from 'account.analytic.account' model as
it doesn't seem to be useful and/or called from any view
- overridden _default_get() for 'project.project' model to set default
value for 'use_tasks' field of inherits account.analytic.account
Christophe Simonis