[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
Replace employee linked to base.user_root (administator) in data
by employee_fp (Pieter Parker) from demo data in order to avoid having 2
employees linked to the root user.
The form_save payment type is used by acquirers (currently only ogone)
to return a reusable payment token on successful payments. These can
then be used to charge the customer again.
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.
The protection prevents fields to be invalidated/recomputed on some records.
This mechanism is useful against accidental cache invalidation when computing
or inversing fields. It also prevents to trigger the recomputation of fields
before and/or after their inversion.
Add a test on stored field with compute and inverse methods: the test checks
how many times the compute and inverse methods are invoked in several cases.
Essentially, the field should not be recomputed when it is written.
When the kitchen ticket is printed, the order lines appear jumbled in
comparison to what is displayed on the PoS interface. This is an issue
since the kitchen cannot link main and side dishes for a given guest.
For example, the following order:
- Steak
- Fries
- Salmon
- Pasta
- Chicken
- Salad
On the kitchen ticket, this could appear as:
- Salmon
- Salad
- Chicken
- Steak
- Fries
- Pasta
The order actually depends on the product id.
The fix is to use the order line id instead of the product id in the
resume dictionary. Although a dictionary is an unordered collection,
most browsers keep the dictionary ordered. For example:
```
var a = {"18": "18", "1": "1", "21": "21", "14": "14"};
for(var i in a) { console.log(i) };
1
14
18
21
```
opw-680796
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
- created report/project_cumulative.py for model
project.task.history.cumulative that was in project.py
- moved project.project kanban view from project_dashboard.xml
to project_views.xml, which required moving some menuitems
as well so they are available while refering them in other files
Since base.user_root has 2 employees (one in demo, one in data).
The method _compute_leaves will use the employee id forced in context.
The test should be improved later.
Maybe not 2 employees for same partner...
[NEW] point_of_sale: new tour
[IMP] hr_expense: main employee is created by default, so that you can
use the email gateway and record expenses, without configuration
required
[IMP] all tours: applying JWR propositions: americanization of tips
[IMP] crm tour: add invite people steps
Merge branch 'master-expense-tip-fp'
Usability: remove the Settings tour and include the addition of users
back at the end of others tour. The reasons:
- When someone starts with Project, we don't want to invite him going on
the settings tour (Don't make me think/choose)
- If the user starts with Settings (e.g. out of curisity), he will not
have a great on boarding experience.
- We expect the user to follow the steps in this order 1/ discover
project tasks and, only after, 2/ invite users (he will probably not
invite users before discovering the application)
The drawback is that we have to add "Invite Users" steps on others tour,
but only those for which it has a sense:
- Website, Accounting, eCommerce are typically single-users apps (we
don't need to make him invite people)
- CRM, Project are multi-users apps
There's really no reason to limit group_operator to numeric fields and Postgres's flexible aggregate make the ability to aggregate on non-numeric fields (and/or non-numerically)
* moves group_operator to Field
* adds a default value of `sum` on integer, float and monetary fields
* in read_group, filters on fields with a group operator rather than by
type (also allow id fields, since Id doesn't have a group_operator by
default it will be ignored anyway) (sequence is still specifically
excluded for now because they're usually regular Integer fields)
Closes#12372
1/ The tip should be on the textarea, not on the button.
2/ The access right field on the quick user creation form is confusing.
I propose to put it in "Technical Feature" so that it's not visible for normal users.
3/ dissociate les settings tour from project tour
Was removed at 2e4b82f4 (for good reasons) but an explicit empty value is better
for migration as it prevents needing to explicitly removed the domain.
Fabien Pinckaers