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.
In the dashboard, the domain wasn't passed to the view since the new views.
The action in the dashboard and the one saved were thus different (ex: when
saving 'Customer', you got all partners).
This was also causing a traceback when editing a value in the grid view.
This domain is now correctly passed.
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
In case Postresgl access rights prevents the pguser to access
`pg_database`, the server should not crash when trying to create the
database because the pguser does not have the right to check if the
database exists and he won't be able to create a new database anyway.
However the database might exists and in such a case the flow should
continue. This patch allows the flow to be resumed in such a case, and
in case the database did not actually exists, a warning will tell the
user that it was not possible to check if the db existed and the
registry for this database will fail to be loaded afterward.
When you valid a picking wave of 100 pickings, and that one is blocked
(eg: no serial attributed), you have no way to know wich one fail except
opening all one by one.
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.
Use case to reproduce the bug:
One procurement is running for a PO. Cancel one move in the picking and
create it again. Pass the picking in done.
--> The procurement stay in running state
It happens because the check method of procurement look if all moves linked
are in done state but in this case, there is one move in cancel and one
move in done.
This commit check instead if all move are in cancel or done and at
least one is in done state.
opw-753177
Before this rev., nothing was rendered when the 'gauge' widget was
set on a field (e.g. Sales > Leads Management > Team Assignation),
because the API of the fields in web evolved a lot recently, and
the rendering should now be done in a private function called
'_render', not 'render'.
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.
This module defines tours meant to test some cross-app workflows in Odoo.
At this time, it contains a 'tour' that do some important tasks like:
- product creation
- sale order creation
- reordering rule
- invoicing
- reconciliation
- ...
Before this commit, it was only possible to set an option with
his value.
For example:
<select name="test">
<option value="1">One</option>
<option value="2">Two</option>
</select>
The only way to set the first option was to do the following:
run: "text 1"
With this commit, we can now select the first option with his text value:
run "test One"
We need this because in 'main_flow_tour', some values are generated ids.
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.
Since werkzeug 0.12, the `BaseWSGIServer.__init__` method expect the
socket to be bound to determine the effective port it listen to [1].
Stop pretend to bind the socket and close it directly after use.
[1] see pallets/werkzeug@1fc28cbb30
Before this commit, the pad widget did not force the view to save the
current value, since it did not change (pad values are just the url for
the pad). However, this is a problem for the server, since it uses the
fact that the web client forces a save to update the description field
in the model (get the data from the pad server and add it to the
database).
This was not a big deal when looking at the pad (the pad widget fetches
its data each time), but it is a problem that the database is not
synchronized with the current data.
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.
*board,crm
Before this rev., the dashboard panel (e.g. of the sales team
dashboard) wasn't displayed when there were no record to display,
whereas it should. Only the nocontent helper was displayed.
This was a bug introduced with the new view: the views' controller
was in charge to display the renderer (if there were data to
display) xor the nocontent helper. As the dashboard panel was
rendered by the renderer, it couldn't be displayed alongside the
nocontent helper.
This rev. moves this logic to the renderer. So now, the controller
always contains the renderer, which decides what to render (the
data or the nocontent helper). This way, the dashboards can display
their panel and the nocontent helper.
Christophe Simonis