When a message is posted through the chatter and creates a new partner
the issue is now updated so that the partner field is correctly set to
the newly-created partner.
Chatter on issue now uses the reload option so that the view is reloaded
after posting a message. The user therefore sees that the record has been
updated accordingly.
This commit removes document count on project kanban view. Indeed it
does not add much valuable information and bloats the kanban cards.
In order to keep the kanban card order, it was required to adapt all
inherited views. The order is 'task', 'issue', 'rating', 'timesheet'
and 'forecast'.
It also uses a read_group to better compute task count, by the way.
* Remove filter tag
* Use color attribute on the view who add a filter/legend
* Filter is automatically added when 'avatar_field' option is used on a
field tag, and the default template display the avatar.
* Can overwrite the template (add tag template who contains qweb with
<t t-name="calendar-box">...</t>
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Activity types are currently hard to find and define. In this commit we
add a menu under project configuration to access generic or project
related activity types (task, issue).
This commit is an improvement considered as an usability fix, therefore
targeting stable version.
- Use read_group to compute task_count of res.partner
for performance sake
- When creating a task/issue from partner form view,
the default partner will be the current one (event if
the use case is rare)
- Only display button when count is greater than 0
- Also avoid default 'My Tasks' filter when coming from
partner form view
Uncheck use tasks and/or use issues and/or allow timesheets
all links are still available from the kanban
timesheet is available from the form view
tasks and issues hidden in the form view
NB: allow_timesheets was defined in timesheet_grid, but it should be standard in hr_timesheet
Indeed currently it is only visible in edit mode. However we noticed
people did not trigger the edit mode to find fields they do not expect
to find. Making them visible helps understanding projects can be used
notably for tasks and issues.
A new view is dedicated for that kanban view. It is based on the standard
issue kanban view but using the group_create=false attribute to disable
the ability to create new columns.
It is done using a different view because standard issue kanban view
requires this ability. However it is not possible to achieve that goal
using conditional attributes.
Move portal features (mainly ir.rule) from project_issue to
website_project_issue.
Remove backend menu item, issues should be accessed from the website_portal My
account page, the backend portal menuitem is removed.
Add the dependency on website_portal to display the issue count on projects.
Original authors: Vipul Bhatt, Florian Wintjens
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.
Thibault Delavallée