For large lists of blocked emails, the time taken to load the records in
cache becomes prohibitive. For instance on a sample blocklist of 600k
entries, the `search([])` to load them could take 80-90s to run!
And this toll is taken every time the mail composer processes an email
batch in mass-mailing mode. Technically, most of the time is spent
iterating on the list of ids many time, in order to prefetch fields
into cache by determining what's missing.
Loading the contents of the list in raw SQL takes a fraction of that
time (400ms vs 90s).
Subsequently using a set for lookups in that blocklist is also much
faster (average time complexity O(1) vs O(n)).
Example: looking up an item in a 600k-entry blocklist is easily 5
orders of magnitude faster!
```
In [1]: blocklist = set(x[0] for x in self._cr.fetchall())
In [2]: len(blocklist)
Out[2]: 634610
In [3]: self._cr.execute("SELECT email from mail_blacklist")
In [4]: blocklist = set(x[0] for x in self._cr.fetchall())
In [5]: %timeit "hello@hello.com" in blocklist
The slowest run took 35.29 times longer than the fastest. This could mean that an intermediate result is being cached.
10000000 loops, best of 3: 31.6 ns per loop
In [6]: self._cr.execute("SELECT email from mail_blacklist")
In [7]: blocklist = [x[0] for x in self._cr.fetchall()]
In [8]: %timeit "hello@hello.com" in blocklist
100 loops, best of 3: 2.24 ms per loop
```
closesodoo/odoo#57129
X-original-commit: 3b9a85754f30f0bef508d0b576ff679c87ead5da
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Using a `set` to lookup recipients that already received an email is
much faster on average than with a list. `x in list` is O(n) on
average, whereas `x in set` closer to O(1) on average.
Example: for a sample mailing with 50k recipients that is half-through,
filtering the remaining half (25k) took 10s with a list, and 1s with
the set.
X-original-commit: 7948698cc6e6b0af5fc84847ea7ec166882eda0b
tracked
On production order view, dot not show the Serial Numbers column
when in draft or when no component tracked by serial number
closesodoo/odoo#56889
X-original-commit: 4fc8374ee4470a05b27216999e341418e72f28ea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When pos_hr is installed but not checked in the current pos.config,
the close button was not showing for non admin users.
closesodoo/odoo#57141
X-original-commit: ead7e3b801d4f7dcb2d48cf308e405d643dc5368
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Incorrect override of message_post.
Without this decorator, message_post returns a string `mail.message(ID,)` via
RPC. Discuss needs the message ID to scroll chat window
closesodoo/odoo#57123
X-original-commit: 3939d3aa3b60e0f606a9f7defd695417f7b3f383
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Automatically load messages from a thread cache only if the thread cache is used
in at least one thread view.
Ensure thread viewer don't keep thread view records alive when they are not
displayed.
This change is particularly important for performance, to avoid spamming RPC at
init if many threads are opened in chat windows.
task-2310623
closesodoo/odoo#57121
X-original-commit: 8d3413ff647de8d98c6858062dd07dde4160af95
Related: odoo/enterprise#12979
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When a user is accessing a work order in state ready, we are updating it and
rewriting date_planned_start field. We also update accordingly the associated
slot of the workcenter calendar (leave_id), but if the ressource of this slot
is linked to another user, a record rule on resource.calendar.leaves is preventing
the update, which should occur without error, even if the user does not have
Time Off / All Approver rights.
closesodoo/odoo#57120
X-original-commit: 790fb1820fbd49d07206963077216cc304ed2b0a
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Initial rendering of order management screen shows the list of orders
based on the previous render. This is done so that during fetching of
new orders from the server, a list of orders are already shown.
This optimization causes a random runbot error when transferring an
order from one table to the other. The moment the order management
screen is open, it will render orders with the old table, but right
after fetching of orders, the listed orders are immediately updated.
To rectify the random error, we modify the test so that instead of
immediately clicking the transferred order, we wait for its new table
to show before selecting it.
closesodoo/odoo#57104
X-original-commit: 713dd3777ca0ce9d121d5162a3d63de3237509f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Before this commit, the ListRenderer's on_attach_callback hook was
called each time the view was reloaded, even though the renderer
was already in the DOM. As a consequence, sub components were
mounted several times, which could lead to issues.
For instance, go to Inventory > Operations > Transfers, create a
new one. Change the Operation Type to a Receipt, and change again
to a Delivery: it crashed.
Task 2315149
Closes#56701closesodoo/odoo#57101
X-original-commit: 78f361fb5382e4c7aed9a4e705e20f8d8757300d
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In multi-company configuration setup, Company A and Company B.
Have a project in Company A that I want to share with a user in
Company B. The user only has access to Company B.
Share using the project link and open using the user
Traceback error will raise.
Adding a default value to retrieve in case the filter option is used
but the user has no permissions on the records.
opw-2322236
closesodoo/odoo#57090
X-original-commit: bcb62e8f6e20bccc2f2350bdc1268c495b7103da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The register payment wizard for invoices is fetching a default account
for the partner in a compute, without verifying the company.
This can cause the wizard to load an bank account from another company
and block the user to finish the payment.
This commit will make sure the account loaded is from the current company.
Task id #2308032closesodoo/odoo#57072
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
These tests assert that some user interactions didn't do something.
The user interactions were mistakenly expecting to trigger some
re-render.
Task-2333810
closesodoo/odoo#57091
X-original-commit: b4c4086104d815442ff6f2e92f80513f2ffad5ab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Have a default db in US (date format mm/dd/yyy)
Change the user lang in UK (date format dd/mm/yyyy)
Go to POS, make a sale.
On the receipt screen, the receipt footer will display the date with the
US date format.
opw-2325382
closesodoo/odoo#57060
X-original-commit: 65e15d6baed602ee026825c7331d565688c4aecd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The method action_validate_invoice_payment() has been removed from the base
model but is still overriden in the payment module.
This commit will remove the override.
Task id #2285897closesodoo/odoo#56278
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The only reason the customer facing display was a field was that the
customers were able to modify it. As this feature is has been removed,
we can turn it into a Qweb template.
We also remove customer_facing_display.scss as it wasn't used anymore
Before this commit, when being in a form view without active field
(the field is defined on the model, but not present in the view),
the action "Unarchive" was available in the Actions menu, even
though the record was actually active.
The issue has been introduced by [1]. This commit restores the
previous behavior: when the active field isn't in the view, the
Archive/Unarchive action isn't available in the Actions menu.
[1] 220eb4db39closesodoo/odoo#57041
X-original-commit: 97b70aab69b491443d862847fbff69c4e29274af
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The return value of `send_printing_job` was not correcty formated for
the ePOS printers so the POS showed an error even though the receipt
was correctly printed.
closesodoo/odoo#57051
X-original-commit: 827c8d0b257d027504df1acf469d6c4761603550
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
It was only possible to print the tip receipts through an IoT Box.
If no IoT Box is configured, we now show the browser's dialog.
X-original-commit: 4b48109bb414b4768712d0e5d8706fd0088bef4b
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
When we make a request to /hw_proxy/sanner there are a timeout of 7,5 sec
After this timeout we wait for 5 sec before send another request.
And we clean the queue of barcode in IoT Box after 5 sec.
So if a cashier scan a product between this "gap" the product is not added to the POS
With this commit we remove the delay before send another request.
closesodoo/odoo#57019
X-original-commit: 13367ebd673c6941c8e06d99f2b66ca535ab4b3b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closesodoo/odoo#56995
X-original-commit: c121a246f16899735306266a3a12b526e08e7620
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When we are creating invoices from a pos order, we should be able to
extend the values used to create the invoices, when you have custom
fields or module extention.
This was possible in versio 13.0 and accidentally removed in the
following commit.
closesodoo/odoo#57023
X-original-commit: 352ee90eb2a26aff8454846f6db719fbaae0ebd7
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The helper message has been changed in the following menus:
-My reports
-Expense Reports To Approve
-All Expense Reports
-Expenses Analysis
Task-2320205
closesodoo/odoo#56989
Related: odoo/enterprise#12913
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Clean view definitions and coherency
SPECIFICATIONS
Remove dead code and files.
Remove duplicate fields in tree views
Remove duplicate field in kanban views, especially when dealing with
preface / templates sections.
Enforce currency presence for monetary widgets and fields.
Use existing state values for state-based conditions in views
More details in sub commits. Heuristics used to detect those issues will land
in master as this merge targets a stable version.
LINKS
Task ID-2329114
PR odoo/odoo#56946
PR odoo/enterprise#12893closesodoo/odoo#56996
Forward-port-of: odoo/odoo#56946
Related: odoo/enterprise#12917
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Various attributes use state field to control display of nodes: like the
'states' (visibility), statusbar_visible (available status in status bar).
In this commit we fix various incorrect state values as those are either
typos, either references to dead or removed status.
An heuristic to detect invalid state for conditions will land soon in master.
As this commit targets a stable version only view fixes are provided.
Task ID-2329114
PR odoo/odoo#56946
X-original-commit: b4e1e9f3ae86e6b5e7015c0241791f733ee942f4
When a field is specified as widget="monetary" it makes sense to have the
currency actually shows. It won't happen if currency field is not present
within the view.
An heuristic to detect missing currency field presence when using monetary
fields or monetary widget tag will land soon in master. As this commit targets
a stable version only view fixes are provided.
Task ID-2329114
PR #56946
X-original-commit: 9c1c848ad1e8fef11320e2a162b008de7e304bcb
Remove duplicate fields in tree views / kanban (outside of templates).
A field should not be present twice in a kanban view. If one of the nodes
has custom attributes behavior of other nodes is somehow unpredicatable.
Having field present only once gives a more coherent behavior. Xpaths
could also lead to weird results if fields are present several times.
Notably adding a field in the view preface instead of inside the view
template itself (see b63043e for example of fix).
An heuristic to detect duplicate fields will land soon in master. As this
commit targets a stable version only view fixes are provided.
Task ID-2329114
PR odoo/odoo#56946
X-original-commit: 90f8e9255fa46c408763346ed135d9e561ae7fd5
Remove duplicate fields in tree views / kanban (outside of templates).
A field should not be present twice in a tree view. If one of the nodes has
custom attributes then behavior of other nodes is somehow unpredictable.
Having field present only once gives a more coherent behavior. Xpaths
could also lead to weird results if fields are present several times as
developers generally do not expect fields to be present several times in a
view.
An heuristic to detect duplicate fields will land soon in master. As this
commit targets a stable version only view fixes are provided.
Task ID-2329114
PR odoo/odoo#56946
X-original-commit: 977c2b9d12419fba3bada1ebefcca15f051ca565
Before this commit, the end users were unable to click on the
kanban image to see document's preview.
To fix this we removed lines from a previous fix which is no
longer useful in 13.0 because we now use kanban views for
many2X fields instead of list views.
See original commit:
https://github.com/odoo/odoo/commit/26c62cbb4401bffb72ce77fee481ca84b77a8143
So for mobile phones it's working fine.
For iPads, this rule is no longuer necessary since iPadOS.
See "Accelerated Scrolling on iOS and iPadOS":
https://webkit.org/blog/9674/new-webkit-features-in-safari-13/
For previous versions it still works because the DOM has changed.
Steps to reproduce:
- Go to Document
- Click on "o_kanban_image"
=> Your're stuck on a grayed page.
opw-2260101
closesodoo/odoo#56977
X-original-commit: 0d41d0daa7220a791bc4df85cca4100e3634e432
Related: odoo/enterprise#12907
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes the reminder button classes to enable/disable the right ones
as it's being clicked.
(We also fix a css rule for event colors).
Task ID 2325327
X-Original-commit 58917df45d93cd9787036582e6f745901996166c
closesodoo/odoo#56988
X-original-commit: 0c78735ba82553da2633feb48901ed8d0043c049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
- Go to Contacts > Configuration > Country Group
- Open Europe
United Kingdom is still in the group, but should not.
opw-2328125
closesodoo/odoo#56987
X-original-commit: e43c35d3c95c58d6d6af424d4eebf8244c83f332
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Currently, 200+ country flags are stored in ALL db's as ir_attachment's (thus in the filestore), and also duplicated at each backup, ...
To reduce the footprint of Odoo databases (and their backups), the country flags are now considered as static images and accessed as such, without storing their references in database.
##### New widget for static image URL's
A new `image_url` widget is added (frontend & backend), to allow specification of a static URL in Char fields, enabling the access and display of `res.country` flags through their static urls : `/base/static/img/country_flags/<country_code>.png`.
##### Restriction of countries creation & deletion
To ensure no inconsistency can be introduced because the flags are now static, we now restrict the creation and deletion of countries.
Countries are nearly static data, they shouldn't ever be deleted... This prevents common database inconsistencies, bugs and feature disabling.
Manually created countries can easily be wrongly configured, won't behave as expected and/or will crash with Odoo integration (delivery carriers, taxes, VAT validation/formatting).
Therefore, creation/deletion of countries is limited to admins, supposed to know what they are doing...
Will probably be backported in V14
LINKS
Task ID-2325371
COM PR odoo/odoo#52774
UPG PR odoo/upgrade#1338
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The modification of countries data should be restricted to knowledgeable users.
Indeed, by modifying, deleting and/or creating res.country records, the resulting
behavior generally won't be what you expect, breaking existing flows (delivery, taxes, VAT validation, ...)
in an open OR hidden way...
By restricting those modifications, we reduce the risks of users breaking their database through
'minor' changes unexpectingly triggering 'heavy' problems.
Martin Trigaux