The report "Manufacturing Orders" is just the graph/pivot view of MO,
most of the infomation can be found on a more accurate report
"Production Analysis".
In this commit, we removed "Manufacturing Orders" from the report view.
Users can still access it from Operations -> Manfacturing Orders ->
graph/pivot view.
Task-2695732
closesodoo/odoo#130342
Related: odoo/enterprise#44912
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
The field manual_consumption field on mrp.bom is computed,
`readonly=False` should be added to make sure it's changable.
Also on the form view, `force_save="1"` should be added to make sure the
value will be saved since we make it readonly in some cases on the view.
closesodoo/odoo#132600
X-original-commit: 4bdfd0d1e0d95af92a1afae5888e9e587fc4994e
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
* = account, calendar, im_livechat, mrp, project_todo, sms, snailmail,
test_mail, web, website_livechat
`contains` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
closesodoo/odoo#130451
Related: odoo/enterprise#44999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
`QUnit` tests require at least one `assert`. This change allows to write
tests that only contain `waitUntil` without extra `assert` in the test.
`waitUntil` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
Currently existing tests that contain `waitUntil` have been adapted
accordingly. More and more tests should make use of it in the future.
Part-of: odoo/odoo#130451
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
With this commit
================
Removed 'action_mass_start' and 'action_mass_pause' methods also
the 'button_start' and 'button_pending' methods have been modified
to accommodate multiple work orders, ensuring seamless functionality.
closesodoo/odoo#130663
Related: odoo/enterprise#45883
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit
==================
Marking multiple work-orders as done was not functioning as expected.
Only the first work-order status was being marked as done, and not all of them.
Steps to Produce
================
- Create a bom product having multiple work-orders.
- Create a MO and confirm it.
- Inside WO list view select multiple work orders of the recently created MO,
and click on "done". You will notice that even though multiple work-orders
were selected, only the first work-order status is changed to "done".
With this commit
================
On selecting multiple work-orders and triggering "done" will work as expected,
and the status of all selected work-orders will be marked as "done".
Task: 3374990
X-original-commit: 486aab5ee8ae1cd8792bc9bbb4aae1797c38fe5f
Part-of: odoo/odoo#130663
This commit fixes the layout of the BOM control panel.
task-3419079
Part of task-3326263
closesodoo/odoo#132025
X-original-commit: c0fac4b7b8b66315a553337956999d8eb602ac13
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
PR #106911 added the new picking.type for repair and hide the
`show_operations` field from its form view. Unfortunately this writes
over the existing invisible attr for mrp_operation (depending on the
order of module installation, otherwise mrp will do the same to repair).
Therefore we update the attribute logic to only include the picking
types that should have the field visible (incoming, outgoing, internal,
and dropship).
closesodoo/odoo#132012
X-original-commit: 1688a8d82ce7aec32f17fc8c35295cccbb682dd6
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
We only show the move that requires a manual operation in the
shop floor application. Currently we only see the MO for table top
with a single operation to register the finished serial.
It's a bit funnier to see also the components required and check them
Also the manual_consumption field is a compute store without inverse.
It means it's readonly true by default. But we should be able to pass
a value and use it instead of the compute
X-original-commit: 58118291e148a144058c0c883ddd138187a86f3d
Part-of: odoo/odoo#131707
Before [1] the demo user only has the basic right. Now it has
the administrator rights and it prevent an easy testing for user
flow.
The demo and admin users get their rights from the common
template with administrator right everywhere. Since it's a
data, we could just remove the administrator level and set
the user level in the demo data.
[1] commit 121cd0d608
X-original-commit: 7b7fdf5d4eb892bfd3c2fdb575264025dca21ca5
Part-of: odoo/odoo#131707
Previous fix c7616df enforced an order on the workorders for the
computation of the time_cycle. However, 'asc' is used by default in
order clauses if not explicitly written.
This resulted in using the oldest workorder instead of the newest to
compute the duration.
closesodoo/odoo#131830
X-original-commit: a69d13abbc81b36aaf717f8e4d665fda8580c1fc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce the bug:
- Create a storable product "P1"
- Add 2 variants:
- Color: Red and Blue
- Size: XS and M
- Create a Bill of Materials (BoM):
- Add any components
- Create operation "OP1":
- Apply only to: Red XS
- Create operation "OP2":
- Blocked by "OP1"
- Apply to all variants
- Create a MO with the variant "P1 (Blue and M)"
- Try to confirm the MO
Problem:
a traceback is triggered, the issue has been fixed in: https://github.com/odoo/odoo/commit/0f21fde26fa4387d93722092ebf21d294fcfcd4f
Solution:
Link only if an operation is blocked by another operation with the same attribute values.
OPW-3329263
closesodoo/odoo#131727
X-original-commit: 2fa8e2f64292483c0aa27141fe59eb4a6ff8effb
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When user uninstall the module 'Manufacturing' the relevant records are not
deleted from the Operation Types, Transfers and Stock Rules.
To produce in sass-16.2:
- Install 'Manufacturing' module
- Create mrp order and validate it.
- Now uninstall 'Manufacturing' module.
- Operation Type 'Manufactuing' is still showing. (14.0 to master)
- Go to 'Inventory' and click on 'Receipts' and remove all the filters.
- Another way > Create a new 'stock.picking' with 'Operation Type' as
'Manufacturing'
Error: A traceback appears: 'Wrong value for stock.picking.picking_type_code:
Manufacturing'
Fixed this issue by updating the code of the picking type and archiving it after
uninstallation of module using 'ondelete' function.
sentry-4167898386
task-3318858
closesodoo/odoo#131725
X-original-commit: 0b400d33ed9ad15d539306ff7ba8519afc63234c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min
It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough
closesodoo/odoo#131307
X-original-commit: cad75ac78b61046352c39d3f3b7717cfbad42c8b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
**Sum of timesheets time different than what the timer displays**
Steps to reproduce:
1. Start a workorder timesheet, then stop it
2. Repeat the process multiple times.
Current behavior:
The error is based on a microsecond precision so you could need
to try multiple times before reaching the problem.
- The time displayed on the timer widget does not display the same as
the sum in the timesheet list.
- The difference between the start date and end date of a timesheet
is not always equal to its duration.
Expected behavior:
- The sum of duration should be the same as the one displayed on the
timer widget.
- The difference between the start and end date of a timesheet
should be equal to it's duration.
The computation of the duration of a timesheet will take microseconds
into account. It's not useful in the timsheets to save microseconds
as the precision is too high and as the user cannot change it manually
anyway.
Removing this precision (i.e. setting microseconds to 0) solve this
problem as it does not trigger rounding errors in a single timesheet
and thus in the total computation of duration of a workorder.
Also, there was a precision rounding error on the timer widget.
Time is saved as minutes in db, and displayed as seconds.
So 2s is 1/30 of min => 0,0333... min.
As multiplying this by 60 will return 1,99999 and as the timer was flooring the result,
there was some difference between the time recorded and the value displayed in the
widget.
enterprise : https://github.com/odoo/enterprise/pull/41727
opw-3241156
closesodoo/odoo#130618
X-original-commit: 0172395fa60c94150609bbbfe174d5eee44525fe
Related: odoo/enterprise#45109
Signed-off-by: Tiffany Chang <tic@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit
==================
When creating a BOM through a MO (form view), the WO expected duration is reset
to the default value on the source MO as well as the corresponding Operations in
the BOM.
Steps to Produce
=================
- Create a MO with 1+ WOs and set an expected duration for the WOs.
- Generate a BOM through the MO and observe the changed duration after saving
the BOM
After this commit
=================
After this commit the operation/WO duration doesn't reset to default values.
task - 3414446
closesodoo/odoo#129390
X-original-commit: 05d0dc26e24f24107a5e443dc9ccafd0ff7a1af9
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Before this commit
==================
Marking an operation as done rather than start and done, the status of
subsequent immediate next linked work orders is not updated properly inside
WO list view.
Steps to Reproduce
==================
- Create a bom product having more than one operations.
- Create a MO and confirm it.
- Inside WO list view select a single first operation of the recently created
MO, and click on done, you will find that the status of subsequent operation
(immediate next) is not updated properly.
This happens because of the reservation state of the MO which has initial
state as false and thus the status of work-order changes to 'waiting'.
With this commit
================
Marking operation as done the status of subsequent linked work order gets
updated properly.
closesodoo/odoo#128881
Task: 3358125
X-original-commit: 0533577264413934179cc32e0cfe26cb324dd58a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
-Create a product in kg as storable.
-Add it into the BOM of another as grams.
-Create an MO with the BOM with more than 1 quantity to be produced.
-Set the quantity to be produced to 1, validate and create backorder.
Bug:
Error message: "It is not possible to reserve more products of test kg
than you have in stock."
Fix:
correct conversion of units during backorder reservation of component
closesodoo/odoo#129152
X-original-commit: 8f26839998f21e521ecaeba38a2bcc6c72894f41
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The `mrp.production` method `_pre_button_mark_done` will now be public
so it can be called since the web client.
This change is done in order to know if trying to mark as done a
production will return a wizard or not, which is needed in the new MRP
Display view since there is a delay before a MO is actually marked as
done and we don't want to see the wizard poping up after this delay but
before !
The method `_set_qty_producing` public is also public now because it's
called in `_onchange_producing` but saddly, the onchanges don't happen
in the MES view, so this way we can manually call it when needed.
task-3231200
Part-of: odoo/odoo#127250
In `mrp_workorder` (enterprise), we're adding a new view to process
manufacture orders and workorders: MES.
These changes are more or less related to MES. See following for the
main changes.
== Be able to mass produce an ongoing production order ==
Currently once the mo is in progress it's not possible to use
the mass produce feature anymore. Even in basic cases where the
componenets are not tracked. It's also not possible to mark
all the productions directly as done. It's needed in the
mrp display action, so we enable it everywhere
== Manage different flows with tracking ==
Currently there is 2 different flows:
- No tracking -> All the quantities easy
- Lot -> All the quantities + display button to create lot number
- Serial with component not tracked or only one: Mass produce
- Serial that require a match between components SN/Lot and finished
product serial number -> Only display it as one unit with an automatic
backorder/
task-3231200
Part-of: odoo/odoo#127250
Co-authored-by: R1D1CUL0US <clpi@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
- Add table's leg in stock;
- Don't confirm `mrp_production_3`;
- Decrease qty to produce for `mrp_production_1` and confirm it.
task-3231200
Part-of: odoo/odoo#127250
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Step to produce:
=================
- Create MO of serial tracking product.
- Start workorder.
- Click on continue consumption button.
- Enter quantity to consume then click on validate button.
- Then when we click on Continue button quantity become zero or negative.
Issue:
========
If the product tracking is serial and quantity is already set to 1 in this case
it write the same 1 value in serial tracking order because of that it calls
'_update_component_quantity' method again it will make the quantity zero.
After this commit:
=====================
Prevent the quantity becoming zero.
Task id: 3212121
closesodoo/odoo#128665
X-original-commit: 907129be7efba2a0b68f9bef14c6a22c1be8861a
Related: odoo/enterprise#44183
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product "P1":
- Unit of measure: KG
- Bill of Materials for 1 "g" of "P1":
- Component: 1 unit of "C1"
- Route: Manufacture
- reordering rule: Min 0, Max 0
- Create a Sales Order with 510 g of "P1" and confirm it.
- A Manufacturing Order for 510 g of "P1" will be created.
- Create a second SO with 510 g of "P1" and confirm it.
Problem:
The quantity in the MO will be updated to 1.02 g of P1 instead of 1020g
"Whenever we update the quantity, the `_run_manufacture` function is
triggered. Consequently, we use the `product_uom_qty` from the
manufacturing order to calculate the remaining quantity. However,
this field is computed, and it converts the quantity into the unit of
measure of the product, rather than that of the manufacturing order.
https://github.com/odoo/odoo/blob/3b801a6d48f1feffd1b87a7d54731ab58e8d63e9/addons/mrp/models/stock_rule.py#L75https://github.com/odoo/odoo/blob/5118d248ccf16fe4d2703c2a64e0267f783a56d1/addons/mrp/models/mrp_production.py#L171-L172
Opw-3410254
closesodoo/odoo#128776
X-original-commit: 04371c0ec777cede50e940f45064f86cb4cb8964
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The purpose of this commit is to review the responsiveness and spacing
of some settings that were visually broken.
The nested checkboxes were growing too much on smaller screens
making the content overflow.
This commit adapts these checkboxes settings to make them more readable
and consistent.
It also review the input that overflow similarly to nested checkboxes
such as the count of extra hours in attendances settings.
In 16.2 some SCSS was added to control field widget spacing on mobile,
however it was breaking the layout for the `.o_boolean_fields`.
Task-3113372
closesodoo/odoo#126347
X-original-commit: 80aa03e86bd47e6349a5fa69397857fdf6a8cc0b
Related: odoo/enterprise#43142
Signed-off-by: Tiffany Chang <tic@odoo.com>
When user not seleted 'work center' and only selecting 'Scheduled Start
Date' and 'Scheduled End Date' while creating 'work_order' in
'mrp_production', this traceback raises.
To reproduce the issue:
1. Install 'mrp'
2. Activate 'Work Orders' in configuration/settings
3. Go to menuitem/operation and create 'Manufacturing Orders'
4. Select any product and add a line in Work Orders
5. Give values to 'Scheduled Start Date' and 'Scheduled End Date' only.
Error: A traceback appears:"ValueError: Expected singleton:
resource.calendar()"
On '_calculate_duration_expected' method resource_calendar_id value is
getting from 'workcenter_id'.
https://github.com/odoo/odoo/blob/36459d26f1adb92f92d52ce05329e8ad3e95dd91/addons/mrp/models/mrp_workorder.py#L399-L404
Therefore in the above use case, when triggering the onchnage method,
because of resource_calender is dependend on 'workcenter' and when
workcenter is not selected it will lead to the above traceback.
Sentry-4244804815
closesodoo/odoo#128643
X-original-commit: 102ba9a848162db0029ca639ea84a9319b80d278
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce
==================
- Create and confirm MO with BOM1
- Consume the theoretical qty of your MO
- Update the BOM1
- Click on the `Produce All` button
- You will receive a message that the consumed quantity does not match the quantity
of the BOM1 anymore
- When clicking on the set quantities and validate button, the consume
quantities are not the ones that are previewed in the flexible consumption message,
but the initial MO quantities.
So in this commit, we updated the `To Consume` quantities as per the flexible
consumption wizard.
task - 3323154
closesodoo/odoo#128488
X-original-commit: fe95a33770c8b701b007310e2b9b5f7b0596f5a9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
While creating a Manufacturing Orders, when user give date format as '%d/%m/%Y'
and when it tries to match the date format with '%m/%d/%Y' in
'_add_transit_line' method, the error will be generated.
Steps to Produce:-
1. Install 'mrp' and 'purchase' module
2. Change the format of date in 'Languages' as '%d/%m/%Y'
3. Activate 'Multi-Step Routes' in inventory configuration
4. Go to 'Warehouse' and select 3 steps route in 'Incoming Shipments' and
'Manufacture' and save
5. Go to 'mrp' and create a new BOM
6. Go to 'purchase' and create a PO with the same product in BOM and confirm it
7. Click on smart button 'Receipt' -> 'set quantities' -> 'validate'
8. Go to 'mrp' and create a MO with same BOM change the 'Scheduled Date' and
confirm it
9. Click on smart button 'Overview'
Trace-back will be generated.
Applying these changes will resolve this issue.
sentry-4088257491
closesodoo/odoo#128453
X-original-commit: d1d7141fd52bd7167910074adcde2cd95e8b9440
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
*: mail, mrp, test_website, web, web_editor
Before this commit '.webp' images could not be used in odoo.
After this commit '.webp' images can be uploaded to odoo.
- can be used in image field
- can be used in HTML field image
- can be used in mails and website
- can be transformed (shape mask, filter effect, crop, rotate, resize,
adjust quality)
task-2774352
Part-of: odoo/odoo#85494
yhu-odoo