Purpose
=======

Speed up survey completion.

Specifications
==============

This commit apply an auto commit when user select a choice on a simple choice
question or on a matrix question with simple choice.

The auto commit happens following those conditions:
- Only on simple choice and matrix with simple choice questions
- For matrix, only when last subquestion is answered
- Only when Back mode is active
- If this is not the last question

Link
====

PR #46768
Task 2208574

This commit slightly changes the way users navigate through the survey form:
- The back button was moved to the bottom-right of the screen.
- The "Continue" button stays at the center but there is also a "next" button
  at the bottom-right of the screen (same behavior -> submits the form)
- Arrow keys (left + right) navigation is now supported

Technical note: As the survey navigation is now outside of the survey content,
that was re-rendered on every submit, we have to manually refresh the
navigation with a second template render on the controller side.

LINKS

PR #46768
Task 2208574

This commit slightly improves the survey form by adding a few cosmetic changes,
notably:

- Add/reduce some margins/paddings
- Adjust colors/font-weight
- Adjust heights
- Change some icons by more fitting replacements
- Center matrix choices
- Move survey progression to bottom-right
- Remove ugly jumbotrons
- Hide survey title in page_per_question layout
- When there are 5 or less option for simple_choice or multiple_choice
  questions, display the options vertically.
- Only show the textarea for the "comment answer" if the user clicks on the
  related option.

One of the biggest design change is the introduction of a "minimized layout"
that reduces the width of some question types on bigger screen.
This gives a cleaner look to the survey form.
Impacted question types:
- Numeric
- Date
- Datetime
- Simple / Multiple choices

Technical note: As the survey progression is now outside of the survey content,
that was re-rendered on every submit, we have to manually refresh the
progression with a second template render on the controller side.

Small fix addition:
We also fix the matrix key selection feature in case the matrix had a total of
more than 25 options, which would raise an error.
Indeed, they "use key selection" condition only checked the number of rows,
and not the rows * columns (total number of options count).

LINKS

PR #46768
Task 2208574

PURPOSE

This commit adds a big flow test/tours to the survey sessions, for the host
point of view.
This will avoid breaking the feature with future changes, as it contains some
tricky and complex mechanics (especially the screens chaining).

SPECS

The tour tests the whole host point of view.

Break down of the testing/tour main points:
- Create the survey session
- Check our attendees are accounted for
- Open the 'session manager'
- Display the nickname question, and move to the next one (as answers are not
  displayed for nickname questions)
- Check answers are correctly displayed for the 3 'simple' question types
  (text, date, datetime)
- Move to the choice question and check that answers are displayed
- If everything is correctly displayed, move to the next question
- On the scored choice question, check that the screens are correctly chained:
  no results displayed -> results displayed -> correct/incorrect answers ->
  leaderboard
- On the scored + timed multiple choice question, check the same than previous
  question, except that the results are supposed to be displayed automatically
  when the question timer runs out
- Test the 'back' behavior and check that screens are reversed correctly
- Check that our final leaderboard is correct based on attendees answers
- Close the survey session

LINKS

PR #46768
Task 2208574

This commit improves the session host view by showing matrix choices for matrix
questions.

This is done to help people in the audience that are not participating to the
session to have some context about possibles question answers.

LINKS

PR #46768
Task 2208574

PURPOSE

Improve the various sessions flow to make it easier for attendees to reach the
session and to allow better interactions between the host and his audience.

This comes with small usability improvements as well as increased
"beautifulness" by using custom layouts & animations.

SPECS

This commit changes the survey sessions fade in/out delay for both the host
and the attendees.

When going from one question to another, the total delay is now 1 second
(instead of 2 previously), with 500 ms for fade out and 500 ms for fade in.

The previous delay gave an impression of "slowness".

The delays and "server lag reduction" on the attendees side were adapted
accordingly.

LINKS

PR #46768
Task 2208574

PURPOSE

Improve the various sessions flow to make it easier for attendees to reach the
session and to allow better interactions between the host and his audience.

This comes with small usability improvements as well as increased
"beautifulness" by using custom layouts & animations.

SPECS

- For live session only:
  Currently, the "short link" feature is good but it still needs to be improved
  with the following points:
    - Make the default "code" shorter (4) and digit only.
    - Allow to customize the "code"
    - Check for potential collisions

Added at the same time:
- input element is focused when you land on the '/s' page.

LINKS

PR #46768
Task 2208574

Clarify the kanban view to clearly display how many attendees
could show up as well as other places where attendees are mentionned.

Task ID 2205701

