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
Commit 81364790b9 added default values for all fields present
in the view to emulate. However some fields present in the view are not stored and should
not be sent to create. This bug appears with function field in new API that are not stored.
Using the Yaml import generated warning, for example for fields like alias_domain that is
a not stored computed field.
"I felt a great disturbance in the Force, as if millions of voices
suddenly cried out in terror and were suddenly silenced. I fear
something terrible has happened."
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
This commit would makes us very vulnerable to spams and malevolent
bots who would forge e-mails to force the creation of a res_partner
for each e-mail, quickly overloading the database. I'm reverting
this as it was requested by al.
After discussion with yti, the original issue was that to use the
mail thread on the hr application, the user needed to create a
res_partner just to send him a mail, even if he was refused.
A proposed solution would be to add the e-mail of the applicant
to the suggested recipients of the mail thread.
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.
Frédéric van der Essen