Public users (website visitors) do not need to be part of
a livechat channel to talk with the operator, they are using
a dedicated mechanism.
Explicitly including them is redundant and bloats the database.
The GeventServer process was not enforcing the
configured memory limits. In the unlikely event
of a service handling hundreds of concurrent
longpolling requests on hundreds of different
databases, this could render the Registry LRU
ineffective in keeping a low memory footprint.
Even after being evicted from the LRU, these
hundreds of registries would still be referenced
by their in-progress requests, so the memory
would not be freed. An Odoo 10 registry can
typically take 15MB of memory, so this could
become a problem.
By default auto_search is set to `True` on window actions, this mean
that for example on a list or kanban view the records will be searched
on the view opening without any user action needed.
Setting it to `False` disable this.
Doing this had two drawbacks:
- depending on race condition, the view could be displayed before the
search view was loaded,
- the code expected `active_search` to be present which was not the case
in this instance.
Before 151c9074 the second issue would not happen (active_search was set
directly resolved if a search was not to be done) and this commit also
wait for the search view being ready before showing the view.
opw-741186
opw-741546
closes#16805
- Create an article with one supplierinfo (with a delivery delay and a
min. quantity > 0) and a customer delivery delay
- Trigger the creation of a PO by a procurement order for this article
The supplier delivery delay is not taken into account in the date order
of the PO because the seller is not selected.
This is because the procurement quantity is not sent to the seller
selection.
opw-16702
Closes#16702
Steps to reproduce:
1. Create two products A and B that require a serial number
2. Create a product C with no trcking
3. Create a BOM for a A with two components B an C
4. Create a MO for A with qty > 1
5. Check availabiltity and produce the first A
6. Record the SN for the first assembly
Bug: When producing the second assembly, it was not possible to
record the SN for the components.
opw:741316
When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").
Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c429).
opw-705329
closes#16698
Issue: 741582
This bug happens when you click multiple time quickly on 'run scheduler' button
or if you call 'run reordering rules' and then 'run scheduler' rapidly
It could create duplicate PO or MO.
This happens because the run_scheduler function free the lock while it should
not. ProcurementSudo was created with the old cursor that contains the lock and
the record set that search returns also contains this cursor. The run will call the record set with the bad cursor and commit the lock instead of the wanted
behavior.
This commit creates the ProcurementSudo with the new cursor that does not
contains the lock.
- Create 5 PO with 40 lines each for Partner A
- Create an invoice
- Add each PO thanks to the field "Add Purchase Order"
The process takes more and more time for each PO.
Most of the time is spent in the recomputation of the secondary fields
(in the `onchange` method of "models.py"). The root cause is the cache
invalidation due to the relational fields recomputed as superuser by
default.
opw-740485
Before this commit, when the user modified the dashboard, it was not always visible without refreshing the web client
For example, display the current dashboard, then go to another view and add an extra view in the dashboard, then go back to the dashboard.
The reason is that the dashboard layout is actually stored in the arch of a form view, and that arch is cached by the data manager.
This is why each change to the dashboard arch requires that we clear the cache.
OPW 740739
Closes#16691
Since the account is a mandatory field, we raise an clear error is no
account is defined.
This is necessary when running an automatic reconciliation on the POS.
The POS uses a try/except to avoid any error, but in the case of an SQL
error, the cursor is invalidated, so the transaction fails.
opw-741677
In PostgreSQL, a field of type `integer` must be in the range
-2147483648 to +2147483647. If the user enters a lower or a larger
value, a traceback is thrown.
opw-740286
When a invoice line is create a default layout_category_sequence was created
with a value of 0, updating the value of layout_category_id.sequence instead
of fetching it.
This operation was very slow on the invoice creation wizard
opw-741517
- Create a SO of 1000
- Create a down payment of 300, validate
- Create the final invoice
In the partner view, a total of 1600 is displayed as invoiced.
In the case of a down payment, the corresponding invoice line has an
amount with a negative sign. Since the report computes the absolute
value before multiplying by the sign, this information is lost.
The absolute value is not necessary since `price_subtotal_signed`
already includes the correct sign.
opw-741159
The calendar view display records with the start corresponding to the
record field set as `date_start`, and the stop to the record field set
as `date_stop`.
Since ef886aed2 there some issue when mingling calendar with
`date_start` or `date_stop` date fields and `all_day` unset:
- if user had timezone between UTC+8 and UTC+14, when moving as
"All day", the record start would be saved on the previous day.
- if used had timezone between UTC-12 and UTC-5, when moving as
"All day", the record end would get on the following day.
- if the event was moved onto a given time (in the "Day view"), the
event start would be set to the previous day if it was before midnight
in UTC time, and the end would be set on the following day if it was
after UTC 23:59.
The source of the issue was that after ef886aed2 a datetime was always
sent to the server, so depending on the browser timezone the server
could for example receive '2017-04-27 23:00' instead of '2017-04-28'.
This fix go back to the previous behavior.
fixes#15540
opw-15540
closes#16698
In some email templates of Odoo, the From: field is generated from the
company name. If this name contains an "&" character, this will lead in
an escaping eg; &
Sender header will look like:
From: Machin & Brol <machinbrol@toto.com>
This case is not well handled by email providers like Gmail, that
splits the line on the ";" and considers there are 2 senders, and then
discards the email.
We then fix the templates, waiting for a better fix in master.
To reproduce, see issue #16611.
In the mentioned use case, a line with a quantity of zero is created,
which generates a traceback at invoice validation.
Fixes#16611
opw-741055
In function name_get on model "delivery.carrier", the field name
is taken from "product.template" and the translations were just
available on model "product.product".
The translations for the "product.template" records were not available
in the .pot file because there was no external identifiers created for
the "product.template".
Now when creating the external identifier of a record, all the external
identifiers of the inherits models of this record are also created.
In this way, all the translations will be created.
opw:728682
This reverts commit 75d9674d4 and revert well 551719a81e which wass done
on mail.mass_mailing instead of mail.template (on which it should not be
done).
Olivier Dony