Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
Commit 7cd2f6370 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.
This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.
This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Such buttons are not going to work on records that actually do not
exist yet. The behavior is now the same as in saas-15.
Steps to reproduce the bug:
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- Click on the little square with a + in the m2m list view, the
server will crash in the ensure_one of the function called by
the button since there is no record to run it on.
Previously, we did not handle the case where the result of the m2m
default get was a new record. In this case, we can't just send a
replace all command giving the ids since the new record has no id.
We decided to keep the replace all command even when it is empty
to stay consistent with the o2m implementation, even though saas-15
did not behave like that.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the id given to the onchange is a virtual one,
rather than a create which would not include an id.
Previously, it used to create a virtual datapoint even though there was
no change on this field. If the field was a many2one, this datapoint
triggered a name_get call afterwards, but giving the virtual id of
the datapoint since there is no real record. The solution is to avoid
creating a virtual datapoint when it is not needed at all, thus fixing
the wrong name_get call.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the web client tries to fetch the name_get of
this datapoint even though the record does not exist.
Onchange RPCs return an object that may contain a 'domain' key.
When it does, its value is an object whose keys are field names and
values are the new domain for the corresponding field.
Commit 8473bde8 added the support of the 'domain' key, but stored
it directly in the fieldsInfo (an object gathering information of
the fields in the view, and which is shared between all records).
This was wrong as the domain isn't necessarily the same for all
records. To reproduce, with the UOMs activated, go to Sales >
Quotation, in the form view, add an order line, set a product
(e.g. Graphic Card), the onchange sets the domain for the uom
field (matching uoms like 'unit', 'dozens'). Add a second line
with a service product, the onchange returns another domain for
the uom field (matching uoms like 'hours', days'). Click again on
the uom field of the first line, the domain is the one of the
second record, which is wrong.
This rev. directly stores the domains returned by the onchange on
the object representing the record, so that this information isn't
shared between records anymore.
Before this commit, it was impossible to load the x2many fields subviews when
they were not defined inline.
Now it is possible to call the method "_loadSubviews" to do so.
Used mainly in studio, to be able to display the x2many fields without inline
views.
Before this revision, editing a many2one inside an x2many field did not
cause an update of the x2many field upon saving. This is due to the fact
that a field on a screen was deemed affected by a record change only if
its value or a directly related record has been updated.
This present revision looks for changes recursively, thereby including
the case where an x2many field contains a many2one.
The bug appeared for example in Manufacturing, when editing the product
name of a BOM line.
To reproduce:
- Go Website Admin > Configuration > Settings
- Change the Website Name
- Click on 'Cancel'
The name is saved.
When the "Cancel" button is clicked, we automatically save the record
(which is a transient model). Since the field is a related to the
company, the name is changed even if we canceled.
opw-760749
Since the switch to the new views, clicking on a 12am cell in a week
view of calendar triggers a traceback. A similar issue happens when
creating an event at 11.30pm. This is due to the fact that events
starting or ending at 12am are suspected to be incorrect and are thus
checked against the database.
This commit fixes both issues, by requiring that database checks be
carried out only if the records actually exist in the database.
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
When I did efd15852, I accidentally undid d20074c5. That commit
wanted to filter out unwanted values from the action context, but
it was too violent, as it was discarding the action context. (See
bug described in efd15852)
My original commit aimed at avoiding the filtering of the action
context by having it devoid of unwanted values altogether. The
idea was "if this is an action button, we don't want the element
context". However, the default behavior of the _getContext function
was to add the element context. There were options to force to add
the element context despite being in a case where it should not be
added, but we needed the opposite: do not add the element context.
We used "additionalContext" in this fashion, the idea was: "if I
give you specific context values, don't polute it with the element
context". This was efd15852.
However, not all actions have context defined explicitely in their
definition. In this case, since additionalContext was undefined,
the element context was added again, despite our will not to add
it for actions. We solved this by simply always giving an
additionalContext to getContext, providing an empty one if needed.
To reproduce this bug (which is the same as efd15852):
- Go to Manufacturing
- Click on menu Master Data then Products
- Open a product
- Click on the "Bills of Materials" stat button
- Click on create
- The create crashes because of the "default_type" context key
that is erroneously passed from the "Products" action to the
"Bills of Materials" stat button action.
This commit aims to reproduce saas-15 behaviour when rendering the
calendar. More explicitely, in favourable conditions, we would like the
calendar to be contained in a scroller adapted to the screen dimensions.
To do so, we require that the calendar only use the height given by its
parent container (in case of overflow, the calendar should have its own
scrollbars). We then trigger a 'resize' event to account for a bad
initial render of the calendar.
This fix reproduces a behavior implemented in saas-15.
It avoids simultaneous actions when you quickly click
on status bar buttons.
For example, in a manufacturing order, the main_flow_tour clicks
on 'check availability' and 'produce'.
Clicking on 'check availability' triggers an act_window_close
action when it has done.
Clicking on produce opens a dialog. Both action are executed simultaneously.
It may happen that the act_window_close closes the dialog opened by action
'produce', which makes the test fail.
Now the following buttons are disabled if you click on a status bar button:
- action buttons in control panel
- action buttons in status bar
- stat buttons in button box
A traceback occurred when trying to reload a graph view with no
groupBy in the searchview, because the array of fields to read
given to the read_group RPC didn't contain the default groupBy
field (Error "Fields in 'groupby' must appear in the list of
fields to read"), e.g. in Sales > My Pipeline.
In previous versions, readonly used to prevent sending the values
of the fields to the server. However, it was not working properly
for fields which have their own sub-arch in the view, as the value
used to be sent regardless of the readonly value.
In the new views, the readonly modifier is never overlooked, which
created a bug in the stock_picking_return wizard which was not
able to return products received from a po anymore. Basically the
value of the product_id field was not sent so the create crashed.
This commit introduces a new "force_save" modifier which is used
to express that we want to save the value of the field even though
it is readonly from a user interface point of view.
Since the switch to the new views, 'all' filters such as "Everybody's
calendar" did not work as intended (activating the filter would
sometimes lead to fewer events being shown).
This commit corrects the way 'all' switches affect a domain.
More precisely, the conversion from filters to domain has been changed
in the following way.
- Ticking all visible checkboxes associated with a filter no longer
means the same as ticking the 'all' checkbox. The former choice was
particularly problematic when a filter only had one visible checkbox,
in which case it was not possible to see the list of records
only associated with that one filter.
- The conversion used to contain an impossible case in which we convert
a filter into a 'not in' domain. All the related logic has now been
deleted.
- Minor changes (renaming variables etc.) to make the code more
readable.
Grouped lists aren't editable. However, they may contain a widget
allowing the edition in readonly (e.g. priority, toggle_button...).
This is for example the case in Leaves > Reporting > Leave Details.
When the toggle button is clicked, the model is correctly notified
of the change, which is correctly sent to the server. However,
before this rev., the edited row wasn't redrawn in the grouped
list, so the former value of the boolean was still displayed.
Let's assume that we have a form view with a one2many field
displayed as a list containing two fields A and B (an input field,
e.g. a char field). An onchange on the one2many is triggered as
soon as A changes. This triggers a reset of the one2many which
thus redraws the corresponding line by resetting its widgets.
A problem occured when the user updated A, and directly (before
the onchange returned) updated the input field B, as in this case
the new value in B was erased when the onchanged returned, as the
widget was reset with its former value (or with the value returned
by the onchange, if any). Note that the model was aware of the
change on B, so the model and the UI were actually desynchronized.
This was quite hard to reproduce in practice, by hand, but it
occured in the tour testing 'the flow', in the form view of
account.bank_statement, with fields partner_id and amount of the
line_ids one2many.
With this rev., we don't re-render the input fields if there are
pending changes that haven't been acknowledged by the model.
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
Olivier Dony