This commit fine tune the appearance of the show detials icon as well as
the editability of the quantity done directly through the move line.
- if no product is selected, don't allow to fill quantity done
- if the selected product requires the show details icon, don't allow to
fill quantity done and directly display it
The scheduler cron will now only call `run_scheduler`. We refactore this
method to extract `_run_scheduler_tasks` and place a call to
`_merge_quant` a the end.
We override `_run_scheduler_tasks` in stock_account to run the fifo
vacuum when the scheduler cron is executed.
The sum is already used in views for
<field name="foo" sum="Total" />
Where "Total" is translatable and extracted in source terms export.
The progress bar kanban widget expect a field name (untranslatable).
Avoid to translate a field name by changing the attribute
Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.
Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.
In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).
ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).
OPW-771886
The code made the assumption that everything brought by in chained move
is available on the quants. This is not always true, for example when x
products are brought by a move in the chain, the user can make an
inventory adjustment that reduce the quantity available. Thus, we
implement a fallback in case the quantity brought by is not available:
do not reserve more than what's really available. If the user make
available some products with the same characteristics (lot/owner/pack)
in the location, they will be used by a new call to _action_assign.
Indeed, the reserved quants are not discernable. This is not an issue in
reality, as the user cannot discern the products himself if they share
the same characteristics.
When a record was added in a kanban thanks to the quick create, column
tooltip and column progressbar were not updating the values they showed.
Now, adding/deleting records updates the whole column as the update
operations.
Thanks to @kig-odoo for the test.
Note: to backport (partially)
When using quick create to create a kanban record, if this record was
then updated thanks to a field widget, the view crashed. This was
because it tried to update the whole column but the newly created
record was not properly attached to it in the model.
Thanks to @sja-odoo for the test.
Note: to backport (partially)
When an onchange is set on an x2many field displayed as an editable
list in a form view, and the user updates one of the subrecords,
the updated subrecord is kept in the DOM and updated, and all other
subrecords in the relation are re-rendered and re-inserted at their
correct place in the list (because the onchange might have changed
them).
Before this rev., the order of the subrecords after the edited one
was reversed.
When undoing the original move line, make sure to handle the packages
correctly (in the destination location, undo the result package, not the
source one.
Before this commit:
1. You could create a page with supported extension in the path (eg: myfile.js)
You would then be redirected to the webeditor (myfile.js?enable_editor..)
But in this case, it would just redirect you to a plain text page without odoo
layout because supported extension are rendered with a specific mimetype.
(is it is a .js page, it will just render the page content as a js file)
2. These kind of page would still call t-layout that you should be removed in
backend in order to make it work
Now:
1. You will be automatically redirected to the back end to edit your file
instead of landing on a text-only page.
2. Supported extension now have their own template (eg: .js file now have
<script text=..> tag added automatically in their content)
Kanban records with 'global click' feature activated should open
the record in a form view when the corresponding card is clicked.
Before this rev., it wasn't working if the user clicked on a tag
of the kanban record, because of an unused click handler defined
on the Many2ManyTags widget (preventing the global click feature
from actually performing the global click).
This rev. removes that handler in the KanbanFieldMany2ManyTags.
This reverts commit b6ef149b as it seems that we don't want this
feature ultimately (was confusing for users trying to open the
record, but it filtered instead).
Note that opening the record by clicking on a tag still doesn't
work, but this is fixed by the next commit.
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
The one2many default get code used to meddle with basic_model's res_ids
manually, which ended up desynchronizing the data and res_ids fields
of the list representation of the one2many values.
This commit solves the issue by using the proper mechanisms of the
basic_model, that is creating a proper datapoint for those ids.
Steps to reproduce the original issue:
- Install sale_mamangement, mrp and purchase
- Create a product
- In the Inventory tab, in Routes, uncheck Buy
- Check and then uncheck back any other route than Buy
- Get a traceback because we are looking for a record with a given
res_id in the list data but since they are desynchronized, data
is empty at that point even though res_ids is not.
when having a tax with multiple children (grouped tax) if we use it in the reconciliation
widget while creating a new line, not all taxes children were taken into account.
Martin Trigaux