- 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
When a user click on an action button, we need to check if the record
match with the domain to remove it from the view if this action change
the record value.
Special case: we filter by active field equal true, if the active field
is available in the data (field present in the kanban view).
opw-1832879
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
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.
Install a database in some other language than en_US
In debug mode and in the app list viewer,
you'll see that the apps field are translated into your language
Then do an "Update App List"
Reload your page
Before this commit, the Apps' field lost their translation
This was because when checking for any updated data for known modules,
the ORM fetched the translation automatically, and compared the old (translated)
value with the new (English) value from the manifest
After this commit, This operation doesn't make the translations to be lost,
because only english values are compared
OPW 1832796
closes#23910closes#24091
Since 3d04e4488, several pages have to be denoted by:
`<div class="article" />`
And not as previously:
`<div class="page" />`
This was not taken into account in the "Location BarCode" report so we
had only one page of barcode (so 4 barcodes since there is 4 barcode by
page) displayed.
fixes#19698
opw-1817574
closes#24098
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
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,...
This commit format the display_name of sale.order.line,
without context key.
The webclient trigger the name_search with context
key, but display the field without it.
So on task form view, when searching an SO line, user
will see 'SO0001 - my product' in its dropdown, but the
complete SO line description when saving.
This commit proposes, in aggreement with AL and FP, to
a global (and non conditionnal) format, since it seems
task form view is the only one place requiring the SO
line name_get.
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 #34702Closes#22268
The id of the record may be a real database id or a string containing a virtual
id (e.g. "42-20380119031417").
The id is always stored as a string but must be converted to int when sent to
the ORM (to avoid self.browse('42'))
The calendar modules do handle correctly virtual ids in its unlink method but it
is not the case of the other modules that are expecting integers.
Convert to int if we are working with real ids
Replace and closes#22115
'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.
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.
The project of a SO will not be used anymore, as we planned
to have a sale order creating multiple projects.
The concept of 'only project from SO' does not make sense.
This commit provide a real reporting tool
for project profitability: graph and pivot
views.
You can now have a look at cost and revenues
per project, so line, product, see which
project manager brings the more money, which
project costs many human time, ...
The project overview is based on this report
analysis to be consistent.
However, a change of computation for 'amount
invoiced' is introduced: we now based the amount
on the price_reduce of the SO line, and not from
the invoice lines. Also, once a draft invoice is
generated, the quantity is considered as invoiced
at the price of the SO line (no matter is extra
discount happens when validating invoices).
- Redesign all mimetype icons
- use SVG to reduce file size and improve rendering quality.
- Add a data attribute to attachments to detect the file extension (in somes
cases just mimetype is not accurate)
Prakash Prajapati