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
- Set up a product with 'Real Price' costing method, in real time
valuation
- Receive 1000 units at $0.10 each
- Create a landed cost of $456.70, validate => it creates a quants of
999 units at cost $0.56 and 1 unit at cost $-2.74.
- Perform an inventory adjustment, and set the quantity to 0 instead of
1000, post inventory.
An error arises due to the constrain debit + credit >= 0.
This is caused by the method `_prepare_account_move_line` from
`stock.move`, which cannot handle negative cost for quants.
opw-752063
Fixes#17707
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
This fix 2332df6bc7 has been done in stable and some customers
wants to keep the button "Post Inventory" available all the time.
Now the button is just visible in developper mode.
opw:748347
On the CRM dashboard, the shortcut 'exp. closing' is the same than the
'overdue' shortcut. However, the number of opportunities in these
categories is computed differently (see method
`retrieve_sales_dashboard`).
We introduce a new filter "Overdue Opportunities" which reflects this
difference.
Backport of 9d2f48dc7f
opw-704173
opw-751165
When clicking on the app website admin with the arabic language,
it raised an error because this.date_from.format('YYYY-MM-DD') in
function fetch_data returned an arabic date "٢٠١٧-٠٧-٠٥".
opw:751960
A user without 'Administration/Settings' access rights cannot use the
'Retry' button on a mass-mailing.
This is because only this level of power is allowed to unlink
`mail.mail` records. However, this button is supposed to be used by
regular mass mailing users.
opw-744616
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.
When a user tries to add a product on an opportunity, the date_order of the
order is added into the context. This value can be False.
When "_compute_price_rule" is called without "date" arguments
(some onchange, compute...) the method method use the context date (in this
case the value is False) or the today date.
The date value is used in an sql request and raise a value exception.
opw-751700
- Use the form builder to send an email
- Customize the snippet to include the subject and the body
- Send a mail
=> The subject is not included in the email
This is because the subject is filtered out and considered as a
blacklisted field.
It happens because `mail.mail` inherits from `mail.message`. The field
property `website_form_blacklisted` is set to:
- `True` for `mail.mail`
- `False` for `mail.message`
Since we go through all inherited models, the property on `mail.mail` is
overriden by the property on `mail.message`.
It is actually not necessary to go through all inherited models, since
in the case of `inherits`, we copy the fields of the inherited model to
the target model. The check is simplified by only checking the fields of
the current model.
Based on work of @nla-odoo
opw-748926
The old release of wkhtmltopdf are no longer published on the download page.
The developer explicitely asks to use the github link
cf: wkhtmltopdf/wkhtmltopdf#3524
wkhtmltopdf/wkhtmltopdf#3521
wkhtmltopdf/wkhtmltopdf#3518
wkhtmltopdf/wkhtmltopdf#3508
Closes#18146
- use datas of all lines, and not only the last lines.
- removed useless 'move_id' field from account.move.line
Was PR #18175. Courtesy of Sylvain Legal
If a user chooses a product that has a blocking error message, the product
is set to False. This is good, but we do not want the following to happen:
The other onchange triggers are called and "product_uom_change"
generates an error because there is no product. (In fact it is
"_compute_price_rule" on "product.pricelist" who raise)
The onchange update the values of the other fields related to the
product (eg for the "name" field where the name of the product that
is canceled by the warning is assigned).
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:751697
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
Nicolas Martinelli