closes odoo/odoo#48584

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Purpose of the task is, Warn the user that we do not recommend editing
the architecture of standard views because During migration if the
client does standard views modification then during migration all views
will be updated according to the new odoo version and all customization
will be lost.
So during upgraded database testing issues will come about that views
or client will post issues and ask about where our customization
is gone.

So in this commit, we added alert message on edit of view like:
'Be aware that editing the architecture of a standard view is not
advised, since the changes will be overwritten during future module
updates. We recommend applying modifications to standard views through
inherited views or customization with Odoo Studio.'

closes odoo/odoo#48492

Taskid: 2219956
Closes: #48492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Add a related field `accounting_date` in the expense to the expense
report.

 - Should represent the accounting_date field from the expense report
 linked to this expense
 - Only visible if the status of the report is approve, post or done
 - Only visible if the user has at least the Accounting > Auditor access
 right level
 - Should be in read-only
 - Should be stored

closes odoo/odoo#48238

Taskid: 2221668
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

* = event, website_event_track, website_sale, website_hr_recruitment,
website_livechat, website_sale, website_slides

The option to sanitize or not the forms was not available, this will
allow better flexibility on whether forms should be sanitized or not on
an HTML field.
Also we use this new param to allow forms to be added on some already
existing html fields where forms where sanitized out.

task-2209554

closes odoo/odoo#47318

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

closes odoo/odoo#41499

Related: odoo/upgrade#854
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Add new Kanban examples and improve the usability of the dialog.

closes odoo/odoo#48620

Taskid: 2210279
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This reverts commit f7d7c53c.

Need to investiguate debug=assets mode.
Revert to unlock others devs

closes odoo/odoo#48675

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

closes odoo/odoo#48660

Related: odoo/upgrade#1014
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Currently the code for default name is inside the timesheet_grid
so on community the name(description) of the analytic line is
required.

so move the default name code from timesheet_grid to hr_timesheet.

TaskID: 2176065
Related Enteprise PR: https://github.com/odoo/enterprise/pull/9561



closes odoo/odoo#48657

Closes: #48657
Related: odoo/enterprise#9561
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

- open accounts in a full view instead of a modal
- ability to reverse entries at their own accounting date
- don't create draft closing entries and reminder if no configuration for tax groups
- reordered account menus
- improved invoice form view

Task ID : 2209497

closes odoo/odoo#48355

Related: odoo/upgrade#1001
Related: odoo/enterprise#9485
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Because.

Mighty PO said: "We'll need this in internal"

Don't ask me, it's changing every two days.

Task 2204084

closes odoo/odoo#48097

