Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
Fine tuning of this commit: 51d072db44
When clicking on the group of the Inventory at Date, the
product.price.inventory must follow the same order as the
read_group in stock.history.
opw:747857
Before this commit, many2one fields were not (fully) usable in a list view: if
the user wrote some text, then when a dropdown with various choices
opened, pressed the 'down' key (to select a choice), the down keypress
caused a navigation move to the next line, which cancelled the
selection.
In this commit, we make the assumption that if the many2one dropdown is
opened, then navigation moves are not what the user wants.
- Create an asset, post one line.
- Go back to the asset => the button is green
- Click again on the line => the button is orange
There is no protection to prevent the user to post the same entry
several times (a new account move is created every time it is clicked).
We fix the JS widget, but we add an extra layer of protection at the
Python level.
opw-778756
Commit b131e9b0ef changed the way the keypress event was bound from vanilla JS to JQuery
In the pos, since it cleans up every jquery event for performances' sake, this binding was cancelled.
This commit cleans up the cleanup process of event at pos startup and rebind the keypress event to the now clean body.
OPW 778565
[FIX] point_of_sale: barcode bindings other strategy
closes#20535
Before this commit, when trying to access website_public_price from the backend (when adding this field to a view for example), a traceback saying that the website attribute on the request object was non existent was raised.
After this commit, we control for this and the field displays correctly
OPW 778586
closes#20536
Before this commit, when opening the POS in IE11, then the customer list, the list was empty.
This was due to condition that was wrongly evaluated as false due to the fact that IE11 apparently only wants ECMA5.1 to deal with constructing Date() from a string.
After this commit, we construct the Date() object with the right string, and the list of customers doesn't disappear.
OPW 776463
For reference:
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15closes#20468
When evaluating a domain, each x2many in the evaluation context is
actually replaced by a list of ids. However, previously, it was actually a
list of commands. The list of ids is much better, since it does not
depends on the exact commands that were generated.
Taxes tags for some localization have been rewrote in order to improve the taxes report.
However, these changes delete the existing account.tags on stable version.
These "[l10n_*] one tag per grid in tax reports" should target master instead of 9.0.
-opw: 777464
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
In some cases, vendor reference for payment may already exists.
For instance in Belgium, some suppliers provide recurring invoices which
contain the same communication for the payment. From the version 9.0,
the field Vendor refrence is used for payment communication and the
maching on bank statement.
So, in this case, we have to put the communication from the payment in
this field and, as explained just above, maybe the same as on another
invoice.
Therefore, this commit provides a hook to modify/disable this behavior.
Closes#20343
opw-777608
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
The access to the state of sale.order.line (related field) seems very slow for big sale order. Bypassing the related field and using the real field instead, improves performance.
When trying to get the pdf content in an IFrame, the url based on
ID was not found and then redirected to a rewritten URL eventually
with wrong protocol (https became http). This causes a bug in
modern browser that doesn't allow mixed content if the base website
is in https. By using the slug in the URL, there is no redirection
and we avoid changing the protocol.
Thanks @Gorash and @nim-odoo
opw-777950
Before this commit, you was able to double click on the button when
are in registration flow. In this case, you subscribe 2 times and so
take 2x more seats, what can be annoying when you have a limited room.
In the same time, we fix the form in the form that generate
strange behaviour like some events not bubbled correctly.
The attendee form (into the modal) was inside the registration form.
$'attendee_form).on('submit') obviously failed due to this bad dom.
This commit closes opw-778191
Since Odoo 8.0,
the default stock input account for product categories
in the Canadian localization is set to
`214100 CANADA REVENUE AGENCY`
This is the case since this commit:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecL294
In which the account with the XML ID 2141_en
214100 Stock Received But Not Billed
has been renamed
214100 CANADA REVENUE AGENCY
In this very same commit, the account "Stock Received But Not Billed" has been moved to the account 217100,
under the XML ID chart2171_en:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecR447
While the default value for the products categories stock input account remained the same, the account with as code 2141:
https://github.com/odoo/odoo/blob/8.0/addons/l10n_ca/account_chart_template_en.xml#L8
This is an oversight. It was not meant that way. The default stock input account for products
should well be "Stock Received But Not Billed".
In addition, a stock account is supposed to be of type assets, and not of type liabilities.
I contacted @max3903, who was a contributor of the l10n_ca localization,
and who is therefore a better expert than me regarding the Canadian localization.
He confirmed me all the above findings.
opw-775413
When having a product with included taxes that are changed/removed with
a fiscal position, the price changes depending on if the pricelist's
discount_policy is with_discount or without_discount.
This commit aligns the without_discount behavior to the with_discount
behavior.
Note: the behaviour isn't 100% correct. The applied discount will be
computed on the list_price, instead of the tax excluded
list_price. If a price_surcharge is set, it will be wrong.
Supplements https://github.com/odoo/odoo/commit/0d56dca
When basing a pricelist on another pricelist in different currency
conversion was not being made correctly, since commit https://github.com/odoo/odoo/commit/6b3a808
that changes the pricelist_item on which the currency_id is set in
_get_real_price_currency.
Also align the _get_display_price's base_price to the
_onchange_discount's new_list_price in the case where the pricelist
depends on other pricelists that are in without_discount mode as well.
This fixes several problems with the reconciliation widget when used with multi-currency.
- company in EUR, create invoice 25 USD, statement of 25 USD (in journal USD), try to reconcile, the amount is not correctly converted, we see two different values, can't reconcile
- company in EUR, create invoice in EUR, statement in USD journal, the amount displayed for the EUR invoice is not correct
When using the HTML editor, when attempting to save a syntax-invalid
XML, the error line is supposed to be displayed in red. This was not
the case anymore since saas-15. This was a simple mistake of comparison
between a stringified integer ID and its integer equivalent.
On rereservation of an mo, it will remove the existing stock.move.lots
if no quantity was done on them. We wanted to avoid however that it
would remove the temporary stock.move.lots on the workorder. On the normal
ones however, there is also a workorder_id. That way it would
not unlink stock.move.lots when you had workorders. By checking the temporary or
not flag (done_wo) instead of workorder_id, we solve the issue.
Courtesy of blaggacao fixes#19422
Calendar tests did not go into US for a timezone problem, making it more difficult to correct errors.
To do: pass all the tests js in US (with simplification for the calculations of the times)
Tasks are showing up on Wednesday when they are Thursday. Checked the dates
on the tasks and my timezone preferences are set to Americas-New York.
fix: Do not apply timezone for all day mode.
A traceback was raised when opening a new record for a model with a
one2many displayed inside a one2many (e.g. simply displaying the
number of records in the relation), and with an onchange setting a
default value to the inner one2many (for example, linking it to
existing records).
As the inner o2m has no subviews, it has no fieldsInfo, and the
code assumed that fieldsInfo was always set.
This was for example reproducible from v11 as follows:
- create a product (with MTO/Buy and call for tender (need
purchase agreement module))
- create an SO with this product and confirm it
- go to purchase order form view and add a move_dest_ids field in
the tree definition of field order_line
- go to menu purchase agreement and choose the PA generated by
your SO
- add a vendor, confirm the PA and click on 'New Quotation'.
The ORM doesn't automatically link subrecords when it receives an
update command for a one2many. However, it may be necessary when
the default_get returns existing records for a one2many field. It
only worked before this rev. for the hr_expense model because of an
hack from 2016 (to reproduce: go to Expenses, check some expenses
from the list view, in Actions, click on 'Submit to Manager', the
new hr_expense_sheet contains the checked expenses (one2many), and
the webclient only sent an update command by linked subrecord).
This rev. fixes the problem properly: when the default_get returns
existing subrecords for a one2many field, a link_to command (4) is
generated alongside the update (1) command.
Before this commit, buttons in form view with the confirm attributes had
a peculiar behaviour:
- < saas-16: they saved the record as soon as you clicked on them, so
the warning was basically ignored
- in saas-16+ (the new views): the button did not save the record before
calling the method, at all.
This can be a problem, obviously. Also, it does not seem consistent to
have a different behaviour when the user clicks on OK in the confirm
dialog, compared to a button without the confirm attribute.
So, with this commit, we just make sure that such buttons save the
record before calling the method, just like other buttons.
As a way to optimize loading, images are not necessarily fetched in db.
They have, in their url a "unique" parameter, which is the last_update date on **the record** and controls on the python-side whether it should get the image from a cache or from the db.
Before this commit, this __last_update field wasn't present in the view, so it wasn't fetched, and writes on a model's image worked but did not refresh.
The image displayed was the old one.
After this commit, when the image field widget is present, we force the loading of the __last_update field of the record.
Upon update, the image displayed is the new one.
OPW 777552
closes#20457
Olivier Dony