The problem occurred in form view, in edit mode, when the user
did some changes in the form, and then clicked on 'Log or schedule
an activity'. When validating the activity, the fields mail_activity
and mail_thread were reloaded but all changes were discarded in the
process.
This rev. ensures to reload the requested field without discarding
the changes.
Also add a lost functionality, when coming from payment view, pass account_move_line id to the context so that it is directly opened as a proposition in the reconciliation widget. If a matching line is found for that payment, also propose the matching line.
Before this commit, create a contract which expire in 2 months.
The cron will check all contracts that have a date_end >= tomorrow.
All contract with a end_date will be close.
Now we check all contracts that have a end_date <= yesterday and close it
1. Create a product A, set to stockable product, set its UOM and
purchase UOM to Unit(s)
2. Create SO with A, but use a different UOM than Unit(s) (e.g. Dozen)
3. Validate, go to delivery, validate, and print the delivery slip
Ordered quantity shown on delivery slip is in SO UOM but listed as
product UOM.
opw-766914
Resetting the key 'test_barcode_handler' to its value before the
test was technically the best solution, as a test should leave the
environment unchanged. However, in this case, the widget is
undefined (there is obviously no 'test_barcode_handler').
Whereas this should not be a problem (the fields in the registry
are supposed to be accessed using get(), and the presence of a
key mapping undefined is equivalent to the absence of the key in
this case), this breaks a test in Studio if the latter one is
executed after the barcode test. This is because Studio browses the
map of the field registry to access each field's prototype. When it
encounters an undefined value, it crashes.
When used on a large db with lots of records to process, `last_run`
date that was written on the base.automation could be a few seconds
later than `now` that was used to check whether to run the automated
action. This caused some small time frames to be never checked, and some
records to be missed. We fix this by using exactly the same timestamp.
opw-766182
This was the case about 15minutes ago. But before pushing we
decided to change the Barcode override of FormController to
directly use handlers of the FormController when it could (e.g.
to handle 'Edit', 'Discard' actions). This wasn't a good idea as
those handlers don't return anything, and the barcode mechanism
requires its handlers to return a deferred. So basically, it
crashed when such a barcode was scanned. Having a test suite is
nice, but you should not forget to relaunch it before pushing...
The barcode mechanism is supposed to handle commands PAGER-FIRST
(go to first record referenced in the pager) and PAGER-LAST (go
to last record). Before this rev., it wasn't the case.
We needed to add an option 'notifyChange' to the updateState
function of the pager, to ensure that the form is correctly
reloaded when the pager cursor is manually set (by the barcode
handler) on the first or last element.
The barcode mechanism is optimized to (in certain conditions),
directly increment the quantity of a numerical field inside an
x2many, without performing any RPC, and then re-rendering the
x2many to display the new value.
Before this rev., it seemed to work fine, but when the view was
saved, those changes of quantity were lost. This was because the
changes weren't correctly notified to the model (the quantity
field being inside an x2many, the correct update command for the
x2many should be generated).
When a barcode field with widget="barcode_handler" is in a form
view, an onchange RPC should be done each time a barcode is
scanned.
Before this rev., it worked by chance because the views using it
don't define a 'pack_operation_product_ids' field.
Anyway, this widget is meant to be generic, so it shouldn't
hardcode a fieldname.
Before this rev. a warning was displayed when a barcode mapping an
invisible button was scanned. It shouldn't, for the following
reason. In the stock.picking form view, two buttons with
barcode_trigger='validate' are in the page ('Start Inventory' and
'Validate'), and there is always at least one of them that is
invisible. So when scanning the 'validate' barcode, we don't want
a warning to be displayed, as there is potentially another button
that is able to handle the request.
When scanning a command barcode, the view shouldn't be redrawn
after the operation corresponding to the command is executed,
for two reasons: first, it is useless as the view has already
been reloaded, and second, it may cause issues if it has been
destroyed meanwhile.
For example, when scanning barcode O-CMD.MAIN-MENU from a
picking form view: a do_action is performed to go back to the
main barcode client action (so the current form view is destroyed),
but an handler tried to redrawn the destroyed form view, which
produced a crash because the session was required by Date fields,
and it couldn't be provided (there were no more parent listening
to provide it).
When a keypress event is triggered in a 'field_float_scannable'
widget, the event is first catched by the barcodes mechanism, and
then manually re-triggered. However, the way it was done implied
that the environment was notified of each keypress event, so if
there was an onchange on that particular field, an onchange RPC
was done at each keypress.
Moreover, the focus was lost at each keypress as well.
When creating a new picking and adding a new product operation, the operation was
disappearing. As the field `product_id` is readonly in some conditions, its value
wasn't sent by the client on the picking write rpc.
This behaviour of not sending readonly fields in x2many has been correctly
implemented with the new views but some views (like this one) was basing their
behaviour on this breach.
See rev. https://github.com/odoo/odoo/commit/3b3f6f04af79d7dcc4461262e14e05096d76180b for more details.
The key `form_view_initial_mode` can be set in the action context, to
open the action in edit mode, mainly.
This key wasn't supported since the new view refactoring so this commit
restores its support.
This option has been removed with the new views but was used in barcode.
The form renderer was also dealing with some part of the autofocus
but this should only be handled by the controller.
The logic is now only in the controller and a test case has been added.
Since the new views, most of the barcodes feature was
broken. This commit re-enables the support of commands like
'edit', 'save', 'cancel', 'previous' and 'next'.
Also changed javascript event handler to jquery event handler to
make barcodes testable in phantomjs.
In case where the product is of invoice_type 'order' and not 'delivery',
we allow the user to edit the anlaytics lines / timesheet.
Previously, an employee was unable to edit an timesheet line once saved.
When you work on prepaid pack / long task, it is frequent to edit
existing timesheet line.
In the reconciliation widget, create a counterpart line. No domain is
applied on the "Account" field regarding the company, meaning that we
can select an account from any company.
opw-694149
Bug:
Before the the fix, when trying to get all the translations of templates from a
specific model:
-All the translations for the templates of this model were catched first -> TT
-All the records of this model for a specific company were catched afterwards -> RC
Then, the linked between the translations(TT) and the records(RC) were made in function
process_translations.
But in some cases, a few records were removed and then it raised an error because the number
of translations was different than the number of records.
Fix:
Thanks to the function create_record_with_xmlid in addons/account/models/chart_template.py, all the records
created from a template have an xml_id in ir.model.data with str(company.id)+'_'+template_xmlid.name
So with this way, it is possible to catch only the records created from a template.
opw:767095
Before this commit, it could happen that a x2many field was considered
invalid, which prevent triggering onchanges, even though each of its
required fields are properly set. Here is such a scenario:
We have a one2many field something_ids in a form view, with an inline
tree view, which contains a field X. The field X is required on the
model, but marked required="0" in the inline view.
In that case, we incorrectly evaluated the required modifiers: since the
attrs did not contain the required attribute, we fell back on the
field_get value, which is true in this case. But this is not correct,
the fieldviewget already computed the actual modifiers and took into
account the fact that it was overridden. We need to only look at the
modifiers.
The behavior is no longer implemented by the web client. Implement it
server-side as part of the onchange mechanism, simply by defining onchange
methods for the fields that have the flag.
Before this rev., the button box wasn't displayed on new (not saved
yet) records. This wasn't the case before the new views.
This is a problem in lunch, as the lunch.order form view is opened
in create mode, and the balance is displayed in the button box.
Before this rev., keys like pivot_measures, graph_mode..., were
correctly took into account at first load of Pivot or Graph view,
but not at reload.
Those keys are particularily useful when a user saves a research
to its favorites. When such a favorite is selected, the view is
reloaded and the interesting information is in the context.
The former implementation of the Pivot view used __count__ as
magic field to display the number of records in groups. However,
in filters defined in xml, __count is used instead of __count__,
so it crashed when such filters were activated.
With the new views, we made those filters work by using __count.
However, if a user saved filters using __count__ at that time as
favorite, activating them in the new views produces a crash as
well.
This rev. adds a compatibility layer to ensure that the pivot
view handles both __count__ and __count measures uniformly.
When a graph is added to the dashboard, it doesn't have a minimum
height set, so only the label and the axis are displayed, not the
content.
opw-766454
Aaron Bohy