Purpose is to maximize size of editor to focus more on the note content
edition.

Indeed notes will soon be more about todo-list and reminders.

Purpose is to have first column holding all todos and reminders. We then
add a few columns for today / tomorrow / later to help people organize
themselves.

Rename 'Purchase Bill' into 'Vendor Bills' to be consistent with the
labels of module purchase.

TASK-38741

- We show the completion date of a picking when it's done
- We add the filter that show canceled picking
- We remove the filter that show confirmed picking as it doesn't exist
  anymore

TASK-38741

TASK-38741

- Set groups on group by and filters

TASK-38741

TASK-38741

TASK-38741

- Delivery slip of a picking not done will show the initial demands
- Delivery slip of a picking done will show details of what have been processed
- Remove the shipment backorder message
- Remove the Weight and show the Shipping Weight

TASK-38741

- Remove the commitment date
- Remove 'Origin' term in picking report
- Add report header below barcode
- Arrange fields space
- Change fields sequence

TASK-38741

TASK-38741

We always show the origin field in the tree view of manufacturing orders

TASK-38741

- Remove 'Production Order #'
- Don't diplay source field if empty
- Change subtittle
- If MO not done, only shown reserved products
- If MO done, show what has been really consumed
- Show product barcode
- Show reserved product location
- Show reserved product tracking data

TASK-38741

Users can configure multiple references in a same
category. This might cause problems during conversion
and does not make sense.
Since this is a "late" constraint, we define it in
python to avoid conflict with existing data.
We allow user to have multiple unactive reference, but
force to have exactly one active. So when a new UoM
category is created, user have to encode the reference
unit first, and then the bigger/smaller ones.

This commit also update stock tests, since they were
redefining new reference UoM in the same category, and
finally, this commit provides some tests for this
uniqueness and custom UoM behavior.

Task #1820076

In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.

Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.

To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)

Task #1820076

These modules are currently made to run with an odoo 8.0 server.
They are given as-it on the odoo repository but are intended to be run on the
posbox and not supported on a classic server.

This reverts commit a094095e.

Context problems, see PR #20834

Add a new report in order to display:
- bom structure and cost
- bom structure
- bom cost
The user is allowed to print multiple bom reports at once.
Print the report dynamically depending what have been unfolded.

In html the rendering is lazy, when unfolding the client make a request
to the server in order to get the html that will be append to the DOM.

For the pdf the kwargs unfolded could be used in order to render everything
at once.

With the help of:
Dhaval Suthar <dut@odoo.com>
Jigar Patel <jat@openerp.com>

task-36741

Move it from enterprise to community since it will
be used for bom structure report and set bom_cost on product
cost functionalities.

Include set_html in the deferred of start

Since report refactoring the function to override is get_report_values
that only returns a dict of value that are used in rendering.
In order to render a pdf with a landscape orientation, a context key could
be added however since it's not possible to return a report object in
get_report_values, it's difficult to add a contexti without using some tricks.

This commit add a report option to use in the template that will be used
in order to modify the pdf orientation. The process used was already existing
for other options like dpi,...

Current demo data do not have advanced configuration.
This commit provides new demo data in order to test
bom report or advanced MRP configuration with sub bom
bom with kit,...

The pupose is to add the new dynamic bom report
Chekc the next commits in order to have more details

Closes #20161

Impacted modules: hr_timesheet, sale_timesheet and project.

This merge commit provides feature for service flow (selling
timesheet). The most important points are

1/ selling project based on template: on product configuration,
user can now set a template for the Sales Order to create a
project by duplicating this ones (stages, tasks, ... are duplicated
from the template). If several Sale Lines are based on the same
template, only one will be created. Same mecanism if multiple product
creating a project without template: only one project per SO.

2/ Project Overview Revamp: before this, it was based on a filter
domain on analytic line (aka timesheet). This causes many problem
as if you are selling prepaid services, you project plan was empty
as long as no timesheet was created. Moreover, this kind of domain
is not very usefull for the user (nobody want to see project plan of
timesheet containing "analysis" for instance). The project plan is
now a filter on project, to ease fetching data from the project (even
if no timesheet or forecast), and allow cross project analysis.
The overview table part is now available even when forecast is not
installed.

3/ Assign Tasks Massively: a wizard is provided to ease linking
task to the same Sale Order Line, to ease billing their related
timesheets.

4/ Usability Details: filter task per SO or SO line, stat button
on Sale Order now redirect to kanban project instead of global
project plan, generated task/project names are cleaner, ...

