We add a index on the workcenter_id and workorder_id, both
have a One2many related to (`time_ids` of workcenter and workorder)
and both is in the some search domain in python (also in search view).
(Also change the `readonly='True'` into correct form `readonly=True`
of `production_id`, and remove duplicate fields `workcenter_id` in view)
task-2389380
closesodoo/odoo#63500
Related: odoo/upgrade#2042
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Otherwise, they may crash or be incorrectly verified when
creating/updating recordsets containing multiple records.
Also improve the constraint error messages to be more detailed.
When possible, use a sql constraint instead to speed up the records
validation.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Before, the auto-planning of workorder autorize overlaps between then.
E.g. if a workorder (WO1) begin at Now + 30min with a duration of 60 minutes
and we try to plan a new workorder (WO2) Now, this one will be plan now
until Now + 120 min (30 min of WO2 + 60 min of WO1 + 30 min of WO2).
In our case we don't want this behavior by default,
because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B.
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these features in account.
Also small fix about the planning has been done:
- Due to the strong link of date_planned(_...) between the MO and WO,
the replan of the late first WO was wrong.
If the MO is planned before now, then don't take in account
date_planned_start and try to plan WO as soon as possible.
- Also, fix error handling when the WO is planned before the
previous one.
task-2169447
_get_unavailability_intervals didn't return the correct
dict (describe in the docstring). Then the override in
maintenance module was wrong.
task-2082261
closesodoo/odoo#42530
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
Modify tree view for MRP Production
Modify form view and tree view for Unbuild orders
Add group by for Bill of Materials
By default show line shart when opening MRP Production report
Modify view for Work Orders
Modify view for Work Centers
Modify view for Routings
Modify view for Maintenance Request
Modify view for Bill of Materials
task-2042304
closes - https://github.com/odoo/odoo/pull/35482
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose: link workcenters that can do the same job together.
Planning a workorder will be done by choosing, among the similar
workcenters, the one that will finish the production the soonest.
This commit adds a new many2many field on the mrp.workcenter
model. Planning the workorders will:
1. Loop on the operation's workcenter and all the alternative ones.
2. Compute the first available work slot for each of those workcenters.
3. Choose the soonest finished slot
Furthermore, planning workorder is done thanks to the resource module.
Each workorder is saved on its own workcenter calendar by a resource.calendar.leaves
The two date fields are thus computed from the leave date.
Task : 1892819
closesodoo/odoo#33018
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When clicking on 'In Progress', 'To Launch' will open a list view instead it
is needed that, clicking on those links will open tablet view in enterprise and
list view in community.
And also, to remove xpath (from enterprise) because they are not generic
and can only be applied at one element at a time. Instead, a method is defined
by this commit which is overridden in enterprise to open kanban view.
task - 1967745
closesodoo/odoo#32815
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
mrp.workcenters are resources instances. Their resource_type is human by
default while workcenters should be considered as material. This commit
set the resource_type as material by default in case of workcenter
When users create new productivity losses of type productivity or performance,
they could not be used. Only one is selected randomly. So it makes no sense to allow
that configuration.
Related to task: 58625
Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
This commit ensures that the prerequisites for the new tablet view
(introduced in Enterprise) are met. Aside from a few additional fields
and simple view modifications which allow simpler changes via
inheritance, the main change it introduces is the capability to take
into account consumed quantities of untracked components.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
The default of the date_start on the time records was a
result of the function fields.Datetime.now instead of the function itself
resulting in the start of each blocking time as the start of the server
The labels of the fields say that they store hours, but actually they store minutes. Correct the code to store hours.
Add digits to fload field for a better display in the webclient
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
MRP module is migrated to the new API. It excludes mrp models that will change
quit a lot during the new MRP conversion. Actually most of the code is not
migrated, but at least side models and their methods are already migrated.
This should lessen the diff when writing the new MRP.
Split files and move them according to the new API guidelines. Containing
- mrp splitted into its main models and files
- stock code moved into its own models and files
- various renaming
Rémy Voet (ryv)