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.
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 the invoice is validated, the related timesheet are
set as invoice, and are not updateable anymore.
In order quantity, create and confirm SO, log 2 timesheet
lines and validate invoice. Your 2 timesheet lines will be
mark as invoiced. The other hour to deliver will not be linked
to the invoice (and their revenue=0), so the futur lines will
be updateable. But for the 2 first, the user will have to create
a new timesheet line, intead of updating an existing one. The
color will tell him which line is invoiced.
When the user remove the partner, the reconciliation widget try to read
information on 'res.users' without any partner id.
Open the match view when change the partner.
Remove max-height which can hide the last proposal.
There was an error message when trying to move an entire
pack that contains multiple quants saying that every component
in the pack should be in the same location. (it the case with the
bug)
It happens because after action_done only one quant of the package is moved
to the new location and other quant still in the old location. Thus the
check fail. Also the extra move for remaining was not created.
This commit changes the get_remaining_prod_quantities on pack operation
that had a migration error between old/new api. This change returns the
correct remaining quantities and thus the extra move is created and all
quants for the pack are moved to the new location.
- Create a mass mailing including a 'tel' or 'sms' link, e.g.
`<a href="tel:555-000-0000">555-000-0000</a>`
- When sent, the link is converted to a tracked linked (`http://...`)
We do not want to convert these links, they should be handled by the
browser directly.
opw-765885
- Create Products A and B, tracked by unique serial number.
- Receive some quantity of B.
- Create a BOM for A which uses 1 unit of B.
- Create a MO for 2 units of A, save and check availability.
- Click on the 'Produce' button.
- Change the suggested lot (choose a new one or create), then click on
the '+' button.
When the wizard is reloaded, the lot chosen is lost.
We reach an exception in the framework: when clicking on the '+' button,
no `create` is performed on the transient model `mrp.product.produce`,
therefore the values are not saved.
Since this use case is an exception and is likely to lead to errors, we
remove the button.
opw-761044
Users will generally not have the right to read Journal Items unless
they are members of one of the Accounting/Invoicing groups.
Removing the payment-related fields & widgets from the view should let
those users view relevant customer invoices (e.g. for Salesmen) without
getting an AccessError, due to the underlying access to Journal Items.
Aaron Bohy