5/ Installing only timesheet module, user will be able to track
cost without selling time. Fields of cost and employee hourly cost
are moved from sale_timesheet to hr_timesheet.

To make this feature works, some technical efforts was required:

1/ Project and Analytic Account: To allow SO to generate multiple
project, we wanted them to share the same analytic account (the one
of the Sale Order). To do so, we had to remove the inheritS between
project.project and account.analytic.account models.
To allow timesheet on a project, an analytic need to be set manually,
or it will be automatically generated (like before with the inheritS),
if allow_timesheet is checked.

2/ Refactoring of SOL service generation: to allow SOL to generate
only one project (per template) for the SO, the part of service creation
on sale.order.line needed a refactoring.

3/ Revamping the overview also improve its performances: some part
are now based on SQL queries (table part), or on report (profitability
report). Doing a report allow the user to create its own filters, and
give him a more accurate tools to extract statistics then project plan.
The idea is to get only one source of information for reporting and
analysis.

Please see sub commits for more details.

Thanks for @tde-banana-odoo for his review and advices during
development,
and thanks to @bst-odoo for his functionnal ideas, testing and support.

Tasks #34702
Closes #22268

'remaining_hours' is defined in project as a simple
float field, manually updateable, only displayed
when the group "Time Estimation on Task" is activated.
But for now, there is no setting to active this group.

Those are legacy useless stuff, so we can remove it.
The purpose is to make 'time estimation' feature only
available when timesheet is installed.

Thie commit also split the compute methods of
'remaining_hours' and 'progress' fields to make
'remaining_hours' updateable, though inverse method.
Without splitting the compute method, the calculation
of the progress was done correctly during onchange
but not when saving.

We want to split the sale order line description as follow:
 - first line will be the title of the task, prefixed by SO
   reference
 - the rest of SO line description should be the task
   description
The purpose is to avoid duplicating the first SO line
description in task title and description.

Task #1831934

From task stat button from SO form view, it
is relevant to see the task of the SO only.
So, we add a filter to do so. AS the kanban
task use a read_group, it is required to store
the sale_order_id field on task.

The code of the project overview is split to be used when only
timesheet is installed (no forecast). The table part only
display column for timesheeted time per month.
When forecast is installed and activated, other columns
comes to complete this table.

This commit also makes visible SO line having no timesheet
linked in project overview.

When selling a project from a sale order, the SO line
creates the project. When we create a task in that
kind of project, by default, the task will be linked
to the SO line of its project.
However, for the SO line field to be visible on the
task form view, the customer must be set. This commit
set the customer from the SO line when changing
the project (billable project only).

Selling product creating project can now be based
on project template. When setting a project template
on product, this will copy the project (like a duplicate)
and replace its customer, ... with information from the
SO line, on SO confirmation.

There is only one project without template per SO, and
one project per template per SO (so 2 SO lines with the
same project template on their product will only create
one project with this template).

When confirming a SO, only one project will be created, even if
some so lines would create a project. Only the first line will
create the project, the other will not be linked to its.
`project_id` field is added on so line, to keep track of the
generated project, as already done for the task.

The '_timesheet_service_generation' method has been rewritten
to be execute in batch and improve performance and prefetching.

On SO confirmation, no message are now post in chatter to avoid
having one message per so line that should have created a task.
A message is only posted when user manually add SO lines on
confirmed SO.

Now that an analytic account can be linked
to several projects, you might want to change
the analytic on the SO.
Before this commit, the user was allow to create
an analytic account on a confirmed SO but not
modify it. This was usefull when you wanted to
reinvoice an expense on a SO without AA set.
This is now solved (AA is automatically created
when validated expense).
Now, we want to allow set manually the AA before
confirming SO to match the one of potential
projects.

This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.

This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.

This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).

The project overview is kind of badly design. This
commit does not solve all the issue but tries to make
it simpler and more efficient:
- Does not depends on AAL anymore: the overview search
is now about projects. You can see the overview of multiple
projects. Even when no timesheet are encoded, the plan will
not be empty.
- "Time by people" displays each employee assigned to task,
even if no timesheet are recorded.
- Code now use reporting view to keep consistency and simple
code in overview controller.

Adding a wizard to assign multiple task to the same
sale order line. This will allow user to invoice
timesheet created before SO confirmation.

The cost of an employee should be in hr_timesheet for a long time, to
allow user to track time on project/task: hours spent and their cost.
This commit simply moves fields and related views. It also moves the
'postprocess' method from sale_timesheet to hr_timesheet since this
method is responsible to set the amount (cost) on AAL.

User can now track their time and cost, without having sale_timesheet
installed.