*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: calendar, im_livechat, survey.
Following @ged-odoo review, the multi tab service has been improved:
- multi_tab_service.js has been moved to the correct location.
- _callLocalStorage method has been removed and replaced by
getItemFromLocalStorage/setItemToLocalStorage.
- underscore.js calls have been removed.
- multi_tab_service is now using function closure style instead of class.
- multi_tab service is now using its own bus instance.
- service name is now in snake case as per convention.
- tests have been added.
- multi tab service now handles setting/removing/getting values
shared between all the tabs.
closesodoo/odoo#96386
Enterprise: https://github.com/odoo/enterprise/pull/29694
Related: odoo/enterprise#29694
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: calendar, survey.
In order to ease the PR introducing websockets in Odoo, introduce
the multi service. Indeed, the cross tab bus won't be necessary
anymore but there will still be a need to elect a main tab: some actions
should only be triggered once. To achieve this, the code electing the main
tab has been split with the one handling the longpolling. The crosstab
bus now relies on the multi tab service to known whether or not the
current tab is the main tab.
task-2053917
closesodoo/odoo#96174
Related: odoo/enterprise#29573
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
on/off are deprecated in favor of addEventListener/removeEventListener.
Calls to the bus service have been updated to reflect those changes.
task-2053917
closesodoo/odoo#96017
Related: odoo/enterprise#29501
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The code handling user presence and the one handling bus notifications
are mixed up. In order to ease the PR introducing the websocket in Odoo
and to clear this mess, the presence service has been introduced.
task-2053917
closesodoo/odoo#95981
Related: odoo/enterprise#29524
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: calendar, iap_mail.
Now that the bus service is a wowl service, we don't need to wait for
the webclient to be ready before using it. Indeed, the services now
have the bus service as a dependency which means it will always be ready
in time. This also showed that the rpc service was missing as a bus service
dependency. It has been added.
Some part of the code were also checking if the bus service was in
`env.services`. Those calls have been removed as well since we now
have the guarantee that it is.
closesodoo/odoo#96002
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit make messaging service available in the frontend and in
the livechat external lib bundle.
This is preparation to refactoring JS livechat to use models and OWL.
*: bus, mail, survey, web, website_livechat
Task-2870899
closesodoo/odoo#92786
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In fixing leftover jammy warnings in #92078 I mistakenly updated the
setting of `_daemonic` to the public `daemon`, missing that it was a
dedicated and explicit workaround for Python's checks (cf
d03b4f8675).
closesodoo/odoo#92255
X-original-commit: e35a4d87578a588e33f604638289ca7e7ee02029
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Python 3.10 formally deprecated the old threading API. This was missed
in #88803.
Also apply a few other fixes and improvements:
- `Thread._daemonic` is a non-public unchecked internal attribute, use
the corresponding documented property
- remove unused assignment to unused local
- define `Event` attribute in `__init__` where it belongs
- cleanup spawning on thread to do everything in ctor (permissible
since 3.3)
- fix import to not rely in implicit sub-module imports
closesodoo/odoo#92187
X-original-commit: 87d087ff7d53394dd991099cf7eac37d1ef68423
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit: a notification asking to reload the current window
appeared as soon as the server detected a change in one of the assets
bundles, even on first load.
To fix this problem and make the feature more meaningful, it has been
decided to only notify the client when the server version (not the
bundle version) is outdated (i.e. on database upgrades, when the changes
in the code are actually relevant).
closesodoo/odoo#82032
X-original-commit: a3b5a9d715be6a93c7f2859074b916f3249f97c3
Signed-off-by: Antony Lesuisse <al@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
*: base_address_city, base_address_extended, bus, crm, im_livechat,
l10n_ae_pos, lunch, pos_restaurant_adyen, test_assetsbundle,
test_converter, test_lint.
It is spelled `auto_install`, the `complexity` key is long gone, `qweb`
has been moved to `assets: {'web.assets_qweb': []}`. `js` and `css` are
long gone too, `maintainer` is redundant with `author` which is
"Odoo S.A." by default already, the `certificate` key is long gone.
closesodoo/odoo#80988
Related: odoo/enterprise#22766
Signed-off-by: Julien Castiaux <juc@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Move user unique index back in bus module so that it is defined even
without mail module installed.
closesodoo/odoo#76454
X-original-commit: beb25dff5af816fa30341490374c9da44da175c1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit prepares the ground for the collaborative feature.
Before this commit, it was impossible to have different channels for
each tabs. In collaboration, multiples tabs could listen to differents set
of channels.
Example:
One tab X could be subscribed to channel [a, b] and tab Y on channel
[a, b] and a tab Z on [a, c].
Before this commit, only the channels of the master tab were
listened. So in this case it was either [a, b] or [a, c] depending on
which tab is the master.
So either channel b or channel c were not listened depending on which tab
is the master.
Now, each time a tab listens or stops listens to a channel, the
master tab listen all channels for all tabs.
task-2497931
odoo pr: 75768
Part-of: odoo/odoo#75768
Previously, when killing the server, the longpolling bus stopped but
didn't start polling again after a few seconds, this was caused by the
fact that ConnectionLostError wasn't treated like a legacy error and
remapped to an object with a message, meaning it didn't trigger
guardedCatch callbacks.
Since ConnectionLostErrors should be handled much the same way as
RPCError when interacting with legacy code this commit simply adds
ConnectionLostError in the same places we already have RPCError during
error handling of legacy errors, but delegates behaviour to the new
lostConnectionHandler when appropriate.
closesodoo/odoo#74530
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
A number of functions from `web.test_utils` have been deprecated at
the module root and should be called through submodules.
Fix a bunch of remaining cases. Also add a few missing `await`s on
`triggerMouseEvent` calls. Don't bother rewriting the imports in
unpacking style as for most updating the imports is unnecessary. Do so
for `field_one2many_tests.js` where we have to rewrite the imports
anyway:
* recursively import controlPanel, createView, mock.patch and
mock.unpatch
* remove the aliasing of controlPanel to cpHelpers
Some services are coupled with a Component. Usually the service
handles the state of the system, and the Component displays or uses it.
To enable the communication between the service and the component
while making it private, the services should add themselves their
Component in the relevant registry, with the proper means of communication
passed in props.
This mechanism relies on c1d49d494e0ae3a94b3943186eb6d1ebd7b98a6e
* bus, calendar
This commit changes the notification API and adapts codes that use it
Notification API before:
- create(...): number
- close(id: number, wait?: number)
Notification API now:
- add(...): RemoveCallback
closesodoo-dev/odoo#908
Related: odoo-dev/enterprise#158
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Before this commit, it might happen that, in some situations,
with several tabs opened, the CrossTabBus called the longpolling
route repeatedly, thus slowing down the server, and freezing the
webclient.
The issue was tricky to reproduce. It was a race-condition that
could occur when several tabs performed simultanous calls to
addChannel, while being unloaded or becoming mastertab in the
meantime (e.g. when opening/closing/refreshing several tabs
simultaneously).
This issue has been introduced by [1] which by mistake (probably)
made each tab calling itself the localStorage to update the list
of channels when it was notified that the list of channels in
the localStorage just changed. So if several tabs had a slightly
different list of channels at a given moment (e.g. at startup),
it might happen that they in turn, undo what another tab just
put in the localStorage, and thus produced an infinite loop of
localStorage writes and longpolling request aborts/calls.
The issue could be reproduced with the OCA module [2], which
performs several addChannel at webclient startup.
This commit restores this part of the code as it was initially
written in [3].
Closes#69067
opw~2502799
maybe opw~2451865 as well
[1] https://github.com/odoo/odoo/commit/6448420
[2] https://odoo-community.org/shop/product/web-notify-2670#attr=10773
[3] https://github.com/odoo/odoo/commit/38581f67236377daa767ca2216529a26b8708b00#diff-f6eccad21ae3543606ab8f97b8b097d015412caeaee2bf8cc928eb3ccabac9f5R149closesodoo/odoo#69777
X-original-commit: a52aa41d04330efb81090409ec7fbcbbedaca317
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Bus holds tests about bus notifications sent when changing bundles. Currently
it checks that exactly 4 notifications are sent during the test, being of
type ``bundle_changed``. However if other notifications are sent during
``bundle_changed_notification`` tour test fails even if notifications are
not linked to bundle events at all.
In this commit we fix this test by checking that we have 4 ``bundle_changed``
notifications sent during the tour. Other notifications are ignored for that
specific test.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
/longpolling/poll requests are most often requests to Odoo. Moreover,
such requests may be sent at the same moment from all users. For
example, when all users are subscribed to a common channel and someone
sent a message, all current polls are closed to deliver the notification
and after that, all clients start the request again.
If some users have several clients open (e.g. on desktop and mobile),
they may send many parallel requests and hence make concurrent queries
to update presence. We don't need be sure that every such query is
processed. So, just fail fast and carry on polling.
To test perfomance impact of this commit, copy curl command for poll request
from browser network tool and repeatly execute it, e.g.,
```
for i in {1..1000}
do
sleep 0.1
curl ... &
done
```
Without this commit you may notice such warnings in the logs:
```
... odoo.service.model: SERIALIZATION_FAILURE, retry 1/5 in 0.2071 sec...
```
At that moment, try to make normal odoo operations (e.g. create a sale
order): it would work slower than usual.
---
opw-2451865
close#57067closesodoo/odoo#67390closesodoo/odoo#67440
X-original-commit: aad9cbe80dae28c0869fe6f543fbe0118357ce57
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Start odoo in threading mode with bus installed. Login in the browser
using any internal user. Make sure the browser call the
/longpolling/poll uri. While the browser is waiting for a response, stop
the server. The server takes up to 50 seconds to stop.
When started in threading mode, a request to /longpolling/poll is served
by a casual http thread. It searches for messages enqueued in the bus
and returns them. If there are no message for the user in the queue yet,
it creates a `threading.Event`, attach it to the user in a shared
dictionnary and `wait()` on it with a timeout of 50 seconds (hardcoded
value). When the bus thread (the one responsible to listen on the
database) receives new messages, it `set()` the events which resume any
http thread that was waiting.
Because when we stop the server, there is no way to server new requests,
there are no way new messages arrive in the bus. All the threads that
were waiting for a new message will just wait until the event timeouts
which slow down the shutdown of the server.
Now we actively `set()` all events in order to resume all those workers
when we stop the server.
The `ImDispatch.poll` signature has been changed too so it is possible
to change (via code) the hardcoded default. The function was using the
object referenced by `TIMEOUT` at the time the function was defined,
using `timeout None` then `if None: timeout=TIMEOUT` ensures we lookup
the variable.
closesodoo/odoo#64530
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
When trying to get the im_status of several partners, if one of them
does not exist, it will return an error.
To reproduce the error:
1. Go to Contacts
2. Open a contact
3. Action > Delete
4. Wait max 50 seconds
=> A Missing Record message is displayed. The im_status RPC includes the
deleted partner's identifier and the server looks for it.
Now, the server skips the missing identifiers.
OPW-2390719
closesodoo/odoo#63198
X-original-commit: a35c65032fc5ed1371957c362921bf5fa30062ff
Signed-off-by: adwid <adwid@users.noreply.github.com>
PURPOSE
Discuss notification needs to be changed for better UI.
SPECIFICATION
Improving design of discuss notification by using bg-info instead of bg-warning.
LINKS
PR https://github.com/odoo/odoo/pull/55542
Task-2308799
closesodoo/odoo#55542
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, archived and deleted partners had not their
im_status being updated automatically. There were some issues
with this, notably:
- odoobot 'bot' status was not displayed in chatter
- im_status of partners becoming archived were not updated.
This commit fixes both issues.
task-2329591
closesodoo/odoo#60567
X-original-commit: 63b081c49da089c839479b807de8c0cea45221da
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Use case:
When the server is restarted, the python is updated,
but some users may have an ongoing session in a browser tab
This may lead to code being unsynchronized and ultimately to some
odd bugs.
Purpose:
When we are in such a case, that is, the assets were recomputed
after a update of the code and a restart of the server by the request of another user,
notify connected users that assets have changed.
Then propose them to reload the page.
Known caveats:
- This is not a developer's feature.
Since assets computing is ORM cached, they have limited
opportunities to rebuild. Namely, the feature won't trigger
each time the JS has changed, rather, it will
when JS has changed AND the cache has been reset somehow (e.g. when the server is restarted).
- This not a portal/website feature either, but only in backend.
Business clients won't be notified that the JS has changed.
- While requests debug=assets do trigger a recomputing
of the *components* of bundles, they do not save a bundle
This means that the requests that sends the notification
cannot be debug=assets.
Task 2034462
closesodoo/odoo#39875
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
*bus,mail
This commit extracts the common basis of the env to use both in
the frontend and the backend. The public env now contains most of
the features that were previously (only) in the webclient env.
Moreover, the PublicRoot no longer uses the ServiceProviderMixin,
such that services are only deployed once, in the (public) env.
Owl components can now be defined in the website, and rely on a
properly built env. Legacy widgets still works as they access
services through the PublicRoot (via trigger_up) which redirects
those requests to the env.
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
Before this commit, the Notification is used but in Chrome Mobile
we can't use it outside a ServiceWorker.
After this commit, if the Notification Object produce
an error it will fallback to the old method do_notify()
Steps to reproduce:
* Open a Odoo instance with Chrome Mobile (e.g. with Demo user)
* In Chrome Mobile, accept to receive the "Native Browser Notification"
* Put Chrome Mobile in the background of Android (don't close it)
* Open another instance of the same Odoo somewhere else with another user (e.g. Admin)
* From Admin, send a direct message to Demo
* Resume Chrome Mobile to the foreground the you will see the traceback (BUG)
GitHub issue: odoo/odoo#34714
Ref:
https://bugs.chromium.org/p/chromium/issues/detail?id=481856closesodoo/odoo#51474
X-original-commit: ebe6731c583f9f4125272af3d8bdc4625e06de7c
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Fix regression introduced with e0ed7b12ca
Issue without current commit:
When doing `abort` next updates from the bus are only received after the normal
timeout, which makes the interface unresponsive to updates during that amount of
time.
`abort` is for example called during `addChannel`, where it is specifically
documented that new updates are to be received immediately.
closesodoo/odoo#49355
X-original-commit: 888610e5e07794e000ef27edcb075cb45c1e2ccc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
tsm-odoo