Related: odoo/enterprise#9394
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======
It might look weird if the play button is displayed on some lines and not others.
It might seem even weirder if we have the Timer functionalities (such as the
timer bar we'll introduce with task 2217930) available even though the timer
is disabled on all projects. In this case, if we wanted something clean, we
would need to introduce a setting to disable the feature in Timesheets as well,
but that seems overkill. At last, you may not want the timer on the task form
view but find it still useful in the Timesheets app.

Specification
=============
Always display the start button, even if allow_timsheet_timer is False on the
selected project.

Task 2204084

Displayed optional fields:
- task_id
- name
- is_timer_running
- unit_amount

Task 2204084

PURPOSE

Allow "free text" questions in the event questions asked to attendees, in
addition to the existing "selection" type.
e.g: "What are your allergies?"

Rework existing reporting on Questions to ease implementation and give more
meaningful answers analysis.

SPECS

**Free Text Questions**

The implementation is heavily based on the modelisation we chose for the survey
module since the features become similar in terms of question types and inputs.

- Introduce a 'question_type' that is either 'simple_choice'
  (= previous behavior) or 'text_box' that will contain the attendee text
  answer.
- Rename the event.answer model to event.question.answer to make it more
  obvious that it contains answer "suggestions" to a question of type
  'simple_choice'.
- Introduce a 'event.user_input.line' that is an answer to a specific question
  for a specific registration.
  It works very similarly to 'survey.user_input.line' but it's not contained in
  a 'user_input' model, it's directly linked to the registration using a
  'user_input_line_ids' o2m field.

The frontend view has been adapted accordingly to display either a selection
input or a textarea based on the question type.
The frontend orm processing now takes in both answer types (id of suggested
answer or text input).

On the backend side, views have been adapted to display event questions and
attendee answers in a more convenient and logical manner.

**Questions Reporting**

Based on latest testing, the reporting on event questions was completely
unusable if you have more than a hundred questions (all events combined) and
needs to be refactored based on new specifications.

We dropped the current reporting and re-introduced a new one after the commits
that let us handled free text questions.

The new reporting allow users to conveniently analyze attendees answers on a
per-question basis. It shows:
- A graph view showing counts of each suggestions for simple_choice questions
- A pivot view showing registrations vs answers for simple_choice questions
- A tree view showing textual answers values for text_box questions

FIXIMP

When changing the event.type, configured event questions that have answers
(type 'simple_choice') new have their answers properly copied onto the event.

LINKS

Upgrade PR odoo/upgrade#799
Task ID 2189529

closes odoo/odoo#45497

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

This commit adds necessary views and actions for users to be able to
conveniently analyze attendees answers.

- A graph view showing counts of each suggestions for simple_choice questions
- A pivot view showing registrations vs answers for simple_choice questions
- A tree view showing textual answers values for text_box questions
  (Tree view is also available for simple_choice)

LINKS

PR #45497
Task 2189529

This commit does not change anything functionally, we just move views around to
appropriate xml files so that everything is organized better.

At the same time, a few views were renamed to match guidelines and we removed
a useless view on event.question.answer, that will only ever be edited inline
or inside many2many_tags.

LINKS

PR #45497
Task 2189529

When applying an event.category on an event.event, we copy the event.questions
from the event.type, but we don't immediately copy the answers associated to
these questions.

This was not done for technical reasons, we were limited by the JS framework.

Since #46807
We now correctly handle nested o2m when triggering compute/onchange.

This commit cleans the code by correctly copying the answers along with the
questions when changing the event.type of an event.event.

LINKS

PR #45497
Task 2189529

This commit adds the display_name to the list of fields so that the view will
correctly compute it and store it in the record state to be displayed by the
associated m2m_tags widget.

Without that small trick the display_name is never computed and the m2m_tags
widget shows empty strings.

LINKS

PR #45497
Task ID 2189529

This commit adds a test tour that will fill up two tickets with a few questions
answers and then assert that the answers are correctly saved for each attendee.

This will help ensuring that the new "free text question" feature works
correctly, along with existing "suggestion question".

LINKS

PR #45497
Task ID 2189529

This commit improves the demo data of the event application by adding a few
questions to better showcase the new 'free text question' feature.

LINKS

PR #45497
Task ID 2189529

PURPOSE

Allow "free text" questions in the event questions asked to attendees, in
addition to the existing "selection" type.
e.g: "What are your allergies?"

SPECS

The implementation is heavily based on the modelisation we chose for the survey
module since the features become similar in terms of question types and inputs.

- Introduce a 'question_type' that is either 'simple_choice'
  (= previous behavior) or 'text_box' that will contain the attendee text
  answer.
- Rename the event.answer model to event.question.answer to make it more
  obvious that it contains answer "suggestions" to a question of type
  'simple_choice'.
- Introduce a 'event.user_input.line' that is an answer to a specific question
  for a specific registration.
  It works very similarly to 'survey.user_input.line' but it's not contained in
  a 'user_input' model, it's directly linked to the registration using a
  'user_input_line_ids' o2m field.

The frontend view has been adapted accordingly to display either a selection
input or a textarea based on the question type.
The frontend orm processing now takes in both answer types (id of suggested
answer or text input).

On the backend side, views have been adapted to display event questions and
attendee answers in a more convenient and logical manner.

LINKS

PR #45497
Upgrade PR odoo/upgrade#799
Task ID 2189529

PURPOSE

The commit removes the reporting on the event.question model along with its
created SQL view 'event.question.report' because they're simply not usable.

SPECS

Based on latest testing, the reporting was completely unusable if you have more
than a hundred questions (all events combined) and needs to be refactored based
on new specifications.

As we need to re-work event questions to be able to add "free text" questions,
we prefer to temporarily drop the reporting instead of having to adapt it.

LINKS

PR #45497
Upgrade PR odoo/upgrade#799
Task 2189529

Prior to this commit, the list_editable_renderer was grabbing the first
table in the DOM. This made it so extending list views with another table
could cause the new table to resize unexpectedly when changing the column
width of the list view generated table (i.e. o_list_table).

While this double table situation may not arise very often, it directly
hindered task: 2198420 and may hinder other customized view tasks.

Related to task: 2198420
("Requests for Quotations KPI's" subsection)

closes odoo/odoo#46654

Related: odoo/upgrade#877
Related: odoo/enterprise#8945
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Adds a customized table to top of list and kanban views of requests for
quotation (RFQs). This table includes the following values:
- RFQs to Send (PO.state = 'draft')
- RFQs Waiting (PO.state = 'sent' and PO.date_order >= now)
- RFQs Late (PO.state = 'sent' and PO.date_order < now)
- Avg Order Value (specifically only for POs)
- Avg Days to Purchase (PO.date_approved - PO.date_created and PO.state
  in ('purchase', 'done'))
- Purchased Last 7 Days (specifically only for POs)
- RFQs Sent Last 7 Days (hacky calculation looking at chatter for state
  change 'RFQ' => 'RFQ Sent')

This change corresponds to "Requests for Quotations KPI's" subsection of Purchase
KPIs task.

Task: #2198420

"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.

Added new values "Average Days to Purchase" and "Average Receipt Delay" to be
used in purchase enterprise reporting tab where:

  Days to Purchase = confirmation date (i.e. 'date_approved') - creation date
  Receipt Delay: effective Date - ('date_planned' or 'expected_date' if
                 no 'date_planned)

Note that these 2 new values are specific to purchase orders only.
Because of this the standard query result cannot be used since it is
done at the purchase order line level. This means duplication of PO
values occur and results in incorrect aggregation calculations. A hack was
done to ensure that these value will aggregated correctly when used at the
enterprise level. Therefore these 2 new values should only be used in
aggregate.

To support these new measures the following updates were also done:
- Addition/improvement of help descriptions for other date related
  measures to avoid confusion
- Change state string to "Status" to match purchase.order (for
  consistent filtering purposes)

This commit supports "Adapt Reporting" subsection of Purchase KPIs task.

Upgrade PR: odoo/upgrade#877
Enterprise PR: odoo/enterprise#8945
Task: 2198420

Adds "Expected Date" and "Effective Date" fields to purchase orders to
match what exists in sales orders. "Effective Date" mirrors sales logic
(= first completed stock move). "Expected Date" has simplier logic due
to simplier nature of receiving stock vs shipping (= earliest "Scheduled
Date" of all PO lines). Form view has been updated to include these new fields.

Additionally code was changed to not have PO 'order_line.date_planned' be
overwritten by the 'purchase_order.date_planned' value. Previous behavior
was both confusing and made it so info was lost. Also logic for related
stock move picking line expected date values has been updated to now consider
'purchase_order.date_planned' value if set. Related changes include:
    - not overwriting when PO is edited+saved (this only occurred in write()
      logic, not create() which caused inconsistent behavior anyways.),
    - updating related tests,
    - removing PO line date_planned editing restriction when PO date_planned
      is set
    - updating of relevant stock moves/picking expected date due to
      PO.line.propogate_date = True ('purchase_order.date_planned' if
      exists, otherwise 'order_line.date_planned')

This change also includes some small related improvements:
- Removal of outdated code comment.
- Addition of Help strings to better explain fields.
- Prevent copy of 'date_planned' value into new POs (now mirrors sales
  logic).

This change corresponds to "Receipt Date on PO's" subsection of Purchase
KPIs task.

Task #2198420

Similarly to method _binary_set_headers, when we serve an attachment
(e.g. image) where an unique is present in URL we add a long time of cache.

We considere that the hash will be changed if attachment is updated, so
while we ask for same checksum, lets the browser return the cached response.

closes odoo/odoo#48653

Signed-off-by: Christophe Simonis <chs@odoo.com>

Reading `state_blanket_order` on multiple records was failing.

e.g.
```python
env['purchase.requisition'].create({})
env['purchase.requisition'].create({})
env['purchase.requisition'].search([]).mapped('state_blanket_order')
```
raised
```python
ValueError: Expected singleton: purchase.requisition(5, 1, 4)
```

closes odoo/odoo#48642

X-original-commit: 031c3f3b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

There is a default filter on Posted, no need to add it in the domain.
This prevented seeing draft invoices.

closes odoo/odoo#48635

X-original-commit: ca67c83e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

before this commit:
- the selection field with OCR options was in hr_expense module

after this commit:
- the selection field is now in expense_extract module

closes odoo/odoo#48617

X-original-commit: 9440139105825d4efa5fda23149c60179870f9f3
Related: odoo/enterprise#9553
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Thomas Carlier <Explicitapps@users.noreply.github.com>

== Fix results scored question display ==

This commit fixes the display for scored choice question.
The text "Right answer" was displayed twice.

== Add default values to avoid constraints inconsistencies ==

This commit adds a 0 default values to some of our validation fields on survey
questions.

Without a default value, the ORM would store "NULL" in the fields and then
allow users to define a "min" without a "max", that would result in an error
while trying to validate the answers to that question.
Furthermore, when creating a question from the frontend, the web framework will
always send 0 for all field values anyway.

The code change adds consistency and avoids potential errors on that issue.

LINKS

Task 2208574

closes odoo/odoo#48371

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Notably

  * have tools and helpers in a SurveyCase and let SurveyCommon bet the
    one with data;
  * remove unnecessary with_user, replaced by standard one;
  * move all tools in SurveyCase to help reusing them;