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.
It may be confusing that a constraint is not triggered in a name_create call.
Testing the absence of value should be done in an override of create, not in a
api.constrains.
Closes#18382
It is costly to compute all issues, return the full list of all issues, only to
compute the length and display it.
Use proper issue_count field.
Closes#18858
The reference widget is also meant to be used on a char field, not only on a
reference field.
The rev. https://github.com/odoo/odoo/commit/a4e30a1b43d0b9acd76508d9e6c466cd1dbdffab removed
the use of `field_utils.format.many2one` and replaced it by `_formatValue` to
support this use case.
The replacement wasn't complete as some occurences was remaining (in reset),
which led to traceback when the widget was reset (impossible to create an
External Identifier anymore).
Also, the reference `_formatValue` wasn't correct as it was displaying the
record `display_name` and not the reference field value ; this only makes sense
for the External Identifier as its display name is the reference field value but
it doesn't make any sense for other reference field.
Last but not least, this commit implements the `onchange` and `default_get` for
the reference field.
Use case to reproduce:
- Create multiple warehouse
- Select a warehouse to ressuply on a warehouse form view
- Go to the supplied warehouse form view
- Change the delivery method -> Traceback can't adapt stock.location type
This happens because there is a write method using a stock
location instead of its id.
This commit use the location id instead of location
Aaron Bohy