Before this revision, pressing ENTER when inside a many2one field
triggers a 'focus out' event. In particular, if one creates a many2one
record and uses the ENTER key to click "Create and Edit", two dialog
windows appear: one to actually create the associated record, and a
second to alert the user that they are creating an associated record.
The latter appears every time the many2one field loses focus.
This commit changes the 'key up' event for many2one fields to ensure
that the ENTER key does not trigger a 'focus out' event.
Lot of features were not working and this commit fixes that
- Create entries upon reconciliation
- Add buttons at the end of the process to view/close bank statement
- Fix partial reconcile
- When changing partner, correctly fetch counterpart account and fix search domain
- Add ability to reconcile without choosing a line (will automatically create a line)
- some other small fixes
Clicking on the discard button in a form view whose previous view is
another form view wouldn't do anything.
This is fixed by making the view_manager trigger_up a history_back event
and then the history_back callback will handle cases in which there is
only one view and only one action, which used to be rejected
Indeed pyeval that evaluates the context explicitly handles null value
differently from undefined values. Let us therefore avoid crashes when
it manipulates the context.
Example of crash
* click on forecast in project kanban view without having already created
forecasts;
* click on 'Assign' to create a new forecast;
* selecting a task crashes because of the domain on task field that is
evaluated using pyeval with an undefined active_id in context that
pyeval cannot handle;
When a chatter is created, appended, and destroyed before being ready,
bad things could happen. This is because the code in start/other
deferred was executed regardless if the widget was still alive. And,
some mechanisms, such as _getBus, depends on the event system. If the
widget is destroyed, it will be remove from the component tree and such
functions will then return undefined.
To protect agains those issues, we simply make sure that the deferred
are only resolved when the widget is still alive.
This widget hasn't been rewritten with the new views.
The purpose of this widget is to open a popup for each invalid partners
(without email) in a many2many to fill the email. If the email is not set, the
partner will not appear in the tags and its id will not be sent (which should
not be the role of a widget but that's the way it is).
Before this commit, all x2many fields values were sent to the server in the
onchange call. If a x2many field was not present in the view, then it
was sent as an empty list [], which is totally wrong.
A few builds fail when run in 'primetime', because the js test suite
takes more than 120 seconds (on the slow runbots). With this commit, we
increase our timer to 180s to make sure that this does not happen again.
Steps to reproduce the bug:
-Create a tax group TX with two taxes: 15% and 5%
-Create a SO with one line and set TX on it
-Print the SO
Bug:
Only the first tax of TX was taking into account
opw:748923
When printing a report, if the company logo or report layout
is not set, it will return an action (ir.actions.act_window)
to set the layout or the logo.
But this change of actions does not forward the data parameters
to print the price list. So it raised an error.
PS: the problem comes from function "set_report_template" which doesn't
take the data parameters into account when it is called from "res.company.report.form".
opw:749724
Steps to reproduce the bug:
-Create a tax group TX with two taxes: 15% and 5%
-Create a SO with one line and set TX on it
-Print the SO
Bug:
Only the first tax of TX was taking into account
opw:748923
When creating an invoice from the purchase order, the later one wasn't correctly
linked anymore (and the invoice couldn't be found through the stat button).
The link is actually done with an onchange at the invoice creation.
The problem here was that the readonly attribute was set on the fields
description but it was not overriden in the view. The onchange was taken into
account in previous versions but with the new views, the correct behaviour has
been implemented: if a field is readonly, the onchange won't write on it.
Before this commit, having an option on a product, the modal had every prices set to the one of the option
This was brought about by commit c8a434306f which was designed for the pricelists and striked prices
After this commit, we keep the intended behavior for pricelists while controlling that options would not mess up the modal
The prices that are displayed are the right ones.
OPW 744943
GH-17342
[FIX] website_sale, website_sale_options:fix the modal of options
Before this commit, the add quantity button were not working at all
This commit corrects the behavior by browsing the dom for anything that looks like a product section
Closes#17353
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
There is a bit of magic in the kanban with many2many: the widget many2many_tags
is automatically set on many2many fields.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
In kanban views where tags were previously colored, we thus have specified the
widget and the color option.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
Before this fix, the field 'color' was hardcoded in the m2m_tags widget,
which means that:
- one couldn't specify another field (problem for custom models, with x_...)
- if the related model didn't have the field 'color', a warning was raised
by the server
Now, the color attribute needs to be specified on the widget options if one
wants to display colored tags.
If the color is not specified, the tags will be displayed in grey.
When an invisible x2many field is modified by an onchange, we had a
crash because the reset function did not return a deferred in that case.
This happens because the signature of _render in AbstractField allow for
an undefined return value, but the reset method should return a
deferred.
This was an issue for example in stock: editing the
pack_operation_product_ids one2many field in a stock.picking could
trigger an onchange on another invisible one2many (with no inline views).
There was a lost promise which made website_form loaded before the
languages informations (such as date format) was loaded.
The server expect the format of the client thus that could lead to wrong
or invalid dates.
opw-749544
closes#18074
Khoi Nguyen