As done in write and already in next version (see 0fd773a), accessing a deleted
record (through read or check access rights) should always return a MissingError
instead of the generic except_orm.
This will allow code ignoring deleted record (e.g. 'recompute' method) to safely
process the other records.
Fixes#6105
When searching if a many2one property field is not set, there may be less
results since only the ones with a reference set to NULL are returned.
We should also get those not in the table.
This commit change this case so instead of returning ['id', 'in', {matching non-set ids}],
the ['id', 'not in', {matching set ids}] is returned.
e.g: if (1, 3, 8) are set, (5, 9) are not set. ['id', 'not in', (1, 3, 8)] would
be returned instead of ['id', 'in', (5, 9)] which might not select all non-set
property fields.
closes#6044
opw-631057
Source from https://code.google.com/p/reset5/
Used same file to be able to merge in stable but should be moved to separate
file in lib folder in master.
Fixes#6376
Indeed, when canceling a transaction, pspReference
is not passed.
In such a case, the arg authResult is set to
`CANCELLED`, and in such a case, we should
just bypass the form_feedback, as done in
the payment_paypal module.
opw-634210
When using another decimal separator than `.` (dot)
in the language settings,
it wasn't possible to build an advanced search specifying
the decimals.
e.g. with a language with decimal separator `,` and thousand
separator `.`,
if you want to search invoices with amount total 366,38
The advanced search "Total" "is equal to" obliged you
to enter your number with `.` as separator (366.38),
and then, when entering the search, the `.` was
regarded as the thousand separator, giving as domain
`('amount_total', '=', 36638)`, which is not what you asked.
opw-634201
PS: The `|| '.'` in the xml template are only for
retro-compatibility, so if the server sources are
updated, but the browser cache is not refreshed
(meaning the Javascript code isn't refreshed, and,
therefore, `widget.decimal_point is undefined)
it still works.
The SQL view implementing the "Invoice Analysis" report
JOINs the res.currency.rate table in order to obtain the
correct currency rate to convert each invoice line amount
in the same currency.
The matching of the rate needs to be done on the date
of that rate (`name` column) - the last rate preceding
the invoice date is presumed to be the right one.
However there is no simple way to make a direct JOIN between
account.invoice.line and res.currency.rate with a single
match, without using an ORDER BY clause and LIMIT 1.
This requires a costly SUBSELECT query for each invoice
line, quickly becoming prohibitive.
Through the use of PostgreSQL's Common Table Expressions
(CTE) it is possible to construct a temporary table
with the rates' start and end date of application.
This temporary table can then be used in a direct
JOIN with account.invoice.line, delivering much better
performance (no SUBSELECT needed for each invoice line)
On a database with 50k invoice lines this makes invoice
analysis return results in less than 800 ms instead of
10+ seconds.
This is related to rev. ab9f02cdee
The above rev. take care to exclude payments that are not yet due;
meaning the ones due in the future, by checking the maturity
date.
Problem: Payments (e.g. move lines from bank statements)
do not have a maturity date. Only move lines that actually
have a maturity date, in the future, must be excluded,
not the one that do not have a maturity date.
opw-633930
Revert c06a96 "[FIX] stock: force recomputing transfer information on picking"
and unlink packoperations only when move lines are changed (fix opw 620636).
c06a96 introduced a regression as it prevents to plan moves (e.g. assigning lots
through the barcode interface) before the reception.
The domain on account.account was preprocessed in search method but it had no
effect on read_group. This lead to inconsistency or errors when using 'goup by'
filter.
Move domain processing in '_where_calc' method instead as this is used by both
'search' and 'read_group'.
when closing a modal, the class 'modal-open' was removed from the
'body' tag and all the existing modals became not scrollable.
The class 'modal-open' must be kept in the 'body' tag if there is
still a visible modal in the dom.
Inspired from commit: dee000be14
opw:633801
This reverts commit 24526b18a7.
The journal_id field is not present on account.account but is processed in
search method.
Next commit will improve the processing to also accept journal_id in read_group.
Adding an image from the frontend use ir.attachment or pre-existing url
and set the url in the blog.post's background_image field. This is
not the same as a binary field which sets the data in the field.
Since it's possible to do it in the frontend, there is no use of the
field in the backend. This fix removes this field.
closes#6497
issue #1305
opw-633725
The onchange partner on the sale.order set the 'note' field as the terms of the
company in the partner's language.
When the SO is created from an opportunity, the terms are not translated.
Call get_salenote method that handles patner's language.
Commit 8a6e859 wrongly introduced this new field when adding the new
`payment_authorize` module.
As 8.0 is a [stable version](http://git.io/vfACM), no data model change
is allowed.
We convert this field to a `fields.dummy` in case someone installed (or
update) this module with this fields to ensure the view still applied
and is not broken.
The function _unite_compute and _unit_compute_inv did not give the same display result.
Regardless the way the tax is computed, the display must be the same. The display must
only shows the name of the tax.
opw:633828
-Test the function _bom_find to check that it searches the bom corresponding
to the properties passed or takes the bom with the smallest sequence.
For this commit: d357667df4279070b51af58cad55ef314688d69f
- Test the function _bom_explode to check that it only takes the lines with the
right properties.
For this commit: 6b6e71a3e0c86aa8a9b8c4f20eaa61b17c64ce7b
Now it's possible to put a property on a bom line.
For example, the bom for an apple pie and for an apricot pie can be made
in a single bom.
Three lines are necessary in the bom of the product "pie":
- First line with product " dough" without property
- Second line, with product "apple" with property "apple" if you want an apple pie
- Third line, with product "apricot" with property "apricot" if you want an apricot pie
The type of this bom pie must be "set" to allow the customer to assemblate
his favorite pie by himself.
Now to sell an apple pie, you must create a SO with the product "pie" and
the property "apple".
In that way, the delivery order consists of two lines:
- dough
- apple
The bom related to the product in a sale line order must be
filtered by the function _bom_find. If two boms can be applied
on a product, the bom with the smallest sequence is applied.
opw:632558
This fix gives the domain to the "See selection" view opened from a
FieldCharDomain.
In Odoo 8.0, this widget is available at two places:
- mass_mailing: Marketing > Mass Mailing | Mass Mailing > (any
newsletter) > "See selection".
- gamification: Settings > Gamification Tools > Challenge > (any
challenge) > "See selection".
With this fix the "Selected records" view display selected records.
closes#6463
opw-633201
The Tax Report printed with details should not include draft accounting entries.
Technicaly, the account move lines include in a draft account move do not have to be
printed
opw:633642
The product margin computed on each line of a sale order must be
rounded according to the currency of the order pricelist.
Inspired from the field 'price_subtotal' in addons/sale/sale.py
Previously, we could unpublish an employee from the website, but there
was no simple way to publish it again after we leave the page.
This fix show the unpublished employees on the about us page for the
users who can modify these employees records.
closes#6416
opw-633462
The `tax_amount` of move lines is by default set to `0.0`.
Nevertheless, this default value is set by Odoo,
not by postgresql.
This is therefore likely that the `tax_amount` is set as
null instead of 0.0, in database.
Therefore, when getting this value directly with a SQL
request, this is possible that `null` will be returned.
Therefore, in this specific case, `res.get(record.id, 0.0`
could return `False`, if the sum of `tax_amount` is `null`,
and try to multiply a boolean with an integer is not possible:
`_rec_get(rec) * rec.sign`
opw-633903
Mathieu Le Marec - Pasquet
Anthony Muschang
Goffin Simon
Nicolas Lempereur
Denis Ledoux
Martin Trigaux
dufresnedavid
Xavier Morel
Sylvain GARANCHER
Nedas Žilinskas
Alexandre Laidin
Olivier Dony
Nicolas Martinelli
Jeremy Kersten
Alejandro Santana
Mohammad Alhashash
Sylvain Calador
Christophe Matthieu
Laurent Destailleur
Guewen Baconnier
Christophe Simonis